Chapter 4 – Requirements Engineering
Lecture 2
Chapter 4 Requirements engineering 1
Topics covered
Functional and non-functional requirements
The software requirements document
Requirements specification
Requirements engineering processes
Requirements elicitation and analysis
Requirements validation
Requirements management
Chapter 4 Requirements engineering 2
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 of WHAT the system should do rather than HOW it
should do it.
Chapter 4 Requirements engineering 3
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 and express requirements as ‘user stories’
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.
Chapter 4 Requirements engineering 4
Users of a requirements document
There are many users
of Requirements Documents!
Here are a few. There are more.
Chapter 4 Requirements engineering 5
Requirements Specification
User requirements have to be understandable by end-users
and customers who do not have a technical background.
System requirements are more detailed requirements and
may include more technical information.
The requirements may be part of a contract for the system
development
It is therefore important that these are as complete as possible.
They often form the basis for litigation when not accommodated!
There are several mechanisms to writing Requirements!
AND there are a lot of things to do before you can write a
requirements specification!
Chapter 4 Requirements engineering 6
Ways of Writing a System Requirements
Specification
Notation Description
Natural language The requirements are written using numbered sentences in natural
language. Each sentence should express one requirement.
Structured natural The requirements are written in natural language on a standard form or
language template. Each field provides information about an aspect of the requirement.
Design description This approach uses a language like a programming language, but with more
languages abstract features to specify the requirements by defining an operational model
of the system. This approach is now rarely used although it can be useful for
interface specifications.
Graphical notations Graphical models, supplemented by text annotations, are used to define the
functional requirements for the system; UML use case and sequence
diagrams are commonly used.
Mathematical These notations are based on mathematical concepts such as finite-state
specifications machines or sets. Although these unambiguous specifications can reduce the
ambiguity in a requirements document, most customers don’t understand a
formal specification. They cannot check that it represents what they want and
are reluctant to accept it as a system contract
Chapter 4 Requirements engineering 7
Requirements and Design
In principle, requirements should state what the system
should do and the design should describe how it does this.
In practice, requirements and design are inseparable
A system architecture may be designed to structure the
requirements;
The system may inter-operate with other systems that generate
design requirements; Especially true when systems are ‘related’ or
share same databases and files.
The use of a specific architecture to satisfy non-functional
requirements may be a domain requirement.
The architecture may well be influenced by portability, scalability,
maintainability, etc.
This may be the consequence of a regulatory requirement.
Natural Language Specification
Requirements are written as natural language sentences
supplemented by diagrams and tables.
Used for writing requirements because it is expressive,
intuitive and universal. This means that the requirements
can be understood by users and customers.
Chapter 4 Requirements engineering 9
Problems with natural language
Lack of clarity
Precision is difficult without making the document difficult to read.
Requirements confusion
Functional and non-functional requirements tend to be mixed-up.
Requirements amalgamation
Several different requirements may be expressed together.
Example requirements for the insulin pump
software system
3.2 The system shall measure the blood sugar and deliver
insulin, if required, every 10 minutes. (Changes in blood
sugar are relatively slow so more frequent measurement is
unnecessary; less frequent measurement could lead to
unnecessarily high sugar levels.)
3.6 The system shall run a self-test routine every minute
with the conditions to be tested and the associated actions
defined in Table 1. (A self-test routine can discover
hardware and software problems and alert the user to the
fact the normal operation may be impossible.)
Chapter 4 Requirements engineering 11
Tabular Specification
Used to supplement natural language.
Particularly useful when you have to define a number of
possible alternative courses of action.
For example, the insulin pump systems bases its
computations on the rate of change of blood sugar level
and the tabular specification explains how to calculate the
insulin requirement for different scenarios.
Tabular Specification of computation for an
insulin pump
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of CompDose = 0
increase decreasing
((r2 – r1) < (r1 – r0))
Sugar level increasing and rate of CompDose=round ((r2 – r2) /4)
increase stable or increasing If rounded result = 0 then
((r2 – r1) ≥ (r1 – r0)) CompDose = MinimumDose
Chapter 4 Requirements engineering 13
Requirements Engineering
Chapter 4 Requirements engineering 14
Requirements Engineering Processes
The processes used for RE vary widely depending on the
application domain, the people involved and the
organization developing the requirements.
However, there are a number of generic activities
common to all processes
Requirements elicitation;
Requirements analysis;
Requirements validation;
Requirements management.
In practice, RE is an iterative activity in which these
processes are interleaved.
Chapter 4 Requirements engineering 15
A spiral view of the requirements engineering
process
Chapter 4 Requirements engineering 16
Requirements Elicitation and Analysis
Sometimes called requirements elicitation or
requirements discovery.
Involves technical staff working with customers to find out
about the application domain, the services that the
system should provide and the system’s operational
constraints.
May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
are called stakeholders.
Chapter 4 Requirements engineering 17
Problems of Requirements Analysis
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organisational and political factors may influence the
system requirements.
The requirements change during the analysis process.
New stakeholders may emerge and the business
environment may change.
Chapter 4 Requirements engineering 18
Requirements Elicitation and Analysis
Software engineers work with a range of system stakeholders
to find out about the
application domain,
the services that the system should provide,
the required system performance,
hardware constraints,
other systems, etc.
Stages include:
Requirements discovery,
Requirements classification and organization,
Requirements prioritization and negotiation,
Requirements specification.
Chapter 4 Requirements engineering 19
The Requirements Elicitation and Analysis
Process
Chapter 4 Requirements engineering 20
