1.  Chapter 4 Requirements Engineering Chapter 4 Requirements engineering1

2. Requirements Engineering  May be used in all software Development models  Waterfall  Agile  Reuse  Other Chapter 4 Requirements engineering2

3. Requirements engineering processes  Vary widely.  Common processes  Requirements elicitation;  Requirements analysis;  Requirements validation;  Requirements management.  Typically iterative/interleaved. Chapter 4 Requirements engineering3

4. Requirements Form  Document (Traditional)  Agreement (Agile) Chapter 4 Requirements engineering4

5. What is a Requirement?  What is needed of the system  Allow storage of name, address, phone, SSS for employees  Phone must allow for international number  Valid?  Number of digits for SSS  GUI toolset  Programming Language Chapter 4 Requirements engineering5

6. Levels of requirement  User requirements  High level  For customers  Their terminology  System requirements  Detailed  For development  For contacts Chapter 4 Requirements engineering6

7. User and system requirements Chapter 4 Requirements engineering7

8. Requirement Types  Functional Requirements  Features  Specific functionality  More from users  Non Functional Requirements  Broad concepts  Apply to large functionality  Performance, Capacity, Reliability, Security, Availability  More from developers Chapter 4 Requirements engineering8

9. Types of Requirements  Functional requirements  Functionality needed  Generate map of voters  Compute tips for tax reports  Generate report of sales by location  Non-functional requirements  Constraints  Speed  Reliability  Uptime  Location (from any browser) Chapter 4 Requirements engineering9

10. Functional Requirements  High level  Calculate wages per employees  Medium  Calculate standard wages  Calculate tips  Calculate overtime  Low  Calculate standard tips  Calculate distributed tips Chapter 4 Requirements engineering10

11. Functional Requirement Challenge  Lack of detail  Lack of clarity Chapter 4 Requirements engineering11

12. Non-functional requirements  Scope  Affect large portions of project  Not specific to functionality  Reliability  Availability  Response time  Capacity (number of records)  Constraints (work with an existing system)  IDE  Programming language  Development method  Coding Standards Chapter 4 Requirements engineering12

13. Non-functional – Functional Link  Non functional requirement may generate many functional requirements  Security  Logons  Password recovery Chapter 4 Requirements engineering13

14. Types of nonfunctional requirement Chapter 4 Requirements engineering14

15. Measurability  Non functional requirements must be measurable Chapter 4 Requirements engineering15

16. Metrics for specifying nonfunctional requirements Chapter 4 Requirements engineering16 PropertyMeasure SpeedProcessed transactions/second User/event response time Screen refresh time SizeMbytes Number of ROM chips Ease of useTraining time Number of help frames ReliabilityMean time to failure Probability of unavailability Rate of failure occurrence Availability RobustnessTime to restart after failure Percentage of events causing failure Probability of data corruption on failure PortabilityPercentage of target dependent statements Number of target systems

17. Examples  All error messages will contain enough identification to locate source of problem in code.  All error messages will lead to a solution  No software installation will require system reboot.  All names in code will be self explanatory  All functionality will appear in menus or on dialogs.  All functionality can be accessed via menu or keystroke. Chapter 4 Requirements engineering17

18. Domain requirements  Operational environment  Train brake control system  Temperature range  Humidity range  Gradient range Chapter 4 Requirements engineering18

19. Software Requirements Doc  Agreed upon plan  Critical for waterfall  review may be after extended period  Less critical / formal for agile  Review/change will come soon anyway Chapter 4 Requirements engineering19

20. Agile methods and requirements  Requirements Document  Waste of Time  Inherently out of date  Replaced by user stories Chapter 4 Requirements engineering20

21. The structure of a requirements document Chapter 4 Requirements engineering21 ChapterDescription PrefaceThis should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. IntroductionThis should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. GlossaryThis should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader. User requirements definition Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified. System architectureThis chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted.

22. The structure of a requirements document ChapterDescription System requirements specification This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined. System modelsThis might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolutionThis should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system. AppendicesThese should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. IndexSeveral indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on. Chapter 4 Requirements engineering22

23. Users of a requirements document Chapter 4 Requirements engineering23

24. Requirement Specification Formats  Natural Language  Structured natural language  Design Description language  Graphical  Mathmatical Chapter 4 Requirements engineering24

25. Natural language specification  Natural language sentences  supplemented by diagrams and tables.  Characteristics  expressive,  Intuitive  universal Chapter 4 Requirements engineering25

26. Guideline  Invent a standard format.  Consistent Language  Shall vs. Should  Highlighting, Underlining.  Avoid computer jargon.  Include rationale for requirements

27. Example requirements for the insulin pump software system Chapter 4 Requirements engineering27 3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.) 3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.)

28. Structured specifications  Standard format  Predictable  Forces spec completion  May contain natural language  May be too rigid  Standard sequence  Tabular Chapter 4 Requirements engineering28

