2/8/2023

Objectives

◇To discuss
▪ Functional and non-functional requirements
Requirements Engineering ▪ The software requirements document
▪ Requirements specification
▪ Requirements engineering processes
▪ Requirements elicitation and analysis
▪ Requirements validation
▪ Requirements management

Software Engineering, 9th ed. Chapter 4

© Sommerville, I. 254
Requirements Engineering (extract)

Requirements Engineering What is a Requirement?

◇It may range from a high-level abstract

◇T h e p r o c e s s o f e s t a b l i s h i n g t h e
services that the customer requires from a
system and the 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.
© Sommerville, I.
Software Engineering, 9th ed. Chapter 4
Requirements Engineering (extract)
255
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
▪ May be the basis for a bid for a contract - therefore
must be open to interpretation;
▪ May be the basis for the contract itself - therefore
must be defined in detail;
◇B o t h t h e s e s t a t e m e n t s m a y b e c a l l e d
requirements.
© Sommerville, I.
Software Engineering, 9th ed. Chapter 4
Requirements Engineering (extract)
256

1
 2/8/2023

Requirements Abstraction Types of requirement

◇User requirements
“If a company wishes to let a contract for a large software ▪ Statements in natural language plus diagrams of the
development project, it must define its needs in a sufficiently services the system provides and its operational
abstract way that a solution is not pre-defined. The constraints.
requirements must be written so that several contractors ▪ Written for customers.
can bid for the contract, offering, perhaps, different ways of
meeting the client organisation’s needs. Once a contract ◇System requirements
has been awarded, the contractor must write a system ▪ A structured document setting out detailed
definition for the client in more detail so that the client descriptions of the system’s functions, services and
understands and can validate what the software will do. operational constraints.
Both of these documents may be called the requirements ▪ Defines what should be implemented so may be part
document for the system.” of a contract between client and contractor.
[A.M. Davis “Software Requirements: Objects, Functions and States”, Englewood Cliffs, 1993]
Software Engineering, 9th ed. Chapter 4
257 © Sommerville, I. 258
Requirements Engineering (extract)

Example
The MHC-PMS (Mental Health Care-Patient
The Mental Health Care Patient Management System
(MHC-PMS) Case Study
Management System)
◇ An information system that is intended for use in clinics.
◇ A system used to maintain records of people receiving
◇ It makes use of a centralised database of patient information
care for mental health problems.
but has also been designed to run on a PC, so that it may be
▪ A patient information system to support mental health care
accessed and used from sites that do not have secure network
• A medical information system that maintains information about
patients suffering from mental health problems and the treatments connectivity.
that they have received. ◇ When the local systems have secure network access, they use
◇ Most mental health patients do not require dedicated patient information in the database but they can download and
hospital treatment but need to attend specialist clinics use local copies of patient records when they are disconnected.
regularly where they can meet a doctor who has detailed MHC-PMS Goals
knowledge of their problems. ◇ To generate management information that allows health
◇ To make it easier for patients to attend, these clinics are service managers to assess performance against local and
not just run in hospitals. government targets.
▪ They may also be held in local medical practices or community ◇ To provide medical staff with timely information to support the
centres. Chapter 1 Introduction 259
treatment of patients.Software Engineering, 9 ed. Chapter 4
th
260
Requirements Engineering (extract)

2
 2/8/2023

The Organisation of the MHC-PMS MHC-PMS Key Features

◇ Individual care management

▪ Clinicians can create records for patients, edit the information in
the system, view patient history, etc.
▪ The system supports data summaries so that doctors can quickly
learn about the key problems and treatments that have been
prescribed.
◇ Patient monitoring
▪ The system monitors the records of patients that are involved in
treatment and issues warnings if possible problems are detected.
◇ Administrative reporting
▪ The system generates monthly management reports showing the
number of patients treated at each clinic, the number of patients
who have entered and left the care system, number of patients
sectioned, the drugs prescribed and their costs, etc.
Software Engineering, 9th ed. Chapter 4 Software Engineering, 9th ed. Chapter 4
261 262
Requirements Engineering (extract) Requirements Engineering (extract)

