Chapter 4

Requirements Engineering

1
Topics covered

Functional and non-functional requirements

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

2
Requirements engineering

The process of establishing the services that a customer

requires from a system and the constraints under which it
operates and is developed.
The system requirements are the descriptions of the system
services and constraints that are generated during the
requirements engineering process.

3
What is a requirement?

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

4
Types of requirement

User requirements System requirements

• Statements in natural language • A structured document setting

plus diagrams of the services out detailed descriptions of
the system provides and its the system’s functions,
operational constraints. services and operational
Written for customers. constraints. Defines what
should be implemented so
may be part of a contract
between client and contractor.

5
Mentacare System Example

6
Mentcare: A patient information system for
mental health care

 A patient information system to support mental health care is a medical

information system that maintains information about patients suffering from
mental health problems intended for use in clinics.
 It makes use of a centralized database of patient information but has also
been designed to run on a PC, so that it may be accessed and used from
sites that do not have secure network connectivity.
 To generate management information that allows health service managers to
assess performance against local and government targets.
 To provide medical staff with timely information to support the treatment of
patients.

7
User and system requirements

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

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.
 Health care managers who obtain management information from the system.

10
Functional and non-
functional requirements

11
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

12
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.

13
Requirements imprecision (not accurate)

 Problems arise when functional requirements are not properly stated.

 Ambiguous requirements may be interpreted in different ways by developers
and users.

 In principle, requirements should be both:

 Complete
They should include descriptions of all facilities required.
 Consistent
There should be no conflicts or contradictions in the descriptions of the system facilities.

14
Non-functional Requirements

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

15
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.

16
Types of nonfunctional requirement

17
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
18
Requirements
specification

26
Requirements specification

 The process of writing the user and system requirements in a requirements

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

27
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

28
A structured specification of a requirement
for an insulin pump

29
A structured specification of a requirement
for an insulin pump

30
Use cases

 Use-cases are a kind of scenario that are included in the UML.

 Use cases identify the actors in an interaction and which describe the
interaction itself.
 A set of use cases should describe all possible interactions with the system.
 High-level graphical model supplemented by more detailed tabular description
(see Chapter 5).
 UML sequence diagrams may be used to add detail to use-cases by showing
the sequence of event processing in the system.

31
Use cases for the Mentcare system

32
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.

33
Users of a requirements document

34
Requirements validation

35
Requirements validation

 Concerned with demonstrating that the requirements define the system that
the customer really wants.
 Requirements error costs are high so validation is very important
 Fixing a requirements error after delivery may cost up to 100 times the cost of
fixing an implementation error.

36
Requirements checking

 Validity.
 Does the system provide the functions which best support the customer’s needs?
 Consistency.
 Are there any requirements conflicts?
 Completeness.
 Are all functions required by the customer included?
 Realism.
 Can the requirements be implemented given available budget and technology
 Verifiability.
 Can the requirements be checked?

37
Requirements change

39
Changing requirements

 The business and technical environment of the system always changes after
installation.
 The people who pay for a system and the users of that system are rarely the
same people.
 Large systems usually have a diverse user community, with many users
having different requirements and priorities that may be conflicting or
contradictory.

40
Requirements management

 Requirements management is the process of managing changing

requirements during the requirements engineering process and system
development.
 New requirements emerge as a system is being developed and after it has
gone into use.
 You need to keep track of individual requirements and maintain links between
dependent requirements so that you can assess the impact of requirements
changes. You need to establish a formal process for making change
proposals and linking these to system requirements.

41
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.

42
Think

• Discover ambiguities or omissions in the following statement of requirements for part

of a ticket-issuing system:
An automated ticket-issuing system sells rail tickets. Users select their destination and
input a credit card and a personal identification number. The rail ticket is issued and
their credit card account charged. When the user presses the start button, a menu
display of potential destinations is activated, along with a message to the user to select
a destination. Once a destination has been selected, users are requested to input their
credit card. Its validity is checked and the user is then requested to input a personal
identifier. When the credit transaction has been validated, the ticket is issued.

43
Task

• Create structured specification requirements and use case diagram for your selected
system.
• ATM
• Vending Machine
• Washing Machine
• Car Parking System
• E-voting System

44