Chapter 1

Introduction to Requirement Engineering

By Esubalew A.
 Contents
What are requirements?
Types of requirements
Functional, non-functional & domain
requirements
Business, user & System requirements
Requirement Engineering: Introduction
What is requirement engineering?
Why Requirement Engineering?
Requirement requirements: How
Requirement requirements: When
Stakeholders in Requirement Engineering
2
 What are requirements?
Software requirements are the descriptions of the
system services (essential & desired) and constraints (on
System operation and software development process).
Requirements might describe
A user-level facility (e.g. the word processor must include a
spell checking and correction command)
A very general system property (e.g. the system must
ensure that personal information is never made available
without authorization)
How to carry out some computation (e.g. the overall mark is
computed by adding the students exam, project &
coursework marks based on the following formula. Total =
[2 * exam + 3*(project + coursework)]/5
A constraint on the development of the system (e.g. The
system must be developed using java)
Etc..
3
 What are requirements?...
Requirements should always be statement of
what a system should do rather than a statement
of how it should do it.
However, sometimes it is necessary for the
requirement documents to include information
about the design of the system.
Readers are often practical engineers – they can relate
it to implementation descriptions
The system may be one of several systems in an
environment - to be compatible with its environment
specifying implementation issues are important
The specifiers are often experts in the application
domain where the system is to be used. The
requirements may be descriptions of how to carry out a
4
computation using application domain
 Types of requirements
Software requirements are often classified as
functional requirements, non-functional
requirements or domain requirements
Functional requirements: Functional
requirements capture the intended behavior of the
system. This behavior may be expressed as
services, tasks or functions the system is required
to perform.
In order to find out functional requirements of a
system try to answer the questions below
What inputs the system should accept?
What outputs the system should produce?
What data the system should store that other systems
might use?
5 What computations the system should perform?
 Types of requirements…
Non-functional requirements: define the overall
qualities or attributes of the resulting system
Non-functional requirements place restrictions on the
product being developed, the development process,
and specify external constraints that the product
must meet.
Example
The product must be available at the beginning of the next
year
The product shall operate on a 3G mobile telephone.
The system shall be easy to use
The system should not fail more than twice in a week.
The system shall respond to every user action in less than 3
seconds
6
 Types of requirements…
Functional Vs Non-Functional Requirements
There is no a clear distinction between
functional and non-functional requirements.
Whether or not a requirement is expressed as
a functional or a non-functional requirement
may depend:
 on the level of detail to be included in the
requirements document
 the degree of trust which exists between
a system customer and a system
developer.
7
 Types of requirements…
Example: The system shall ensure that data is
protected from unauthorised access.
 Conventionally, this would be considered as a non-
functional requirement because it does not specify
specific system functionality which must be provided.
However, it could have been specified in slightly more
detail as follows:
 The system shall include a user authorisation procedure
where users must identify themselves using a login name
and password. Only users who are authorised in this way
may access the system data.
 In this form, the requirement looks rather more like a
functional requirement as it specifies a function (user
login) which must be incorporated in the system.
8
 Types of requirements…
Domain Requirements
Requirements that come from the application domain of
the system and that reflect characteristics of that
domain.
 Domain requirements are not from specific needs of
system users.
They usually include specialized terminologies or
reference to domain concept - they are difficult to
understand
 Implicitness is another problem with domain requirements
They may be new functional requirements (may be
defining specific computations) or can be constraints on
existing requirements.
If domain requirements are not satisfied, the system
may be unworkable.
Examples: from library system
9
 Types of requirements…
Software requirements are defined at various
levels of detail and granularity.
Requirements at different level of detail also
mean to serve different purposes.
Business Requirements:
These are used to state the high-level business
objective of the organization or customer requesting
the system or product.
They are used to document main system features
and functionalities without going into their nitty-gritty
details.
They are captured in a document describing the
project vision and scope.
10
 Types of requirements…
User Requirements:
User requirements add further detail to the business
requirements.
They are called user requirements because they are
written from a user’s perspective and the focus of user
requirement describe tasks the user must be able to
accomplish in order to fulfill the above stated business
requirements.
They are captured in the requirement definition document.
System Requirements:
System requirements are expanded versions of the user
requirements that are used by software engineers as the
starting point for the system design.
They add detail and explain how the user requirements
should be provided by the system
11
 Requirement Engineering: Introduction
To understand customers’ requirements about the
software to be developed is extremely important.
However,
 Customers are unable to express requirements explicitly
Typically, they can not tell you what they want clearly.
The requirements that customers or end-users present
are often: incomplete, inaccurate, and inconsistent.
 Stakeholders (Business and Technical groups) speak
different languages.
 Software requirements are often extremely complex and
large scale.

Requirement Engineering is a relatively new term

which has been invented to cover all of the
activities involved in discovering, documenting and
maintaining a set of requirements for a computer-
12
based system.
 What is Requirement Engineering?
Definition

13
 Why Requirement Engineering?
In spite of new and effective software engineering
techniques, software systems
Are delivered late and over budget
Do not do what really users want
Are prone to failure
Some key aspects of successful software
development are
User input and involvement
Effective management and support
Resources
Clearly defined, complete requirements
 Numerous software engineering studies show this
repeatedly
40-60% of all defects found in software projects can be

14 traced back to poor requirements.

 Why Requirement Engineering?...
The hardest single part of building a
software system is deciding precisely
what to build. No other part of the
conceptual work is as difficult as
establishing the detailed technical
requirements, including all the interfaces
to people, to machines, and to other
software systems No part systems. of the
work so cripples
Generally, the
defining resulting
and applying system
good, if
done wrong.
complete No other part
requirements is more
is hard to work, and
successto
difficult in rectify
this endeavor
later. has eluded1987)
(Brooks, many
software
15
No Silverengineers.
Bullet: Essence and Accidents of Software
 Requirement requirements: How
Software requirements engineering is a disciplined,
process-oriented approach to the definition,
documentation, and maintenance of software
requirements throughout the software development
life cycle.
Software requirements engineering is made up of
two major processes: requirements development and
requirements management.
Requirements development encompasses all of the
activities involved in eliciting, analyzing, specifying,
and validating the requirements.
The activities used for requirement engineering vary
widely depending on the application domain, the
people involved and the organisation developing the
16 requirements.
 Requirement requirements: How…

The requirement engineering process

17
 Requirement Engineering:
When
Requirements development encompasses all
the activities involved in identifying, capturing,
and agreeing upon the requirements.
The majority of the requirements development
activities occur during the early concept and
requirements phases of the life cycle.
Continued elaboration of the requirements,
however, can progress into the later phase of
the software development life cycle.
Requirements management, which is an
ongoing activity throughout the software
development life cycle, encompasses all of the
18
activities involved in
 Requirement Engineering:
When…
Requesting changes to the baselined requirements
performing impact analysis for the requested changes
approving or disapproving those changes, and
implementing the approved changes
ensuring that all work products and project plans are
kept consistent and tracking the status of the
requirements as one progresses through the software
development process.
The implemented software product is validated
against its requirements during the testing phases
of the life cycle to identify and correct defects and
to provide confidence that the product meets those
requirements.
Requirements engineering is an iterative process
19
 Stakeholders: The Who of RE
System Stakeholders are people or organizations who
will be affected by the system and who have direct or
indirect influence on the system requirements.
In order to develop a good requirement document, it is
imperative to involve all kinds of user in the
requirement engineering process.
You need to identify the stakeholders in a system and
discover their requirements.
If you don’t do, you may find that they insist on
changes during the system development or after it has
been delivered for use.
Stakeholders have a tendency to state requirements in
very general and vague terms
 different stakeholders have different requirements –
20 sometimes even conflicting.
 Stakeholders…
Example
For an automated railway signaling system (a
system used to control railway traffic safely)
possible stakeholders are
Train company operators responsible for
running the system
Train crew
Railway managers
Passengers
Equipment installation and maintenance
engineers
Safety certification authorities
21
 Stakeholders…
There are three main categories of stakeholders:
the acquirers of the software product
the suppliers of the software product and
other stakeholders.
The acquirer type stakeholders can be divided
into two major groups.
customers who request, purchase, and/or pay for
the software product in order to meet their
business objectives.
users, also called end-users, who actually use the
product directly or use the product indirectly by
receiving reports, outputs, or other information
generated by the product.
22
 Stakeholders…
The suppliers of the software product include
individuals and teams that are
are part of the organization that develops the
software product or
are part of the organizations that distribute the
software product or
are involved in other product delivery methods
(for example, outsourcing).
System analysts, designers, developers etc
are some examples among suppliers
Suppliers who pay for the development of
the product are called client.
23
 Stakeholders…The
stakeholders map

Use this map to help you

determine which classes of
24
stakeholders are relevant to
 Stakeholders: Example
Assume BDU has signed an agreement with a
software company called ABC for the automation of
the clinic system which encompasses subsystems
like clinical lab subsystem, patient admission
subsystem and the like.
Identify all stakeholders for the system
mentioned.
BDU, BDU managers, Students, doctors and other
health officials, the company ABC, etc
If the University sells the system to other universities
so as to get reimbursed for what it has spent, who is
the client, the customer and the user?
Client: BDU
Customers: Other Universities
25 Users: Anyone using the system