1. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Chapter 5 Software Requirements

2. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 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, 6th edition. Chapter 5 Slide 3 Requirements engineering 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 requirements for the system. l Requirements may be high-level and abstract, or detailed and mathematical. (or somewhere in between)

4. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 4 Requirements engineering 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, 6th edition. Chapter 5 Slide 5 Why is Requirements Engineering 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 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, 6th edition. Chapter 5 Slide 6 Why is Requirements Engineering so hard? l Some analogies:  Working a dynamically changing jigsaw puzzle  Blind men describing an elephant  Different medical specialists describing an ill patient

7. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 7 Types of requirements l Requirements range from being high-level and abstract to detailed and mathematical. l This is inevitable as requirements may 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.

8. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 8 Types of requirements 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…

9. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 9 User and 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 definition System requirements specification

10. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 10 Requirements readers + lawyers

11. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 11 Functional and non-functional 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).

12. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 12 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…”)

13. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 13 Requirements imprecision l Problems arise when requirements are not precisely stated. l Ambiguous requirements may be interpreted in different ways. l Consider the term “appropriate viewers”  User intention – special purpose viewer for each different document type.  Developer interpretation – provide a text viewer that shows the contents of the documents.

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

15. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 15 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)

16. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 16 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.

17. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 17 Non-functional requirements l Define system attributes (e.g., reliability, response time) and constraints (e.g., MTTF ≥ 5K transactions, response time ≤ 2 seconds). l Attributes are often emergent system properties – i.e., only observable when the entire system is operational.

18. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 18 Non-functional requirements l Process constraints may mandate a particular CASE system, programming language, or development method. l Non-functional requirements may be more critical than functional requirements. If not met, the system may be useless. (They are not “second class” requirements.)

19. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 19 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).

20. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 20 Non-functional classifications

21. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 21 Examples of non-functional requirements 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 Organisational 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.

22. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 22 Goals versus (verifiable non- functional) 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.

23. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 23 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.

24. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 24 Requirements measures

25. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 25 Requirement interactions l Competing / conflicting requirements are common with complex systems. 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. Which is the most critical requirement? l For this reason, preferred points in the solution space should be identified.

26. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 26 Possible solutions Power Consumption Weight lowhigh Preferred Solution low high Weight constraint Power Consumption constraint

27. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 27 Domain requirements l Derived from the application domain rather than user needs. l May be new functional requirements or constraints on existing requirements. l If domain requirements are not satisfied, the system may be unworkable.

28. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 28 Library system domain requirements l There shall be a standard user interface to all databases which shall be based on the Z39.50 standard. l Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user, or routed to a network printer.

29. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 29 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 train. (physical law)

30. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 30 Domain requirements problems l Understandability – requirements are 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).

31. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 31 User requirements “shoulds” l Should be understandable by system users who don’t have detailed technical knowledge. l Should only specify external system behavior. l Should be written using natural language, forms, and simple intuitive diagrams.

32. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 32 Some potential problems with using natural language l Lack of clarity – expressing requirements precisely is difficult without making the document wordy and difficult to read. 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. 107-108. Basic problem: need for different models of / perspectives on requirements.

33. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 33 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 identify key parts of the requirement. l Avoid the use of computer (and other types of) jargon.

34. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 34 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.

35. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 35 System requirements and design information l In principle, system requirements should state what the system should do, and not how it should be designed. l In practice, however, 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. (Why?)

36. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 36 MORE potential problems with using natural language l Ambiguity – the readers and writers of a requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. l Over-flexibility – the same requirement may (and probably should) be stated in a number of different ways. The reader must determine when requirements are the same and when they are different. l Lack of modularization – NL structures are inadequate to structure (i.e., organize) system requirements sufficiently.

37. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 37 Alternatives to NL specification “PDL’s”

38. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 38 Structured natural language form / template

39. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 39 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, or when describing hardware and software interfaces.

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

41. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 41 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. Suggest ways to eliminate or mitigate these potential risks.

42. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 42 Interface specification 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. l Formal notations are effective for interface specification – e.g., pre- and post-conditions.

43. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 43 PDL-based interface description Method names and required parameters.

44. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 44 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

45. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 45 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

46. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 46 The requirements document (SRS – “Software Requirements Specification”) l The official statement of what is required of the system developers. l Should include 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.

47. Users of a requirements document

48. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 48 Requirements document requirements (Henniger ’80) l Specify external system behavior. l Specify implementation constraints. l Easy to change (!) l Serve as reference tool for maintenance. l Record forethought about the life cycle of the system; i.e., predict changes. l Characterise responses to unexpected events.

49. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 49 IEEE requirements “standard*” l Introduction l General description l Specific requirements l Appendices l Index l This is a generic structure that must be instantiated for specific systems. *IEEE Disclaimer: “This is not a standard…” More detail in text. (p. 117)

50. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 50 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 Tailored version of IEEE model

51. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 51 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

52. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 52 Key points l Non-functional requirements constrain the system being developed or the development process. l User requirements are high-level statements of what the system should do.

53. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 53 Key points l User requirements should be written in natural language, tables and diagrams. l System requirements are intended to communicate the functions that the system should provide (more precisely that user requirements).

54. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 54 Key points l System requirements may be written in structured natural language, a PDL or in a formal language. l A software requirements document (SRS) is the agreed statement of system requirements (both User and System).

55. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 55 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