Software Engineering: CSC1233

Advanced Software Engineering Concepts: COM3212

Requirements Engineering
Lecture 13

Dr. S.M. Vidanagamachchi

Department of Computer Science [email protected] 2022 1

Outline: Requirements Engineering
• Functional and non-functional requirements
• The software requirements document
• Requirements specification
• Requirements engineering processes
• Requirements elicitation and analysis
• Requirements validation
• Requirements management

Department of Computer Science [email protected] 2022 2

Learning Outcomes
At the end of this module, you should be able to:
• Understand the concepts of user and system
requirements and functional and nonfunctional
software requirements
• Understand how requirements may be organized in a
software requirements document
• Explain the principal requirements engineering
activities of elicitation, analysis and validation, and the
relationships between these activities
• Discuss why requirements management is necessary
and how it supports other requirements engineering
activities
Department of Computer Science [email protected] 2022 3
 Types of Requirements
• User requirements
• System requirements

Department of Computer Science [email protected] 2022 4

User Requirements
• Definition

“User requirements are statements, in a natural

language plus diagrams, of what
services the system is expected to provide to system
users and the constraints
under which it must operate”

• Basically written for customers

Department of Computer Science [email protected] 2022 5
System Requirements
• Definition

“System requirements more detailed descriptions of the

software system’s
functions, services, and operational constraints. ”

• Written as a contract between the customer and the

contractor (S/W organization)
• The “system requirements document” is known as
“functional specification”

Department of Computer Science [email protected] 2022 6

Example: mental health care patient
management system

Department of Computer Science [email protected] 2022 7

Readers of different types of
requirements

Department of Computer Science [email protected] 2022 8

Functional vs Non-Functional
Requirements
• Functional:
These are statements of services the system should
provide, how the system should react to particular
inputs, and how the system should behave in particular
situations. In some cases, the functional requirements
may also explicitly state what the system should not do.

Department of Computer Science [email protected] 2022 9

Functional vs Non-Functional
Requirements
• Non-Functional:
These are constraints on the services or functions
offered by the system. They include timing constraints,
constraints on the development process, and
constraints imposed by standards. Non-functional
requirements often apply to the system as a whole,
rather than individual system features or services.

Department of Computer Science [email protected] 2022 10

Examples: Functional Requirements
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 eight-digit employee number.

Department of Computer Science [email protected] 2022 11

Non-Functional Requirements…
• Reliability, response time, performance/efficiency,
security, maintenance, availability
• Non-functional requirements may affect the overall
architecture of a system rather than the individual
components. For eg, 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 new system
services that are required. In addition, it may also
generate requirements that restrict existing
Department of Computer Science [email protected] 2022 12
requirements.
Non-Functional Requirements…

Department of Computer Science [email protected] 2022 13

Non-Functional Requirements…
• Product requirements : These requirements specify or
constrain the behavior of the software

Examples: performance requirements on how fast the

system must execute and how much memory it
requires, reliability requirements that set
out the acceptable failure rate, security requirements,
and usability requirements.

Department of Computer Science [email protected] 2022 14

Non-Functional Requirements…
• Organizational requirements: These requirements are
broad system requirements derived from policies and
procedures in the customer’s and developer’s
organization.
• Examples: operational process requirements that
define how the system will be used, development
process requirements that specify the programming
language, the development environment or process
standards to be used, and environmental requirements
that specify the operating environment of the system.
Department of Computer Science [email protected] 2022 15
 Non-Functional Requirements…
• External requirements : This broad heading covers all
requirements that are derived from factors external to the
system and its development process.

• Examples: regulatory requirements that set out what

must be done for the system to be approved for use by a
regulator, such as a central bank; legislative requirements
that must be followed to ensure that the system operates
within the law; and ethical requirements that ensure that
the system will be acceptable to its users and the general
public. Department of Computer Science [email protected] 2022
16
Exercise
• List functional and non-functional requirements of the
Amazon.co.uk website

Department of Computer Science [email protected] 2022 17

The Software Requirements Document…
• Requirements specification is the process of writing
down the user and system requirements in a
requirements document

• The user requirements for a system should describe the

functional and nonfunctional requirements

• The requirements document should not include details

of the system architecture or design

• Natural language, with simple tables, forms, and

intuitiveDepartment
diagrams of Computer Science [email protected] 2022 18
 The Software Requirements Document…

• Ideally, the system requirements should simply describe

the external behavior of the system and its operational
constraints

• The system requirements are organized according to

