1. CS 425/625 Software Engineering Software Requirements
Based on Chapter 6 of the textbook [SE-8]
Ian Sommerville, Software Engineering, 8th Ed., Addison-Wesley, 2006
and on Ch6 PowerPoint presentation from the book’s web-site
September 24, 2007

2. Outline Requirements: User Requirements Systems Requirements
Functional
Non-functional
Domain
User Requirements
Systems Requirements
The Software Requirements Document

3. Requirements: Introduction….
Requirements = services the system is expected to provide + constraints placed on the system
Requirements engineering = gathering, negotiating, analyzing, and documenting requirements
The requirements could be expressed at various levels of abstraction
The way requirements are defined has a major impact on the development of the software product

4. Requirements: .Introduction…
“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.” [Davis]

5. Requirements: ..Introduction..
A classification of requirements:
User requirements: higher level description of services requested and constraints imposed
System requirements: a more detailed, structured description of services and constraints. Usually included in the contract between the developer and the client
An even more detailed description of requirements can be provided in a software design specification (closer to implementation)

6. Requirements: …Introduction.
Examples of user requirements definition and system requirements specification [Fig. 5.1, Sommerville 2000]. See also Fig. 6.1 [SE-8]

7. Requirements: ….Introduction
Types of software system requirements:
Functional requirements, describe the requested functionality/behaviour of the system: services (functions), reactions to inputs, exceptions, modes of operations
Non-functional requirements, represent constraints on the system and its functionality: performance constraints, compliance with standards, constraints on the development process
Domain requirements, can be either functional or non-functional and reflect the particularities of the application domain

8. Requirements: Functional
Functional requirements:
Depend on the system, the software, and the users
Can be expressed at different levels of detail (user/system requirements)
For a system, it is desirable to have a complete and consistent set of functional requirements
Completeness: all required system facilities are defined
Consistency: there are no contradictions in requirements

9. Requirements: Non-functional..
Non-functional requirements:
Many apply to the system as a whole
More critical than individual functional requirements
More difficult to verify
Kinds of non-functional requirements:
Product requirements
Organizational requirements
External requirements

10. Requirements: .Non-functional.
A classification of non-functional requirements [Fig. 6.3, SE-7]:

11. Requirements: ..Non-functional
Metrics that can be used to quantitatively specify and verify non-functional requirements [Fig. 6.6, SE-8]

12. Requirements: Domain
Domain requirements indicate specific computations, additional functionality, or constraints on other requirements
Example [Fig.6.7, SE-8]:
The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient
where Dgradient = 9.81ms2 * compensated gradient/alpha
and where the values of 9.81ms2/alpha are known for different types of train.

13. User Requirements… User requirements:
Should be understood by the user, and should not address design and implementation aspects
Should focus on the key facilities required
Problems with requirements written in natural language:
Lack of clarity, ambiguity, various interpretations possible
Confusion, lack of separation between different types of requirements
Mixture of several requirements in the same statement
Hard to modularize and thus hard to find connections between requirements

14. .User Requirements..
Example of improperly stated requirement [Fig. 6.9, SE-8]
2.6 Grid facilities
To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.

15. ..User Requirements.
Another example of requirements statement, well structured and more precise [Fig. 6.10, SE-08]

16. …User Requirements Guidelines for writing requirements:
Create and use a standard format for the entire software requirements specification
Highlight important parts of the requirement statements
Use consistently the language (difference between “should” and “shall”)
Avoid computer jargon

17. System Requirements……
More detailed specifications of user requirements
Included in the contract with the client
Used by developers as basis for design
May be specified using various models (object-oriented models, data-flow diagrams, formal specs, etc.)
Should indicate WHAT the system is required to do (not HOW) and under what conditions and constraints

18. .System Requirements.….
There is nevertheless a blurred line between specification and design because:
A system architecture may be needed to structure the requirements specification
Design constraints may be part of the system requirements
Factors such as interoperability may also impose design constraints

19. ..System Requirements….
Modalities for specifying requirements [Fig. 6.11, SE-8]:

20. …System Requirements…
Standard templates for structured natural language specification should include, as applicable:
Description of the function/service
Inputs and their sources
Outputs and their destinations
Dependencies (other elements required)
Pre-conditions
Post-conditions
Side-effects

21. ….System Requirements..
Example of a system requirement specified using structured natural language [Fig. 5.13, Sommerville 2000] – see also [Fig 6.12, SE-8]

22. …..System Requirements.
Another alternative to natural language (NL) for software specification is Program Description Languages (PDL)
Derived from programming languages
May contain more abstract constructs
Their syntax and semantics could be checked
Recommended for describing sequences of actions whose order is important & for specifying software interfaces
However, PDL specification require advised readers, can be taken as design specs, and may not be expressive enough

23. ……System Requirements
Example of PDL requirements specification [Fig. 5.14, Somm2000],
See also Fig [SE-7]

24. The Software Requirements Document..
This document, also called Software Requirements Specification (SRS), is the official description of the system’s requirements (includes user and system reqs.)
Heninger (1980) recommends that an SRS should:
Specify only external system behaviour
Specify constraints on implementation
Be easy to change
Serve as a reference for maintainers
Record forethought about the software life cycle
Describe acceptable responses to undesired events

25. .The System Requirements Document.
SRS structure according IEEE/ANSI standard (overview only, many more details are given in the standard):
Introduction
General description
Specific requirements
Appendices
Index
This structure needs to be tailored for each particular organization

26. ..The System Requirements Document
A more detailed structure suggested in [Fig. 5.17, Somm00]:
Table of contents
Preface
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index