Advanced Systems Analysis and Design –MSIS811

Requirements Engineering
Topics covered

 Functional and non-functional requirements

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

10/20/2024 Chapter 4 Requirements Engineering 2

Requirements engineering

 The process of finding out, analyzing, documenting

and checking 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.

10/20/2024 Chapter 4 Requirements Engineering 3

What is a requirement?

 The term ‘requirement’ is not used consistently in

the software industry.
 In some cases, a requirement is simply a high-level,
abstract statement of a service that a system should
provide or a constraint on a system.
 At the other extreme, it is a detailed, formal
definition of a system function.

10/20/2024 Chapter 4 Requirements Engineering 4

 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.

10/20/2024 Chapter 4 Requirements Engineering 5

User and system requirements

10/20/2024 Chapter 4 Requirements Engineering 6

Agile methods and requirements

 For most large systems, there is a clearly identifiable

requirements engineering phase before the
implementation of the system begins.
 There are usually subsequent changes to the
requirements and user requirements may be
expanded into more detailed system requirements
 However, the agile approach of concurrently eliciting
the requirements as the system is developed is
rarely used for large systems development

10/20/2024 Chapter 4 Requirements Engineering 7

Agile methods and requirements continued…

 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’ as we discussed earlier.
 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.
10/20/2024 Chapter 4 Requirements Engineering 8
 Functional and non-functional requirements

10/20/2024 Chapter 4 Requirements Engineering 9

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.

10/20/2024 Chapter 4 Requirements Engineering 10

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.

10/20/2024 Chapter 4 Requirements Engineering 11

Imprecision requirements

 Problems arise when functional requirements are

not precisely stated.
 Ambiguous requirements may be interpreted in
different ways by developers and users.
 Consider the requirements:
1. A user shall be able to search the appointments lists for all
medical 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

10/20/2024 Chapter 4 Requirements Engineering 12

 It is natural for a system developer to interpret an ambiguous
requirement in a way that simplifies its implementation
 The above first requirement states that a user shall be able to
search the appointments lists for all clinics.
 Patients may have an appointment at one clinic but actually go to a
different clinic. If they have an appointment, they will be recorded
as having attended, irrespective of the clinic
 The medical staff member specifying this may expect ‘search’ to
mean that, given a patient name, the system looks for that name in
all appointments at all clinics which is not explicit requirement.
 System developers may interpret the requirement in a different
way and may implement a search so that the user has to choose a
clinic then carry out the search

10/20/2024 Chapter 4 Requirements Engineering 13

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.

10/20/2024 Chapter 4 Requirements Engineering 14

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.
 Non-functional requirements, such as performance,
security, or availability, usually specify or constrain
characteristics of the system as a whole.
 Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system may be useless.

10/20/2024 Chapter 4 Requirements Engineering 15

Goals and requirements

 Non-functional requirements may be very difficult to

state precisely and imprecise requirements may be
difficult to verify.
 Goal
 A general intention of the user such as ease of use.
 Verifiable non-functional requirement
 A statement using some measure that can be objectively
tested.
 Goals are helpful to developers as they convey the
intentions of the system users.

10/20/2024 Chapter 4 Requirements Engineering 16

 Requirements engineering processes

10/20/2024 Chapter 4 Requirements Engineering 17

Requirements engineering processes

 The processes used for RE vary widely depending

on the application domain, the people involved and
the organisation developing the requirements.
 However, there are a number of generic activities
common to all processes
 Requirements elicitation and analysis;
 Requirements validation;
 Requirements management.
 In practice, RE is an iterative activity in which these
processes are interleaved.

10/20/2024 Chapter 4 Requirements Engineering 18

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.

10/20/2024 Chapter 4 Requirements Engineering 19

The requirements elicitation and analysis
process

10/20/2024 Chapter 4 Requirements Engineering 20

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

10/20/2024 Chapter 4 Requirements Engineering 21

Requirements discovery
 The process of gathering information about the
required and existing systems and distilling the user
and system requirements from this information.
 Interaction is with system stakeholders from
managers to external regulators.
 Systems normally have a range of stakeholders.

10/20/2024 Chapter 4 Requirements Engineering 22

Interviewing

 Formal or informal interviews with

stakeholders are part of most RE processes.
 Types of interview
 Closed interviews based on pre-
determined list of questions
 Open interviews where various issues are
explored with stakeholders.

10/20/2024 Chapter 4 Requirements Engineering 23

Interviews in practice

 Normally a mix of closed and open-ended

interviewing.
 Interviews are good for getting an overall
understanding of what stakeholders do and how
they might interact with the system.
 Interviewers need to be open-minded without pre-
conceived ideas of what the system should do
 You need to prompt the use to talk about the system
by suggesting requirements rather than simply
asking them what they want.

10/20/2024 Chapter 4 Requirements Engineering 24

Problems with interviews

 Application specialists may use language to

describe their work that isn’t easy for the
requirements engineer to understand.
 Interviews are not good for understanding domain
requirements
 Requirements engineers cannot understand specific
domain terminology;
 Some domain knowledge is so familiar that people find it
hard to articulate or think that it isn’t worth articulating.

10/20/2024 Chapter 4 Requirements Engineering 25

Requirements classification and
organization
• This activity takes the unstructured collection of
requirements, groups related requirements, and
organizes them into coherent clusters.

• The most common way of grouping requirements is

to use a model of the system architecture to identify sub-
systems and to associate requirements with each sub-
system. In practice, requirements engineering and
architectural design cannot be completely separate
activities.

10/20/2024 Chapter 4 Requirements Engineering 26

Requirements prioritization and
negotiation
• When multiple stakeholders are involved,
requirements will conflict.

• This activity is concerned with prioritizing

requirements and finding and resolving requirements
conflicts through negotiation.

• Usually, stakeholders have to meet to resolve

differences and agree on compromise requirements.

10/20/2024 Chapter 4 Requirements Engineering 27

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.
10/20/2024 Chapter 4 Requirements Engineering 28
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.

10/20/2024 Chapter 4 Requirements Engineering 29

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.

10/20/2024 Chapter 4 Requirements Engineering 30

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 or
verified?

10/20/2024 Chapter 4 Requirements Engineering 31

Requirements management

 Requirements management is the process of

understanding and controlling changes to system
requirements

 You need to keep track of individual requirements and

maintain links between dependent requirements so
that you can assess the impact of requirements
changes.

 The formal process of requirements management

should start as soon as a draft version of the
requirements document is available.
10/20/2024 Chapter 4 Requirements Engineering 32