MHC-PMS Concerns User And System Requirements

◇Privacy
▪ It is essential that patient information is confidential
and is never disclosed to anyone apart from
authorised medical staff and the patient themselves.
◇Safety
▪ Some mental illnesses cause patients to become
suicidal or a danger to other people. Wherever
possible, the system should warn medical staff about
potentially suicidal or dangerous patients.
▪ The system must be available when needed otherwise
safety may be compromised and it may be impossible
to prescribe the correct medication to patients.
Software Engineering, 9th ed. Chapter 4 Software Engineering, 9th ed. Chapter 4
263 © Sommerville, I. 264
Requirements Engineering (extract) Requirements Engineering (extract)

3

Readers of different types of requirements
specification
Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 265
Requirements Engineering (extract)
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.
◇F u n c t i o n a l s y s t e m r e q u i r e m e n t s s h o u l d
describe the system services in detail.
Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 267
Requirements Engineering (extract)
2/8/2023
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.
▪ May state what the system should not do.
◇ Non-functional requirements
▪ Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
▪ Often apply to the system as a whole rather than individual
features or services.
◇ Domain requirements
▪ Constraints on the system from the domain of operation
Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 266
Requirements Engineering (extract)
Functional requirements for the MHC-PMS
◇A u s e r s h a l l b e a b l e t o s e a r c h t h e
appointments lists for all clinics.
◇The system shall generate each day, for
each clinic, a list of patients who are
expected to attend appointments that day.
◇Each staff member using the system shall
be uniquely identified by his or her 8-digit
employee number.
Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 268
Requirements Engineering (extract)
4

Requirements imprecision
◇P r obl ems ar i se w hen r equi r ement s ar e n o t
precisely stated.
◇Ambiguous requirements may be interpreted in
different ways by developers and users.
◇Consider the term ‘search’ in requirement 1
“A user shall be able to search the
appointments lists for all clinics.”
▪ This may be understood in different ways by
different individuals.
▪ How?
Software Engineering, 9th ed. Chapter 4
© Sommerville, I.
Requirements Engineering (extract)
Requirements completeness and consistency
◇In principle, requirements should be both
complete and consistent.
◇Complete
▪ They should include descriptions of all facilities required.
◇Consistent
▪ There should be no conflicts or contradictions in the
descriptions of the system facilities.
• See next slide for an example …
◇In practice, it is basically impossible to produce a
complete and consistent requirements document.
Software Engineering, 9th ed. Chapter 4
© Sommerville, I.
Requirements Engineering (extract)
2/8/2023
Requirements imprecision
◇Requirement 1
◇“A user shall be able to search the
appointments lists for all clinics.”
▪ User intention – search for a patient
name across all appointments in all
clinics;
▪ Developer interpretation – search for a
patient name in an individual clinic.
• User chooses clinic then searches.
Software Engineering, 9th ed. Chapter 4
269 © Sommerville, I. 270
Requirements Engineering (extract)
Requirements completeness and consistency
◇ … Consistent
▪ There should be no conflicts or contradictions in the descriptions
of the system facilities.
• User, client and developer have different domains of expertise and
use different vocabularies to describe the same concepts.
• They also have different objectives when defining the systems…
– Users: want a system that supports their current processes
» E.g. you want to register for units online
– Clients: to maximise their ROI
– Developers: to deliver the system on time.
• Can lead to problems
– e.g. when the developer does not properly understand the
needs of the user.
Software Engineering, 9th ed. Chapter 4
271 © Sommerville, I. 272
Requirements Engineering (extract)
5
 2/8/2023

Requirements Imprecision
Non-functional requirements
The Purpose of Analysis

