COMP3211

04. Requirements Engineering

Dr. Max Yu Pei

Intended Learning Outcomes
❖ Upon completion of this lecture, you will
1. understand the concepts of user and system requirements and
why these requirements should be written in different ways;
2. understand the differences between functional and non-
functional software requirements;
3. understand the main requirements engineering activities of
elicitation, analysis, and validation, and the relationships
between these activities;
4. understand why requirements management is necessary and
how it supports other requirements engineering activities.

2
Requirements and Requirements Engineering
❖ The requirements for a system are the descriptions of the
services that a system should provide and the constraints on
its operation.
➢ It may range from a high-level, abstract statement of a service or
of a system constraint to a detailed, formal 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.
❖ The process of finding out, analyzing, documenting, and
checking these services and constraints is called requirements
engineering (RE).

3
Types of Requirements
❖ User requirements: Statements in natural language plus diagrams of the
services the system provides and its operational constraints.
❖ System requirements: A
structured document setting
out detailed descriptions of
the system’s functions, services
and operational constraints.
Defines what should be
implemented. May be part
of a contract between the
client and the contractor.
❖ Different kinds of requirements
are needed to communicate
information about a system to
different types of stakeholders.
➢ Any person or organization who is
affected by the system in some way

4
Agile Methods and Requirements
❖ Requirements in agile processes
➢ Many agile methods argue that producing detailed system
requirements is a waste of time as requirements change so
quickly that the requirements document is always out of date.
➢ Agile methods usually use incremental requirements
engineering and may express requirements as “user stories”.
➢ 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.
❖ This lecture presents a “traditional” view of requirements.
➢ For most large systems, it is still the case that there is a clearly
identifiable requirements engineering phase before
implementation of the system begins.
➢ The outcome is a requirements document.

5
FUNCTIONAL AND NON-FUNCTIONAL
REQUIREMENTS

6
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.
➢ Often apply to the system as a whole, rather than individual
features or services of the system.
❖ In practice, the distinction between the two types is not as
clear-cut as these simple definitions suggest.
➢ Requirements are not independent
➢ The system requirements should specify both the services or the
features of the system and the necessary functionality to ensure
that the services and features are delivered effectively

7
Functional Requirements
❖ Describe functionality or system services.
➢ Depend on the type of software being developed, the expected
users of the software, and the general approach taken by the
organization when writing requirements.
➢ Functional user requirements may be high-level statements of
what the system should do.
➢ Functional system requirements should describe the system
services in detail.
➢ Ideally, the functional requirements specification of a system
should be both complete and consistent.
❖ Mentcare system: functional system 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 8-digit employee number.
8
Non-Functional Requirements
❖ Define system properties (e.g., reliability, response time, and
storage requirements) and constraints (e.g., I/O device
capability and the data representations).
➢ Non-functional requirements may be more critical than
functional requirements—If they are not met, the system may be
useless.
➢ It is often more difficult to identify which system components
implement specific non-functional requirements
▪ Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.
▪ A single non-functional requirement may generate a number
of related functional requirements, and it may also generate
requirements that restrict existing requirements.

9
Classification of Non-Functional Requirements
❖ Product requirements
➢ Requirements which specify that the delivered product must behave in
a particular way
➢ E.g., usability, efficiency (performance, space), dependability, security
❖ Organisational requirements
➢ Requirements which are a consequence of organisational policies and
procedures
➢ E.g., environmental, operational, development
❖ External requirements
➢ Requirements which arise from factors which are external to the system
and its development process
➢ E.g., regulatory, ethical, legislative (accounting, safety/security)

10
Examples of Nonfunctional Requirements
❖ 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 identify themselves using
their health authority identity card.

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

11
Goals and Verifiable Requirements
❖ Non-functional requirements may be 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.

❖ Example: Usability requirement

➢ 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. (Testable non-functional requirement)

12
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

13
Challenges in Specifying Non-Functional Req.
❖ Customers for a system may find it difficult to translate their
goals into measurable requirements.
➢ No simple metrics
➢ Unclear connection between metrics and everyday experience
➢ Too high costs for verification

❖ Non-functional requirements often conflict and interact with

other functional or non-functional requirements

❖ It is difficult to separate functional and non-functional

requirements in the requirements document.

14
REQUIREMENTS ENGINEERING
PROCESSES

15
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;
➢ Requirements specification;
➢ Requirements validation;

❖ In practice, RE is an iterative
activity in which these
processes are interleaved.
A spiral view of the RE process
16
REQUIREMENTS ELICITATION

17
Requirements Elicitation
❖ Sometimes called requirements discovery
➢ Involves technical staff working with stakeholders to find out about the
application domain, work activities, the services and system features
that stakeholders want, etc.
❖ Stages
➢ Discovery and understanding: Interacting with stakeholders to discover
their requirements.
➢ Classification and organisation: Groups
related requirements and organises
them into coherent clusters.
➢ Prioritisation and negotiation:
Prioritising requirements and
resolving requirements conflicts.
➢ Documentation: The requirements are
documented and input into the next round
of the spiral.

