Software Requirements l Descriptions and specifications of a

Software Requirements l Descriptions and specifications of a system ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 1

Requirements engineering l l Determine services that the customer requires and the constraints on system and its development Requirements - system services and constraints ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 4

What is a requirement? l l High-level abstract statement of service /constraint detailed mathematical functional specification Term “Requirements” is “overloaded” • High description for contractor to bid • Detailed description of system to be delivered ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 5

Types of requirement User requirements l System requirements l Software specification l ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 7

Definitions and specifications ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 8

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

Functional and non-functional requirements l l l Functional requirements Non-functional requirements Domain requirements ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 10

Functional requirements l l l Describe functionality or system services Functional user requirements - high-level statements of what the system should do Functional system requirements - describe the system services in detail ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 11

Examples of functional requirements l l l The user shall be able to search either all of the initial set of databases or select a subset from it. The system shall provide appropriate viewers for the user to read documents in the document store. 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. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 12

Requirements imprecision l l l Problems when requirements not precisely stated E. g. the term ‘appropriate viewers’ E. g. does “see” mean on screen or on paper ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 13

Requirements completeness and consistency l l In principle requirements should be both complete and consistent In practice, it is impossible to produce a complete and consistent requirements document ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 14

Non-functional requirements l l l Define system properties and constraints Process requirements Non-functional requirements may be more critical than functional requirements. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 15

Non-functional classifications l l l Product requirements Organisational requirements External requirements ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 16

Non-functional requirement types ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 17

Non-functional requirements examples l Product requirement • l Organisational requirement • l ATM should always give response to user within 1 second All embedded software produced should be developed in Ada or C++ External requirement • ATM software interface should be usable by handicapped ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 18

Goals and requirements l l Danger - Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. Goal • l Verifiable non-functional requirement • l A general intention of the user such as ease of use A statement using some measure that can be objectively tested Goals are helpful to developers as they convey the intentions of the system users ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 19

Examples l A system goal • l The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised. A verifiable non-functional requirement • ©Ian Sommerville 2000 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. Software Engineering, 6 th edition. Chapter 5 Slide 20

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

Requirements interaction l Conflicts between different non-functional requirements are common in complex systems ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 22

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

Domain requirements problems l l Understandability Implicitness ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 26

User requirements l l functional and non-functional - understandable by system users without detailed technical knowledge User requirements are defined using natural language, tables and diagrams ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 27

Problems with natural language l l l Lack of clarity Requirements confusion Requirements amalgamation ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 28

Structured presentation ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 32

Detailed user requirement ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 33

Guidelines for writing requirements l l Invent a standard format and use it for all requirements Use language in a consistent way. Highlight key parts Avoid the use of computer jargon ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 34

System requirements l l More detailed specifications of user requirements Serve as a basis for designing the system May be used as part of the system contract System requirements may be expressed using system models discussed in Chapter 7 ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 35

Requirements and design l l In principle, requirements and design are separate In practice, requirements and design are inseparable ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 36

Problems with NL specification l l l Ambiguity Over-flexibility Lack of modularisation ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 37

Alternatives to NL specification l l Structured natural language Design description languages Graphical notations Mathematical specifications ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 39

Structured language specifications l l l A limited form of natural language may be used to express requirements This removes some of the problems resulting from ambiguity and flexibility and imposes a degree of uniformity on a specification Often best supported using a forms-based approach ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 40

Form-based node specification ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 41

Form-based node specification Function: Withdrawal Description: Withdrawals a given amount of money from customer account Inputs: Bank ID, Account Number, Amount Source: Bank ID and Account Number from customer card, Amount from user Outputs: Success indicator Destination: to control program Requires: Verified customer (must have gotten past sign on) Pre-condition: account must have sufficient funds Post Condition: the account balance must be reduced by the amount withdrawn. Side Effects: money is dispensed, receipt is dispensed ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 42

Form-based specifications l l l Definition of the function or entity Description of inputs and where they come from Description of outputs and where they go to Indication of other entities required Pre and post conditions (if appropriate) The side effects (if any) ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 43

PDL-based requirements definition l l Requirements may be defined operationally using a language like a programming language but with more flexibility of expression Most appropriate in two situations • • l Disadvantages are • • • l Where an operation is specified as a sequence of actions and the order is important When hardware and software interfaces have to be specified The PDL may not be sufficiently expressive to define domain concepts The specification will be taken as a design rather than a specification Only technical people can read them, and non-technical people may be receiving the document Possible use – in combination – to specify important control sequences ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 44

Part of an ATM specification ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 45

Interface specification l l Many systems operate with other systems - operating interfaces must be specified as part of the requirements Three types of interface may have to be defined • • • Procedural interfaces Data structures that are exchanged Data representations ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 47

PDL interface description ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 48

The requirements document l l l The requirements document is the official statement of what is required of the system developers Should include both a user requirements definition and a system specification of requirements It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 49

Users of a requirements document

Requirements document l l l Specify external system behaviour Specify implementation constraints Easy to change Serve as reference tool for maintenance Record forethought about the life cycle of the system i. e. predict changes Characterise responses to unexpected events ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 51

IEEE requirements standard (1993) l l l l Introduction General description Specific requirements Appendices Index This is a generic structure that must be instantiated for specific systems In evolutionary approach to development, not all details will be there initially ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 52

Requirements document structure l l l l l Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 53

Key points l l Requirements set out what the system should do and define constraints on its operation and implementation Functional requirements set out services the system should provide Non-functional requirements constrain the system being developed or the development process User requirements are high-level statements of what the system should do ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 54

Key points l l User requirements should be written in natural language, tables and diagrams System requirements are intended to communicate the functions that the system should provide System requirements may be written in structured natural language, a PDL or in a formal language A software requirements document is an agreed statement of the system requirements ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 5 Slide 55