Date Topic Book Chapter(s)

Wed 8.9. Course introduction

Tue 14.9. Introduction to Software Engineering Chapter 1
Tue 21.9. Software Processes Chapter 2
Course Mon 27.9 Agile Software Engineering Chapter 3
Lecture Tue 5.10. Requirements Engineering Chapter 4

Schedule Mon 11.10. Architectural Design Chapter 6

Wed 20.10. Modeling and implementation Chapters 5 & 7
Mon 1.11. Testing & Quality Chapters 8 & 24
Teachers:
Mon 8.11. Software Evolution & Configuration Management Chapters 9 & 25
Maria
Mon 15.11. Software Project Management Chapter 22
Susan
Sami Mon 22.11. Software Project Planning Chapter 23
Hyrynsalmi Mon 29.11. Global Software Engineering
Wed 8.12. Software Business
Mon 13.12. Last topics
Lecture5
Requirements Engineering

Chapter 4 Requirements Engineering 2

Topics covered

 What is requirement engineering（RE）

 Types of requirement
▪ User requirements and system requirements
▪ Functional and non-functional requirements
 Requirements engineering processes
▪ Requirements elicitation
▪ Requirements specification
▪ Requirements validation
▪ Requirements change

Chapter 4 Requirements Engineering 3

What is requirement engineering（RE）

Chapter 4 Requirements Engineering 4

What is requirements

“If a company wishes to let a contract for a large software development

project, it must define its needs in a sufficiently abstract way that a
solution is not pre-defined. The requirements must be written so that
several contractors can bid for the contract, offering, perhaps, different
ways of meeting the client organization’s needs. Once a contract has
been awarded, the contractor must write a system definition for the
client in more detail so that the client understands and can validate what
the software will do. Both of these documents may be called the
requirements document for the system.” (-Davis 1993)

 Abstract definition of the client’s needs

 Detail definition of the system(software)

Chapter 4 Requirements Engineering 5

Requirements definition in waterfall model

Fixing a requirements error

after delivery may cost up
to 100 times the cost of
fixing an implementation
error.

Chapter 2 Software Processes 6

Requirements definition in agile

Agile development occurs in an

environment where requirements are
ambiguous and incomplete.
Users take part in development
assisting in requirements definition.
 Advantage：improved
understanding of customer needs
and the ability to adapt to the
evolving needs of dynamic
environment.
 Disadvantage： Agile pose several
distinct challenges on requirments.

Chapter 4 Requirements Engineering 7

 Do you think it will be difficult to do
requirements definition? Why?

 Blind men touch elephant—radish, fan, wall, pillar, …?

 Different system stakeholders have different viewpoints&concerns;
 Requirements definition should be a comprehensive description of
the whole system.
Chapter 4 Requirements Engineering 8
System stakeholders

https://www.youtube.com/watch?v=P5X-ridjaOY&t=7s（8 min，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
 Different system stakeholders have different requirements on the
same system.
 System requirements should be both complete and consistent.

Chapter 4 Requirements Engineering 9

What is requirement engineering

 In practice, because of system and environmental

complexity, it is almost impossible to produce a complete
and consistent requirements document.
 The requirements definition is very difficult and very
complex .
 The process of finding out, analyzing, documenting and
checking services and constraints is called requirement
engineering(RE).

Chapter 4 Requirements Engineering 10

 Types of requirements

-User requirements and system requirements

-Functional and non-functional requirements

Chapter 4 Requirements Engineering 11

User requirements and system requirements

Statements in natural language plus

diagrams of the services the system
provides and its operational constraints.

A structured document setting out detailed descriptions of the system’s

functions, services and operational constraints.
May be part of a contract between client and contractor.
Chapter 4 Requirements Engineering 12
Example: 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.
 A medical ethics manager who must ensure that the system meets
current ethical guidelines for patient care.
 Health care managers who obtain management information from the
system.
 Medical records staff who are responsible for ensuring that system
information can be maintained and preserved, and that record
keeping procedures have been properly implemented.

Chapter 4 Requirements Engineering 13

Example: User requirements and system
requirements in Mentcare system

Written in
natural
language,
for
customers

Detailed
description,
technical
contract

Chapter 4 Requirements Engineering 14

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.
 Non-functional requirements
▪ Constraints on the, such as timing constraints, constraints on the
development process, standards, etc.

Chapter 4 Requirements Engineering 15

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.

Chapter 4 Requirements Engineering 16

Non-functional requirements

 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 may be more critical than functional
requirements. If these are not met, the system may be useless.
 Non-functional requirements may affect the overall architecture of a
