Chapter 5

Software Requirements

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

Software Requirements


Descriptions and specifications of a system

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

Requirements engineering
The process of establishing the services that the
customer requires from a system and the constraints
under which it operates and is developed

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

 Types of requirement

User requirements
• Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers

System requirements
• A structured document setting out detailed descriptions of the system
services. Written as a contract between client and contractor

Software specification
• A detailed software description which can serve as a basis for a
design or implementation. Written for developers

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

Requirements readers
Client managers
System end-users
User requirements Client engineers
Contractor managers
System architects

System end-users
Client engineers
System requirements
System architects
Software developers

Client engineers (perhaps)

Software design
System architects
specification
Software developers

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

Functional and non-functional requirements

Functional requirements
• 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
• constraints on the services or functions offered by the system such
as timing constraints, constraints on the development process,
standards, etc.

Domain requirements
• Requirements that come from the application domain of the system
and that reflect characteristics of that domain

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

Functional requirements

Describe functionality or system services

Depend on the type of software, expected users and
the type of system where the software is used

Functional user requirements may be high-level
statements of what the system should do but
functional system requirements should describe the
system services in detail

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

Non-functional requirements

Define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.

Process requirements may also be specified
mandating a particular CASE system, programming
language or development method

Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system is useless

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

Non-functional requirement types
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements

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

User requirements

Should describe functional and non-functional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge

User requirements are defined using natural
language, tables and diagrams

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

System requirements

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, 6th edition. Chapter 5 Slide 11

Interface specification

Most systems must operate with other systems and
the 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

Formal notations are an effective technique for
interface specification

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

 Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

Use the requirements to

System engineers understand what system is to
be developed

System test Use the requirements to

engineers develop validation tests for
the system

Users of a
System Use the requirements to help requirements
maintenance understand the system and
engineers the relationships between its document
parts
Requirements document requirements

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, 6th edition. Chapter 5 Slide 14

IEEE requirements standard

Introduction

General description

Specific requirements

Appendices

Index

This is a generic structure that must be instantiated
for specific systems

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

Requirements document structure

Introduction

Glossary

User requirements definition

System architecture

System requirements specification

System models

System evolution

Appendices

Index

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

Requirements Engineering Process in Software
Engineering


Feasibility Study

Requirements elicitation

Requirements specification

Requirements for verification and validation

Requirements management

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

Requirements Engineering Process in Software
Engineering

Feasibility Study:
Technical Feasibility
Operational Feasibility
Economic Feasibility

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

Requirements Engineering Process in Software
Engineering

Requirements Elicitation
Several techniques can be used to elicit requirements,
including:

Interviews

Surveys

Focus Groups

Observation

Prototyping

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

Requirements Engineering Process in Software
Engineering

Requirements Specification
Several types of requirements are commonly
specified in this step, including

Functional Requirements

Non-Functional Requirements

Constraints

Acceptance Criteria

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

Requirements Engineering Process in Software
Engineering

Requirements Management
Several key activities are involved in requirements
management, including:

Tracking and controlling changes

Version control

Traceability

Communication

Monitoring and reporting

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