1. Technology for a better society TDT4140 Software Engineering 29.01.2013: 1 Experiences from Requirements Engineering: Coping with requirements in large, distributed projects Guest lecture by Per Håkon Meland (per.h.meland@sintef.no)

2. Technology for a better society 2 Customers know exactly what they want All developers understand what the customers want Everyone knows what to do and when to do it The customers never change their mind The budget covers all features (and then some…) Everything is nice and stable In an ideal world…

3. Technology for a better society 3 We need Requirements Engineering (RE)! In our world…

4. Technology for a better society Type of product Hardware/software Simple/complex Critical/leisure Novel/standard Type of development method Waterfall/agile Long-term/rapid Large team/small team Cross-organizational/ single organization 4 Choice of RE method? Courtesy of Tiny Wings

5. Technology for a better society 5 Small projects – keep it simple! https://sourceforge.net/projects/cloudsurfer/

6. Technology for a better society Interconnected software services and tools Collaborative project 18 organizations 42 months ~40 active participants Budget ~14 M€ DoW/contract: 138 pages 6 Case: (not that simple) http://www.aniketos.eu/ RE Goals: Understand Agree upon Work guide Responsibilities

7. Technology for a better society 7 Where did requirements come from in Aniketos?

8. Technology for a better society Describe visions of behaviour Purpose: Requirements elicitation Typically 3-4 requirements per scenario 8 Scenario descriptions (section 4.5.3)

9. Technology for a better society 9 Scenario example

10. Technology for a better society 10 Misuse scenario example

11. Technology for a better society 11 Alternative: Use cases (section 4.5.4) http://www.shields-project.eu/

12. Technology for a better society http://universaal.org/ 12 Alternative: Comic strips

13. Technology for a better society 13 Requirements elicitation and analysis (section 4.5)

14. Technology for a better society 14 Requirements elicitation and analysis (Aniketos)

15. Technology for a better society 15

16. Technology for a better society Start with business requirements/user requirements/high level requirements Easy to understand Technology independent … but may define technology constraints 16 Requirements specification (section 4.3)

17. Technology for a better society 17 ReqID: A unique identifier for each requirement Title: A short title of the requirement (also unique) Description: A description of the requirement Type: The requirements types are based on FURPS: Functionality - Feature set, Capabilities, Generality, Security Usability - Human factors, Aesthetics, Consistency, Documentation Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure Performance - Speed, Efficiency, Resource consumption, Throughput, Response time Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability Source: Originating scenario Target WP: Ownership Structured natural language (section 4.3.1)

18. Technology for a better society 18 Target phase: When Author: Who formulated Related to: Other requirements that (partly) cover the same things. Verification method: Inspection/review Runtime testing Formal proof User feedback Priority: 1: Must have 2: Should have 3: Nice to have Make sure that the requirements can be verified somehow! NB: Pri 2 and 3 are usually overlooked

19. Technology for a better society 19 Example requirements State what the system should do, not how (that's design)

20. Technology for a better society More specific than business requirements and user requirements Often part of the design Technology dependent, short term, internal 20 System requirements

21. Technology for a better society SxC-FR3 Support runtime of security contracts {FR2} SxC-FR3.1 Derive monitoring rules from security contracts {FR2.1} SxC-FR3.1.1 Perform an automatic translation of security contracts to monitoring rules. U1-B SxC-FR3.1.2 Store the monitoring rules. U1-B SxC-FR3.2 Update contracts status based on relevant events {FR2.2} SxC-FR3.2.1 Update stored values: 1) if new data are available 2) if monitoring rules require an update. U1-C SxC-FR3.2.2 Check the monitoring rules. U1-C SxC-FR3.2.3 Store the used values. U1-C 21 System requirements examples

22. Technology for a better society Fulfilment status: Achieved Rejected – The requirement is considered to be out-of-scope or not suitable for the project. Obsolete – The requirement is not considered relevant any more. Redundant – This requirement is already covered by another one. Deferred post-Aniketos – We were not able to achieve this requirement in this project, but still think it is something valuable to do. How addressed: An explanation on how the requirements have been fulfilled Target: The document, module or similar that meets the requirement. Changelog/comments: Written explanations to changes and minor comments (e.g. relationship to other work packages). 22 Management (section 4.7)

23. Technology for a better society The system must never fail and be free from bugs. 23 More examples Not testable Actually two requirements Not very realistic

24. Technology for a better society The system must hash passwords using a salt created with the java.util.Random class. 24 More examples Probably too much of a solution (how) Poor solution as well (java.security.SecureRandom) Technology dependent

25. Technology for a better society The system must be secure. The GUI must be user friendly. The system should have a short response time. 25 More examples Unspecific

26. Technology for a better society The system may log all break-in attempts in a database. 26 More examples Non-committing

27. Technology for a better society Upon password verification, the provided password should be compared with the de- hashed password in the database. If the network is down, the system administrator must be notified (e.g. by e-mail). 27 More examples Stupid!

28. Technology for a better society Input validation Firewall User friendly 28 More examples Incomplete No context

29. Technology for a better society The Aniketos platform should have a developer centre with a download area (to download Aniketos modules/tools/documentation) containing information about requirements and methods of creating Aniketos compliant services. 29 More examples Too long

30. Technology for a better society Only the data administrator should have full access to the user database The support centre should be able to read information about any user 30 More examples Contradicting

31. Technology for a better society The login procedure should take no more than 5 seconds for an average user. The application must implement a two factor authentication procedure. 31 More examples Conflicting: Usability vs security

32. Technology for a better society The ticket ordering system should allow the user to purchase tickets. 32 More examples Irrelevant

33. Technology for a better society 33 More examples Missing!

34. Technology for a better society There is no single RE method for all types of projects Requirements state what the system should do Used for validation (are we making the right product) and verification (are we making it right) Different levels of abstraction Assume that they will change, track changes 34 Summary