1. Software engineering Olli Alm Lecture 2: requirements, modelling & representation

2. Phases of a software engineering project: requirements definition (Pressman: ch. 7: Requirements engineering) (Sommerville: ch. 6-8 in Requirements)  The idea: we have a customer with needs well defined / untechnical / unclear / something? A customer in the broad sense: a company, a friend, a financier or yourself?  In this phase, we try to formalize and specify the customer needs (in order to implement a program) Requirements definition Implementation Maintenance Testing Design

3. Phases of a software engineering project: requirements definition  The result (should be) (a bunch of) specification documents  Description for customer (external, informal+formal)  Description for the designers (internal, informal+formal) agreement between customer and supplier (the contract!)  requirements functional / non-functional  cost + (initial) schedule  representation in good level of abstraction (not too specific, not too broad) But… Requirements definition Implementation Maintenance Testing Design

4. Phases of a software engineering project: requirements definition

5. Two representation levels:  For the customer and team  user requirements  For the team  system requirements Requirements definition Implementation Maintenance Testing Design

6. Phases of a software engineering project: requirements definition An example (Sommerville): 1. The software must provide a means of representing and 1.accessing external files created by other tools. 1.1 The user should be provided with facilities to define the type of external files 1.2. 1.2 Each external file type may have an associated tool which maybe applied to the file 1.2 1.3 Each external file type may be represented as a specific icon on the user’s display 1.2 1.4 Facilities should be provided for the icon representing an external file type to be defined by the user 1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon 1.2 User requirement definition System requirements specification

7. Phases of a software engineering project: requirements definition An example (Sommerville): 1. The software must provide a means of representing and 1.accessing external files created by other tools. 1.1 The user should be provided with facilities to define the type of external files 1.2. 1.2 Each external file type may have an associated tool which maybe applied to the file 1.2 1.3 Each external file type may be represented as a specific icon on the user’s display 1.2 1.4 Facilities should be provided for the icon representing an external file type to be defined by the user 1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon 1.2 User requirement definition System requirements specification What user wants to do How the system makes it possible

