10/13/2023

Week 3 – Requirements Engineering-1

Chapter 4, Software Engineering, 10 Ed

by
Ian Sommerville

Requirements Engineering 1

1
 10/13/2023

Topics covered

 Introduction
 Levels of Requirements
 System Stakeholders
 Functional Requirements (FR)
 Non-functional requirements (NFR)
 Dependability - NFR

Requirements Engineering 4

2
 10/13/2023

Requirements Engineering (RE)

RE is the process of establishing the services

that a customer requires from a system and the
constraints under which it operates and is
developed.

Requirements Engineering 5

Two Levels of requirement

 User requirements (Abstract)

▪ Statements in natural language plus diagrams of the
services the system provides and its operational
constraints.
▪ Written by/for customers.
 System requirements (Detailed)
▪ 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.
Requirements Engineering 6

3
 10/13/2023

User and system requirements

Requirements Engineering 7

Readers of different types of requirements

specification

Requirements Engineering 8

4
 10/13/2023

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

Requirements Engineering 9

Example of Stakeholders - Medical 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.

Requirements Engineering 10

10

5
 10/13/2023

Complete vs Incremental Requirements

 Complete System 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.
 Incremental Requirements
▪ Agile methods usually use incremental requirements
engineering and may express requirements as ‘user stories’
(discussed in last lecture).
▪ 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.

Requirements Engineering 11

11

FUNCTIONAL REQUIREMENTS (FR)

&
NON-FUNCTIONAL REQUIREMENTS (NFR)

Requirements Engineering 12

12

6
 10/13/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 also 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.
 In reality, the distinction between different types of requirements is
not as clearcut as these simple definitions suggest

Requirements Engineering 13

13

FUNCTIONAL REQUIREMENTS
(FR)

Requirements Engineering 14

14

7
 10/13/2023

Examples: Functional Requirements (FRs)

1. A user shall be able to search the appointments lists for

all clinics.

2. The system shall generate each day, for each clinic, a

list of patients who are expected to attend appointments
that day.

3. Each staff member using the system shall be uniquely

identified by his or her 8-digit employee number.

Requirements Engineering 15

15

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, it is impossible to produce a complete and
consistent requirements document, in a first go.
 Requirement conflicts are required to be resolved
through a formal process.

Requirements Engineering 16

16

8
 10/13/2023

Requirements Conflicts & Resolution

(How to resolve shown conflicts?)
https://manual.calibre-ebook.com/faq.html#id9

Example: Electronic Library:

▪ Requirement A: Item Retrieval : “Download option allows the user
to retrieve items in any format”. (Purpose: to increase usability)
▪ Requirement B: No File Conversion: “File conversion should not be
supported”. (Purpose: reduce development cost/schedule)
Requirement Resolution Options:
 Support file conversions for all major types and increase the budget
for the project.
 Support file conversions for limited set of formats (e.g. .pdf, .rtf and
.doc) and increase the budget for the project.
 Make budget and schedule allowances by removing Requirement F:
“Provide a wizard feature for setting up archives”.
 Add the requirement: “A separate version of each item, one for every
format required, must be submitted to the system when a new item is
added”.”.
 Only support the retrieval of items in formats that are available. 17
Requirements Engineering

17

NON-FUNCTIONAL
REQUIREMENTS (NFRS)

Requirements Engineering 18

18

9
 10/13/2023

Non-functional Requirements (NFRs)

 These define system properties and constraints e.g.: -

▪ Properties: e.g., Usability, reliability, response time
and storage requirements.
▪ Constraints: e.g., I/O device capability, system
representations, etc.

 NFRs may be more critical than functional

requirements. If these are not met, the system may be
useless.
See video on NFRs: https://www.youtube.com/watch?v=fc-5HJPBZMQ

Requirements Engineering 19

19

NFR Classifications

 Product requirements
▪ Requirements which specify that the delivered product must
behave in a particular way e.g. dependability, efficiency, usability
requirements of the system.
 Organisational requirements
▪ Requirements which are a consequence of organisational
policies and procedures e.g. operational, environmental,
development requirements of the system.
 External requirements
▪ Requirements which arise from factors which are external to the
system and its development process e.g. regulatory, ethical,
legislative requirements of the system

