2. Requirements Engineering © NC State Software Engineering Faculty L01 - 1

3. Scope of Software Project Failures WHY PROJECTS FAIL % 1. Incomplete Requirements13.1 2. Lack of user involvement12.4 3. Lack of resources10.6 4. Unrealistic Expectations 9.9 5. Lack of executive support 9.3 6. Changing requirements 8.7 7. Lack of planning 8.1 8. Didn’t need it any longer 7.5 9. Lack of IT management 6.2 10. Technology illiteracy 4.3 Jim Johnson, The Standish Group International Project Leadership Conference, May 1995, Chicago © NC State Software Engineering Faculty L01 - 2

4. Relative Cost to Fix an Error Boehm’s analysis of 63 s/w development projects (IBM, GTE, TRW, etc.) to Determine ranges in cost for errors created by false assumptions in req’ts phase But not detected till later phases © NC State Software Engineering Faculty L01 - 3

5. Requirements Software Requirement: condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document –Description of what the customers wants –May be buried beneath layers of assumptions, misconceptions, and politics © NC State Software Engineering Faculty L01 - 4

6. Requirements Engineering Systematic way of developing requirements through an iterative process –Iteration may involve traditional requirements and use cases Results in a specification of the system that stakeholders understand –natural language –easy to understand pictures (UML Diagrams) A stakeholder is a key representative of the groups who have a vested interest in your system and direct or indirect influence on its requirements. –Who are the stakeholders for your project? Think beyond the project sponsors… –Identify stakeholders at sponsor meetings © NC State Software Engineering Faculty L01 - 5

7. Requirements Engineering (2) Analysis: studying user needs to generate system definition that users understand –Fact-finding –Communication –Fact-validation Modeling: translating requirements the user understands to a form that software engineers understand –Representation –Organization © NC State Software Engineering Faculty L01 - 6

8. Types of Requirements Functional requirements: requirements that specify a function that a system or system component must be able to perform –The watch shall display the time. Non-functional requirements: not specifically concerned with the functionality of a system but place restrictions on the product being developed –User visible aspects of the system not directly related to functional behavior –Usability; reliability; privacy; security; availability; performance –Best to translate non-functional to measurable. The response time must be less than 1 second Constraints (“Pseudo requirements”): not user-visible; imposed by the client that restricts the implementation of the system or the development process –The implementation language must be Java. –Unit tests must be written in JUnit. © NC State Software Engineering Faculty L01 - 7

9. Requirements Elicitation Need to understand why not just what –The “why” is the business case and provides context Techniques –Interviews –Observation –Examining Documents and Artifacts –Join Application Design Sessions (JAD) –Groupware –Questionnaires –Prototypes –Focus Groups –On-Site Customer © NC State Software Engineering Faculty L01 - 8

10. Requirements Validation Critical step in the development process, –Usually after requirements engineering or requirements analysis. Also at delivery Requirements validation criteria: –Correctness: The requirements represent the client’s view. –Completeness: All possible scenarios through the system are described, including exceptional behavior by the user or the system –Consistency: There are no functional or nonfunctional requirements that contradict each other –Clarity: There are no ambiguities in the requirements. –Concise Don’t “boil the ocean” or extend beyond what is in current release © NC State Software Engineering Faculty L01 - 9

11. Requirements Validation Criteria (continued) Feasible: –Requirements can be implemented and delivered Traceability: –Each system function can be traced to a corresponding set of functional requirements Understandable Non-prescriptive –everything about what the customer wants and nothing about how the programmer(s) will do it. Consistent language –Shall, should, may –“the physician” vs. “the doctor” Testable © NC State Software Engineering Faculty L01 - 10

12. Requirements Validation Criteria (continued) Shall (== is required to): used to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted: must or will is obsolete Should (== is recommended that): used to indicate –among several possibilities one is recommended as particularly suitable, without mentioning or excluding others –or that a certain course of action is preferred but not necessarily required; –or that (in the negative form) a certain course of action is deprecated but not prohibited May (== is permitted to): used to indicate a course of action permissible within the limits of the standard Can (== is able to): used for statements of possibility and capability, whether material, physical, or causal https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf See Section 11.2.2 © NC State Software Engineering Faculty L01 - 11

13. Types of Requirements Statements Traditional –“The system shall” Use case based (e.g., iTrust) User story – married with acceptance test to supply the detail –Agile requirements © NC State Software Engineering Faculty L01 - 12

14. Traditional Requirements FR2.4 Go to Jail When the player lands on the Go to Jail cell, the player shall be sent to the Jail cell. The player shall not receive $200 if she or he passes the Go cell on the way to the Jell cell. FR2.5 Buy Property When the player lands on a tradable cell, including properties, railroads, and utilities, she or he shall have a chance to buy that cell given that the cell is available. If the player clicks on the Buy button, the cell shall be sold to the player. See FR3 for the price rules on the properties, railroads, and utilities. © NC State Software Engineering Faculty L01 - 13

15. Traditional Requirements NR1.1 User Response The system shall respond to any user input within 0.01 seconds. Constraints –All code development shall be done with the Java programming language –All testing shall be done using JUnit and FIT © NC State Software Engineering Faculty L01 - 14

16. Use Case-Based Requirement Elicitation Use cases describe functional aspects of the system UML focuses on scenario-based requirements elicitation Scenario: –sequence of actions that illustrates behavior. –A scenario may be used to illustrate an interaction or the execution of a use case instance © NC State Software Engineering Faculty L01 - 15

