Chapter 4 – Requirements Engineering

30/10/2014 Chapter 4 Requirements Engineering 1

Topics covered

 Functional and non-functional requirements

 Requirements engineering processes
 Requirements elicitation
 Requirements specification
 Requirements validation
 Requirements change

30/10/2014 Chapter 4 Requirements Engineering 2

Requirements engineering

 The requirements for a system are the descriptions of the services that a system
should provide and the constraints on its operation. These requirements reflect the
needs of customers for a system that serves a certain purpose such as controlling a
device, placing an order, or finding information.
 The process of finding out, analyzing, documenting and checking these services
and constraints is called requirements engineering (RE)

30/10/2014 Chapter 4 Requirements Engineering 3

CONT..

 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
 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;
 Both these statements may be called requirements.

30/10/2014 Chapter 4 Requirements Engineering 4

Requirements abstraction (Davis)

“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 organization’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.”

30/10/2014 Chapter 4 Requirements Engineering 5

 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’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract
between client and contractor.

30/10/2014 Chapter 4 Requirements Engineering 6

User and system requirements

30/10/2014 Chapter 4 Requirements Engineering 7

Readers of different types of requirements
specification

30/10/2014 Chapter 4 Requirements Engineering 8

System stakeholders

 Any person or organization who is affected by the

system in some way and so who has a legitimate interest
 Stakeholder types
 End users
 System managers
 System owners
 External stakeholders

30/10/2014 Chapter 4 Requirements Engineering 9

Stakeholders in the Mentcare system

 Patients whose information is recorded in the system.

 Doctors who are responsible for assessing and treating
patients.
 Nurses who coordinate the consultations with doctors
and administer some treatments.
 Medical receptionists who manage patients’
appointments.
 IT staff who are responsible for installing and maintaining
the system.

30/10/2014 Chapter 4 Requirements Engineering 10

 Your Turn
 What are the stakeholder of the following systems
 HUMAN RESOURCE MANAGEMNT
 STUDENT ATTENCE INFORMATON SYTEM
 Airline Reservation System

30/10/2014 Chapter 4 Requirements Engineering 11

Stakeholders in the Mentcare system

 A medical ethics manager who must ensure that the

system meets current ethical guidelines for patient care.
 Health care managers who obtain management
information from the system.
 Medical records staff who are responsible for ensuring
that system information can be maintained and
preserved, and that record keeping procedures have
been properly implemented.

30/10/2014 Chapter 4 Requirements Engineering 12

Agile methods and requirements

 Many agile methods argue that producing detailed

system requirements is a waste of time as requirements
change so quickly.
 The requirements document is therefore always out of
date.
 Agile methods usually use incremental requirements
engineering and may express requirements as ‘user
stories’ (discussed in Chapter 3).
 This is practical for business systems but problematic for
systems that require pre-delivery analysis (e.g. critical
systems) or systems developed by several teams.
30/10/2014 Chapter 4 Requirements Engineering 13
 Functional and non-functional requirements

30/10/2014 Chapter 4 Requirements Engineering 14

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
30/10/2014 Chapter 4 Requirements Engineering 15
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.
 Functional system requirements should describe the
system services in detail.

30/10/2014 Chapter 4 Requirements Engineering 16

Mentcare system: functional requirements

 A user shall be able to search the 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.

30/10/2014 Chapter 4 Requirements Engineering 17

Requirements imprecision

 Problems arise when functional requirements are not

precisely stated.
 Ambiguous requirements may be interpreted in different
ways by developers and users.
 Consider the term ‘search’ in requirement 1
 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 search.

30/10/2014 Chapter 4 Requirements Engineering 18

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.
 In practice, because of system and environmental
complexity, it is impossible to produce a complete and
consistent requirements document.

30/10/2014 Chapter 4 Requirements Engineering 19

Non-functional requirements

 These 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 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.

30/10/2014 Chapter 4 Requirements Engineering 20

Types of nonfunctional requirement

30/10/2014 Chapter 4 Requirements Engineering 21

Non-functional requirements implementation

 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 organize the system to minimize
communications between components.
 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.
 It may also generate requirements that restrict existing
requirements.

30/10/2014 Chapter 4 Requirements Engineering 22

Non-functional classifications

 Product requirements
 Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
 Organisational requirements
 Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
 External requirements
 Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.

30/10/2014 Chapter 4 Requirements Engineering 23

Examples of nonfunctional requirements in the
Mentcare system

Product requirement
The Mentcare system shall be available to all clinics during normal
working hours (Mon–Fri, 0830–17.30). Downtime within normal
working hours shall not exceed five seconds in any one day.

Organizational requirement
Users of the Mentcare system shall authenticate themselves using
their health authority identity card.

External requirement
The system shall implement patient privacy provisions as set out in
HStan-03-2006-priv.

30/10/2014 Chapter 4 Requirements Engineering 24

Metrics for specifying nonfunctional
requirements

Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems

30/10/2014 Chapter 4 Requirements Engineering 27

Domain requirements problems

Understandability
Requirements are expressed in the language of the application
domain;
Application written for mortgage banking people need to
express functionality in terms of home loans, mortgage
balances, escrow, investor accounting, foreclosure, etc.
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.
And this is often a major problem in communications!!!

Chapter 4 Requirements engineering 28

Key points

Requirements for a software system set out what the

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.

Chapter 4 Requirements engineering 29