18
Problems of Requirements Elicitation
❖ Stakeholders don’t know what they really want.
❖ Stakeholders express requirements in their own terms and
with implicit knowledge of their own work.
❖ Different stakeholders, with diverse requirements, may express
their requirements in different ways.
❖ Organisational and political factors may influence the system
requirements.
❖ The requirements change during the analysis process. New
stakeholders may emerge, and the business environment may
change.

19
Techniques (1)
❖ Interviewing, where you talk to people about what they do.
➢ Closed interviews based on pre-determined list of questions
➢ Open interviews where various issues are explored with
stakeholders.
➢ Normally a mixture of closed and open interviewing.
❖ Problems
➢ Application specialists may use language that isn’t easy for the
requirements engineer to understand to describe their work.
➢ Interviews are not good for understanding domain requirements
❖ Effective interviewing
➢ Be open-minded, avoid pre-conceived ideas about the
requirements, and be willing to listen to stakeholders.
➢ Prompt the interviewee to talk about the system by suggesting
requirements rather than simply asking them what they want.
20
Techniques (2)
❖ Observation or ethnography, where you watch people doing
their job to see what artifacts they use, how they use them, and
so on.

❖ Benefits
➢ People do not have to explain or articulate their work.
➢ Social and organizational factors of importance may be observed.
➢ Requirements can be derived from the way that people actually
work (rather than the way in which they should work).
➢ Requirements can be derived from cooperation and awareness of
other people’s activities.

21
REQUIREMENTS SPECIFICATION

22
Requirements Specification
❖ The process of writing down the user and system
requirements in a requirements document.
➢ User requirements must 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.

23
Requirements and Design
❖ In principle, requirements should state what the system
should do and the design should describe how it does this.

❖ In practice, requirements and design are inseparable

➢ You may have to design an initial architecture of the system to
help structure the requirements specification.
➢ In most cases, systems must interoperate with existing systems,
which constrain the design and impose requirements on the new
system.
➢ The use of a specific architecture to satisfy non-functional
requirements, such as N-version programming to achieve
reliability, may be necessary.

24
Notations for Writing System Requirements

Notation Description
Natural language The requirements are written using numbered sentences in natural language.
sentences Each sentence should express one requirement.
Structured The requirements are written in natural language on a standard form or
natural language template. Each field provides information about an aspect of the requirement.
Graphical Graphical models, supplemented by text annotations, are used to define the
notations functional requirements for the system; UML use case and sequence diagrams
are commonly used.

Design This approach uses a language like a programming language, but with more
description abstract features to specify the requirements by defining an operational model
languages of the system. This approach is now rarely used although it can be useful for
interface specifications.
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

25
Natural Language Specification
❖ Natural languages are
➢ Expressive, intuitive, and universal—the requirements can be
understood by users and customers
➢ Potentially vague and ambiguous—its interpretation depends on
the background of the reader.
❖ Guidelines on writing natural language requirements
➢ Invent a standard format and use it for all requirements.
➢ Use language in a consistent way. Use “shall” for mandatory
requirements; Use “should” for desirable requirements.
➢ Use text highlighting to identify key parts of the requirement.
➢ Avoid the use of computer jargon.
➢ Include an explanation (rationale) of why a requirement is
necessary.

26
Example Natural Language Specifications

3.2 The system shall measure the blood sugar and deliver insulin, if
required, every 10 minutes. (Changes in blood sugar are relatively slow
so more frequent measurement is unnecessary; less frequent
measurement could lead to unnecessarily high sugar levels.)

3.6 The system shall run a self-test routine every minute with the
conditions to be tested and the associated actions defined in Table 1. (A
self-test routine can discover hardware and software problems and alert
the user to the fact the normal operation may be impossible.)

27
Structured Natural Language Specifications
❖ An approach to writing requirements where the requirements
are written in a standard way rather than as free-form text.
➢ Maintains most expressiveness and understandability of NL
➢ Removes some of the problems of NL specification
➢ It is still sometimes difficult to write requirements in a clear and
unambiguous way

28
Tabular Specification
❖ Use tables to add extra information to NL requirements.
➢ Particularly useful when you have to define a number of possible
alternative courses of action.
❖ Example
➢ The insulin pump systems bases its computations on the rate of
change of blood sugar level and the tabular specification
explains how to calculate the insulin requirement for different
scenarios.
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of increase CompDose = 0
decreasing ((r2 – r1) < (r1 – r0))
Sugar level increasing and rate of increase CompDose = round ((r2 – r1)/4)
stable or increasing ((r2 – r1) ≥ (r1 – r0)) If CompDose = 0 then
CompDose = MinimumDose

29
Use Cases
❖ A way of describing interactions between users and a system
using a graphical model and structured text.
➢ In its simplest form, a use case identifies the actors involved in
an interaction and names the type of interaction.
➢ Additional information can be added to describe the interaction
with the system.
❖ Use case diagram
➢ Each use case (a named ellipse)
represents a class of interaction.
➢ An actor (a stick figure) is a person
or a system.
➢ Lines link actors with the
interaction.
➢ Documented with a textual description
30
The Software Requirements Specification (SRS)
❖ The software requirements document is the official statement
of what the system developers should implement
❖ The information in requirements specification depends on the
type of system and the development process used.
➢ Should include both a definition of user requirements and a
specification of the system requirements.
➢ Requirements specification standards have been designed (e.g.,
IEEE standard). These are mostly applicable to the requirements
for large systems engineering projects.
➢ Systems developed incrementally will, typically, have less detail
in the requirements specification.
❖ It is NOT a design document. As far as possible, it should set
out WHAT the system should do rather than HOW it should do
it.
31
The Structure of A Requirements Specification (1)

