Software Requirements IS 301 Software Engineering Lecture 6

Topics covered Ø Functional and non-functional requirements Ø User requirements Ø System requirements Ø

Requirements engineering Ø The process of qestablishing the services that the customer requires from

What is a requirement? Ø It may range from a high-level abstract statement of

Types of requirement Ø User requirements q. Statements in natural language plus diagrams of

Functional and non-functional requirements Ø Functional requirements q. Statements of services the system should

Non-functional classifications Ø Product requirements q. Requirements which specify that the delivered product must

Structured presentation Ø 2. 6. 1 Grid facilities Ø The editor shall provide a

Guidelines for writing requirements Ø Invent a standard format and use it for all

Problems with Natural Language (NL) specification Ø Ambiguity q. The readers and writers of

Structured language specifications Ø The freedom of the requirements writer is limited by a

Form-based specifications Ø Definition of the function or entity. Ø Description of inputs and

Sequence diagrams Ø These show the sequence of events that take place during some

Sequence diagram of ATM withdrawal 46 Notes content copyright © 2004 Ian Sommerville. NU-specific

ATM (2) 47 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright ©

ATM (3) 48 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright ©

ATM (4) 49 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright ©

Users of a requirements document (1) 53 Notes content copyright © 2004 Ian Sommerville.

Users of a requirements document (2) 54 Notes content copyright © 2004 Ian Sommerville.

Homework Ø REQUIRED q. By Monday 20 Sep 2004 q 6. 3 (5 pts)

DISCUSSION 60 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004

Notes 61 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004

Notes 62 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004

Notes 63 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004

Notes 64 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004

Slides: 25

Download presentation

Software Requirements IS 301 – Software Engineering Lecture # 6 – 2004 -09 -13 M. E. Kabay, Ph. D, CISSP Assoc. Prof. Information Assurance Division of Business & Management, Norwich University mailto: mkabay@norwich. edu V: 802. 479. 7937 1 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Topics covered Ø Functional and non-functional requirements Ø User requirements Ø System requirements Ø Interface specification Ø The software requirements document 3 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Requirements engineering Ø The process of qestablishing the services that the customer requires from a system and qthe constraints under which it operates and is developed. Ø The requirements themselves are the descriptions of the Ø system services and Ø constraints Ø that are generated during the requirements engineering process. 4 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

What is a requirement? Ø It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. Ø This is inevitable as requirements may serve a dual function q. May be the basis for a bid for a contract therefore must be open to interpretation; q. May be the basis for the contract itself therefore must be defined in detail; q. Both these statements may be called requirements. 5 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Types of requirement Ø User requirements q. Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. Ø System requirements q. A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. 7 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Functional and non-functional requirements Ø Functional requirements q. Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Ø Non-functional requirements q. Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Ø Domain requirements q. Requirements that come from the application domain of the system and that reflect characteristics of that domain. 10 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Non-functional classifications Ø Product requirements q. Requirements which specify that the delivered product must behave in a particular way; e. g. , execution speed, reliability, etc. Ø Organizational requirements q. Requirements which are a consequence of organizational policies and procedures e. g. process standards used, implementation requirements, etc. Ø External requirements q. Requirements which arise from factors which are external to the system and its development process e. g. interoperability requirements, legislative requirements, etc. 17 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Structured presentation Ø 2. 6. 1 Grid facilities Ø The editor shall provide a grid facility where a matrix of horizontal and vertical lines provide a background to the editor window. This grid shall be a passive grid where the alignment of entities is the user's responsibility. Ø Rationale: A grid helps the user to create a tidy diagram with well-spaced entities. Although an active grid, where entities 'snap-to' grid lines can be useful, the positioning is imprecise. The user is the best person to decide where entities should be positioned. Ø Specification: ECLIPSE/WS/Tools/DE/FS Section 5. 6 Ø Source: Ray Wilson, Glasgow Office 33 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Guidelines for writing requirements Ø Invent a standard format and use it for all requirements. Ø Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. Ø Use text highlighting to identify key parts of the requirement. Ø Avoid the use of computer jargon. 34 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Problems with Natural Language (NL) specification Ø Ambiguity q. The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. Ø Over-flexibility q. The same thing may be said in a number of different ways in the specification. Ø Lack of modularization q. NL structures are inadequate to structure system requirements. 37 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Structured language specifications Ø The freedom of the requirements writer is limited by a predefined template for requirements. Ø All requirements are written in a standard way. Ø The terminology used in the description may be limited. Ø The advantage is that the most of the expressiveness of natural language is maintained but a degree of uniformity is imposed on the specification. 39 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Form-based specifications Ø 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) of the function. 40 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Sequence diagrams Ø These show the sequence of events that take place during some user interaction with a system. Ø You read them from top to bottom to see the order of the actions that take place. Ø Cash withdrawal from an ATM q. Validate card; q. Handle request; q. Complete transaction. 45 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Homework Ø REQUIRED q. By Monday 20 Sep 2004 q 6. 3 (5 pts) q 6. 4 (5 pts) q 6. 5 (5 pts) q 6. 6 (15 pts) Ø OPTIONAL: either or both of the following q. By Monday 27 Sep 2004 q 6. 7 including examples (5 pts) q 6. 8 (5 pts) 59 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.