1. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 1 Chapter 6 Software Requirements

2. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 2 Objectives l To introduce the concepts of abstract “user” and more detailed “system” requirements. l To describe “functional” and “non-functional” requirements. l To explain two techniques for describing system requirements: structured NL and PDLs. l To suggest how software requirements may be organized in a requirements document.

3. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 3 Requirements engineering (RE) l The process of eliciting, analyzing, docu- menting, and validating the services required of a system and the constraints under which it will operate and be developed. l Descriptions of these services and con- straints are the requirement specifications for the system.

4. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 4 RE is both very hard and critical The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult… No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. – Fred Brooks, “No Silver Bullet…”

5. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 5 Why is RE so hard? l Difficulty of anticipation l Unknown or conflicting requirements / priorities (“I’ll know what I want when I see it.”) l Conflicts between & among users and procurers l Fragmented nature of requirements l Complexity / number of distinct requirements (More reasons in Chap. 6)

6. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 6 an·tic·i·pa·tion noun, 14th century 1. a prior action that takes into account or forestalls a later action; 2. the act of looking forward; 3. visualization of a future event or state. We can never know about the days to come, but we think about them anyway…Anticipation, anticipation is makin' me late, Is keepin' me waitin’. -Carly Simon

7. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 7 Why is RE so hard? l Difficulty of anticipation l Unknown or conflicting requirements / priorities (“I’ll know what I want when I see it.”) l Conflicts between & among users and procurers l Fragmented nature of requirements l Complexity / number of distinct requirements (More reasons in Chap. 6)

8. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 8 Why is RE so hard? (cont’d) l Some analogies:  Working a dynamically changing jigsaw puzzle  Blind men describing an elephant  Different medical specialists describing an ill patient

9. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 9 Requirements uses l Requirements range from being high-level and abstract to detailed and mathematical. l Inevitable as requirements serve multiple uses...  May be the basis for a bid for a contract – must be open to interpretation;  May be the basis for the contract itself – must be defined in detail;  May be the basis for design and implementation – must bridge requirements engineering and design activities.

10. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 10 Levels of requirements specification l “User requirements” – statements in natural language plus diagrams of system services and constraints. Written primarily for customers. l “System requirements” – structured document setting out detailed descriptions of services and constraints precisely. May serve as a contract between client and developer. l “Software design specification” – implementation oriented abstract description of software design which may utilize formal (mathematical) notations. Written for developers. Terminology is a problem…

11. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 11 User vs. system requirements 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 1.2 external files. 1.2 Each external file type may have an associated tool which may be 1.2 applied to the file. 1.3 Each external file type may be represented as a specific icon on 1.2 the user’s display. 1.4 Facilities should be provided for the icon representing an 1.2 external file type to be defined by the user. 1.5 When a user selects an icon representing an external file, the 1.2 effect of that selection is to apply the tool associated with the type of 1.2 the external file to the file represented by the selected icon. “User requirement”: Corresponding “System requirements”:

12. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 12 Requirements readers + lawyers

13. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 13 “Functional, non-functional, and domain requirements” l “Functional requirements” – services the system should provide, how it should react to particular inputs, or how it should behave in particular situations. l “Non-functional requirements” – constraints on services or functions (e.g., response time) or constraints on development process (e.g., use of a particular CASE toolset). l “Domain requirements” – “ functional or non- functional requirements” derived from application domain (e.g., legal requirements or physical laws).

14. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 14 Examples of “functional requirements” l The user shall be able to search either all of the initial set of databases or select a subset from it. l The system shall provide appropriate viewers for the user to read documents in the document store. l Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area. (Test of function: “We want the product to…” or “The product shall…”) ?

15. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 15 “Non-functional requirements” l Define system attributes (e.g., reliability, response time) and constraints (e.g., MTTF ≥ 5K transactions, response time ≤ 2 seconds).  Attributes are often emergent system properties – i.e., only observable when the entire system is operational. l Define process constraints (e.g., use of a particular CASE system, programming language, or development method).

16. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 16 “Non-functional requirements” are not second class requirements l “Non-functional requirements” may be more critical than “functional requirements.” If not met, the system may be useless.

17. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 17 General non-functional classifications l “Product requirements” – specify product behavior. l “Organizational requirements” – derived from policies / procedures in customer’s or developer’s organization (e.g., process constraints). l “External requirements” – derived from factors external to the product and its development process (e.g., interoperability requirements, legislative requirements). (Note: these are not orthogonal classifications)

18. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 18 General non-functional classifications (cont’d)

19. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 19 Examples l “Product requirement”: 4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set. l “Organizational requirement”: 9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95. l “External requirement”: 7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system. APSE = Ada Programming Support Environment

20. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 20 “GOALS” vs. (verifiable) REQUIREMENTS l General goals such as “system should be user friendly” or “system should have fast response time” are not verifiable. l “Goals” should be translated into quantitative requirements that can be objectively tested.

21. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 21 Example of system “GOAL” versus verifiable system REQUIREMENT l A system “goal”: The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. l A verifiable non-functional system requirement: Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

22. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 22 Attribute measures

23. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 23 Requirements interactions l Competing/conflicting requirements are common. l Spacecraft system example:  To minimize weight, the number of chips in the unit should be minimized.  To minimize power consumption, low-power chips should be used.  But using low-power chips means that more chips have to be used. l For this reason, preferred points in the solution space should be identified.

24. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 24 Preferred points in a solution space Power Consumption Weight lowhigh low high Weight constraint Power Consumption constraint

25. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 25 Preferred points in a solution space Power Consumption Weight lowhigh low high Weight constraint Power Consumption constraint = feasible solutions

26. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 26 Preferred points in a solution space Power Consumption Weight lowhigh preferred solutions low high Weight constraint Power Consumption constraint = feasible solutions

27. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 27 “Domain requirements” l Derived from the application domain rather than user needs. l May be functional or non-functional. l If “domain requirements” are not satisfied, the system may be unworkable.

28. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 28 Train protection system domain requirement l The deceleration of the train shall be computed as: D train = D control + D gradient where D gradient is 9.81m/s 2 * compensated gradient/alpha and where the values of 9.81m/s 2 /alpha are known for different types of trains. (physical law)

29. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 29 “Domain requirements” problems l Understandability – requirements are often expressed in the language of the application domain and may not be understood by software engineers. l Implicitness – domain experts may not communicate such requirements because they are so obvious (to the experts).

30. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 30 Requirements specification issues l Completeness and consistency problems l “User” vs. “system” requirements l Natural language vs. PDL’s vs. graphical representations l “Interface” vs. “operational” specifications l Specification requirements and “standards”

31. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 31 Requirements completeness and consistency l In principle, a requirements specification should be both complete and consistent.  Complete – all required services and constraints are defined.  Consistent – no conflicts or contradictions in the requirements. l In practice, this is nearly impossible.

32. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 32 “User requirements” l Understandable by system users who don’t have detailed technical knowledge. l Specify external system behavior (plus any user-specified implementation constraints.) l Utilize natural language, forms/tables, and simple, intuitive diagrams.

33. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 33 Some potential problems with using natural language l Ambiguity – requirements may be unclear or may be interpreted in different ways.  Consider the term “appropriate viewers” in: “The system shall provide appropriate viewers for the user to read documents in the document store.”  Expressing requirements unambiguously is difficult without making documents wordy and hard to read.

34. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 34 Mary had a little lamb. Mary had a little lamb heuristic (From Gause & Weinberg, Quality Before Design)

35. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 35 Mary had a little lamb. Mary owned a petite lamb. Mary consumed a small amount of lamb. Mary was involved with a young sheep. Mary conned the trader. Mary conned the trader heuristic (From Gause & Weinberg, Quality Before Design)

36. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 36 Some potential problems with using natural language (cont’d) l Requirements confusion – functions, constraints, goals, and design info may not be clearly distinguished. l Requirements amalgamation – several different requirements may be lumped together. l See illustrations on pp. 127-128. Basic problem: need for different models of / perspectives on requirements.

37. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 37 Guidelines for writing “user requirements” l Adopt a standard format and use it for all requirements. l Use language in a consistent way. E.g., use shall for mandatory requirements, should for desirable requirements. l Use text highlighting to emphasize key parts of the requirement. l Avoid the use of computer (and other types of) jargon.

38. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 38 “System requirements” l More detailed, precise descriptions of user requirements. l May serve as the basis for a contract. l Starting point for system design and implementation. l May utilize different system models such as object or dataflow.

39. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 39 “System requirements” and design information l System requirements normally state what the system should do, and not how it should be designed. l But some design info may be incorporated since:  Sub-systems may be defined to help structure the requirements. (Requirements may be grouped by sub-system.)  Interoperability requirements may constrain the design.  Use of a specific design model may be a requirement.

40. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 40 MORE potential problems with using natural language l Over-flexibility – the same requirement may (and probably should) be stated in a number of different ways. (Readers must determine when requirements are the same and when they are different.) l Lack of modularization – NL structures are inadequate to organize system requirements sufficiently.

41. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 41 Alternatives to NL specification “PDL’s” 10.

42. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 42 Structured natural language form / template

43. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 43 Program Description Languages (PDLs) l Requirements are specified operationally using pseudo-code. l Shows what is required by illustrating how the requirements could be satisfied. l Especially useful when specifying a process that involves an ordered sequence of actions.

44. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 44 Part of an ATM specification JAVA based. Generic pseudocode is more abstract and therefore easier to understand.

45. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 45 PDL disadvantages l PDL may not be sufficiently expressive to illustrate requirements in a concise and understandable way. l Notation is only understandable to people with programming language knowledge. l The specification may be taken as a design prescription rather than a model to facilitate requirements understanding. Can you think of ways to eliminate or mitigate these potential risks?

46. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 46 Graphical representations (See Chapter 8) l Graphical models are particularly useful in describing  system environments (context models)  data structures and flows (semantic data models / dataflow diagrams)  state changes and system responses to events (state machine models)  classification and aggregation of system entities (object models)  dynamic system behavior (sequence models)

47. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 47 The context of an ATM system

48. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 48 Graphical representations (See Chapter 8) l Graphical models are particularly useful in describing  system environments (context models)  data structures and flows (semantic data models / dataflow diagrams)  state changes and system responses to events (state machine models)  classification and aggregation of system entities (object models)  dynamic system behavior (sequence models)

49. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 49 Library semantic model

50. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 50 Order processing DFD

51. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 51 Graphical representations (See Chapter 8) l Graphical models are particularly useful in describing  system environments (context models)  data structures and flows (semantic data models / dataflow diagrams)  state changes and system responses to events (state machine models)  classification and aggregation of system entities (object models)  dynamic system behavior (sequence models)

52. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 52 Microwave oven model

53. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 53 Graphical representations (See Chapter 8) l Graphical models are particularly useful in describing  system environments (context models)  data structures and flows (semantic data models / dataflow diagrams)  state changes and system responses to events (state machine models)  classification and aggregation of system entities (object models)  dynamic system behavior (sequence models)

54. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 54 Library class hierarchy

55. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 55 Graphical representations (See Chapter 8) l Graphical models are particularly useful in describing  system environments (context models)  data structures and flows (semantic data models / dataflow diagrams)  state changes and system responses to events (state machine models)  classification and aggregation of system entities (object models)  dynamic system behavior (sequence models)

56. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 56 Example: UML “Sequence diagrams” l These show the sequence of events that take place during some user interaction with a system. l You read them from top to bottom to see the order of the actions that take place. l Cash withdrawal from an ATM  Validate card;  Handle request;  Complete transaction.

57. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 57 “Sequence diagram” of ATM withdrawal

58. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 58 “Interface specifications” l Used to specify operating interfaces with other systems.  Procedural interfaces (e.g., function, procedure, or method names)  Data structures that are exchanged  Data representations (if necessary) l Also used to specify functional behavior.  Formal notations (e.g., pre- and post-conditions) are effective.

59. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 59 PDL-based interface description Method names and required parameters.

60. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 60 “Interface specifications” l Used to specify operating interfaces with other systems.  Procedural interfaces (e.g., function, procedure, or method names)  Data structures that are exchanged  Data representations (if necessary) l Also used to specify functional behavior.  Formal notations (e.g., pre- and post-conditions) are effective.

61. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 61 Example: “interface” vs. “operational” specifications of a simple function Function: Set BIG to the largest value in array A[1..N] “interface specification”: pre-condition: N ≥ 1 post-condition: there exists an i in [1,N] such that BIG=A[i] & for every j in [1,N], BIG ≥ A[j] & A is unchanged

62. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 62 Example: “interface” vs. “operational” specifications of a simple function Function: Set BIG to the largest value in array A[1..N] “operational specification”: if N ≥ 1 then do BIG := A[1] for i = 2 to N do if A[i] > BIG then BIG := A[i] end_if end_for end_if

63. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 63 The requirements document (SRS – “Software Requirements Specification”) l Official statement of what is required of system developers. l Includes both user and system requirements. l NOT a design document. As much as possible, it should set out WHAT the system should do rather than HOW it should do it.

64. Users of an SRS

65. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 65 Requirements document requirements (Henniger ’80) l Should specify external system behavior. l Should specify implementation constraints. l Should be easy to change (!) l Should serve as a reference tool for maintenance. l Should include forethought about the life cycle of the system (i.e., predicted changes). l Should specify responses to unexpected events.

66. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 66 IEEE requirements “standard*” l Generic Structure:  Introduction  General description  Specific requirements  Appendices  Index l Instantiated for specific systems. *IEEE Disclaimer: “This is not a standard…” More detail in text. (p. 137)

67. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 67 Requirements document structure l Preface (intended readers, version, change history) l Introduction l Glossary l User requirements definition l System architecture l System requirements specification l System models l System evolution l Appendices l Index An instantiated version of the IEEE model

68. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 68 Key points l Requirements set out what the system should do and define constraints on its operation and implementation. l “Functional requirements” set out services the system should provide l “Non-functional requirements” constrain the system being developed or the development process. (cont’d)

69. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 69 Key points (cont’d) l “User requirements” are high-level statements of what the system should do. l They should be written in natural language, forms/tables, and diagrams. (cont’d)

70. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 70 Key points (cont’d) l “System requirements” are intended to communicate the functions that the system should provide (more precisely than “user requirements”). l They should be written in structured natural language, a PDL, or in a formal language. l A software requirements document (SRS) is the agreed statement of a system’s requirements (both “User” and “System”).

71. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 71 A review of Sommerville’s classifications of requirements l “Functional” vs. “Non-Functional” l Within the “Non-Functional” category:  “Product” vs. “Organizational” vs. “External” (3 different sources)  “Goals” vs. verifiable (non-functional) requirements l “Domain requirements” (a 4 th source; may be “functional” or “non-functional”) l “User” vs. “System” vs. “Software Design Specification” (different levels and intended uses) l “Operational” vs. “Interface”

72. ©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 72 Chapter 6 Software Requirements