17. External System Behavior: Use Case Model Complete course of events in the system, from the user’s perspective Use Cases Model: Illustrates –(use cases) the system’s intended functions –(actors) surroundings – external to the system –(use case diagrams) relationships between use cases and actors The collection of all use cases is everything that can be done to/with the system © NC State Software Engineering Faculty L01 - 16

18. Actors Are NOT part of the system – they represent anyone or anything that must interact with the system –Only input information to the system –Only receive information from the system –Both input to and receive information from the system Represented in UML as a stickman, even when they are not “people”, such as a billing system © NC State Software Engineering Faculty L01 - 17

19. Use Case A sequence of transactions performed by a system that yields a measurable result of values for a particular actor A use case typically represents a major piece of functionality that is complete from beginning to end. A use case must deliver something of value to an actor. Use cases that an actor “wants” begin with verbs. © NC State Software Engineering Faculty L01 - 18

20. Template for Flow of Events X Flow of Events for the Use Case X.1 Preconditions What needs to happen (in another use case) before this use case can start? X.2 Main Flow X.3 Subflows Break “normal” flow into pieces “called” by Main Flow or another subflow X.4 Alternative Flows Things that happen outside of the “normal” flow “called” by Main Flow or a subflow  Covers multiple related scenarios!!! © NC State Software Engineering Faculty L01 - 19

21. Clear Intersection Example User wants to drive through an intersection. The user can only clear through the intersection if the traffic light is green and there are no cars in the intersection. Otherwise, the car needs to join a queue. © NC State Software Engineering Faculty L01 - 20

22. 1. Flow of Events for the Clear Intersection Use Case 1.1 Preconditions Traffic light has been initialized 1.2 Main Flow This use case begins when a car enters the intersection. The car checks its status [S1]. The use case ends when the car clears the intersection [S4]. 1.3 Subflows S1 Check Status: Check status [S2, S3]. If the light is green, and the queue is empty, the car clears the intersection [S4]. Otherwise, it joins a queue [S5]. S2 Check Light: Send information on whether the light is red, yellow, or green. S3 Check Queue: Send information on whether the queue is empty or not S4 Go: The car clears the intersection and the use case ends. S5 Join a Queue: Car is added to queue © NC State Software Engineering Faculty L01 - 21

23. Scenario: Car approaches intersection with green light and no queue © NC State Software Engineering Faculty L01 - 22 1.1 Preconditions Traffic light has been initialized 1.2 Main Flow This use case begins when a car enters the intersection. The car checks its status [S1]. The use case ends when the car clears the intersection [S4]. 1.3 Subflows S1 Check Status: Check status [S2, S3]. If the light is green, and the queue is empty, the car clears the intersection [S4]. Otherwise, it joins a queue [S5]. S2 Check Light: Send information on whether the light is red, yellow, or green. S3 Check Queue: Send information on whether the queue is empty or not S4 Go: The car clears the intersection and the use case ends. S5 Join a Queue: Car is added to queue

24. Scenario: Car approaches intersection with red light and no queue © NC State Software Engineering Faculty L01 - 23 1.1 Preconditions Traffic light has been initialized 1.2 Main Flow This use case begins when a car enters the intersection. The car checks its status [S1]. The use case ends when the car clears the intersection [S4]. 1.3 Subflows S1 Check Status: Check status [S2, S3]. If the light is green, and the queue is empty, the car clears the intersection [S4]. Otherwise, it joins a queue [S5]. S2 Check Light: Send information on whether the light is red, yellow, or green. S3 Check Queue: Send information on whether the queue is empty or not S4 Go: The car clears the intersection and the use case ends. S5 Join a Queue: Car is added to queue

25. 1. Flow of Events for the Clear Intersection Use Case © NC State Software Engineering Faculty L01 - 24 1.1 Preconditions Traffic light has been initialized 1.2 Main Flow This use case begins when a car enters the intersection. The car checks its status [S1]. The use case ends when the car clears the intersection [S4]. 1.3 Subflows S1 Check Status: Check status [S2, S3, E1, E2]. If the light is green, and the queue is empty, the car clears the intersection [S4]. Otherwise, it joins a queue [S5]. S2 Check Light: Send information on whether the light is red, yellow, or green. S3 Check Queue: Send information on whether the queue is empty or not S4 Go: The car clears the intersection and the use case ends. S5 Join a Queue: Car is added to queue 1.4 Alternative Flows E1 Light Out: The light is not red, yellow, or green. Wait for clear intersection and gun it. E2 Accident: An accident is blocking the intersection. Rubber neck and slowly drive around it.

26. Flow of Events vs Scenario Flow of events enumerates all subflows and exception flows. Scenario is one path through your flow of events When you’re testing, make sure you cover a reasonable (80%??) set of scenarios. © NC State Software Engineering Faculty L01 - 25

27. Stereotypes Use Case X (Login to System) includes Use Case Y (Update User Activity Log): –X has a multi-step subtask Y. In the course of doing X or a subtask of X, Y will always be completed. Use Case X (Obtain Student info Updates) extends Use Case Y (Login to System): –Y performs a sub-task and X is a similar but more specialized way of accomplishing that subtask. X only happens in an exception situation. Y can complete without X ever happening. © NC State Software Engineering Faculty L01 - 26

28. Requirements in Senior Design Requirements must be written in a traditional format – “The system shall….” –Requirements must be numbered –Related requirements should be grouped under subheadings –Each functional traditional requirement should have an associated acceptance test! © NC State Software Engineering Faculty L01 - 27

29. Requirements in Senior Design Use cases are an excellent tool to identify related scenarios and can drive creation of traditional requirements –Sponsors like to discuss scenarios –Iterate between use cases and traditional requirements –If you write use cases, include them in your progress report © NC State Software Engineering Faculty L01 - 28