system rather than the individual components.
 A single non-functional requirement, such as a security requirement,
may generate a number of related functional requirements that
define system services that are required.

Chapter 4 Requirements Engineering 17

Types of nonfunctional requirement

Chapter 4 Requirements Engineering 18

Requirements engineering processes

Chapter 4 Requirements Engineering 19

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 analysis;
▪ Requirements specification
▪ Requirements validation;
▪ Requirements management(evolution).

Chapter 4 Requirements Engineering 20

The requirements engineering process

In practice, the whole

process may be repeated,
and form an iterative
activity.

Chapter 4 Requirements Engineering 21

A spiral view of the requirements engineering
process
B
8

7 1 3

A 4
C
6

10

Chapter 4 Requirements Engineering 22

Requirements elicitation and analysis

 Sometimes called requirements discovery.

 May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc.
 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.

Chapter 4 Requirements Engineering 23

Difficulties of requirements elicitation

 Stakeholders don’t know what they really want.

 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting
requirements.
 Organisational and political factors may influence the
system requirements.
 The requirements change during the analysis process,
because new stakeholders may emerge and the
business environment may change.

Chapter 4 Requirements Engineering 24

The requirements elicitation and analysis
process

Chapter 4 Requirements Engineering 25

Requirement elicitation techniques

 The process involves meeting(interview) with different

system stakeholders to discover information about the
system.
 Supplement with information, documents, knowledge of
existing systems.
 Understand how people work， how they may need to
change to accommodate a new system(Ethnography,
Stories and scenarios).

Chapter 4 Requirements Engineering 26

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

Chapter 4 Requirements Engineering 27

Ethnography

 Analysts can spend a considerable time observing and

analysing how people actually work.
 Ethnographic studies have shown that work is usually
richer and more complex than suggested by simple
system models.

Chapter 4 Requirements Engineering 28

Ethnography and prototyping for requirements
analysis

 Combines ethnography with prototyping

 Prototype development results in unanswered questions
which focus the ethnographic analysis.

Chapter 4 Requirements Engineering 29

Stories and scenarios

 Stories and user scenarios are real-life examples of how

a system can be used for a particular task.
 Because they are based on a practical situation,
stakeholders can relate to them and can comment on
their situation with respect to the story.

Chapter 4 Requirements Engineering 30

Example： story of Photo sharing in the
classroom (iLearn)

Jack is a primary school teacher in Ullapool (a village in northern Scotland). He has

decided that a class project should be focused around the fishing industry in the area,
looking at the history, development and economic impact of fishing. As part of this, pupils
are asked to gather and share reminiscences from relatives, use newspaper archives and
collect old photographs related to fishing and fishing communities in the area. Pupils use
an iLearn wiki to gather together fishing stories and SCRAN (a history resources site) to
access newspaper archives and photographs. However, Jack also needs a photo sharing
site as he wants pupils to take and comment on each others’ photos and to upload scans
of old photographs that they may have in their families.

Jack sends an email to a primary school teachers group, which he is a member of to see
if anyone can recommend an appropriate system. Two teachers reply and both suggest
that he uses KidsTakePics, a photo sharing site that allows teachers to check and
moderate content. As KidsTakePics is not integrated with the iLearn authentication
service, he sets up a teacher and a class account. He uses the iLearn setup service to
add KidsTakePics to the services seen by the pupils in his class so that when they log in,
they can immediately use the system to upload photos from their mobile devices and
class computers.

Chapter 4 Requirements Engineering 31

Scenarios

 A structured form of user story，should include

▪ A description of the starting situation;
▪ A description of the normal flow of events;
▪ A description of what can go wrong;
▪ Information about other concurrent activities;
▪ A description of the state when the scenario finishes.

Chapter 4 Requirements Engineering 32

Example： scenario of Uploading photos
（iLearn)-A

 Initial assumption: A user or a group of users have one or more digital photographs
to be uploaded to the picture sharing site. These are saved on either a tablet or
laptop computer. They have successfully logged on to KidsTakePics.
 Normal: The user chooses upload photos and they are prompted to select the
photos to be uploaded on their computer and to select the project name under which
the photos will be stored. They should also be given the option of inputting keywords
that should be associated with each uploaded photo. Uploaded photos are named by
creating a conjunction of the user name with the filename of the photo on the local
computer.
 On completion of the upload, the system automatically sends an email to the project
moderator asking them to check new content and generates an on-screen message
to the user that this has been done.

Chapter 4 Requirements Engineering 33

Example： scenario of Uploading photos
（iLearn)-B

 What can go wrong:

 No moderator is associated with the selected project. An email is automatically