the different sub-systems that make up the system

• Architectural definition is essential if you want to reuse

software components when implementing the system
(chapter 6 and 18 for more details)
Department of Computer Science [email protected] 2022 19
Ways of Writing SRS

Department of Computer Science [email protected] 2022 20

Natural Language Specification
• Has been used since the beginning of software
engineering
• Guidelines: to minimize misunderstandings when
writing natural language requirements
– Invent a standard format and ensure that all requirement
definitions adhere to that format
– Use language consistently to distinguish between mandatory
and desirable requirements
– Use text highlighting (bold, italic, or color) to pick out key
parts of the requirement
– Avoid the use of jargon, abbreviations, and acronyms
– Try to associate a rationale with each user requirement
Department of Computer Science [email protected] 2022 21
 Structured Specifications
• The freedom of the requirements writer is limited and all
requirements are written in a standard way

• Maintains most of the expressiveness and

understandability of natural language but ensures that
some uniformity is imposed on the specification

• Requirements are organized more effectively

Department of Computer Science [email protected] 2022 22

Structured Specifications
• Information should be included:
1. A description of the function or entity being specified.
2. A description of its inputs and where these come from.
3. A description of its outputs and where these go to.
4. Information about the information that is needed for the
computation or other entities in the system that are used
(the ‘requires’ part).
5. A description of the action to be taken.
6. If a functional approach is used, a pre-condition setting
out what must be true before the function is called, and a
post-condition specifying what is true after the function is
called.
7. A description of the side effects (if any) of the operation.
Department of Computer Science [email protected] 2022 23
Structured Specifications: Example

Department of Computer Science [email protected] 2022 24

Requirements Elicitation and Analysis:
Process Model

Department of Computer Science [email protected] 2022 25

Reasons for difficulties in Elicitation
Phase
• Stakeholders often don’t know what they want from a
computer system
• Stakeholders in a system naturally express requirements
in their own terms and with implicit knowledge of their
own work
• Different stakeholders have different requirements and
they may express these in different ways
• Political factors may influence the requirements of a
system
• The economic and business environment in which the
analysis takes place
Department of is dynamic
Computer Science [email protected] 2022 26
Example: stake-holders mental
healthcare patient information system
• Patients , Doctors, Nurses, Medical receptionists, IT staff
, A medical ethics manager, Healthcare manager,
Medical record staff

Department of Computer Science [email protected] 2022 27

Interviewing
• Formal or informal interviews with system stakeholders
are part of most requirements engineering processes

• Ask questions to stakeholders about the system that

they currently use and the system to be developed

• Requirements are derived from the answers to these

questions

• Closed interviews and open interviews (no pre-defined

Department of Computer Science [email protected] 2022 28
agenda)
Scenarios
• People usually find it easier to relate to real-life
examples rather than abstract descriptions

• They can understand and criticize a scenario of how

they might interact with a software system

• A scenario starts with an outline of the interaction.

During the elicitation process, details are added to this
to create a complete description of that interaction.

Department of Computer Science [email protected] 2022 29

Scenarios
• Each scenario usually covers one or a small number of
possible interactions

• The user stories used in extreme programming, are a

type of requirements scenario

Department of Computer Science [email protected] 2022 30

Scenarios
1. A description of what the system and users expects
when the scenario starts
2. A description of the normal flow of events in the
scenario
3. A description of what can go wrong and how this is
handled
4. Information about other activities that might be going
on at the same time
5. A description of the system state when the scenario
finishes
Department of Computer Science [email protected] 2022 31
Scenarios: Example

Department of Computer Science [email protected] 2022 32

Brainstorming
• Used in requirements elicitation to get as many ideas as
possible from a group of people

– An activity done in a group, not individually

– Normally composed of organizational stakeholders who
are generating ideas that will be refined later
– Specifically defined for one stated purpose (more
effective)

Department of Computer Science [email protected] 2022 33

Prototyping & Focus Groups
• Prototyping: Throw-away (paper or dummy GUI) vs
Evolutionary prototyping

• Focus group: A focus group is a gathering of people who

are representative of the users or customers of a
product to get feedback
– The feedback can be gathered about needs / opportunities /
problems to identify requirements, or can be gathered to
validate and refine already elicited requirements

Department of Computer Science [email protected] 2022 34

Use Case Analysis

Department of Computer Science [email protected] 2022 35

