Chapter 1

Introduction to Requirement Engineering

 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: Who

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

3
 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
 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
5
still considered the major cause of software failure today" .
 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
6
application domain
 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
7 devt.
 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.
Functional requirements 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?

8
 What outputs the system should produce?
What data the system should store that other systems might
use?
What computations the system should perform?

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.

9
 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

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

11
 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.
12
 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
13
be unworkable.
 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.
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
14 explicit.
 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
15
and facilitates an organization in achieving them.
 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.

16
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 detailed
descriptions of the systems functions, services and
operational constraints. Defines what should be
implemented so may be part of a contract between
17 client and contractor.
 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
18 and large scale.
 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
19
requirements development (CarnegieMellon 2006).
 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 world goals for,
functions of, and constraints on software systems and also
concerned with the relationship of these factors to precise
20 specifications of software behavior (Zave 1997).
 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).

21
 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.
22
 What is Requirement Engineering?
Definition

23
 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
24
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 the
resulting system if done wrong. No other part is more difficult to
rectify later. (Brooks, 1987)
No Silver Bullet: Essence and Accidents of Software Engineering.
Generally, defining and applying good, complete requirements
is hard to work, and success in this endeavor has eluded many
software engineers. Requirement Engineering alleviates this
25
problem
 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
26 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
27
cycle, encompasses all of the activities involved in
 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.
Requirements engineering is an iterative process
28
 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.
29 .
 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)

30
 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).
people or organizations opposed to the system
(negative stakeholders; see also Misuse case)
those organizations who integrate horizontally with the
organization for whom the analyst is designing the
31 system
 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
32
 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
33
generated by the product.
 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.
34
 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
35
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

36
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
37 care.
 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.

38