◇ The optical illusion we just saw represents a picture that
is ambiguous.
◇ The models we create to describe our system must have
zero ambiguity.
◇ This is precisely why we must carry out analysis: to
create the analysis model of the system that is correct,
complete, consistent and verifiable.
◇ We carry out a requirements elicitation, then the
requirements specification (describing the functional
and non-functional requirements) then start the analysis.
◇These define system properties and constraints
▪ e.g. reliability, response time and storage requirements.
▪ Constraints include e.g. I/O device capability e.g.:
▪ the visual display has
▪ high resolution
▪ 3D capabilities,
▪ touch-sensitivity using pens or fingers
▪ the system has voice recognition capabilities
◇Process requirements may also be specified mandating a particular
◇IDE,
◇programming language or
◇development method.
◇Non-functional requirements may be more critical than functional
requirements.
▪ If these are not met, the system may be useless.

273
Software Engineering, 9th ed. Chapter 4
SQA © Sommerville, I. 274
Requirements Engineering (extract)

Non-functional requirements implementation Few Interfaces

◇Non-functional requirements may affect the
overall architecture of a system rather than the
individual components.
▪ For example, to ensure that performance requirements are
met, you may have to organise the system to minimise
communications between components.
◇The “few interfaces” principle states that the
overall number of communication channels
between modules should be as small as
possible:
▪ Every module should communicate with as few others as
possible. 275

6
 2/8/2023

Types of nonfunctional requirement

Non-functional requirements implementation

◇A single non-functional requirement, such as a

security requirement, may generate a number of
related functional requirements that define system
services that are required.
◇Each staff member using the system shall be
uniquely identified by his or her 8-digit employee
number.
◇It may also generate requirements that restrict
existing requirements.
◇A user shall be able to search the appointments
lists for all clinics. This user can only be a doc or an
admin. 277 © Sommerville, I.
Software Engineering, 9th ed. Chapter 4
Requirements Engineering (extract)
278

Examples of nonfunctional requirements in the

Non-functional classifications
MHC-PMS

Product requirement
◇ Product requirements
The MHC-PMS shall be available to all clinics during normal
▪ Requirements which specify that the delivered product must
behave in a particular way working hours (Mon–Fri, 0830–17.30). Downtime within
• e.g. execution speed, reliability, etc. normal working hours shall not exceed five seconds in any one
◇ Organisational requirements day.
▪ Requirements which are a consequence of organisational policies
and procedures Organisational requirement
• e.g. process standards used, implementation requirements, etc. Users of the MHC-PMS system shall authenticate themselves
◇ External requirements using their health authority identity card.
▪ Requirements which arise from factors which are external to the
system and its development process External requirement
• e.g. interoperability requirements, legislative requirements, etc. The system shall implement patient privacy provisions as set
out in HStan-03-2006-priv.
Software Engineering, 9th ed. Chapter 4 Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 279 © Sommerville, I. 280
Requirements Engineering (extract) Requirements Engineering (extract)

7
 2/8/2023

Goals and requirements Usability requirements

◇Non-functional requirements may be very difficult
to state precisely.
◇Imprecise requirements may be difficult to verify.
◇Goal
▪ A general intention of the user such as ease of use.
◇Verifiable non-functional requirement
▪ A statement using some measure that can be
objectively tested.
◇Goals are helpful to developers as they convey
the intentions of the system users …
◇The system should be easy to use by medical
staff and should be organised in such a way
that user errors are minimised. (Goal)
◇Medical staff shall be able to use all the system
functions after four hours of training. After
this training, the average number of errors
made by experienced users shall not exceed
two per hour of system use. (Testable non-
functional requirement)

Software Engineering, 9th ed. Chapter 4 Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 281 © Sommerville, I. 282
Requirements Engineering (extract) Requirements Engineering (extract)

Metrics for specifying nonfunctional