Chapter Description
Preface This should define the expected readership of the document and describe its
version history, including a rationale for the creation of a new version and a
summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It should also
describe how the system fits into the overall business or strategic objectives of the
organization commissioning the software.
Glossary This should define the technical terms used in the document. You should not make
assumptions about the experience or expertise of the reader.
User requirements Here, you describe the services provided for the user. The nonfunctional system
definition requirements should also be described in this section. This description may use
natural language, diagrams, or other notations that are understandable to
customers. Product and process standards that must be followed should be
specified.
System This chapter should present a high-level overview of the anticipated system
architecture architecture, showing the distribution of functions across system modules.
Architectural components that are reused should be highlighted.

32
The Structure of A Requirements Specification (2)

Chapter Description

System This should describe the functional and nonfunctional requirements in more detail.
requirements If necessary, further detail may also be added to the nonfunctional requirements.
specification Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships between
the system components and the system and its environment. Examples of
possible models are object models, data-flow models, or semantic data models.
System evolution This should describe the fundamental assumptions on which the system is based,
and any anticipated changes due to hardware evolution, changing user needs,
and so on. This section is useful for system designers as it may help them avoid
design decisions that would constrain likely future changes to the system.
Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database descriptions.
Hardware requirements define the minimal and optimal configurations for the
system. Database requirements define the logical organization of the data used
by the system and the relationships between data.
Index Several indexes to the document may be included. As well as a normal alphabetic
index, there may be an index of diagrams, an index of functions, and so on.

33
REQUIREMENTS VALIDATION

34
Requirements Validation
❖ The process of checking that requirements define the system
that the customer really wants
➢ Overlaps with elicitation and analysis
➢ Different types of checks
▪ Validity checks. Do the requirements reflect the real needs of
system users?
▪ Consistency checks. Are there any requirements conflicts?
▪ Completeness checks. Are all functions required by the customer
included?
▪ Realism checks. Can the requirements be implemented, given the
available budget and technology?
▪ Verifiability checks. Can the requirements be verified?

35
Requirements Validation Techniques
❖ Various techniques that can be used individually or together
➢ Requirements reviews
▪ Systematically and manually analyze the requirements to
check for errors and inconsistencies
▪ Should be held regularly during the formulation of
requirements
▪ Should involve both client and contractor staff
▪ May be formal (with completed documents) or informal.
➢ Prototyping
▪ Using an executable model of the system to check
requirements.
➢ Test-case generation
▪ Developing tests for requirements to check verifiability.
❖ You rarely find all requirements problems during the
requirements validation process!
36
REQUIREMENTS CHANGE

37
Changing Requirements
❖ Software systems are often
developed to address “wicked”
problems—problems that
cannot be completely defined

❖ Once a system has been installed and is regularly used, new

requirements inevitably emerge.
➢ The original requirements may have errors and omissions.

➢ The business and technical environment of the system

always changes after installation.
➢ Large systems usually have a diverse stakeholder
community, which may change, and the requirements and
priorities of those stakeholders may change.

38
Requirements Management
❖ The process of managing changing requirements during the
requirements engineering process and system development.
➢ To keep track of individual requirements and maintain links
between dependent requirements to facilitate the impact
assessment of requirements changes.
❖ Important issues in requirements management planning
➢ Requirements identification;
➢ A change management process;
➢ Traceability policies;
➢ Tool support.
❖ Stages in requirements change management
➢ Problem analysis and change specification
➢ Change analysis and costing
➢ Change implementation (including revising the SRS)
39
Key Points (1)
❖ 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.
❖ Non-functional requirements often relate to the emergent
properties of the system and therefore apply to the system as
a whole.

40
Key Points (2)
❖ The requirements engineering process is an iterative process
that includes requirements elicitation, specification and
validation.
❖ Requirements elicitation is an iterative process that can be
represented as a spiral of activities – requirements discovery
and understanding, requirements classification and
organization, requirements prioritization and negotiation, and
requirements documentation.
❖ You can use a range of techniques for requirements elicitation
including interviews and ethnography. User stories and
scenarios may be used to facilitate discussions.

41
Key Points (3)
❖ Requirements specification is the process of formally
documenting the user and system requirements and creating
a software requirements document.
❖ The software requirements specification is an agreed
statement of the system requirements. It should be organized
so that both system customers and software developers can
use it.
❖ Requirements validation is the process of checking the
requirements for validity, consistency, completeness, realism,
and verifiability.
❖ Business, organizational and technical changes inevitably lead
to changes to the requirements for a software system.
Requirements management is the process of managing and
controlling these changes.
42
THE END

43