Lecture 8: Decision Tables . Documents resolving later negotiation - PowerPoint PPT Presentation

Topic Area Requirements Engineering: Content Risks Implied by Bad Requirements Speci � cations VL 6 • Introduction preparation of tests , • Requirements Specification • without a description of allowed outcomes, tests are design and implementation , • Desired Properties randomly searching for generic errors (like crashes) Softwaretechnik / Software-Engineering • without specification, � systematic testing hardly possible • Kinds of Requirements programmers may just “ask around” when in doubt, possibly • Analysis Techniques yielding different interpretations acceptance by . � difficult integration . customer, Lecture 8: Decision Tables . • Documents resolving later negotiation objections or regress • Dictionary, Specification (with customer, require- claims, marketing ments design / design / quality quality negotiation negotiation speci- acceptance acceptance • Specification Languages implemen- implemen- assurance assurance fication tation tation • without specification, it department, or is unclear at delivery ...) • Natural Language time whether behaviour 2018-05-28 customer developer is an error (developer docu- docu- • Decision Tables needs to fix) or correct VL 7 mentation mentation (customer needs to • Syntax, Semantics . accept and pay) � . re-use re-use nasty disputes , . • Completeness, Consistency, ... additional effort documentation , e.g., the user’s manual , Prof. Dr. Andreas Podelski, Dr. Bernd Westphal • Scenarios VL 8 • without specification, the user’s manual author can only re-use , . • User Stories, Use Cases describe what the system does , not what it should do . . ( “every observation is a feature” ) • without specification, re-use needs to be based on • Live Sequence Charts – 6 – 2018-05-07 – Sreintro – Albert-Ludwigs-Universität Freiburg, Germany – 8 – 2018-05-28 – Sblockcontent – re-reading the code � risk of unexpected changes VL 9 • later re-implementations . • Syntax, Semantics . – 8 – 2018-05-28 – main – – 8 – 2018-05-28 – main – . • the new software may need to adhere to requirements of the old software; if not properly specified, . • Definition: Software & SW Specification the new software needs to be a 1:1 re-implementation of the old � additional effort 6 /42 VL 10 . . • Wrap-Up . 2 /48 3 /48 Content Requirements on Requirements Speci � cations Structure of Topic Areas • (Basic) Decision Tables A requirements specification should be Example : Requirements Engineering • Syntax, Semantics • correct • neutral , abstract • ...for Requirements Specification — it correctly represents the wishes/needs of — a requirements specification does not the customer, constrain the realisation more than necessary, • ...for Requirements Analysis Vocabulary e.g. consistent, • complete complete, tacit, etc. • Completeness, — all requirements (existing in somebody’s head, or a document, or ...) should be present, • traceable , comprehensible In the course: Techniques • Useless Rules, — the sources of requirements are documented, • relevant • Determinism requirements are uniquely identifiable, Use Cases informal e.g. “Whenever a crash...” — things which are not relevant to the project Logic should not be constrained, Pattern Language e.g. “Always, if h crash i at t ...” • Domain Modelling • consistent , free of contradictions • testable , objective — each requirement is compatible with all other — the final product can objectively be checked • Conflict Axiom, semi-formal requirements; otherwise the requirements are for satisfying a requirement. • Relative Completeness, not realisable , • Vacuous Rules, Decision Tables e.g. “ � t, t � � Time • ...” formal • Correctness and completeness are defined relative to something Live Sequence Charts • Conflict Relation which is usually only in the customer’s head . � is is difficult to be sure of correctness and completeness . • Collecting Semantics – 1 – 2018-04-16 – Sccontent – – 6 – 2018-05-07 – Sre – • “Dear customer, please tell me what is in your head!” is in almost all cases not a solution ! – 8 – 2018-05-28 – Scontent07 – • Discussion – 8 – 2018-05-28 – main – It’s not unusual that even the customer does not precisely know...! – 8 – 2018-05-28 – main – For example, the customer may not be aware of contradictions due to technical limitations. 14 /42 28 /45 4 /48 5 /48 6 /48