8. Phases of a software engineering project: requirements definition: user requirements User requirement guidelines (Sommerville): 1. Use standard format / template 2. Use consistent language, classify requirements (!) (mandatory [’system shall…’, desirable [’system should’] etc.) 3. (- Highlight the keyparts of the text -) 4. Avoid computer jargon! 5. In addition to text, use diagrams & pictures

9. Phases of a software engineering project: requirements definition: system requirements System requirements (Sommerville): Describe external behaviour of the system, not it’s design or implementation (if possible)  In some cases, selected architecture affect on requirements  design is included to requirements Extend the use cases

10. Phases of a software engineering project: requirements definition Distinction in types of requirements: functional requirements Services that system should provide How the system should react particular inputs How the system should behave in particular situations non-functional requirements reliability, privacy, safety, efficiency, portability, usability  n-f requirements may affect also to the process, not only to the product (e.g. process quality(?) for safety) Requirements definition Implementation Maintenance Testing Design

11. Phases of a software engineering project: requirements definition Examples of non-functional requirements (Sommerville): ”the user interface should be implement as simple HTML without frames or Java applet” (product requirement) ”the system development process and documents shall conform to the process and deliverables defined in XYZ…” (organizational requirement) ”The system shall not disclose any personal information…” (external requirement) Requirements definition Implementation Maintenance Testing Design

12. Phases of a software engineering project: requirements definition Requirements definition Implementation Maintenance Testing Design Metrics for non-functional requirements (Sommerville)

13. Representing user interaction in high level  Forms of representation: Natural language (NL), structured templates (ST), diagrams (D)  In requirements analysis: 1. Scenario descriptions 2. Use cases 3. Sequence diagrams

14. Representing user interaction in high level: 1. scenarios  Scenario description: real-life example of the use case with the ”default progress / phases”  Case example, opening the door: ”The teacher is on the hallway. She wants to enter the class room. She takes the keys from her pocket and opens the door by turning the key in the lock and then pulling the door.”  Informative description to represent the system usage scenarios in high level  Description in natural language (previous example) or with controlled templates.

15. Representing user interaction in high level: 1. scenarios (template)  Scenario description: real-life example of the use case with the ”default progress / phases”  Template: a form-like description, e.g.: Initial assumption: the situation Normal: usual flow of the case What can go wrong: unexpected behavior Other activities: what is happening simultaneously System state or completion: where we are after this?

16. Representing user interaction in high level: 1. scenarios (template) An example [Sommerville, ch.7]

17. Representing user interaction in high level: 1. scenarios (template) An example [Sommerville, ch.7]

18. Representing user interaction in high level: 2. use cases  How the user interacts with the system Actors involved, the type of the interaction Stick figures, named ellipses + arrow in between © Sommerville, 2004

19. Representing user interaction in high level: 2. use cases  How the user interacts with the system Actors involved, the type of the interaction Stick figures, named ellipses + arrow in between Roles of the users / user groups! © Sommerville, 2004

20. Representing user interaction in high level: 2. use cases  How the user interacts with the system Actors involved, the type of the interaction Stick figures, named ellipses + arrow in between Roles of the users / user groups! © Sommerville, 2004

21. Representing user interaction in high level: 3. scenario diagrams  Scenario diagrams extend use cases to describe also the inner behavior of the system Interaction between components Timely dependent description  In addition, sequence diagrams are also used to describe design and implementation of the system  how components interacts with each other

22. Representing user interaction in high level: 3. scenario diagrams © Sommerville, 2004

23. Representing user interaction in high level: 3. scenario diagrams © Sommerville, 2004  Scenario diagram is also known by name sequence diagram in general, sequence diagrams indicate interaction between objects or functional units to fulfill a certain (”bigger”) task. Timely dependence: sequence diagram states explicitly the order of the interaction  But not (usually) the processing time of a component  Relative processing time can be described by the vertical length of the activity

24. Representing user interaction in high level: 3. scenario diagrams © Sommerville, 2004 activity of the object time

25. Phases of a software engineering project: requirements definition  The output of this phase is software requirements document IEEE standard IEEE/ANSI 830-1998  Should state WHAT the system should do, not HOW it does it (how  design document) [Sommerville] Requirements definition Implementation Maintenance Testing Design

26. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 1) Preface 2) Introduction 3) Glossary 4) User requirements definition 5) System architecture 6) System requirements specification 7) System models 8) System evolution 9) Appendices 10) Index

27. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 1) Preface -expected readership -version history (of this document) -what is new in this version -summary of changes

28. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 2) Introduction -need for the system (=why?) -short description of functions -business / strategic objectives of the customer

29. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 3) Glossary -technical terms explained

30. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 4) User requirements definition -user requirements -non-functional system requirements -natural language, diagrams, controlled language, templates…

31. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 5) System architecture -high-level overview of the system -main modules and their functions represented

32. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 6) System requirements specification -functional requirements in detail -non-functional requirements in detail

33. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 7) System models -relations between system modules -object models? Flow models?

34. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 8) System evolution -explicit notion how the system will adapt for changing user needs hardware evolution

35. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 9) Appendices -technical, detailed documentation

36. Software requirements document Adapted from Sommerville, Software engineering 7, p.139 Document structure: 10) Index -for finding descriptions

37. Software requirements document Document structure (revisited), essential parts bolded: 1) Preface 2) Introduction 3) Glossary 4) User requirements definition 5) System architecture 6) System requirements specification 7) System models 8) System evolution 9) Appendices 10) Index

38. Software requirements: case study  Define requirements for door access system Give a general description of the system Define functional requirements Define non-functional requirements Can you specify different groups of users? Define use cases Give examples of basic scenarios