Requirements Engineering 20

20

10
 10/13/2023

Types of NFRs (Non-exhaustive List)

See also: https://www.altexsoft.com/blog/non-functional-requirements/

most important/broad-
ranging Property

Requirements Engineering 21

21

Examples of NFRs - Medical system

 Product requirement: The Medical 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 Medical
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 Specs.

Requirements Engineering 22

22

11
 10/13/2023

Precise vs Imprecise NFRs

 Imprecise requirements are in the form of Goals from

Client. These are helpful to developers as they convey
the intentions of the system users.

 Precise requirements are then developed using some

measure to make these objectively Testable

Requirements Engineering 23

23

Usability requirements (Example)

 The system should be easy to use by medical staff and

should be organized in such a way that user errors are
minimized. (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.
(Measurable and Testable NFR)

Requirements Engineering 24

24

12
 10/13/2023

Few Metrics for specifying Precise NFRs

Property Measure (Matrices)

Processed transactions / second

Performance User/event response time
Screen refresh time
Mbytes
Size
Number of ROM chips
Training time
Usability
Number of help screens
Mean time to failure
Probability of unavailability
Reliability
Rate of failure occurrence
Availability
Time to restart after failure
Robustness Percentage of events causing failure
Probability of data corruption on failure
Requirements Engineering 25

25

Examples - Specifying NFRs with Metrices (1/2)

Ref: https://www.altexsoft.com/blog/non-functional-requirements/

 Performance
▪ The landing page supporting 5,000 users per hour must provide
6 second or less response time in a Chrome desktop browser,
including the rendering of text and images and over an LTE
connection
 Scalability
▪ The system must be scalable enough to support 1,000,000 visits
simultaneously, while maintaining optimal performance
 Portability
▪ A program running on Windows 10 must be able to run on
Windows 11 without any change in its behavior and performance

LTE is a half-point between 3G and 4G, so its performance is degraded as compared to the fourth generation
Requirements Engineering 26

26

13
 10/13/2023

Examples - Specifying NFRs with Metrices (2/2)

Ref: https://www.altexsoft.com/blog/non-functional-requirements/

 Reliability
▪ The system must perform without failure in 95 percent of use
cases during a month
 Availability
▪ The web dashboard must be available to NUST users 99.98
percent of the time every month during business hours EST.
 Localization
▪ The date format must be as follows: date-month-year (dd-mm-yyyy)
 Security
▪ The payment processing gateway must be PCI DSS compliant

What are the 12 requirements of PCI DSS Compliance?

Requirements Engineering 27

27

Dependability reflects the extent of the user’s

confidence that it will operate as users expect and
that it will not ‘fail’ in normal use

DEPENDABILITY PROPERTIES
REFERENCE: CH 10, IAN SOMMERVILLE 10TH EDITION

Requirements Engineering 28

28

14
 10/13/2023

Principal Properties of Dependability

(Non-exhaustive List)

• Availability: The probability that the system will be up and

running and able to deliver useful services to users.
• Reliability: The probability that the system will correctly deliver
services as expected by users.
• Safety: A judgment of how likely it is that the system will not
cause damage to people or its environment.
• Security: A judgment of how likely it is that the system can
resist accidental or deliberate intrusions.
• Resilience: A judgment of how well a system can maintain the
continuity of its critical services in the presence of disruptive
events such as equipment failure and cyberattacks.

Requirements Engineering 29

29

Dependability Properties Inter-dependencies

 Safe system operation depends on the system being

available and operating reliably.
 A system may be unreliable because its data has been
corrupted by an external attack (security).
 Denial of service (DoS) attacks on a system making it
insecure are intended to make it unavailable.
 If a system is infected with a virus, you cannot be
confident in its reliability or safety.

Chapter 10 Dependable Systems 30

30

15
 10/13/2023

How to achieve Dependability?

• Avoid the introduction of accidental errors when developing

the system.
• Design systems to be fault tolerant so that they can continue
in operation when faults occur.
• Design protection mechanisms that guard against external
attacks.
• Include system capabilities to recognize and resist
cyberattacks.
• Include recovery mechanisms to help restore normal system
service after a failure.

Requirements Engineering 31

31

END WEEK 3

Requirements Engineering 32

32

16