Characteristics of excellent requirements
• Correct
– The requirements should reflect the actual needs of the
stakeholders
• Unambiguous
– They should not be able to be interpreted in different ways by
different people
• Complete
– They should include descriptions of all facilities required
• Consistent
– There should be no conflicts or contradictions in the
descriptions of the system facilities
• Verifiable
– The requirements should be written in a way so that the
Department of Computer Science
completed system could [email protected] 2022
tested against them 36
Ambiguous requirements
• May be interpreted in different ways by different people

• Consider requirement 1 from previous MHC system

example:
– A user shall be able to search the appointments lists for
all clinics
• User intention – given a name, search across all
appointments in all clinics
• Developer interpretation – given a name and a clinic,
search in the individual clinic only. User chooses clinic then
search

Department of Computer Science [email protected] 2022 37

Non-verifiable vs. verifiable requirement
• The system should be easy to use by medical staff and
should be organized in such a way that user errors are
minimized

• 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

Department of Computer Science [email protected] 2022 38

Exercise

Your group of software developers is experiencing

difficulties in the domain and requirement analysis
phase. What are the possible difficulties and how you
can overcome it?

Department of Computer Science [email protected] 2022 39

 Exercise: Answers
• Lack of understanding of the domain or the real problem
Do domain analysis and prototyping etc.
• Requirements can change rapidly
Perform incremental development, build flexibility into the
design, do regular reviews
• Attempting to do too much
Document the problem boundaries (scope) at an early stage,
carefully estimate the time
• It may be hard to identify conflicting sets of requirements
Brainstorming, focus groups, prototypes, interviews
• It is hard to state requirements precisely
Break requirements down into simple sentences and review
them carefully, look for potential
Department of Computer Science
ambiguity,
[email protected]
make early
2022 40
prototypes
A Spiral View of the Requirements
Engineering Process

Department of Computer Science [email protected] 2022 41

Requirements Engineering

Department of Computer Science [email protected] 2022 42

Requirements Engineering Discipline

Department of Computer Science [email protected] 2022 43

Requirements validation
• Types of checks carried out:
– Validity checks
A user may think that a system is needed to perform
certain functions. However, further thought and
analysis may identify additional or different
functions that are required.
– Consistency checks
Requirements in the document should not conflict.
That is, there should not be contradictory constraints
or different descriptions of the same system function.

Department of Computer Science [email protected] 2022 44

Requirements validation
• Types of checks carried out:
– Completeness checks
The requirements document should include
requirements that define all functions and the
constraints intended by the system user
– Realism checks
Using knowledge of existing technology, the
requirements should be checked to ensure that they
can actually be implemented
– Verifiability
To reduce the potential for dispute between customer
and contractor, system requirements should always be
writtenDepartment
so that theyScience
of Computer are verifiable
[email protected] 2022 45
Requirements validation
• Validation techniques:
– Requirements reviews
The requirements are analyzed systematically by a team
of reviewers who check for errors and inconsistencies
– Prototyping
In this approach to validation, an executable model of
the system in question is demonstrated to end-users
and customers
– Test-case generation
Requirements should be testable
Developing tests from the user requirements before any code
is written is an integral part of extreme programming (test-
first development)
Department of Computer Science [email protected] 2022 46
Requirements management
• There are several reasons why change is inevitable

• 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

Department of Computer Science [email protected] 2022 47

Requirements change management
• Problem analysis and change specification
The process starts with an identified requirements problem
or, sometimes, with a specific change proposal, should
check the validity

• Change analysis and costing

The cost of making the change is estimated both in terms of
modifications to the requirements document and, if
appropriate, to the system design and implementation

Department of Computer Science [email protected] 2022 48

Requirements change management
• Change implementation
The requirements document and, where necessary, the
system design and implementation, are modified.

Department of Computer Science [email protected] 2022 49

IEEE SRS Template

Department of Computer Science [email protected] 2022 50

SRS template from Wiegers 2003

Department of Computer Science [email protected] 2022 51

 Exercise
• What kind of approach was introduced for elicitation and
modelling to give a functional view of the system?

a) Object Oriented Design (by Booch)

b) Use Cases (by Jacobson)
c) Fusion (by Coleman)
d) Object Modeling Technique (by Rambaugh)

Department of Computer Science [email protected] 2022 52

Exercise
• Why is Requirements Elicitation a difficult task?
a) Problem of scope
b) Problem of understanding
c) Problem of volatility
d) All of the mentioned

Department of Computer Science [email protected] 2022 53

 Thank you

Department of Computer Science [email protected] 2022 54