29. A structured specification of a requirement for an insulin pump Chapter 4 Requirements engineering29

30. A structured specification of a requirement for an insulin pump Chapter 4 Requirements engineering30

31. Tabular specification of computation for an insulin pump Chapter 4 Requirements engineering31 ConditionAction Sugar level falling (r2 < r1)CompDose = 0 Sugar level stable (r2 = r1)CompDose = 0 Sugar level increasing and rate of increase decreasing ((r2 – r1) < (r1 – r0)) CompDose = 0 Sugar level increasing and rate of increase stable or increasing ((r2 – r1) ≥ (r1 – r0)) CompDose = round ((r2 – r1)/4) If rounded result = 0 then CompDose = MinimumDose

32. Requirements Elicitation Process  Discovery  Classification/ Organization  Prioritization/ Negotiation  Documentation Chapter 4 Requirements engineering32

33. Elicitation - Participants  Development personnel  System engineers  Developers  Managers  Customer  Managers  Engineers,  Domain experts  Trade unions Chapter 4 Requirements engineering33

34. Elicitation Problems  Stakeholders  limited understanding of needs  Assume basic knowledge of their domain  Availability  Multiple stakeholders  Different priorities  Conflicting requirements  Which stakeholder  Manager  User  Changing business  Generally  Due to the system itself Chapter 4 Requirements engineering34

35. Discovery Approaches  Interview  Scenario  Use Case  Ethnography Chapter 4 Requirements engineering35

36. Types of Interviews  Types of interview  Closed  list of questions  Open  various issues explored. Chapter 4 Requirements engineering36

37. Interviews in practice  Be prepared with questions  BUT, start with open ended questions  Bring up issues where you expect will cause problems

38. Scenarios  Real-life examples of how a system can be used.  Include  description of the starting situation  description of the normal flow of events  description of what can go wrong  Information about other concurrent activities  description of the state when the scenario finishes

39. Scenario for collecting medical history in MHC-PMS Chapter 4 Requirements engineering39

40. Scenario for collecting medical history in MHC-PMS Chapter 4 Requirements engineering40

41. Use cases  UML  Actors, Interaction  Should describe all possible interactions with the system.  Graphical or tabular Chapter 4 Requirements engineering41

42. Use cases for the MHC-PMS Chapter 4 Requirements engineering42

43. Ethnography  Based on interviews  Watching people work  Often < 1hr  Capture  Interactions  Activities  Data  Forms  Pressures Chapter 4 Requirements engineering43

44. Ethnography  Model the work environment  Process flow  Interactions  Data  Context Chapter 4 Requirements engineering44

45. Ethnography  Useful for  Understanding environment  People involved  Current Processes  Implicit environment  Workflow  Implicit aspects of work that people don’t explain  Understanding without formal explanation  Shows that work is usually richer and more complex than suggested by simple system models. Chapter 4 Requirements engineering45

46. Pros/Cons  Pros  Actual work not concept  Develops thorough knowledge of users, environment  Cons  Focused only on existing process  Focused only on needs of users Chapter 4 Requirements engineering46

47. Focused ethnography  Combines ethnography with prototyping  Prototype can be evaluated in the work environment Chapter 4 Requirements engineering47

48. Requirements checking  Validity. Does the system provide the functions which best support the customer’s needs?  Consistency. Are there any requirements conflicts?  Completeness. Are all functions required by the customer included?  Realism. Can the requirements be implemented given available budget and technology  Verifiability. Can the requirements be checked? Chapter 4 Requirements engineering48

49. Requirements validation techniques  Requirements reviews  Systematic manual analysis of the requirements.  Prototyping  Using an executable model of the system to check requirements. Covered in Chapter 2.  Test-case generation  Developing tests for requirements to check testability. Chapter 4 Requirements engineering49

50. Requirements reviews  Regular  Client and contractor  Formal or informal Chapter 4 Requirements engineering50

51. Review checks  Verifiability  Is the requirement realistically testable?  Comprehensibility  Is the requirement properly understood?  Traceability  Is the origin of the requirement clearly stated?  Adaptability  Can the requirement be changed without a large impact on other requirements? Chapter 4 Requirements engineering51

52. Requirements Management  Tracking changes to requirements  New requirements  Changed requirements  Dropped Requirements  “Scope creep” Chapter 4 Requirements engineering52

53. Requirements Management  Implicit part of agile development Chapter 4 Requirements engineering53

54. Changing requirements  The business and technical environment of the system always changes after installation.  New hardware  necessary to interface the system with other systems  business priorities change  new legislation and regulations may be introduced  Budgetary changes  The people who pay for a system and the users of that system are rarely the same people. Chapter 4 Requirements engineering54

55. Changing requirements  Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory.  The final system requirements are inevitably a compromise between them and, with experience, it is often discovered that the balance of support given to different users has to be changed. Chapter 4 Requirements engineering55