Home

Requirements Engineering - Software Engineering

Contents

1. 05 2015 05 11 main Softwaretechnik Software Engineering Lecture 05 Requirements Engineering 2015 05 11 Prof Dr Andreas Podelski Dr Bernd Westphal Albert Ludwigs Universitat Freiburg Germany 2 90 You Are Here ulew LES Side S0 05 2015 05 11 main Course Content Original Plan Tr ee ee rr w e ON 0NnNR AR Fr rr ER L11 L12 L13 T 5 L14 L15 L16 T 6 L17 L18 r 20 4 23 4 27 4 30 4 4 5 7 5 11 5 14 5 18 5 21 5 25 5 28 5 1 6 4 6 8 6 11 6 15 6 18 6 22 6 25 6 29 6 2 1 6 7 9 7 13 7 16 7 20 7 2313 Mo Do Mo Do Mo Do Mo Do Mo Do Mo Do Mo Do Mo Do Mo Do Mo Do Mo Do Mo Do Mo Do Mo Do 3 90 05 2015 05 11 Sprelim Contents amp Goals Last Lecture e process models V Modell XT agile XP Scrum process metrics CMMI SPICE This Lecture e Educational Objectives Capabilities for following tasks questions e What is requirements engineering RE e Why is it important why is it hard e What are the two three most relevant artefacts produced by RE activities e What is a dictionary e What are desired properties of requirements specification documents e What are hard soft open tacit functional non functional requirements e What is requirements elicitation e Which analysis technique would you recommend
2. 2015 05 11 Setprop Determinism Example un ct jb y lt oO gt cH D ae O E x stop stop ventilation e is non determistic 05 2015 05 11 Setprop 65 90 Determinism Example un ct jb y lt oO gt cH D ae O E x stop stop ventilation e is non determistic In a state with b both rules are enabled 05 2015 05 11 Setprop 65 90 05 2015 05 11 Setprop Determinism Example button pressed x x slop stop ventilation un ct jb y lt oO gt cH mM ae O E x e is non determistic In a state with b both rules are enabled e Is non determinism a bad thing in general 65 90 05 2015 05 11 Setprop Determinism Example T room ventilation ri ra rs LT ao start ventilation RT stop stop ventilation x e is non determistic In a state with o b both rules are enabled e Is non determinism a bad thing in general e Just the opposite one of the most powerful modelling tools we have e Read table T as e under certain conditions which will specify later the button may switch the ventilation on and e under certain conditions which will specify later the button may switch the ventilation off e This is quite some less chaos than full chaos e We can already analyse the specification
3. Set And Where s The Table Decision tables can be written in tabular form o button pressed x x off venation gt on ventilation on Coo start ventilation gt stop stop ventilation 52 90 05 2015 05 11 Set And Where s The Table Decision tables can be written in tabular form T room ventilation ri re o button pressed x gt off ventilation off A on ventilation on go start ventilation x stop stop ventilation x From the table to the rules e ri bA on off gt go e r2z bAzon A off gt stop 52 90 05 2015 05 11 Set And Where s The Table Decision tables can be written in tabular form T room ventilation la Je b button pressed x x off ventilation off Tx on ventilation on x go start ventilation fox f a stop ventilation f fx From the table to the rules e ri bA on off gt go e r2z bAzon A off gt stop 52 90 05 2015 05 11 Set And Where s The Table Decision tables can be written in tabular form T room ventilation a Je b button pressed x x off ventilation off Tx on ventilation on x go start ventilation fox f a stop ventilation f fx From the table to the rules e ri bA on off gt go e rg bA 70n A off gt s
4. re use e re use based on re reading the code gt risk of unexpected changes later re implementations e the new software may need to adhere to requirements of the old software if not properly specified the new software needs to be a 1 1 re implementation of the old additional effort 10 90 And What s Hard About That 05 2015 05 11 Sreintro 11 90 Once Again The Software Peoples View on Requirements 05 2015 05 11 Sreintro 12 90 Once Again The Software Peoples View on Requirements Example children s birthday present requirements birthday on May 27th e Ich will n Pony I want a pony e Common sense understanding 05 2015 05 11 Sreintro 12 90 Once Again The Software Peoples View on Requirements Example children s birthday present requirements birthday on May 27th e Ich will n Pony I want a pony e Common sense understanding That is we re looking for one small horse like animal we may guided by economic concerns taste etc choose exact breed size color shape gender age may not even be born today only needs to be alive on birthday 12 90 05 2015 05 11 Sreintro Once Again The Software Peoples View on Requirements Example children s birthday present requirements birthday on May 27th e Ich will n Pony I want a pony e Common se
5. 47 90 Satisfaction of Conditions and Premises e Let Y be a set of states with a satisfaction relation Fo C x C We say o satisfies condition c and write o o c if and only if 0 c Fo otherwise we write oF oy Example useful sets of states for room ventilation model e X C gt 0 1 B a state X is a boolean valuation of conditions o defined by o o c if and only if a c 1 05 2015 05 11 Set 47 90 05 2015 05 11 Set Satisfaction of Conditions and Premises e Let Y be a set of states with a satisfaction relation Fo C x C We say o satisfies condition c and write o o c if and only if 0 c Fo otherwise we write oF oy Example useful sets of states for room ventilation model e Y C gt 0 1 B a state o X is a boolean valuation of conditions o defined by o o c if and only if o c 1 e Ya b V gt BU R o b B button state v V RZ voltage at ventilator o defined by e o Ko b if and only if o b 1 e o Ko on if and only if o V gt 0 7 ventilator rotates e o Ko off if and only if o V lt 0 7 voltage too low for rotation 47 90 05 2015 05 11 Set Satisfaction of Conditions and Premises Let Y be a set of states with a satisfaction relation Fo C x C We say o satisfies condition c and write o o c if and only if 0 c Fo otherwise we write oF oy Example
6. Requirements on Requirements Specifications A requirements specification should be 05 2015 05 11 Sre correct it correctly represents the wishes needs of the customer complete all requirements existing in somebody s head or a document or should be present relevant things which are not relevant to the project should not be constrained consistent free of contradictions each requirement is compatible with all other requirements otherwise the requirements are not realisable 22 90 05 2015 05 11 Sre Requirements on Requirements Specifications A requirements specification should be correct it correctly represents the wishes needs of the customer complete all requirements existing in somebody s head or a document or should be present relevant things which are not relevant to the project should not be constrained consistent free of contradictions each requirement is compatible with all other requirements otherwise the requirements are not realisable neutral abstract a requirements specification does not constrain the realisation more than necessary 22 90 05 2015 05 11 Sre Requirements on Requirements Specifications A requirements specification should be correct it correctly represents the wishes needs of the customer complete all requirements existing in somebody s head or
7. Sponsor Software Engineering Standards Committee of the IEEE Computer Society Approved 25 June 1998 IEEE SA Standards Board Abstract The content and qualities of a good software requirements specification SRS are de scribed and several sample SRS outlines are presented This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selec tion of in house and commercial software products Guidelines for compliance with IEEE EIA 12207 1 1997 are also provided Keywords contract customer prototyping software requirements specification supplier system requirements specifications The Institute of Electrical and Electronics Engineers Inc 345 East 47th Street New York NY 10017 2394 USA Copyright 1998 by the Institute of Electrical and Electronics Engineers Inc All rights reserved Published 1998 Printed in the United States of America ISBN 0 7381 0332 2 No part of this publication may be reproduced in any form in an electronic retrieval system or otherwise without the prior written permission of the publisher 39 90 05 2015 05 11 Sspeclang 1 INTRODUCTION 1 1 Purpose 1 2 Acronyms and Definitions 1 3 References 1 4 User Characteristics 2 FUNCTIONAL REQUIREMENTS 2 1 Function Set 1 2 2 etc 3 REQUIREMENTS TO EXTERNAL INTERFACES 3 1 User Interfaces 3 2 Interfaces to Hardware 3 3 Interfaces to Software Produc
8. e programmers may use different interpretations of unclear requirements gt difficult integration e the user s manual e if the user s manual author is not developer he she can only describe what the system does not what it should do no more bugs every observation is a feature 10 90 05 2015 05 11 Sreintro Purposes of the Requirements Specification e coordination with the customer or the marketing department or e not properly clarified specified requirements are hard to satisfy mismatches with customer s needs turn out in operation the latest additional effort e design and implementation e programmers may use different interpretations of unclear requirements gt difficult integration e the user s manual e if the user s manual author is not developer he she can only describe what the system does not what it should do no more bugs every observation is a feature e preparation of tests e without a description of allowed outcomes tests are randomly searching for generic errors like crashes systematic testing impossible 10 90 05 2015 05 11 Sreintro Purposes of the Requirements Specification e coordination with the customer or the marketing department or e not properly clarified specified requirements are hard to satisfy mismatches with customer s needs turn out in operation the latest additional effort design and implem
9. look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning C Of course A Also on the weekends C No on weekends the entrance stays closed A And during company holidays C Then it also remains closed of course A And if you are ill or on vacation C Then Mr M opens the door A And if Mr M is not available too C Then the first client will knock on the window A Okay Now what exactly does morning mean Ludewig and Lichter 2013 05 2015 05 11 Sre How Can Requirements Engineering Look In Practice Set up a core team for analysis 3 to 4 people include experts from the domain and developers Analysis benefits from highest skills and strong experience During analysis talk to decision makers managers domain experts and users Users can be interviewed by a team of 2 analysts ca 90 min The resulting raw material is sorted and assessed in half or full day workshops in a team of 6 10 people One searches for e g contradictions between customer wishes and for priorisation Note The customer decides Analysts may make proposals different op
10. 00 gt 01 gt 02 e also 74 00 O oo b A off 01 FbA on oi FbA off ic No T2 0 2 0 e but not do Ag O1 oo KE b A on and oo KK b A off oo E bA off go go e and also T3 O00 00 O1 a O2 oo b A off 01 FE bA off shorthands b on off shorthands go stop go LS OF ws go stop 0 50 90 05 2015 05 11 Set Isn t There a Bell Ringing 51 90 Isn t There a Bell Ringing Definition Software is a finite description S of a possibly infinite set S of finite or infinite computation paths of the form Oy A ON OA O where e c Y 1 No is called state or configuration and e a E A i No is called action or event The possibly partial function S gt S is called interpreta tion of S 05 2015 05 11 Set 51 90 Isn t There a Bell Ringing Definition Software is a finite description S of a possibly infinite set S of finite or infinite computation paths of the form Oy A ON OA O where e c Y 1 No is called state or configuration and e a E A i No is called action or event The possibly partial function S gt S is called interpreta tion of S a decision table T is software surprise surprise 05 2015 05 11 Set 51 90 And Where s The Table 05 2015 05 11 Set 52 90 05 2015 05 11
11. 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning C Of course A Also on the weekends C No on weekends the entrance stays closed A And during company holidays C Then it also remains closed of course A And if you are ill or on vacation C Then Mr M opens the door A And if Mr M is not available too C Then the first client will knock on the window 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision
12. all really all or are there exceptions 05 2015 05 11 Sspeclang 35 90 DE Ll AA A AREAS A A USA E E PRA SA R6 R7 R8 R9 05 2015 05 11 Sspeclang QSA Check nominalisations Recognise and refine unclear substantives Clarify responsibilities Identify implicit assumptions ali Peally UniveEtaally Van FATS all really all Url al there exceptions Nouns like registration often hide complex processes that need more detailed descriptions the verb register raises appropriate questions who where for what Is the substantive used as a generic term or does it denote something specific Is user generic or is a member of a specific classes meant If the specification says that something is possible Impossible or may should must happen clarify who is enforcing or prohibiting the behaviour Terms the firewall that are not explained further often hint to implicit assumptions here there seems to be a firewall 30 90 Natural Language Patterns Natural language requirements can be written using A B C D E F where A clarifies when and under what conditions the activity takes place 05 2015 05 11 Sspeclang 37 90 Natural Language Patterns Natural language requirements can be written using A B C D E F where clarifies when and under what conditions the activity ta
13. e A do_ventilate stop_ventilate r b A ventilation_off gt go r2 b A ventilation_on gt stop T roak What s in T interleaving Naja for example g0 stop o 71 00 01 gt 02 oo b A off o1 FbA on To 00 oo E b A on and oo E b A off go go and also T3 O0 00 O1 a O2 oo b A off 01 FE bA off shorthands b on off shorthands go stop 50 90 05 2015 05 11 Set Decision Tables Example Back to lecture hall 101 0 026 s ventilation system e C button_pressed ventilation_on ventilation_off y shorthands b on off e A do_ventilate stop_ventilate shorthands go stop e ri b A ventilation_off gt go r2 b A ventilation_on gt stop T roak What s in T interleaving Naja for example g0 stop g0 g0 o 71 00 01 gt 02 e also 74 09 01 gt 092 oo b A off 01 FbA on oi FbA off ic No e T2 00 oo E b A on and oo E b A off go go e and also T3 O00 00 O1 a O2 oo b A off 01 FE bA off 50 90 05 2015 05 11 Set Decision Tables Example Back to lecture hall 101 0 026 s ventilation system e C button_pressed ventilation_on ventilation_off e A do_ventilate stop_ventilate r b A ventilation_off gt go r2 b A ventilation_on gt stop T roak What s in T interleaving Naja for example g0 stop g0 e 71
14. useful sets of states for room ventilation model 1 C gt 0 1 B a state 1 is a boolean valuation of conditions o defined by o o c if and only if o c 1 Ys b V gt BUR 0 b B button state v V R voltage at ventilator o defined by e o Ko b if and only if o b 1 e o Ko on if and only if o V gt 0 7 ventilator rotates e o Ko off if and only if o V lt 0 7 voltage too low for rotation In other words gt can be whatever you want as long as you explain define how to read out from o gt whether conditions b on off should be considered satisfied in 47 90 Satisfaction of Premises e Given o the usual interpretation of the logical connectives true V induces a satisfaction relation C X x C for premises as follows e o E true for all o 2 e go c if and only if o Ko e o Fc V Cg if and only if o 0 c or O o Ca 05 2015 05 11 Set 48 90 Satisfaction of Premises e Given o the usual interpretation of the logical connectives true V induces a satisfaction relation C X x C for premises as follows e o E true for all o 2 e o c if and only if o Koc e o FC V Co if and only if o Fo cy or o Fo Ca e We call r y gt a over C and A enabled o if and only if o y Note In the following we may use A gt lt gt as abbreviations as usual 05 2015 05 11 S
15. 500 but payment history ok e clerk cashes cheque but offers new conditions 54 90 05 2015 05 11 Set Decision Tables as Software Specification 55 90 Another Bell e T can be viewed as a software specification by setting LE epee 15 ST z lts in words e Any software S whose behaviour is a subset of T s behaviour satisfies the specification T In particular need not have all computation paths of T e The computation paths of T are all allowed for the final product S what is not a computation path of T is forbidden for the final product e The refinement view Any software S which is a refinement of a software S TI spec satisfies the specification T 05 2015 05 11 Set 56 90 05 2015 05 11 main Basic Requirements Quality Criteria for DTs 57 90 Quality Criteria for DTs Uselessness and Vacuity Definition Uselessness and Vacuity Let T be a decision table e A rule r y gt a is called vacuous wrt states 2 if and only if there is no state o 2 such that Of UO e A rule r y gt a is called useless or redundant if and only if there is another rule r whose premise y is subsumed by p and whose effect is the same as r s i e if lt O SS NO r is called subsumed by r 05 2015 05 11 Setprop 58 90 Uselessness Example Example e cA 7c gt Q is vacuous Proposition any
16. Definition Vacuitiy wrt Conflict Axiom A rule r y gt a T over C and A is called vacuous wrt conflict axiom Ycon P C if and only if the premise implies the conflict axiom i e if p gt YPconfr 05 2015 05 11 Setconfl 10 90 05 2015 05 11 Setconfl Conflicting Conditions and Actions Consistency e A conflict axiom for conditions C is a formula Pena P C Definition Vacuitiy wrt Conflict Axiom A rule r y gt a T over C and A is called vacuous wrt conflict axiom Ycon P C if and only if the premise implies the conflict axiom i e if p gt Yeconfr e A conflict relation on actions A is a transitive and symmetric relation 4 C Ax A Definition Consistency Let r y gt a T be a rule i r is called consistent with conflict relation 4 if and only if there are no conflicting actions in a i e if Aa a2 ae 01402 ii T is called consistent if and only if all rules r T are consistent 10 90 Example Conflicting Conditions Actions e Let Yeon on A off A Hon A 0ff on models an opposite of off neither can both be satisfied nor bot non satisfied e Let 4 be the transitive symmetric closure of stops go actions stop and go are not supposed to be executed at the same time e Then b button pressed ventilation off on EMEZ go start ventilation RA stop stop ventilation gt 0 e r IS vacuous wrt Y
17. Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what Is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning C Of course 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entra
18. P 1995 The Mythical Man Month Essays on Software Engineering Anniversary Edition Addison Wesley DIN 2009 Projektmanagement Projektmanagementsysteme DIN 69901 5 Gacitua R Ma L Nuseibeh B Piwek P de Roeck A Rouncefield M Sawyer P Willis A and Yang H 2009 Making tacit requirements explicit talk IEEE 1990 EEE Standard Glossary of Software Engineering Terminology Std 610 12 1990 IEEE 1998 IEEE Recommended Practice for Software Requirements Specifications Std 830 1998 Ludewig J and Lichter H 2013 Software Engineering dpunkt verlag 3 edition Rupp C and die SOPHISTen 2009 Requirements Engineering und Management Hanser 5th edition 90 90
19. and should not need unnecessary effort e easily usable storage of and access to the requirements specification should not need significant effort 05 2015 05 11 Sre 24 90 05 2015 05 11 Sre Requirements on Requirements Specification Documents The representation and form of a requirements specification should be e easily understandable not unnecessarily complicated all affected people are able to understand the requirements specification e precise the requirements specification does not introduce new unclarities or rooms for interpretation testable objective e easily maintainable creating and maintaining the requirements specification should be easy and should not need unnecessary effort e easily usable storage of and access to the requirements specification should not need significant effort Note Once again it s about compromises e A very precise objective requirements specification may not be easily understandable by every affected person provide redundant explanations e It is not easy to have both low maintenance effort and low access effort gt value low access effort higher a requirements specification document is much more often read than changed or written most changes require reading beforehand a 90 05 2015 05 11 Sre Kinds of Requirements 25 90 Kinds of Requirements Hard and Soft Requirements e Example o
20. describing a subset s of chaos e Design Implementation means choosing from the obtained subset s of chaos 13 90 And What s Hard About That Example customer says I need a computation of square numbers i e f x 2 05 2015 05 11 Sreintro 14 90 And What s Hard About That Example customer says I need a computation of square numbers i e f x x e We ve got options to choose from i unsigned int include lt gmp h gt ae EL PE XC a sq unsigned short x void sq mpz_t x return Xx x return x x mpz mul x x x y gt 1h 100 gt 2h 200 4h 400 14 90 05 2015 05 11 Sreintro And What s Hard About That Example customer says I need a computation of square numbers i e f x gt x e We ve got options to choose from i unsigned int include lt gmp h gt e SG PE a sq unsigned short x void sq mpz_t x return xXx x return x x mpz mul x x x i gt 1h 100 gt 2h 200 4h 400 with errors sq Cis 1 1 14 90 05 2015 05 11 Sreintro 05 2015 05 11 Sreintro Example customer says I need a computation of square numbers i e f x x And What s Hard About That e We ve got options to choose from int sq int x return Xx x y gt 1h 100 with errors sq Cis 1 1 unsigned int i
21. stop ventilation e is not complete there is no rule e g for the case b A on A off T room ventilation ara oT x e A A on A A go startventilation gt stop stop ventilation o e is complete 62 90 05 2015 05 11 Setprop e is not complete there is no rule e g for the case b A on A off e is complete Completeness Example T room ventilation ale b button pressed x off ventilation off Sid Ton ventilation on ao start ventilation gt stop stop ventilation T room ventilation r ra else b button pressed EAS ventilation off ox on A 1 ao start ventilation A stop stop ventilation x 62 90 05 2015 05 11 Setprop Incompleteness Consequences e An incomplete decision table may allow too little behaviour it forbids too much e This very incomplete decision table T room ventilation a gt E Cai ES on ao start ventilation x stop stop ventilation e forbids all actions in case b A 0n A off is satisfied e May not be the intention of the customer 63 90 Quality Criteria for DTs Determinism Definition Determinism A decision table T is called deterministic if and only if the premises of all rules are pairwise disjoint 1 e if VOR Ss COR Or at F je H a A ol Otherwise T is called non deterministic 64 90 05
22. 0 05 2015 05 11 Sreintro Requirements and Requirements Analysis requirement 1 A condition or capability needed by a user to solve a problem or achieve an objective 2 A condition or capability that must be met or possessed by a system or system component to satisfy a contract standard specification or other formally imposed documents 3 A documented representation of a condition or capability as in 1 or 2 IEEE 610 12 1990 requirements analysis 1 The process of studying user needs to arrive at a definition of system hardware or software requirements 2 The process of studying and refining system hardware or software re quirements IEEE 610 12 1990 1 90 05 2015 05 11 Sreintro Requirements and Requirements Analysis requirement 1 A condition or capability needed by a user to solve a problem or achieve an objective 2 A condition or capability that must be met or possessed by a system or system component to satisfy a contract standard specification or other formally imposed documents 3 A documented representation of a condition or capability as in 1 or 2 IEEE 610 12 1990 requirements analysis 1 The process of studying user needs to arrive at a definition of system hardware or software requirements 2 The process of studying and refining system hardware or software re quirements IEEE 610 12 1990 1 90 The Requirements
23. Documents of the Requirements Analysis Dictionary e Requirements analysis should be based on a dictionary e A dictionary comprises definitions and clarifications of terms that are relevant to the project and of which different people in particular customer and developer may have different understandings before agreeing on the dictionary e Each entry in the dictionary should provide the following information term and synonyms in the sense of the requirements specification meaning definition explanation deliminations where not to use this terms validness in time in space denotation unique identifiers open questions not yet resolved related terms cross references Note entries for terms that seem crystal clear at first sight are not uncommon 05 2015 05 11 Sre e All work on requirements should as far as possible be done using terms from the dictionary consistently and consequently The dictionary should in particular be negotiated with the customer and used in communication if not possible at least developers should stick to dictionary terms 19 90 Documents of the Requirements Analysis Dictionary e Requirements analysis should be based on a dictionary e A dictionary comprises definitions and clarifications of terms that are relevant to the project and of which different people in particular customer and developer may have different understandings before agreei
24. Engineering Problem 05 2015 05 11 Sreintro 8 90 The Requirements Engineering Problem x A 05 2015 05 11 Sreintro all computation paths over X and A aka chaos 8 90 05 2015 05 11 Sreintro The Requirements Engineering Problem all computation paths over gt and A aka chaos requirements all these computation paths are allowed 8 90 The Requirements Engineering Problem 05 2015 05 11 Sreintro all computation paths over gt and A aka chaos requirements all these computation paths are allowed one software which satisfies the requirements 8 90 The Requirements Engineering Problem all computation paths over gt and A aka chaos requirements all these computation paths are allowed one software which satisfies the requirements e Requirements engineering Describe specify the set of the allowed computation paths e Software development Create one software S whose computation paths S are all allowed 8 90 05 2015 05 11 Sreintro The Requirements Engineering Problem all computation paths over gt and A aka chaos requirements all these computation paths are allowed one software which satisfies the requirements e Requirements engineering Describe specify the set of the allowed computation paths e Software development Create one software S whose computa
25. Open and Tacit e Open customer is aware of and able to explicitly communicate the requirement e semi tacit customer not aware of something being a requirement obvious to the customer not considered relevant by the customer not known to be relevant Examples e buttons and screen of a mobile Analyst phone should be on the same side knows domain new to domain e important web shop items should be on the right side because our main users are socialised with right to left reading direction e the ECU embedded control unit may only use a certain amount of bus capacity Customer Client tacit semi tacit explicit e distinguish don t care intentionally left to be decided by developer Gacitua et al 2009 21 90 Kinds of Requirements Functional and Non Functional o Sigh 05 2015 05 11 Sre 28 90 Kinds of Requirements Functional and Non Functional Sigh e Recall definition of software A finite description of a set of computation paths of the form oT Q2 T 00 7 Oj Note states may be labelled with timestamps or energy consumption so far e Another view software is a function which maps input to output sequences a ai a A 5 01 0l 07 gt og ag ol as 05 2015 05 11 Sre 28 90 05 2015 05 11 Sre Kinds of Requirements Functional and Non Functional Sigh Recall definition of software A fini
26. Specifying Behaviour with Decision Tables A decision table T induces computation paths as follows e Let C bea set of conditions A a set of actions e Let X Ho be a set of states with a satisfaction relation for conditions e Set A 24 as event set A finite or infinite state event sequence Qi Q2 is called computation path of T if and only if e for alli No exists r prae ET such that 0 y and aj41 Q In other words if and only if Vi No 3r y gt a ET c Y ayy a 49 90 05 2015 05 11 Set Specifying Behaviour with Decision Tables A decision table T induces computation paths as follows e Let C bea set of conditions A a set of actions Let 2 o be a set of states with a satisfaction relation for conditions Set A 24 as event set A finite or infinite state event sequence Qi Q2 is called computation path of T if and only if e for alli No existsr p gt 0 T such that 0 y and aj41 Q In other words if and only if Vi No 3r y gt a ET g Y ayy a e Set T interleave 7 m is a computation path of T We call linterleave the interleaving interpretation semantics of decision tables e Note We will also define the collecting semantics cottect later 49 90 05 2015 05 11 Set Decision Tables Example Back to lecture hall 101 0 026 s ventilation system e C button_pressed ventilation_
27. a document or should be present relevant things which are not relevant to the project should not be constrained consistent free of contradictions each requirement is compatible with all other requirements otherwise the requirements are not realisable neutral abstract a requirements specification does not constrain the realisation more than necessary traceable comprehensible the sources of requirements are documented requirements are uniquely identifiable 22 90 05 2015 05 11 Sre Requirements on Requirements Specifications A requirements specification should be correct it correctly represents the wishes needs of the customer complete all requirements existing in somebody s head or a document or should be present relevant things which are not relevant to the project should not be constrained consistent free of contradictions each requirement is compatible with all other requirements otherwise the requirements are not realisable neutral abstract a requirements specification does not constrain the realisation more than necessary traceable comprehensible the sources of requirements are documented requirements are uniquely identifiable testable objective the final product can objectively be checked for satisfying a requirement 22 90 The Crux of Requirements Engineering Customer Analyst requirement
28. below There s a tradeoff between narrowness and openness 05 2015 05 11 Sreintro 15 90 A First Summary A good requirements specification i avoids disputes with the customer at milestones or delivery time 11 prevents us from doing too little too much work iii is economic see below There s a tradeoff between narrowness and openness e the optimum wrt i and ii is the complete perfect software product as needed by the customer most narrow e no disputes amount of work needed is clear Drawback hard expensive to get that s bad for iii 05 2015 05 11 Sreintro 15 90 A First Summary A good requirements specification i avoids disputes with the customer at milestones or delivery time ii prevents us from doing too little too much work iii is economic see below There s a tradeoff between narrowness and openness e the optimum wrt i and ii is the complete perfect software product as needed by the customer most narrow e no disputes amount of work needed is clear Drawback hard expensive to get that s bad for iii e The cheapest not most economic requirements specification is do what you want most open Drawback high risk value for not doing i and ii 05 2015 05 11 Sreintro 15 90 A First Summary A good requirements specification i avoids disputes with the customer at milestones or del
29. by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning C Of course A Also on the weekends C No on weekends the entrance stays closed A And during company holidays C Then it also remains closed of course A And if you are ill or on vacation C Then Mr M opens the door 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning C Of course A Also on the weekends C No on weekends the entrance stays closed A And during company holidays C Then it also remains closed of course A And if you are ill or on vacation C Then Mr M opens the door A And if Mr M is not available too 05
30. confl e ra is inconsistent with 4 05 2015 05 11 Setconfl 11 90 05 2015 05 11 Setconfl Conflicting Conditions Actions Consequences e Vacuity wrt Yoon Same as with uselessness and general vacuity doesn t hurt but May make communication with customer harder Implementing vacuous rules is a waste of effort e Consistency A decision table with non useless vacuous but inconsistent rules cannot be implemented Detecting an inconsistency only late during a project can incur significant cost Inconsistencies in particular in multiple decision tables created and edited by multiple people as well as in requirements in general are not always as obvious as in the toy examples given here would be too easy 12 90 05 2015 05 11 main Other Semantics for Decision Tables 13 90 05 2015 05 11 Setcoll A Collecting Semantics for Decision Tables Q Q e Let T be a decision table and 7 0 gt 0 lt Ca a state event sequence e Recall 7 is a computation path of T in the interleaving semantics if Vic No I7T pP gt 0 ET 0 H Y i Q e Tis a computation path of T in the collecting semantics if and only if Vic No IT P gt 0 ET oc H p Qi 1 U a yp a ET ae That is all rules which are enabled in g fire simultaneously the joint effect is the union of the effects e Advantage e separation of co
31. cument are to be interpreted as described in RFC 2119 Note that the force of these words is modified by the requirement level of the document in which they are used MUST This word or the terms REQUIRED or SHALL mean that the definition is an absolute requirement of the specification MUST NOT This phrase or the phrase SHALL NOT mean that the definition is an absolute prohibition of the specification SHOULD This word or the adjective RECOMMENDED mean that there may exist valid reasons in particular circumstances to ignore a particular item but the full implications must be understood and carefully weighed before choosing a different course SHOULD NOT This phrase or the phrase NOT RECOMMENDED mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label Bradner Best Current Practice RFC 2119 RFC Key Words MAY This word or the adjective OPTIONAL mean that truly optional One vendor may choose to include the it particular marketplace requires it or because the vendor it enhances the product while another vendor may omit th An implementation which does not include a particular of prepared to interoperate with another implementation whi include the option though per
32. e examples point out particular corner cases Customers without strong maths computer science background are often overstrained when left alone with a formal requirements specification e Result dictionary specified requirements e Many customers do not want radical change but improvement e Good questions How re things done today What should be improved 05 2015 05 11 Sre 32 90 05 2015 05 11 main Specification Languages 33 90 05 2015 05 11 Sspeclang Requirements Specification Language specification A document that specifies in a complete precise verifiable manner the requirements design behavior or other characteristics of a sys tem or component and often the procedures for determining whether these provisions have been satisfied IEEE 610 12 1990 34 90 05 2015 05 11 Sspeclang Requirements Specification Language specification A document that specifies in a complete precise verifiable manner the requirements design behavior or other characteristics of a sys tem or component and often the procedures for determining whether these provisions have been satisfied IEEE 610 12 1990 specification language A language often a machine processible combina tion of natural and formal language used to express the requirements design behavior or other characteristics of a system or component For example a d
33. e from chaos N requirements e Z zx is always 0 is a semi informal software specification e lt denotes all imaginable softwares with an x which is always 0 7 S Yoo 0 02 S Vi No eo Ex 0 13 90 05 2015 05 11 Sreintro 05 2015 05 11 Sreintro A Bit More Abstract Software vs Real World Requirements In other words e common sense understanding choose from QU requirements e software engineering understanding choose from chaos N requirements e Z zx is always 0 is a semi informal software specification e lt denotes all imaginable softwares with an x which is always 0 7 S Yoo 0 02 S Vi No eo Ex 0 e The software specification true I don t care at all denotes chaos 13 90 05 2015 05 11 Sreintro A Bit More Abstract Software vs Real World Requirements In other words e common sense understanding choose from QU requirements e software engineering understanding choose from chaos N requirements e Z zx is always 0 is a semi informal software specification e lt denotes all imaginable softwares with an x which is always 0 7 S Yoo 0 02 S Vi No eo Ex 0 e The software specification true I don t care at all denotes chaos e Writing a requirements specification means constraining chaos or
34. e g we state that we do not under any condition want to see on and off executed together 65 90 Non determism Consequences e Good e A non determistic decision table leaves more choices more freedom to the developer e Bad e A non determistic decision table leaves more choices to the developer even the choice to create a non deterministic final product Input Deterministic final products i e same data in same data out are easier to deal with and are usually desired e Another view deterministic decision tables can be implemented with deterministic programming languages 66 90 05 2015 05 11 Setprop 05 2015 05 11 Setprop Implementing Decision Tables b button pressed Hx x ventilation off x on ventilationon TC x go start ventilation x stop stop ventilation RA int b on off extern void go extern void stop 1 2 3 4 5 void xeffect 0 6 7 8 9 void dt read_b_on_off read 10 11 compute 12 f f 13 if b amp amp off effect go 14 15 if b amp amp on effect stop 16 i7 execute_effect write 18 67 90 05 2015 05 11 main More Requirements Quality Criteria for DTs 68 90 05 2015 05 11 Setconfl Consistency of Rules T room ventilation r r2 else b button pressed ventilation off Ton ventilation on g
35. echnical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning C Of course A Also on the weekends C No on weekends the entrance stays closed A And during company holidays 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning C Of course A Also on the weekends C No on weekends the entrance stays closed A And during company holidays C Then it also remains closed of course 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in s
36. eed to be distinguished to understand requirements The dictionary explains these terms Arenis et al 2014 20 90 05 2015 05 11 Sre Example Wireless Fire Alarm System e During 2 e and re e repeater similar require Excerpt from the dictionary ca 50 entries Part A part of a fire alarm system is either a par ticipant or a central unit Repeater A repeater is a participant which accepts messages for the central unit from other partici pants or messages from the central unit to other participants A repeater consists of the following devices wireless communication module 1 to 4 here fixed to 2 Central Unit A central unit is a part which receives messages from different assigned participants as sesses the messages and reacts e g by forwarding to persons or optical acustic signalling devices A central unit consist of the following devices Terminal Participant A terminal participant is a participant which is not a repeater Each ter minal participant consists of exactly one wireless communication module and devices which provide sensor and or signalling functionality Dictionary Example With Room for Improvement Arenis et al 2014 20 90 Documents of the Requirements Analysis Specifications e Recall Lastenheft Requirements Specification Entire demands on deliverables and ser vices of a developer within a contracted development created by the custom
37. entation e programmers may use different interpretations of unclear requirements gt difficult integration the user s manual e if the user s manual author is not developer he she can only describe what the system does not what it should do no more bugs every observation is a feature preparation of tests e without a description of allowed outcomes tests are randomly searching for generic errors like crashes systematic testing impossible acceptance by customer resolving later objections or regress claims e at delivery time unclear whether behaviour is an error developer needs to fix or correct customer needs to accept and pay gt nasty disputes additional effort 05 2015 05 11 Sreintro 10 90 05 2015 05 11 Sreintro Purposes of the Requirements Specification coordination with the customer or the marketing department or e not properly clarified specified requirements are hard to satisfy mismatches with customer s needs turn out in operation the latest additional effort design and implementation e programmers may use different interpretations of unclear requirements gt difficult integration the user s manual e if the user s manual author is not developer he she can only describe what the system does not what it should do no more bugs every observation is a feature preparation of tests e without a description of allowed outcome
38. equirements defines acceptance criteria thus will be considered in any dispute at software delivery time plus speaking of documentation mind the gt bus factor e actively discussed in industry these days traceability 05 2015 05 11 Sreintro 9 90 Purposes of the Requirements Specification 05 2015 05 11 Sreintro 10 90 Purposes of the Requirements Specification e coordination with the customer or the marketing department or e not properly clarified specified requirements are hard to satisfy mismatches with customer s needs turn out in operation the latest additional effort 05 2015 05 11 Sreintro 10 90 Purposes of the Requirements Specification e coordination with the customer or the marketing department or e not properly clarified specified requirements are hard to satisfy mismatches with customer s needs turn out in operation the latest additional effort e design and implementation e programmers may use different interpretations of unclear requirements gt difficult integration 05 2015 05 11 Sreintro 10 90 Purposes of the Requirements Specification e coordination with the customer or the marketing department or e not properly clarified specified requirements are hard to satisfy mismatches with customer s needs turn out in operation the latest additional effort e design and implementation
39. er Pflichtenheft Feature Specification Specification of how to realise a given re quirements specification created by the developer DIN 69901 5 2009 21 90 05 2015 05 11 Sre Documents of the Requirements Analysis Specifications e Recall Lastenheft Requirements Specification Entire demands on deliverables and ser vices of a developer within a contracted development created by the customer Pflichtenheft Feature Specification Specification of how to realise a given re quirements specification created by the developer DIN 69901 5 2009 e Recommendation If the requirements specification is not given by customer but needs to be developed focus on and maintain only the collection of requirements possibly sketchy and unsorted and maintain the feature specification Ludewig and Lichter 2013 21 90 05 2015 05 11 Sre Documents of the Requirements Analysis Specifications e Recall Lastenheft Requirements Specification Entire demands on deliverables and ser vices of a developer within a contracted development created by the customer Pflichtenheft Feature Specification Specification of how to realise a given re quirements specification created by the developer DIN 69901 5 2009 e Recommendation If the requirements specification is not given by customer but needs to be developed focus on and maintain only the collection of requirements possibly sketchy and unsor
40. esign language or requirements specification language Contrast with pro gramming language query language IEEE 610 12 1990 34 90 05 2015 05 11 Sspeclang Requirements Specification Language specification A document that specifies in a complete precise verifiable manner the requirements design behavior or other characteristics of a sys tem or component and often the procedures for determining whether these provisions have been satisfied IEEE 610 12 1990 specification language A language often a machine processible combina tion of natural and formal language used to express the requirements design behavior or other characteristics of a system or component For example a design language or requirements specification language Contrast with pro gramming language query language IEEE 610 12 1990 requirements specification language A specification language with spe cial constructs and sometimes verification protocols used to develop ana lyze and document hardware or software requirements IEEE 610 12 1990 34 90 05 2015 05 11 Sspeclang Requirements Specification Language specification A document that specifies in a complete precise verifiable manner the requirements design behavior or other characteristics of a sys tem or component and often the procedures for determining whether these provisions have been satisfied IEEE 610 12 1990 spec
41. et 48 90 05 2015 05 11 Set Satisfaction of Premises e Given o the usual interpretation of the logical connectives true V induces a satisfaction relation C X x C for premises as follows e o E true for all o 2 e go c if and only if o Koc e o FC V Co if and only if o Ko cy or o Fo Ca e We call r y gt a over C and A enabled o if and only if o Fy Note In the following we may use A gt 4 as abbreviations as usual Example e Consider o X with o b gt 1 on gt 1 off H 0 and y b on E P C Then o E y thus r is enabled in 48 90 05 2015 05 11 Set Specifying Behaviour with Decision Tables A decision table T induces computation paths as follows o Let C be a set of conditions A a set of actions e Let 2 Ho be a set of states with a satisfaction relation for conditions e Set A 24 as event set 49 90 05 2015 05 11 Set Specifying Behaviour with Decision Tables A decision table T induces computation paths as follows e Let C bea set of conditions A a set of actions e Let X Ho be a set of states with a satisfaction relation for conditions e Set A 24 as event set A finite or infinite state event sequence Qi Q2 is called computation path of T if and only if e for alli No exists r yp rae ET such that c p and Qi41 Q 49 90 05 2015 05 11 Set
42. f a hard requirement e Cashing a cheque over N must result in a new balance decreased by N there is not a micro cent of tolerance 05 2015 05 11 Sre 26 90 Kinds of Requirements Hard and Soft Requirements e Example of a hard requirement e Cashing a cheque over N must result in a new balance decreased by N there is not a micro cent of tolerance e Examples of soft requirements e If the vending machine dispenses the selected item within 1s it s clearly fine if it takes 5 min it s clearly wrong where s the boundary e A car entertainment system which produces noise due to limited bus bandwidth or CPU power in average once per hour is acceptable once per minute is not acceptable 26 90 05 2015 05 11 Sre Kinds of Requirements Hard and Soft Requirements e Example of a hard requirement e Cashing a cheque over N must result in a new balance decreased by N there is not a micro cent of tolerance e Examples of soft requirements e If the vending machine dispenses the selected item within 1s it s clearly fine if it takes 5 min it s clearly wrong where s the boundary e A car entertainment system which produces noise due to limited bus bandwidth or CPU power in average once per hour is acceptable once per minute is not acceptable The border between hard soft is difficult to draw e As developer we want requirements specifications t
43. gt is equivalent to C gt B then r is not vacuous yet it may be subsumed by another rule 59 90 05 2015 05 11 Setprop Uselessness Consequences e Doesn t hurt wrt the final product The decision table 7 with useless rules has the same computation paths as the one with useless rules removed e But e Decision tables with useless rules are unnecessarily hard to work with read maintain e May make communication with customer harder 60 90 Quality Criteria for DTs Completeness Definition Completeness A decision table T is called complete if and only if the disjunction of all rules premises is a tautology i e if Vo Pp AET 61 90 05 2015 05 11 Setprop 05 2015 05 11 Setprop Completeness Example b button pressed x x off ventilation of id x Con ventilation on oo ao start ventilation x stop stop ventilation D0 62 90 05 2015 05 11 Setprop Completeness Example b button pressed x off ventilation o Ton ventilation on ao start ventilation gt stop stop ventilation e is not complete there is no rule e g for the case b A on A off 62 90 05 2015 05 11 Setprop Completeness Example T room ventilation lado b button pressed x off ventilation off Sid Ton ventilation on ao start ventilation gt stop
44. haps with reduced function same vein an implementation which does include a particu MUST be prepared to interoperate with another implementa does not include the option except of course for the option provides Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be use and sparingly In particular they MUST only be used wh actually required for interoperation or to limit behavic potential for causing harm e g limiting retransmisssi example they must not be used to try to impose a partic on implementors where the method is not required for interoperability Security Considerations These terms are frequently used to specify behavior with implications The effects on security of not implementi SHOULD or doing something the specification says MUST N NOT be done may be very subtle Document authors should to elaborate the security implications of not following recommendations or requirements as most implementors wil had the benefit of the experience and discussion that pr specification Acknowledgments The definitions of these terms are an amalgam of definit from a number of RFCs In addition suggestions have be incorporated from a number of people including Robert Ul Narten Neal McBurnett and Robert Elz 05 2015 05 11 Sspeclang IEEE Std 830 1998 Revision of IEEE Std 830 1993 IEEE Recommended Practice for Software Requirements Specifications
45. he blueprints Kopetz 2011 Lovins and Lovins 2001 Definition Bj rner and Havelund 2014 A method is called formal method if and only if its techniques and tools can be explained in mathematics Example If a method includes as a tool a specification language then that language has e a formal syntax e a formal semantics and e a formal proof system 1 2015 04 20 main Formal Rigorous or Systematic Development Decision tables DT are one example for a formal requirements specification language we give a formal syntax and semantics requirements quality criteria e g completeness can be formally defined thus for a DT we can formally argue whether it is complete or not some formal arguments can be done automatically tool support main 1 2015 04 20 The techniques of a formal method help e construct a specification and or e analyse a specification and or e transform refine one or more specification s into a program The techniques of a formal method besides the specification languages are typically software packages that help developers use the techniques and other tools The aim of developing software either e formally all arguments are formal or e rigorously some arguments are made and they are formal or e systematically some arguments are made on a form that can be made formal is to be able to reason in a precise manner ab
46. ification language A language often a machine processible combina tion of natural and formal language used to express the requirements design behavior or other characteristics of a system or component For example a design language or requirements specification language Contrast with pro gramming language query language IEEE 610 12 1990 requirements specification language A specification language with spe cial constructs and sometimes verification protocols used to develop ana lyze and document hardware or software requirements IEEE 610 12 1990 software requirements specification SRS Documentation of the essen tial requirements functions performance design constraints and attributes of the software and its external interfaces IEEE 610 12 1990 34 90 05 2015 05 11 Sspeclang Requirements Specification Language specification A document that specifies in a complete precise verifiable manner the requirements design behavior or other characteristics of a sys tem or component and often the procedures for determining whether these provisions have been satisfied IEEE 610 12 1990 specification language A language often a machine processible combina tion of natural and formal language used to express the requirements design behavior or other characteristics of a system or component For example a design language or requirements specification language Contrast
47. in which situation e Content e motivation and vocabulary of requirements engineering e the documents of requirements analysis and desired properties of RE e guidelines for requirements specification using natural language 4 90 05 2015 05 11 main Customer Developer 5 90 The hardest single part of building a software system is deciding precisely what to build No other part of the conceptual work is as difficult as establishing the detailed technical requirements No other part of the work so cripples the resulting system if done wrong No other part is as difficult to rectify later F P Brooks Brooks 1995 MYTHICAL MAN MONTH BROOKS JR 6 90 05 2015 05 11 Sreintro 05 2015 05 11 Sreintro Requirements and Requirements Analysis requirement 1 A condition or capability needed by a user to solve a problem or achieve an objective 2 A condition or capability that must be met or possessed by a system or system component to satisfy a contract standard specification or other formally imposed documents 3 A documented representation of a condition or capability as in 1 or 2 IEEE 610 12 1990 requirements analysis 1 The process of studying user needs to arrive at a definition of system hardware or software requirements 2 The process of studying and refining system hardware or software re quirements IEEE 610 12 1990 1 9
48. is either the system or the concrete name of a sub system one of three possibilities e does description of a system activity e offers description of a function offered by the system to somebody e is able if usage of a function offered by a third party under certain conditions extensions in particular an object 37 90 05 2015 05 11 Sspeclang Natural Language Patterns Natural language requirements can be written using A B C D E F where clarifies when and under what conditions the activity takes place is MUST obligation SHOULD wish or WILL intention also MUST NOT forbidden is either the system or the concrete name of a sub system one of three possibilities e does description of a system activity e offers description of a function offered by the system to somebody e is able if usage of a function offered by a third party under certain conditions extensions in particular an object the actual process word what happens Rupp and die SOPHISTen 2009 37 90 05 2015 05 11 Sspeclang Natural Language Patterns Natural language requirements can be written using A B C D E F where clarifies when and under what conditions the activity takes place is MUST obligation SHOULD wish or WILL intention also MUST NOT forbidden is either the system or the concrete name of a sub system one of three pos
49. ivery time 11 prevents us from doing too little too much work iii is economic see below There s a tradeoff between narrowness and openness e the optimum wrt i and ii is the complete perfect software product as needed by the customer most narrow e no disputes amount of work needed is clear Drawback hard expensive to get that s bad for iii e The cheapest not most economic requirements specification is do what you want most open Drawback high risk value for not doing i and ii e Being too narrow has another severe drawback 05 2015 05 11 Sreintro 15 90 Namely Requirements Specification vs Design e Idealised views advocate a strict separation between requirements what is to be done and design how are things done e Rationale Fixing too much of the how too early may unnecessarily narrow down the design space and inhibit new ideas There may be better easier cheaper solutions than the one imagined first 16 90 05 2015 05 11 Sreintro 05 2015 05 11 Sreintro Namely Requirements Specification vs Design e Idealised views advocate a strict separation between requirements what is to be done and design how are things done e Rationale Fixing too much of the how too early may unnecessarily narrow down the design space and inhibit new ideas There may be bette
50. kes place B is MUST obligation SHOULD wish or WILL intention also MUST NOT forbidden 05 2015 05 11 Sspeclang 37 90 05 2015 05 11 Sspeclang Natural Language Patterns Natural language requirements can be written using A B C D E F where A clarifies when and under what conditions the activity takes place B is MUST obligation SHOULD wish or WILL intention also MUST NOT forbidden C is either the system or the concrete name of a sub system 37 90 Natural Language Patterns Natural language requirements can be written using A B C D E F where A clarifies when and under what conditions the activity takes place B is MUST obligation SHOULD wish or WILL intention also MUST NOT forbidden C is either the system or the concrete name of a sub system D one of three possibilities e does description of a system activity e offers description of a function offered by the system to somebody e is able if usage of a function offered by a third party under certain conditions 05 2015 05 11 Sspeclang 37 90 05 2015 05 11 Sspeclang Natural Language Patterns Natural language requirements can be written using A B C D E F where clarifies when and under what conditions the activity takes place is MUST obligation SHOULD wish or WILL intention also MUST NOT forbidden
51. mitted and everything happens according to the blueprints Kopetz 2011 Lovins and Lovins 2001 Definition Bj rner and Havelund 2014 A method is called formal method if and only if its techniques and tools can be explained in mathematics Example If a method includes as a tool a specification language then that language has e a formal syntax e a formal semantics and e a formal proof system Formal Rigorous or Systematic Development 1 2015 04 20 main The techniques of a formal method help e construct a specification and or e analyse a specification and or e transform refine one or more specification s into a program The techniques of a formal method besides the specification languages are typically software packages that help developers use the techniques and other tools The aim of developing software either e formally all arguments are formal or e rigorously some arguments are made and they are formal or e systematically some arguments are made on a form that can be made formal is to be able to reason in a precise manner about properties of what is being developed Bjgrner and Havelund 2014 21 37 3 90 05 2015 05 11 Srefm Recall Formal Methods Formal Methods in the Software Development Domain back to technological paradise where no acts of God can be permitted and everything happens according to t
52. nce Customer Yes as told you A Every morning C Of course A Also on the weekends 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning C Of course A Also on the weekends C No on weekends the entrance stays closed 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know t
53. ncerns multiple smaller tables may contribute to a transition e no non determinism between rules all enabled ones fire e Disadvantages conflicts much less obvious 14 90 05 2015 05 11 Setcoll An Update Semantics for Decision Tables e By now we didn t talk about the effect of actions from A on states Actions are uninterpreted e Recall the cash cheque example Here it makes sense because the next state seen by the bank clerk may be the result of many database updates by other bank clerks We can also define a semantics with action effects e Let A be a set of actions and a set of states o Let acte A X X 2 which assigns to each pair of a 0 of action and state a new state o a is called the result of applying a to e Example on gt b on off we could define yo actesr o al oy U on 1 off gt 0 stop acre 0 o lp U on gt 0 off gt 1 e The interleaving semantics with action effects is then VieNo3ir p gt 0 T eo E YA ay a 0541 la oct 0 5 90 05 2015 05 11 Setcoll An Update Semantics for Decision Tables Cont d In addition we may want to constrain initial states i e give a set Xin C Computation paths of T over 2 are then required to have dy Xini Example decision table T room ventilation a off ventilation of M gt Ton ventilation on go start ventilation A stop stop ve
54. nclude lt gmp h gt sq unsigned short x void sq mpz_t x return x x mpz mul x x x 2h 200 4h 400 not defined for 2 14 90 And What s Hard About That Example customer says l need a computation of square numbers i e f x 2 e We ve got options to choose from d int include lt gmp h gt int sq int x To q unsigned short x void sq mpz_t x y POP os 0 return x x x mpz mul x x x i 1h 100 2h 200 4h 400 with errors sq 2 1 1 not defined for 2 usage non trivial mpz t x mpz_init x mpz_set_si x 2147483647 sq x fprintf stdout i gt 2147483647 mpz_out_str stdout 10 x fprintf stdout An E 2 3 4 5 6 8 14 90 05 2015 05 11 Sreintro And What s Hard About That Example customer says l need a computation of square numbers i e f x gt x e We ve got options to choose from d int include lt gmp h gt int sq int x fo q unsigned short x void sq mpz_t x y POPE eS 00 return x x x mpz mul x x x i 1h 100 2h 200 4h 400 with errors sq 2 1 1 not defined for 2 usage non trivial mpz t x mpz_init x mpz_set_si x 2147483647 sq x fprintf stdout i gt 2147483647 mpz_out_str stdout 10 x fprintf stdout An e Okay customer said in
55. ng on the dictionary e Each entry in the dictionary should provide the following information term and synonyms in the sense of the requirements specification meaning definition explanation deliminations where not to use this terms validness in time in space denotation unique identifiers open questions not yet resolved related terms cross references Note entries for terms that seem crystal clear at first sight are not uncommon 05 2015 05 11 Sre e All work on requirements should as far as possible be done using terms from the dictionary consistently and consequently The dictionary should in particular be negotiated with the customer and used in communication if not possible at least developers should stick to dictionary terms e Note do not mix up real world domain terms with ones only living in the software 19 90 05 2015 05 11 Sre Dictionary Example With Room for Improvement Example Wireless Fire Alarm System e During a project on designing a highly reliable EN 54 25 conforming wireless communication im protocol we had to learn that the relevant X Co components of a fire alarm system are e terminal participants wireless sensors and manual indicators e a central unit not a participant e and repeaters a non terminal participant lL a E e repeaters and central unit are technically very similar but n
56. niques 05 2015 05 11 Sre 18 90 Documents of the Requirements Analysis Dictionary e Requirements analysis should be based on a dictionary 05 2015 05 11 Sre 19 90 Documents of the Requirements Analysis Dictionary e Requirements analysis should be based on a dictionary e A dictionary comprises definitions and clarifications of terms that are relevant to the project and of which different people in particular customer and developer may have different understandings before agreeing on the dictionary 05 2015 05 11 Sre 19 90 05 2015 05 11 Sre Documents of the Requirements Analysis Dictionary e Requirements analysis should be based on a dictionary e A dictionary comprises definitions and clarifications of terms that are relevant to the project and of which different people in particular customer and developer may have different understandings before agreeing on the dictionary e Each entry in the dictionary should provide the following information e term and synonyms in the sense of the requirements specification e meaning definition explanation e deliminations where not to use this terms e validness in time in space e denotation unique identifiers e open questions not yet resolved e related terms cross references Note entries for terms that seem crystal clear at first sight are not uncommon 19 90
57. nse understanding That is we re looking for one small horse like animal we may guided by economic concerns taste etc choose exact breed size color shape gender age may not even be born today only needs to be alive on birthday e Software Engineering understanding 12 90 05 2015 05 11 Sreintro Once Again The Software Peoples View on Requirements Example children s birthday present requirements birthday on May 27th e Ich will n Pony I want a pony e Common sense understanding That is we re looking for one small horse like animal we may guided by economic concerns taste etc choose exact breed size color shape gender age may not even be born today only needs to be alive on birthday e Software Engineering understanding We may give everything as long as there s a pony in it e a herd of ponies e a whole zoo if it has a pony 12 90 05 2015 05 11 Sreintro A Bit More Abstract Software vs Real World Requirements In other words e common sense understanding choose from QU requirements e software engineering understanding choose from chaos N requirements 13 90 05 2015 05 11 Sreintro A Bit More Abstract Software vs Real World Requirements In other words e common sense understanding choose from QU requirements e software engineering understanding choos
58. ntilation with Ming on gt 0 off gt 1 has only one computation path namely O a with 01 on gt 0 off gt 1 We can say T terminates This gives rise to another notion of vacuity r on A off gt a is never enabled because no state satisfying the premise is ever reached even with conflict axiom conf false 16 90 05 2015 05 11 Setcoll Distinguishing Controlled and Uncontrolled Conditions e For some systems we can distinguish inputs and outputs e In terms of decision tables e C is partitioned into controlled conditions Ce and uncontrolled conditions Ca i e C C UL e actions only affect controlled conditions e Example e Ce fon off only the software switches the ventilation on or off e Cu b the button is not controlled by the software but by the environment by a user external to the computer system e One more quality criterion another notion of completeness We want the specification to be able to deal with all possible sequences of inputs i e we require Tle le Cor Alo 1 90 05 2015 05 11 Setcoll Controlled and Uncontrolled Conditions Example e Example T room ventilation ER o button pressed x oF ventilation of SSS Ton ventilation on go start ventilation RA stop stop ventilation e is not input sequence complete There is no rule enabled if the button is pressed when
59. o start ventilation AA stop stop ventilation RA e Conditions and actions are abstract entities without inherent connection to the real world e Yet we want to use decision tables to model represent requirements on the behaviour of software systems which are used in the real world e When modelling real world aspects by conditions and actions we should also model relations between actions conditions in the real world domain model 69 90 05 2015 05 11 Setconfl Consistency of Rules T room ventilation r r2 else b button pressed ventilation off on ventilation on PP go start ventilation AA stop stop ventilation RA e Conditions and actions are abstract entities without inherent connection to the real world e Yet we want to use decision tables to model represent requirements on the behaviour of software systems which are used in the real world e When modelling real world aspects by conditions and actions we should also model relations between actions conditions in the real world domain model Example e if on models room ventilation is on and e if off models room ventilation is off e then in the abstract setting o on A off is still possible T doesn t know that on and off model opposites in the real world 69 90 Conflicting Conditions and Actions Consistency e A conflict axiom for conditions C is a formula Pena P C
60. o be as hard as possible i e we want a clear right wrong e As customer we often cannot provide this clarity we know what is clearly wrong and we know what is clearly right but we don t have a sharp boundary intervals rates etc can serve as precise specifications of soft requirements 26 90 05 2015 05 11 Sre Kinds of Requirements Open and Tacit e Open customer is aware of and able to explicitly communicate the requirement e semi tacit customer not aware of something being a requirement obvious to the customer not considered relevant by the customer not known to be relevant 21 90 05 2015 05 11 Sre 05 2015 05 11 Sre Kinds of Requirements Open and Tacit e Open customer is aware of and able to explicitly communicate the requirement e semi tacit customer not aware of something being a requirement obvious to the customer not considered relevant by the customer not known to be relevant Examples e buttons and screen of a mobile phone should be on the same side e important web shop items should be on the right side because our main users are socialised with right to left reading direction e the ECU embedded control unit may only use a certain amount of bus capacity e distinguish don t care intentionally left to be decided by developer 21 90 05 2015 05 11 Sre Kinds of Requirements
61. on ventilation_off e A do_ventilate stop_ventilate e r b A ventilation_off gt go e r2 b A ventilation_on stop eo T roak What s in T tene shorthands b on off shorthands go stop 50 90 05 2015 05 11 Set Decision Tables Example Back to lecture hall 101 0 026 s ventilation system e C button_pressed ventilation_on ventilation_off e A do_ventilate stop_ventilate r b A ventilation_off gt go r2 b A ventilation_on gt stop T roak What s in T interleaving Naja for example g0 stop 1 00 01 gt 02 oo b A off o1 FbA on shorthands b on off shorthands go stop 50 90 05 2015 05 11 Set Decision Tables Example Back to lecture hall 101 0 026 s ventilation system e C button_pressed ventilation_on ventilation_off e A do_ventilate stop_ventilate e r b A ventilation_off gt go e r2 b A ventilation_on stop e T r1 ro What s in T interleaving Naja for example go stop o 71 00 gt 01 gt 02 oo b A off 01 FbA on 12 00 oo KE b A on and oo KK b A off shorthands b on off shorthands go stop 50 90 05 2015 05 11 Set Decision Tables Example Back to lecture hall 101 0 026 s ventilation system e C button_pressed ventilation_on ventilation_off
62. out properties of what is being developed Bjgrner and Havelund 2014 21 37 3 90 05 2015 05 11 main Formal Specification and Analysis of Requirements Decision Tables for Example 44 90 05 2015 05 11 Set Decision Tables Definition Decision Table Let C be a set of atomic conditions and A a set of actions i The set C of premises over C consists of the terms defined by the following grammar y true c p1 y1 V Yo CEC ii A rule r over C and A is a pair p a denoted by y gt a which comprises a premise y C and a finite set a C A of actions the effect iii Any finite set T of rules over C and A is called decision table over C and A 45 90 05 2015 05 11 Set Decision Tables Example This might ve been the specification of lecture hall 101 0 026 s ventilation system e Conditions C button_pressed ventilation_on ventilation_off y shorthands b on off e Actions A do_ventilate stop_ventilate shorthands go stop e Rules e r b A ventilation_off gt go e r2 b A ventilation_on gt stop e Decision table T tr ro 46 90 05 2015 05 11 Set Satisfaction of Conditions and Premises e Let Y be a set of states with a satisfaction relation Fo C x C We say o satisfies condition c and write o o c if and only if 0 c Fo otherwise we write oF oy
63. put values are from 0 27 E 2 3 4 5 6 8 14 90 05 2015 05 11 Sreintro And What s Hard About That Example customer says l need a computation of square numbers i e f x 2 e We ve got options to choose from i unsigned int include lt gmp h gt ne n a 7 t sq unsigned short x void sq mpz_t x y E A return x x mpz mul x x x i 1h 100 2h 200 4h 400 with errors sq 2 1 1 not defined for 2 usage non trivial mpz t x mpz_init x mpz_set_si x 2147483647 sq x fprintf stdout i gt 2147483647 mpz_out_str stdout 10 x fprintf stdout An e Okay customer said input values are from 0 27 e Still we ve got options E 2 3 4 5 6 8 unsigned int sq unsigned short x unsigned int r 0 n for n x n n r x sleep 1 return r 14 90 05 2015 05 11 Sreintro A First Summary A good requirements specification i avoids disputes with the customer at milestones or delivery time 11 prevents us from doing too little too much work iii is economic see below 05 2015 05 11 Sreintro 15 90 A First Summary A good requirements specification i avoids disputes with the customer at milestones or delivery time 11 prevents us from doing too little too much work iii is economic see
64. r easier cheaper solutions than the one imagined first e In practice this separation is often neither possible nor advisable Existing components should be considered re use Customer safety regulations norms etc may require a particular solution anyway It is often useful to reflect real world structures in the software In some low risk cases it may be more economical to skip requirements analysis and directly code and document a proposal Complex systems may need a preliminary system design before being able to understand and describe requirements One way to check a requirements specification for consistency realisability is to think through at least one possible solution The requirements specification should answer questions arising during development 16 90 05 2015 05 11 main Requirements Engineering Basics 17 90 Requirements Analysis Basics e Note analysis in the sense of finding out what the exact requirements are Analysing an existing requirements feature specification later In the following we shall discuss 1 documents of the requirements analysis e dictionary e requirements feature specification ii desired properties of e requirements specifications e requirements specification documents iii kinds of requirements e hard and soft e open and tacit e functional and non functional sighx iv a selection of analysis tech
65. rements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to e ask what is wanted ask what is not wanted e establish precision look out for contradictions e anticipate exceptions difficulties corner cases e have technical background to know technical difficulties e communicate formal specification to customer e test own understanding by asking more questions i e to elicit the requirements 31 90 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in sta
66. rule with insatisfiable premise is vacuous 05 2015 05 11 Setprop 59 90 Uselessness Example Example e cA 7c gt is vacuous Proposition any rule with insatisfiable premise is vacuous e Let Y c 0 there s only one state o 2 and c not satisfied in Then c gt a is vacuous 05 2015 05 11 Setprop 59 90 05 2015 05 11 Setprop Uselessness Example Example e cA 7c gt is vacuous Proposition any rule with insatisfiable premise is vacuous e Let Y c 0 there s only one state o 2 and c not satisfied in Then c gt a is vacuous T room ventilation bee eee Tb button pressed x aff venation Rep Con ventilation on gt PX go start ventilation AT stop stop ventilation x e ra is useless it is subsumed by r3 e r3 is not subsumed by r4 59 90 05 2015 05 11 Setprop Uselessness Example Example e cA 7c gt is vacuous Proposition any rule with insatisfiable premise is vacuous e Let Y c 0 there s only one state o 2 and c not satisfied in Then c gt a is vacuous T room ventilation bee eee o A BOOR on A go start ventilation AT stop stop ventilation PR e ra is useless it is subsumed by r3 e r3 is not subsumed by r4 e Proposition if rule r is given in form of a table and if
67. s tests are randomly searching for generic errors like crashes systematic testing impossible acceptance by customer resolving later objections or regress claims e at delivery time unclear whether behaviour is an error developer needs to fix or correct customer needs to accept and pay nasty disputes additional effort e re use e re use based on re reading the code gt risk of unexpected changes 10 90 05 2015 05 11 Sreintro Purposes of the Requirements Specification coordination with the customer or the marketing department or e not properly clarified specified requirements are hard to satisfy mismatches with customer s needs turn out in operation the latest additional effort design and implementation e programmers may use different interpretations of unclear requirements difficult integration the user s manual e if the user s manual author is not developer he she can only describe what the system does not what it should do no more bugs every observation is a feature preparation of tests e without a description of allowed outcomes tests are randomly searching for generic errors like crashes systematic testing impossible acceptance by customer resolving later objections or regress claims e at delivery time unclear whether behaviour is an error developer needs to fix or correct customer needs to accept and pay nasty disputes additional effort
68. s analysis e Correctness and completeness of a requirements specification is defined relative to something which is usually only in the customer s head in that case there is hardly a chance to be sure of correctness and completeness 23 90 05 2015 05 11 Sre The Crux of Requirements Engineering Customer Analyst requirements analysis e Correctness and completeness of a requirements specification is defined relative to something which is usually only in the customer s head in that case there is hardly a chance to be sure of correctness and completeness e Dear customer please tell me write down what is in your head is in almost all cases not a solution e It s not unusual that even the customer does not precisely know For example the customer may not be aware of contradictions due to technical limitations 23 90 05 2015 05 11 Sre Requirements on Requirements Specification Documents The representation and form of a requirements specification should be 05 2015 05 11 Sre 24 90 Requirements on Requirements Specification Documents The representation and form of a requirements specification should be e easily understandable not unnecessarily complicated all affected people are able to understand the requirements specification 05 2015 05 11 Sre 24 90 Requirements on Requirements Specification Documen
69. sibilities e does description of a system activity e offers description of a function offered by the system to somebody e is able if usage of a function offered by a third party under certain conditions extensions in particular an object the actual process word what happens Rupp and die SOPHISTen 2009 After office hours A the system C should B offer to the operator D a backup F of all new registrations to an external medium E 37 90 05 2015 05 11 Sspeclang Other Pattern Example RFC 2119 Network Working Group S Bradner Request for Comments 2119 Harvard University BCP 14 March 1997 Category Best Current Practice Key words for use in RFCs to Indicate Requirement Lev Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community and requests discussion and suggestions for improvements Distribution of this memo is unlimited Abstract In many standards track documents several words are used to signify the requirements in the specification These words are often capitalized This document defines these words as they should be interpreted in IETF documents Authors who follow these guidelines should incorporate this phrase near the beginning of their document The key words MUST MUST NOT REQUIRED SHALL SHALL NOT SHOULD SHOULD NOT RECOMMENDED MAY and OPTIONAL in this do
70. tating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning C Of course A Also on the weekends C No on weekends the entrance stays closed A And during company holidays C Then it also remains closed of course A And if you are ill or on vacation 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding
71. te description of a set of computation paths of the form i Q2 T 00 7 Oj Note states may be labelled with timestamps or energy consumption so far Another view software is a function which maps input to output sequences et pit g a g a S o oi gt ohn DE og ag of as Every constraint on things observable in the computation paths is a functional requirement because it requires something for the function S Thus timing energy consumption etc may be subject to functional requirements Clearly non functional requirements programming language coding conventions process model requirements portability 28 90 05 2015 05 11 Sre Requirements Analysis Techniques 29 90 05 2015 05 11 Sre A Selection of Analysis Techniques Focus current desired innovation Analysis Technique situation situation consequences Analysis of existing data and documents TT he Observation TT he closed Questionning with structured questions open o E O O Interview O Modelling Experiments Prototyping E Participative development E Ludewig and Lichter 2013 30 90 Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the I want a pony world in multiple senses 05 2015 05 11 Sre 31 90 05 2015 05 11 Sre Requi
72. ted and maintain the feature specification Ludewig and Lichter 2013 e Note In the following unless otherwise noted we discuss the feature specification i e the basis of the software development To maximise confusion we may occasionally inconsistently call it requirements specification or just specification should be clear from context 21 90 05 2015 05 11 Sre Requirements on Requirements Specifications A requirements specification should be 05 2015 05 11 Sre 22 90 Requirements on Requirements Specifications A requirements specification should be e correct it correctly represents the wishes needs of the customer 05 2015 05 11 Sre 22 90 Requirements on Requirements Specifications A requirements specification should be e correct it correctly represents the wishes needs of the customer e complete all requirements existing in somebody s head or a document or should be present 22 90 05 2015 05 11 Sre Requirements on Requirements Specifications A requirements specification should be e correct it correctly represents the wishes needs of the customer e complete all requirements existing in somebody s head or a document or should be present e relevant things which are not relevant to the project should not be constrained 05 2015 05 11 Sre 22 90
73. the ventilation is off e Note it s not that pressing the button such a state has no effect but the system stops to work it gets stuck in that state Because in order to take a transition we need to have at least one enabled rule 18 90 05 2015 05 11 main Decision Tables Discussion 19 90 User Stories 80 90 ulew LES Side S0 81 90 A1oyssesns TT GO GTOZ GO 82 90 A1oyssesns TT GO GTOZ GO Scenarios 83 90 ulew LES Side S0 05 2015 05 11 main Live Sequence Charts 84 90 05 2015 05 11 main Use Case Diagrams 85 90 Wrap Up 86 90 uleW TT GO STOZ SO 87 90 ulew TT GO GT0Z GO 05 2015 05 11 main Software vs Systems Engineering 88 90 References 89 90 ulew LES Side S0 05 2015 05 11 main References Arenis S F Westphal B Dietsch D Mu iz M and Andisha A S 2014 The wireless fire alarm system Ensuring conformance to industrial standards through formal verification In Jones C B Pihlajasaari P and Sun J editors FM 2014 Formal Methods 19th International Symposium Singapore May 12 16 2014 Proceedings volume 8442 of LNCS pages 658 672 Springer Balzert H 2009 Lehrbuch der Softwaretechnik Basiskonzepte und Requirements Engineering Spektrum 3rd edition Brooks F
74. ting communicating requirements They live in the I want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what Is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you 05 2015 05 11 Sre Requirements Elicitation e Observation Customers are typically not trained in stating communicating requirements They live in the l want a pony world in multiple senses e lt is the task of the analyst to i e to elicit the requirements ask what is wanted ask what is not wanted establish precision look out for contradictions anticipate exceptions difficulties corner cases have technical background to know technical difficulties communicate formal specification to customer test own understanding by asking more questions A made up dialogue Analyst So in the morning you open the door at the main entrance Customer Yes as told you A Every morning 05 2015 05 11 Sre Requirements
75. tion paths S are all allowed e Note different programs in different programming languages may also describe S e Often allowed any refinement of gt later e g allow intermediate transitions 8 90 05 2015 05 11 Sreintro So What is So Important About That ki ii Customer Develer Customer Developer Developer Customer Developer Customer Customer Developer announcement software contract maintenance Lastenheft incl Pflichtenheft milestone N software delivery verification amp validation 05 2015 05 11 Sreintro 9 90 So What is So Important About That FA Ph eee Sc eee 1d Customer Developer Customer Developer Developer Customer Developer Customer announcement software contract p 5 Lastenheft incl Pflichtenheft milestone N software delivery maintenance e the documentation of the requirements defines acceptance criteria thus will be considered in any dispute at software delivery time plus speaking of documentation mind the gt bus factor 05 2015 05 11 Sreintro Customer Developer So What is So Important About That FA AA be gt he ii teme Develer o Developer Developer Customer Developer Customer Customer Developer announcement software contract x Lastenheft incl Pflichtenheft milestone N software delivery maintenance e the documentation of the r
76. tions to choose from but the customer chooses And the choice is documented The raw material is basis of a preliminary requirements specification audience the developers with open questions Analysts need to communicate the requirements specification appropriately explain give examples point out particular corner cases Customers without strong maths computer science background are often overstrained when left alone with a formal requirements specification Result dictionary specified requirements 32 90 How Can Requirements Engineering Look In Practice e Set up a core team for analysis 3 to 4 people include experts from the domain and developers Analysis benefits from highest skills and strong experience e During analysis talk to decision makers managers domain experts and users Users can be interviewed by a team of 2 analysts ca 90 min e The resulting raw material is sorted and assessed in half or full day workshops in a team of 6 10 people One searches for e g contradictions between customer wishes and for priorisation Note The customer decides Analysts may make proposals different options to choose from but the customer chooses And the choice is documented e The raw material is basis of a preliminary requirements specification audience the developers with open questions Analysts need to communicate the requirements specification appropriately explain giv
77. top e r3 non A 70ff gt 52 90 05 2015 05 11 Set Decision Tables vs Rules In General ex description condition va gt gt rn Lem description condition noma omn ar description actioni oma onn Cas description action aa in Vij A Wi j 1 x 53 90 05 2015 05 11 Set Decision Tables vs Rules In General T decision table MA a ec ex description condition va gt gt rn Lem description condition noma omn ar description actioni oma onn Cay description action k aa in Vij A Wi j x C Cis m A SH ise Oe C ifv Xx t F urne AA AF Umm 2407 wa Exh Fase foss true ifv x Recall Ni lt cjcm F vj i ci true by definition Tesis Tal From rules to table use disjunctive normal form of y 53 90 05 2015 05 11 Set Decision Tables as Business Rules ar cash cheque AAA Faz do not cash cheque Las offer new conditions Balzert 2009 54 90 05 2015 05 11 Set Decision Tables as Business Rules T1 cash a cheque ri ra else ar cash cheque AAA az do not cash cheque x _ Las offer new conditions x Balzert 2009 e One customer session at the bank cc onc if o Cy A Co A C3 e clerk checks database state e database says credit limit exceeded over
78. ts The representation and form of a requirements specification should be e easily understandable not unnecessarily complicated all affected people are able to understand the requirements specification e precise the requirements specification does not introduce new unclarities or rooms for interpretation testable objective 05 2015 05 11 Sre 24 90 Requirements on Requirements Specification Documents The representation and form of a requirements specification should be e easily understandable not unnecessarily complicated all affected people are able to understand the requirements specification e precise the requirements specification does not introduce new unclarities or rooms for interpretation testable objective e easily maintainable creating and maintaining the requirements specification should be easy and should not need unnecessary effort 05 2015 05 11 Sre 24 90 Requirements on Requirements Specification Documents The representation and form of a requirements specification should be e easily understandable not unnecessarily complicated all affected people are able to understand the requirements specification e precise the requirements specification does not introduce new unclarities or rooms for interpretation testable objective e easily maintainable creating and maintaining the requirements specification should be easy
79. ts Software Firmware 3 4 Communication Interfaces 4 REQUIREMENTS REGARDING TECHNICAL DATA 4 1 Volume Requirements 4 2 Performance 4 3 etc Structure of a Requirements Document Example 5 GENERAL CONSTRAINTS AND REQUIREMENTS 5 1 Standards and Regulations 5 2 Strategic Constraints 5 3 Hardware 5 4 Software 5 5 Compatibility 5 6 Cost Constraints 5 7 Time Constraints 5 8 etc 6 PRODUCT QUALITY REQUIREMENTS 6 1 Availability Reliability Robustness 6 2 Security 6 3 Maintainability 6 4 Portability 6 5 etc 7 FURTHER REQUIREMENTS 7 1 System Operation 7 2 Customisation 7 3 Requirements of Internal Users Ludewig and Lichter 2013 based on IEEE 1998 40 90 41 90 You Are Here ulew LES Side S0 oq OW oq OW oq OW oq OW oq OW od OW oq OW od OW oq OW oq OW od OW oq OW oq OW oq OW LEC 20 LOT Ler 26 Z9 LS 9 6C 9 GC 9 CC 9 81 9 ST OTL 98 OV OT Ss 8c Sac STC S 8T GYI GIT az Gv Vv OE VLE VEC YOC oN 817 217 9 1 OT 7 GT 7 917 S L ETT ZIT 117 1 017 6 7 87 A AN NO OQMNiLo JEFES 42 90 WJS1S TT GO GTOZ S0 05 2015 05 11 Srefm Recall Formal Methods Formal Methods in the Software Development Domain 1 2015 04 20 main back to technological paradise where no acts of God can be per
80. with pro gramming language query language IEEE 610 12 1990 requirements specification language A specification language with spe cial constructs and sometimes verification protocols used to develop ana lyze and document hardware or software requirements IEEE 610 12 1990 software requirements specification SRS Documentation of the essen tial requirements functions performance design constraints and attributes of the software and its external interfaces IEEE 610 12 1990 34 90 Natural Language Specification Ludewig and Lichter 2013 based on Rupp and die SOPHISTen 2009 rule explanation example Name the actors indicate whether the user or the system does something Not the item is deleted State each requirement in active voice R2 Express processes Not is has but reads creates full verbs by full verbs require information which describe the process more precisely Not when data is consistent but after program P has checked consistency of the data R3 Discover In the component raises an error ask whom the incompletely message is addressed to defined verbs R4 Discover Conditions of the form if else need descriptions of the incomplete if and the then case conditions R5 Discover universal Are sentences with never always each any quantifiers all really universally valid Are

Download Pdf Manuals

Related Search

Related Contents

Batch Process User Manual  取扱説明書 - 日東工業株式会社 N-TEC  TDR 2000 english - Electrocomponents  Graphic Operation Terminal GT2104-RTBD News  Instrucciones de uso / Rabomed_forte  13 VTR250-30KFK6600.book  Samsung SGH-D520 User Manual  Atdec TELEHOOK Projector Ceiling Mount    Model 2460 High-Current Interactive SourceMeter® Instrument  

Copyright © All rights reserved. Failed to retrieve file