Decision Table Syntax Decision Table Semantics • Let C be a set of conditions and A be a set of actions s.t. C � A = � . Each rule r � { r 1 , . . . , r n } of table T • A decision table T over C and A is a labelled ( m + k ) × n matrix T : decision table r 1 · · · r n c 1 description of condition c 1 v 1 , 1 · · · v 1 ,n . . . . ... . . . . T : decision table · · · . . . . r 1 r n c m description of condition c m v m, 1 · · · v m,n Decision Tables c 1 description of condition c 1 v 1 , 1 · · · v 1 ,n a 1 description of action a 1 w 1 , 1 · · · w 1 ,n . . . ... . . . . . . . . . . . . . . . . ... . . . . . c m description of condition c m v m, 1 · · · v m,n a k description of action a k w k, 1 · · · w k,n a 1 description of action a 1 w 1 , 1 · · · w 1 ,n . . . ... . . . . . . . . . is assigned to a propositional logical formula F ( r ) over signature C � � A as follows: description of action a k · · · a k w k, 1 w k,n • Let ( v 1 , . . . , v m ) and ( w 1 , . . . , w k ) be premise and effect of r . • where • c 1 , . . . , c m � C , • v 1 , 1 , . . . , v m,n � { � , × , � } and • Then • a 1 , . . . , a k � A , • w 1 , 1 , . . . , w k,n � { � , ×} . F ( r ) := F ( v 1 , c 1 ) � · · · � F ( v m , c m ) � F ( w 1 , a 1 ) � · · · � F ( w k , a k ) | {z } | {z } =: F pre ( r ) =: F e � ( r ) • Columns ( v 1 ,i , . . . , v m,i , w 1 ,i , . . . , w k,i ) , 1 � i � n , are called rules , where • r 1 , . . . , r n are rule names . – 7 – 2018-05-14 – Scoreet – – 7 – 2018-05-14 – Scoreet – � x , if v = × � • ( v 1 ,i , . . . , v m,i ) is called premise of rule r i , � F ( v, x ) = ¬ x , if v = � – 8 – 2018-05-28 – main – – 8 – 2018-05-28 – main – – 8 – 2018-05-28 – main – ( w 1 ,i , . . . , w k,i ) is called effect of r i . � true , if v = � � 24 /64 25 /64 7 /48 8 /48 9 /48 Yes, And? Decision Table Semantics: Example We can use decision tables to model (describe or prescribe) the behaviour of software ! � x , if v = × Example : F ( r ) := F ( v 1 , c 1 ) � · · · � F ( v m , c m ) � T : room ventilation r 1 r 2 r 3 � F ( v, x ) = ¬ x , if v = � Ventilation system of b button pressed? × × − � F ( v 1 , a 1 ) � · · · � F ( v k , a k ) � true , if v = � � ventilation off? × − ∗ off lecture hall 101-0-026. on ventilation on? − × ∗ go start ventilation × − − Decision Tables as Requirements Specification stop stop ventilation − × − T r 1 r 2 r 3 c 1 × × � • We can observe whether button is pressed and whether room ventilation is on or off , c 2 × � � c 3 � × � and whether (we intend to) start ventilation of stop ventilation . a 1 × � � • We can model our observation by a boolean valuation σ : C ∪ A → B , e.g., set a 2 � × � σ ( b ) := true , if button pressed now and σ ( b ) := false , if button not pressed now . • F ( r 1 ) = c 1 � c 2 � ¬ c 3 � a 1 � ¬ a 2 σ ( go ) := true , we plan to start ventilation and σ ( go ) := false , we plan to stop ventilation . • A valuation σ : C ∪ A → B can be used to assign a truth value to a propositional formula ϕ over C ∪ A . • F ( r 2 ) = c 1 � ¬ c 2 � c 3 � ¬ a 1 � a 2 As usual, we write σ | = ϕ iff ϕ evaluates to true under σ (and σ �| = ϕ otherwise). • F ( r 3 ) = ¬ c 1 � true � true � ¬ a 1 � ¬ a 2 • Rule formulae F ( r ) are propositional formulae over C ∪ A – 7 – 2018-05-14 – Scoreet – thus, given σ , we have either σ | = F ( r ) or σ �| = F ( r ) . – 8 – 2018-05-28 – Setasspec – – 8 – 2018-05-28 – main – – 8 – 2018-05-28 – main – • Let σ be a model of an observation of C and A . 26 /64 We say, σ is allowed by decision table T if and only if there exists a rule r in T such that σ | = F ( r ) . 10 /48 11 /48 12 /48