generated to the school administrator asking them to nominate a project moderator.
Users should be informed that there could be a delay in making their photos visible.
 Photos with the same name have already been uploaded by the same user. The user
should be asked if they wish to re-upload the photos with the same name, rename
the photos or cancel the upload. If they chose to re-upload the photos, the originals
are overwritten. If they chose to rename the photos, a new name is automatically
generated by adding a number to the existing file name.
 Other activities: The moderator may be logged on to the system and may approve
photos as they are uploaded.
 System state on completion: User is logged on. The selected photos have been
uploaded and assigned a status ‘awaiting moderation’. Photos are visible to the
moderator and to the user who uploaded them.

Chapter 4 Requirements Engineering 34

Requirements specification

 The process of writing down 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.

Chapter 4 Requirements Engineering 35

The software requirements document

 The software requirements document is NOT a design

document. As far as possible, it should set of WHAT the
system should do rather than HOW it should be done.
 The software requirements document is the official
statement of what is required of the system developers.
 The requirements may be part of a contract for the
system development
▪ It is therefore important that these are as complete as possible.

Chapter 4 Requirements Engineering 36

Requirements document variability

 Requirements documents
standards have been
designed e.g. IEEE
standard.
 Information in
requirements document is
variable, depends on type
of system and the
approach to development
used.

Chapter 4 Requirements Engineering 37

Notations for writing system requirements

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

Chapter 4 Requirements Engineering 38

Natural language specification

 Requirements are written as natural language sentences

supplemented by diagrams and tables.
 Problems with natural language
▪ Precision is difficult.
▪ Several different requirements may be expressed together.
▪ Functional and non-functional requirements tend to be mixed-up.

30/10/2014 Chapter 4 Requirements Engineering 39

Structured specifications

 An approach where requirements are written in a

standard way.
 This works well for some types of requirements e.g.
requirements for embedded control system
 But it is sometimes too rigid for writing business system
requirements.

Chapter 4 Requirements Engineering 40

Example： a structured specification of a
requirement for an insulin pump （A）

Chapter 4 Requirements Engineering 41

Example： a structured specification of a
requirement for an insulin pump （B）

Chapter 4 Requirements Engineering 42

Tabular specification

 Used to supplement natural language.

 Particularly useful when you have to define a number of
possible alternative courses of action.
 For 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.

Chapter 4 Requirements Engineering 43

Example： Tabular specification of computation
for an insulin pump

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 rounded result = 0 then
CompDose = MinimumDose

Chapter 4 Requirements Engineering 44

Use cases diagram

 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.
 UML sequence diagrams may be used to add detail to
use-cases by showing the sequence of event processing
in the system.

Chapter 4 Requirements Engineering 45

Example： Use cases for the Mentcare system

Chapter 4 Requirements Engineering 46

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
Chapter 4 Requirements Engineering 47
Example: nonfunctional requirements in the
Mentcare system

 Non-functional requirements may be very difficult to state precisely

and may be difficult to verify.
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 as set out in
HStan-03-2006-priv.

Chapter 4 Requirements Engineering 48

Requirements checking

Requirements error costs are high, so validation is very

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

Checking techniques：
 Requirements reviews
▪ Systematic manual analysis of the requirements.
 Prototyping
▪ Using an executable model of the system to check requirements
( Covered in Chapter 2).
 Test-case generation
▪ Developing tests for requirements to check testability.

Chapter 4 Requirements Engineering 50

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.

Chapter 4 Requirements Engineering 51

Requirements change management

Chapter 4 Requirements Engineering 52

Essay4：Requirements engineering in traditional
and agile contexts

 Research on traditional requirements and in requirements

agile context.
 Write a 750-word essay contrasting requirements
engineering in traditional (waterfall) and agile development
contexts.
• Use the reading materials (textbook, articles, slides). You may use
additional materials (that you have found by yourself), as well.​
• Use referencing according to the guidelines, and try to aim for the
750-word limit. Too short or overly long essays will receive a lower
score. For the highest score, your essay should be within the 560-
940 word range (within 25%).​
• Reference list is NOT included in the word limit​
• Remember the importance of referencing, and of avoiding
plagiarism.
Chapter 4 Requirements Engineering 53
Essay will be graded on:

 the correctness and comprehensiveness of traditional

requirements engineering and agile requirements analysis.
 the reasonableness and appropriateness of your viewpoint
of the combination method.
 the length, as described above.
 the correct use of referencing. Note that absence of
references fails the essay completely, as you are required to
reference).
 an overall assessment of the essay quality.

Chapter 4 Requirements Engineering 54