Lecture No.

3: Requirement
Engineering
Objectives:
•Requirement Engineering Definitions
•Importance of Requirements
•Role of Requirements
•Some Risks from Inadequate Requirement
Process
•Levels of Software Requirements
•Stakeholders
1
2
 Requirement Engineering
Software development life cycle divided into four phases
namely vision, definition, development, and maintenance.
Each one of these stages has a different focus of activity.

• During the vision phases, the focus is on why do we

want to have this system.
• During definition phase the focus shifts from why to
what needs to be built to fulfill the previously outlined
vision.
• During development the definition is realized into design
and implementation of the system.
• Finally during maintenance all the changes and
enhancements to keep the system up and running and
adapt to the new environment and needs are carried out.
3
 Requirement Engineering-I
Requirement engineering mainly deals with
the definition phase of the system.
Requirement engineering is the name of the
process when the system services and
constraints are established.
It is the starting point of the development
process with the focus of activity on what .

4
 Software Requirement Definitions
Jones defines software requirements as a statement of
needs by a user that triggers the development of a program
or system.

Alan Davis defines software requirements as a user need

or necessary feature, function, or attribute of a system that
can be sensed from a position external to that system.

According to Sommerville, requirements are a

specification of what should be implemented. They are
descriptions of how the system should behave, or of a
system property or attribute. They may be a constraint on
the development process of the system.

5
Software Requirement Definitions-I
IEEE defines software requirements as:
1) A condition or capability needed by user to
solve a problem or achieve an objective.
2) 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.
3) A documented representation of a condition or
capability as in 1 or 2.

6
Software Requirement Definitions-II
As can be seen, these definitions slightly
differ from one another but essentially say
the same thing:
A software requirement is a document that
describes all the services provided by the
system along with the constraints under
which it must operate.

7
 Importance of Requirements
Many of the problems encountered in SW
development are attributed to shortcoming in
requirement gathering and documentation
process.

It has been noted that 40-60% of all defects

found in software projects can be traced
back to poor requirements.

8
 Importance of Requirements-I
This following graph
shows the relative cost
of fixing problem at the
various stages of
software development.
Boehm (1981) has
reported that correcting
an error after
development costs 68
times more.
Other studies suggest
that it can be as high as
200 times. Since cost is
directly related with the
success or failure of
projects, it is clear from
all this discussion that
having sound
requirements is the most
critical success factor for
any project

9
 Role of Requirements
Software requirements document plays the central role in the entire software
development process.

To start with, it is needed in the project planning and feasibility phase. In this
phase, a good understanding of the requirements is needed to determine the time
and resources required to build the software. As a result of this analysis, the scope
of the system may be reduced before embarking upon the software development.

Once these requirements have been finalized, the construction process starts.
During this phase the software engineer starts designing and coding the
software. Once again, the requirement document serves as the base reference
document for these activities.

It can be clearly seen that other activities such as user documentation and
testing of the system would also need this document for their own deliverables.

On the other hand, the project manager would need this document to monitor
and track the progress of the project and if needed, change the project scope by
modifying this document through the change control process

10
Role of Requirements

11
 Some Risks from Inadequate
Requirement Process
1. Insufficient user involvement leads to
unacceptable products.
2. Creeping user requirements contribute to
overruns and degrade product quality.
3. Ambiguous requirements lead to ill-spent
time and rework.
4. Gold-plating by developers and users
adds unnecessary features.
12
 Some Risks from Inadequate
Requirement Process-II

5. Smallest specifications lead to missing

key requirements and hence result in an
unacceptable product.

13
 Levels of Software
Requirements
1) 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 basic details. They are captured in a document
describing the project vision and scope.

2) 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.

14
 Levels of Software
Requirements-I
3) Functional Requirements
The next level of detail comes in the form of what is called functional
requirements. They bring-in the system’s view and define from the system’s
perspective the software functionality the developers must build into the product
to enable users to accomplish their tasks stated in the user requirements -
thereby satisfying the business requirements.

4) Non-Functional Requirements
A software requirement as a document that describes all the services provided
by the system along with the constraints under which it must operate. That is,
the requirement document should not only describe the functionality needed
and provided by the system, but it must also specify the constraints under
which it must operate. Constraints are restrictions that are placed on the
choices available to the developer for design and construction of the software
product. These kinds of requirements are called Non-Functional Requirements.
These are used to describe external system interfaces, design and
implementation constraints, quality and performance attributes. These also
include regulations, standards, and contracts to which the product must
conform.

15
Word Processing System Example
Let us assume that we have a word-
processing system that does not have a
spell checker. In order to be able to sell the
product, it is determined that it must have a
spell checker.
Hence the business requirement could be
stated as: “user will be able to correct
spelling errors in a document efficiently.
Hence, the Spell checker will be included as
a feature in the product.”
16
 Word Processing System Example-I
In the next step we need to describe what
tasks must be included to accomplish the
above-mentioned business requirement.
The resulting user requirement could be as
follows: finding spelling errors in the
document and decide whether to replace
each misspelled word with the one chosen
from a list of suggested words. It is
important to note that this requirement is
written from a user’s perspective.
17
Word Processing System Example-II
After documenting the user’s perspective in the
form of user requirements, the system’s
perspective: what is the functionality provided by
the system and how will it help the user to
accomplish these tasks. Viewed from this angle,
the functional requirement for the same user
requirement could be written as follows: the spell
checker will find and highlight misspelled words. It
will then display a dialog box with suggested
replacements. The user will be allowed to select
from the list of suggested replacements. Upon
selection it will replace the misspelled word with
the selected word. It will also allow the user to
make global replacements.
18
 Word Processing System Example-III

Finally, a non-functional requirement of the

system could require that:

“it must be integrated into the existing word-

processor that runs on windows platform.”

19
20
 Stakeholders
Stakeholders are different people who would
be interested in the software.

A study of over 8300 projects revealed that

the top two reasons for any project failure
are lack of user input and incomplete
requirements.

21
The following diagram shows the role of different
stakeholders in the setting the system requirements
22
Requirement Statement and Requirement
Specification Documents
• Different levels of software requirements
are documented in different documents.
• The two main documents produced during
this phase are:
 Requirement Statement
 Requirement Specification.
They are also called Requirement Definition and Functional
Specification and are used to document user requirements and
functional requirements respectively.

23
Requirement Statement
Characteristics
• A good Requirements statement document must
possess the following characteristics.
• Complete - Each requirement must fully
describe the functionality to be delivered.
Correct - Each requirement must accurately
describe the functionality to be built.
• Feasible - It must be possible to implement
each requirement within the known capabilities
and limitations of the system and its
environment.
24
Cont…
• Prioritized - An implementation priority
must be assigned to each requirement,
feature or use case to indicate how
essential it is to a particular product
release.
• Unambiguous - All readers of a
requirement statement should arrive at a
single, consistent interpretation of it.

25
Requirement Specification
Characteristics
• A good Requirements specification
document should possess the following
characteristics.
• Complete - No requirement or necessary
information should be missing.
• Consistent – No requirement should
conflict with other software or higher-level
system or business requirements.
26
Example:
• Let us try to understand this with the help of
example:
Following is the set of (functional) requirements
that conflicted with one another:
1. System must monitor all temperatures in a
chemical reactor.
2. System should only monitor and log
temperatures below -200 C and above 4000 C.

27
Cont..
• In this case the two requirements clearly
conflict with each other in stating what
information needs to be monitored and
stored.

28
Cont..
• Modifiable - Must be able to revise the
Software Requirement Specification when
necessary and maintain a history of
changes made to each requirement

29