Chapter 1

Introduction to Requirement Engineering

Contents
What are requirements?
Types of requirements
Requirement Engineering: Introduction
What is requirement engineering?
Why Requirement Engineering?
Requirement requirements: How
Requirement requirements: When
Stakeholders in Requirement Engineering:

Who

What are requirements?

Software requirements are the descriptions of

the system services (essential & desired) and

constraints (on System operation and software
development process).
SWRequirements are statements of what the
system must do, how it must behave, the
properties it must exhibit, the qualities it must
possess, and the constraints that the system
and its development must satisfy.
The Institute of Electrical and Electronics
Engineers (IEEE) defines a requirement as
a condition or capability needed by a user to solve a

problem or achieve an objective

a condition or capability that must be met or possessed

by a system or system component to satisfy a contract,

standard, specification, or other formally imposed
document
a documented representation of a condition or capability
as in definition 1 or 2 [IEEE 1990a] .
Requirement: A statement that identifies a product or
process operational, functional, or design characteristic
or constraint, which is un ambiguous, testable or
measurable, and necessary for product or process
acceptability (by consumers or internal quality
assurance guidelines).
4

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. Because:
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 computation using application
domain

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
constraint on the development of the system (e.g. The system must
be developed using java) Etc..
[Davis 1990a, Faulk 1997a]. "The inability to produce complete,
correct, and unambiguous software requirements is still considered
the major cause of software failure today" .

Examples of Requirements
The system shall maintain records of all

payments made to employees on accounts of

salaries, bonuses, travel/daily allowances,
medical allowances, etc.
The system shall interface with the central
computer to send daily sales and inventory data
from every retail store
The system shall maintain records of all library
materials including books, serials, newspapers
and magazines, video and audio tapes, reports,
collections of transparencies, CD-ROMs, DVDs,
etc
The system shall allow users to search for an item
by title, author, or by International Standard Book
Number.
7

Examples of Reqs.
The systems user interface shall be

implemented using a web browser

The system shall support at least twenty
transactions per second
The system facilities which are available to
public users shall be demonstrable in ten
minutes or less

Why Requirements.
The most common reasons for project failures are not technical and
Table 1.1 identifies the main reasons why projects fail. The data is
drawn from surveys conducted by the Standish Group in 1995 and
1996.
Incomplete requirements
13.1%
Lack of user involvement
12.4%
Lack of resources
10.6%
Unrealistic expectations
9.9%
Lack of executive support
9.3%
Changing requirements/specifications
8.7%
Lack of planning
8.1%
Didnt need it any longer
7.5%
Hence giving emphasis to requirements is crucial in any system devt.
9

Types of 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.
describe what the system or software must do and sometimes
called behavioral or operational requirements.
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?
What computations the system should perform?
10

Functional Requirements
Statements describing what the system does
Functionality of the system.
Statements of services the system should provide
Reaction to particular inputs
Behavior in particular situations

Abnormal behavior is also documented as

functional requirements in the form of exception

handling
Functional requirements should be complete and
consistent
Customers and developers usually focus all their
attention on functional requirements
11

Functional Requirement
Examples
The
system shall solve a quadratic equation using
the following formula

x = (-b+sqrt(b2 4*a*c))/2*a
The user shall be able to search either the entire

database of patients or select a subset from it

(admitted patients, or patients with asthma, etc.)
The system shall provide appropriate viewers for
the user to read documents in the document store
The system shall allow customers to return nonperishable items within fifteen days of the
purchase. A customer must present the original
sale receipt to return an item
12

Comments on Examples
Notice the level of detail in different requirements

described above. Some are very detailed compared

to others.
Notice the ambiguity in the requirement, which uses
the term appropriate viewers
This requirement does not mention the formats of
documents and types of viewers, which can be used
Notice the ambiguity in the requirement for solving
the quadratic equation. The requirement does not
speak about the possibility when the value of a is
zero
Incomplete and ambiguous requirements are open
to multiple interpretations and assumptions
This can lead to the development of poor quality, or
faulty, software products

13

Types of requirements
Non-functional requirements (NR): define the overall

qualities or attributes of the resulting system like: (security),

Usability, Reliability, Performance & Supportability
NR specify system properties, such as reliability and safety.

14

Types of requirements
NR 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

15

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.

16

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

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

Domain Requirements
Banking domain has its own specific constraints,
Example
for example, most banks do not allow over-draw
on most accounts, however, most banks allow
some accounts to be over-drawn
In a commission-based sales businesses, there
is no concept of negative commission.
However, if care is not taken novice developers
can be lured into developing systems, which
calculate negative commission.
For example, a train control system has to take into

account the braking characteristics in different weather

conditions. This is a domain requirement for a train
protection system
19

Domain requirements problems

Understandability
Requirements are expressed in the

language of the application domain;

This is often not understood by software
engineers developing the system.
Implicitness
Domain specialists understand the area
so well that they do not think of making
the domain requirements explicit.
20

Software requirements are defined at various

