1. TDT 4242 Inah Omoronyia and Tor Stålhane Requirements Specification and Testing An introduction TDT 4242 Institutt for datateknikk og informasjonsvitenskap

2. TDT 4242 Challenges in Requirements Engineering What is a requirement? What a system must do (functional): System requirements How well the system will perform its functions (non-functional): System quality attributes defined operational capabilities business needs satisfy The RE process: Ultimately:

3. TDT 4242 Challenges in Requirements Engineering

4. TDT 4242 Challenges in Requirements Engineering Source: Benoy R Nair (IBS software services) Importance of getting requirements right: 1/3 budget to correct errors originate from requirements

5. TDT 4242 Challenges in Requirements Engineering Source: Benoy R Nair (IBS software services) Factors that make a software project challenging:

6. TDT 4242 Challenges in Requirements Engineering Source: Benoy R Nair (IBS software services) Why projects are cancelled:

7. TDT 4242 Requirements Development - 1 Requirements Elicitation: The process of discovering the requirements for a system by communication with customers, system users and others who have a stake in the system development. Requirements gathering techniques Methodical extraction of concrete requirements from high level goals Requirements quality metrics

8. TDT 4242 Requirements Development – 2 Effects of Inadequate Requirements development – Ariane 5: (An expendable launch system used to deliver payloads into geostationary transfer orbit or low Earth orbit) Ariane 5 succeeded Ariane 4. Wrong implicit assumptions about the parameters, in particular the horizontal velocity that were safe for Ariane 4 but not Ariane 5. horizontal velocity exceeded the maximum value for a 16 bit unsigned integer when it was converted from it's signed 64 bit representation. Ariane 5: component (requirements) should have been designed for reuse – but the context of reuse was not specified. Cost of poor requirements in Ariane 5 Data overflow on launch Self-destruction of the complete system Loss > 500 Million EUR

9. TDT 4242 Requirements Development – 3 Effects of Inadequate Requirements development – Airbus: Requirement: Reverse thrust may only be used, when the airplane is landed. Translation: Reverse thrust may only be used while the wheels are rotating. Implementation: Reverse thrust may only be used while the wheels are rotating fast enough. Situation: Rainstorm – aquaplaning Result: Crash due to overshooting the runway! Problem: erroneous modeling in the requirement phase

10. TDT 4242 Problem world and machine solution The problem to be solved is rooted in a complex organizational, technical or physical world. The aim of a software project is to improve the world by building some machine expected to solve the problem. Problem world and machine solution each have their own phenomena while sharing others. The shared phenomena defines the interface through which the machine interacts with the world. E-commerce world Requirements engineering is concerned with the machine’s effect on the surrounding world and the assumption we make about that world.

11. TDT 4242 Formulation of requirements statements Statement scope: Phenomenon of train physically moving is owned by environment. It cannot be directly observed by software phenomenon The phenomenon of train measured speed being non-null is shared by software and environment. It is measured by a speedometer in the environment and observed by the software.

12. TDT 4242 Two types of requirements statements Descriptive statements: state properties about the system that holds regardless of how the system behaves. E.g. If train doors are open, they are not closed. Prescriptive statements: States desirable properties about the system that may hold or not depending on how the system behaves Need to be enforced by system components E.g. Train doors shall always remain closed when the train is moving

13. TDT 4242 Formulation of system requirement A prescriptive statement enforced by the software-to-be. Possibly in cooperation with other system components Formulated in terms of environment phenomena Example: All train doors shall always remain closed while the train is moving In addition to the software-to-be we also requires the cooperation of other components: Train controller being responsible for the safe control of doors. The passenger refraining from opening doors unsafely Door actuators working properly

14. TDT 4242 Formulation of software requirement A prescriptive statement enforced solely by the software-to- be. Formulated in terms of phenomena shared between the software and environment. The software “understand” or “sense” the environment through input data Example: The doorState output variable shall always have the value ‘closed’ when the measuredSpeed input variable has a non- null value

15. TDT 4242 Domain properties A domain property: Is a descriptive statement about the problem world Should hold invariably regardless of how the system behaves Usually corresponds to some physical laws Example: A train is moving if and only if its physical speed is non-null.