requirements Reminder:
Property Measure
Speed Processed transactions/second
User/event response time
◇Functional requirements:
Screen refresh time ◇statements of services the system should provide.
Size Mbytes
Number of ROM chips ◇Non-functional requirements:
Ease of use Training time ◇Constraints on the services or functions offered by
Number of help frames
the system such as timing constraints, constraints
Reliability Mean time to failure
Probability of unavailability on the development process, standards, etc.
Rate of failure occurrence ◇Domain requirements:
Availability
Robustness Time to restart after failure ◇Constraints on the system from the domain of
Percentage of events causing failure operation …
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 283 284
Requirements Engineering (extract)

8
 2/8/2023

Domain requirements Train protection system

◇T h e s y s t e m ’ s o p e r a t i o n a l d o m a i n i m p o s e s ◇T h i s i s a d o m a i n r e q u i r e m e n t f o r a t r a i n
requirements on the system. protection system:
▪ For example, a train control system has to take into account ◇The deceleration of the train shall be computed as:
the braking characteristics in different weather conditions.
▪ Dtrain = Dcontrol + Dgradient
◇Domain requirements can be ▪ where D gradient is 9.81ms 2 * compensated gradient
◇new functional requirements, /alpha
◇constraints on existing requirements or where the values of 9.81ms 2 / alpha are known for
◇defined specific computations. different types of train.
◇If domain requirements are not satisfied, the system ◇It is difficult for a non-specialist to understand the
may be unworkable. implications of this and how it interacts with other
requirements.
Software Engineering, 9th ed. Chapter 4 Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 285 © Sommerville, I. 286
Requirements Engineering (extract) Requirements Engineering (extract)

Domain Requirements Problems Key points

◇Understandability ◇ Requirements for a software system set out what the

▪ Requirements are expressed in the language
of the application domain;
▪ This is often not understood by software
engineers developing the system.
◇Implicitness
▪ Domain specialists understand the area so
well that they do not think of making the
domain requirements explicit.
system should do and define constraints on its operation
and implementation.
◇ Functional requirements are statements of the services
that the system must provide or are descriptions of how
some computations must be carried out.
◇ Non-functional requirements often constrain the
system being developed and the development process
being used.
▪ They often relate to the emergent properties of the system and
therefore apply to the system as a whole.

Software Engineering, 9th ed. Chapter 4 Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 287 © Sommerville, I. 288
Requirements Engineering (extract) Requirements Engineering (extract)

9

The Software Requirements Document
◇The software requirements document is the
official statement of what is required of the
system developers.
◇Should include both
▪ a definition of user requirements and
▪ a specification of the system requirements.
◇It is NOT a design document.
▪ As far as possible, it should set out WHAT the system
should do rather than HOW it should do it.
Software Engineering, 9th ed. Chapter 4
© Sommerville, I.
Requirements Engineering (extract)
A ‘prescribing medication’ story
2/8/2023
Agile methods and requirements
◇ Many agile methods argue that producing a requirements document
is a waste of time as requirements change so quickly.
◇ The document is therefore always out of date.
◇ Methods such as XP use incremental requirements engineering
▪ they express requirements as ‘user stories’ or scenarios.
▪ These are written on cards and the development team break them down
into implementation tasks. These tasks are the basis of schedule and
cost estimates. (See next 2 slides)
▪ The customer chooses the stories for inclusion in the next release based
on their priorities and the schedule estimates.
◇ This is practical for business systems but problematic for systems
that require a lot of pre-delivery analysis (e.g. critical systems) or
systems developed by several teams.
Software Engineering, 9th ed. Chapter 4
289 © Sommerville, I. 290
Requirements Engineering (extract)
Examples of task cards for prescribing
medication
291 292
10
 2/8/2023

Users of a requirements document Requirements document variability

◇Information in requirements document depends

on type of system and the approach to
development used.
◇Systems developed incrementally will, typically,
have less detail in the requirements document.
◇Requirements documents standards have been
designed e.g. IEEE standard.
▪ These are mostly applicable to the requirements for
large systems engineering projects.

Software Engineering, 9th ed. Chapter 4 Software Engineering, 9th ed. Chapter 4
© Sommerville, I. 293 © Sommerville, I. 294
Requirements Engineering (extract) Requirements Engineering (extract)

11