levels of detail and granularity.

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 (basic important) details.
They are captured in a document describing the
project vision and scope.
A key factor in the success of a system is the
extent to which the system supports the
business requirements and facilitates an
organization in achieving them.
21

User Requirements:
User requirements add further detail to the

business requirements.
They are called user requirements because
they are written from a users 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.
Eg. The system should be easy to use by
medical staff and should be organized in
such a way that user errors are minimized.
22

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
capture the vision of the customer,
enable defining the scope of the system,
and allow estimating the cost and
schedule required to build the system.
A
structured document setting out
23
detailed descriptions of the systems

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
24
groups) speak different languages.

Inverse Requirements
They explain what the system shall not do.

Many people find it convenient to describe

their needs in this manner
These requirements indicate the indecisive
nature of customers about certain aspects
of a new software product
Example:
The system shall not use red color in the
user interface, whenever it is asking for
inputs from the end-user
25

Design and Implementation

They are development guidelines within which
Constraints
the designer must work
These requirements can seriously limit design
and implementation options
Can also have impact on human resources

Examples
The system shall be developed using the

Microsoft .Net platform

The system shall be developed using open

source tools and shall run on Linux operating

system

26

Sources of Requirement
Stakeholders
People affected in some way by

the system
Documents
Existing system
Domain/business area

27

Requirement Engineering: Introduction

The

term requirements engineering is often too

narrowly equated with requirements analysis, which is
just one of the activities within the wider discipline. The
emphasis on engineering is useful for two main
reasons:
Dealing with requirements is an essential part of
every engineering endeavor. Indeed, requirements
engineering is a subset of systems engineering in
general, not just software engineering.
The term subsumes the wide variety of other titles
given to activities relating to requirements, such as
requirements analysis and the two terms used for key
process areas: requirements management and
requirements development (CarnegieMellon 2006).

28

Requirements Engineering(RE) provides the

basic agreement between end-users and
developers on what the software should do. It
is a clear statement on the scope and
boundaries of the system to be analyzed and
studied. It gives stakeholders an opportunity
to define their requirements understandable
to the development team
RE involves all life-cycle activities devoted
to identification of user requirements, analysis
of the requirements to derive additional
requirements,
documentation
of
the
requirements
as
a
specification,
and
validation of the documented requirements
against user needs, as well as processes that
support these activities (DoD 1991).
A branch of SWE concerned with the real
29 world goals for, functions of, and constraints

the subset of systems engineering concerned

with discovering, developing, tracing,

analyzing, qualifying, communicating and
managing requirements that define the
system at successive levels of abstraction.
Requirements engineering is complex
because of the three roles involved in
producing even a single requirement: the
requestor (referred to as the "user" in the
IEEE definition), the developer (who will
design and implement the system), and the
author (who will document the requirements).

30

Contd
Typically, the requestor understands the problem

to be solved by the system but not how to develop

a system.
The
developer understands the tools and
techniques required to construct and maintain a
system but not the problem to be solved by that
system.
The author needs to create a statement that
communicates unambiguously to the developer
what the requestor desires. Hence, requirements
address a fundamental communications problem.
RE according to Laplante (2007) is "a subdiscipline of
systems engineering and sw engineering that is
concerned with determining the goals, functions, and
constraints of HW&SW systems.
31

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 traced back to poor requirements.
32

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
Generally,
and applying
good, complete
requirements
work
so defining
cripples
the resulting
system
if is
hard towrong.
work, and success
in this endeavor
eluded many
done
No other
part ishas
more
software engineers. Requirement Engineering alleviates this
difficult
to
rectify
later.
(Brooks,
1987)
33 problem

No Silver 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 (RD) and requirements
management(RM).
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
34 organisation developing the requirements.

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
activities involved in
35

Contd.

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.

36 Requirements engineering is an iterative process

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 dont do, you may find that they insist on
changes during the system development or
after it has been delivered for use.
.
37

Contd..
Stakeholders have a tendency to state

requirements in very general and vague

terms
different stakeholders have different
requirements sometimes even conflicting
It is increasingly recognized that
stakeholders are not limited to the
organization employing the analyst.
Other stakeholders will include:
anyone who operates the system (normal
and maintenance operators)
38

anyone who benefits from the system (functional,

political, financial and social beneficiaries)

anyone involved in purchasing or procuring the
system. In a mass-market product organization,
product management, marketing and sometimes
sales act as surrogate consumers (mass-market
customers) to guide development of the product
organizations which regulate aspects of the
system (financial, safety, and other regulators).
those organizations who integrate horizontally
with the organization for whom the analyst is
designing the system

39

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
40

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

The suppliers of the software product

include individuals and teams that are

part of the organization that develops
the software product or
part of the organizations that distribute
the software product or
involved in other product delivery
methods (for example, outsourcing).
System analysts, designers, developers
etc are some examples among suppliers

42

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
43 Users: Anyone using the system

ATM stakeholders
Bank customers
Representatives of other banks
Bank managers
Counter staff
Database administrators
Security managers
Marketing department
Hardware and software maintenance engineers
Banking regulators

44

Stakeholders in the MHC-PMS

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

Contd
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.
46