16. TDT 4242 Goal orientation in requirements engineering – 1 A goal is an objective that the system under consideration shall achieve. –Ranges from high-level strategic to low-level technical concerns over a system –System consist of both the software and its environment. Interaction between active components, i.e. devices, humans, software etc also called Agents

17. TDT 4242 Goal orientation in requirements engineering – 2 Goals can be stated at different levels of granularity: –High-level goal: A goal that requires the cooperation of many agents. They are normally stating strategic objective related to the business, e.g. The system’s transportation capacity shall be increased by 50% –Requirement: A goal under the responsibility of a single agent in the software-to-be. –Assumption (expectation): A goal under the responsibility of a single agent in the environment of the software-to-be. Assumptions cannot be enforced by the software-to-be

18. TDT 4242 Goal statement typology

19. TDT 4242 Goal types

20. TDT 4242 Behavioral goal specialization

21. TDT 4242 Goal categorization – 1 Goal categories are similar to requirements categories:

22. TDT 4242 Goal categorization – 2 Functional goal: States the intent underpinning a system service Satisfaction: Functional goals concerned with satisfying agent request Information: Functional goals concerned with keeping agents informed about important system states Stimulus-response: Functional goals concerned with providing appropriate response to specific event Example: The on-board controller shall update the train’s acceleration to the commanded one immediately on receipt of an acceleration command from the station computer

23. TDT 4242 Goal categorization – 3 Non-functional goal: States a quality or constraint on service provision or development. Accuracy goal: Non-functional goals requiring the state of variables controlled by the software to reflect the state of corresponding quantities controlled by environment agent E.g: The train’s physical speed and commanded speed may never differ by more than X miles per hour Soft goals are different from non-functional goals. Soft goals are goals with no clear-cut criteria to determine their satisfaction. E.g: The ATM interface should be more user friendly

24. TDT 4242 Goal refinement A mechanism for structuring complex specifications at different levels of concern. A goal can be refined in a set of sub-goals that jointly contribute to it. Each sub-goal is refined into finer-grained goals until we reach a requirement on the software and expectation (assumption) on the environment. NB: Requirements on software are associated with a single agent and they are testable

25. TDT 4242 Goal refinement: Example

26. TDT 4242 Goal refinement tree – 1 Refinement links are two way links: One showing goal decomposition, the other showing goal contribution

27. TDT 4242 Goal refinement tree – 2 Goal feature annotation

28. TDT 4242 Requirements quality metrics – 1 Qualitative Goal-Requirements tracing: An approach to requirements refinement/abstraction that makes it less likely to generate trace links that are ambiguous, inconsistent, opaque, noisy, incomplete or with forward referencing items

29. TDT 4242 Requirements quality metrics – 2 Ambiguity: Requirement with terms or statements that can be interpreted in different ways. Sub-class concept reasoning: Inconsistency: Requirement items that are not compatible with other requirement nodes. Predefined semantic reasoning – Cc

30. TDT 4242 Requirements quality metrics – 3 Forward Referencing: Requirement items that make use of problem world domain features that are not yet defined. E, C and D need to be mapped to a requirement item

31. TDT 4242 Requirements quality metrics – 4 Opacity: Requirement items for which rational or dependencies are invisible. Multiple unrelated concept mapping. A is not related to B

32. TDT 4242 Requirements quality metrics – 5 Noise: Requirement items that yield no information on problem world features. X refers to a concept undefined in the domain

33. TDT 4242 Requirements quality metrics – 6 Completeness: The needs of a prescribed system are fully covered by requirement items without any undesirable outcome. No requirement item mentions the goal concept Z

34. Quality metrics on a requirements set provides useful understanding, tracking and control of requirements improvement process. Requirements quality metrics

35. TDT 4242 Where do the goals come from? We get goals from: Preliminary analysis of the current system. Systematically by searching intentional keywords in documents provided, interview transcripts etc. E.g. ‘objective’, ‘purpose’, ‘in order to’. Iterative refinement and abstraction of high-level goals: By asking the how and why question. Results in a goal refinement tree Approaches: KAOS – Goal driven requirements acquisition.

36. TDT 4242 Summary Goals can be defined at different levels of abstraction There are two types of goals: Behavioral or soft goal There are several categories of goals, e.g. Functional and non-functional Goal refinement provides a natural mechanism for structuring complex specifications at different levels of concern: Goal refinement graph