Chapter Three
Requirement
Engineering
01/22/25 Software Component Design (SENG 4093) 2
Outlines
What is requirement?
What is Requirement Engineering?
Software Requirement and their type
Requirement Engineering Process
Software Requirement Specification
Requirement Elicitation Process
01/22/25 Software Component Design (SENG 4093) 3
What is requirement?
Requirement is a statement that
identifies a capability, characteristic or
quality of system in order for it to have
value and utility to a customer or user.
It is an important factor for the
development of any project and it defines
what different stakeholders (users,
customer,
manager and developer) need and how
system will fulfil these needs.
They are generally expressed in natural
language for the reason that everyone
can well understand it.
What is requirement?
It helps the analyst to better
understand which element and
function are necessary in the
development of particular project.
Requirements are used as input in a
design, implementation and validation
stage of product development.
a project can be succeed or failed at
any time during project life cycle
because of poor requirement
gathering and managing process.
What is requirement?
It is about WHAT not HOW
Requirements are the descriptions of the
services provided by a system and its
operational constraints
It may range from a high level abstract
statement to a detailed mathematical
specification
It may be as complex as a 500 pages of
description
2/3 of finished system errors are
requirements and design errors.
A careful requirements process doesn’t mean
there will be no changes later
What??
Requirements must be determined and
agreed to by the customers, users, and
suppliers of
a software product.
The requirements define the “what” of a
software product:
Whatthe software must do to add value for its
stakeholders. (functional requirements)
What the software must be to add value for its
stakeholders. (nonfunctional
requirements)
What limitations there are on the choices that
developers have when implementing the
software.
Type and Levels of Requirement
Type and Levels of Requirement
Business requirements define the business
problems to be solved or the business
opportunities to be addressed by the software
product.
In general, the business requirements define why
the software product is being developed.
User requirements look at the functionality of the
software product from the user’s perspective.
They define what the software has to do in
order for the users to accomplish their
objectives.
Type and Levels of Requirement
The product’s functional
requirements that define the
software functionality must be built
into the product to enable users to
accomplish their tasks, thereby
satisfying the business requirements
What is Requirements
engineering?
Requirements engineering (RE) refers to the
process of defining, documenting, and
maintaining requirements in the engineering
design process.
Requirement engineering provides the
appropriate mechanism to understand what the
customer desires, analysing the need, and
assessing feasibility, negotiating a reasonable
solution, specifying the solution
clearly, validating the specifications and
managing the requirements as they are
transformed into a working system.
engineering?
Requirement engineering is the disciplined
application of proven principles, methods, tools,
and notation to describe a proposed system's
intended behaviour and its associated constraints.
It is the process to gather the software
requirements from client, analyse and document
them is known as requirement engineering.
The goal of requirement engineering is to develop
and maintain sophisticated and descriptive ‘System
Requirements Specification’ document.
Software Requirements
The software requirements are description of
features and functionalities of the
target system.
Requirements convey the expectations of
users from the software product.
The requirements can be obvious or hidden,
known or unknown, expected or
unexpected from client’s point of view.
Largely software requirements must be
categorized into two categories.
FunctionalRequirement
Non-Functional Requirment
Types of requirements
Functional requirements
Services the system should provide
What the system should do or not in reaction to
particular situations
Non-functional requirements
Constraints on the services or functions offered by
the system
Examples: Timing constraints, constraints on the
development process (CASE, language,
development method…), standards etc
Domain requirements
From the application domain of the system
May be functional or non-functional
Examples: Medicine, library, physics, chemistry
Note: You can have user/system
functional/non-functional requirements.
User requirements
First attempt to describe functional and
non-functional requirements
Understandable by the user
Problems:
Lack of clarity - ambiguous language
Requirements confusion - functional, non-
functional requirements, design information
are not distinguished
Requirements amalgamation – several
requirements are defined as a single one
Incompleteness – requirements may be missing
Inconsistency – requirements may contradict
themselves
User requirements
Guideline to minimize the issues:
Separate requirements –separate functional
and non-functional requirements,
requirements must be clearly identified (e.g.
by a number)
Include a rationale for each requirement –
helps clarify reasoning behind the
requirements and may be useful for evaluating
potential changes in the requirements
Invent or use a standard form/template
Distinguish requirements priorities
Example: MoSCoW (Must, Shall, Could, Want/Will
(no TBD))
Testable (write test cases)
Deliverables
System requirements
Elaborate the user requirements to
get a precise, detailed and
complete version of them
Used by designers and developers
An important aspect is how to
present/write system requirements
Natural language is often used!
The difference between user and
system requirements must not be
thought as a detail
System requirements
Example: If sales for current month are
below target sales, then report is to be
printed unless difference between target
sales and actual sales is less than half of
difference between target sales and actual
sales in previous month, or if difference
between target sales and actual sales for
the current month is less than 5%.
Problems:
Difficult to read
Ambiguity: sales and actual sales, 5% of what?
Incomplete: what if sales are above target
sales?
requirements
Natural language (informal
requirements)
Reviled by academics
But widely practiced: everybody can read
them, finding a better notation is hard
Structured natural language
Forms/templates are used to bring some
rigor to natural language presentations
Graphical notations
Using boxes, arrows… but they mean
different things to different people
Formal specification
Based on logic, state machines…
Non-functional requirements
They can be further categorized into:
Product requirements
Product behavior
Ex: Timing, performance, memory, reliability,
portability, usability
Organizational requirements
Policies and procedures in the customer’s and
developer’s organizations
Example: Process requirements, implementation
requirements, delivery requirements
External requirements
Factors externals to the system and the development
process
Example: Interoperability, legislation, ethics
Non-functional requirements may be more critical than
functional requirements. (The system may be useless…)
Non-functional requirements
Non-functional
requir ements
Product Or ganizational External
requir ements requir ements requirements
Ef ficiency Reliability Portability Interoperability Ethical
requir ements requir ements requirements requirements requirements
Usability Delivery Implementation Standards Legislative
requirements requirements requir ements requirements requirements
Performance Space Privacy Safety
requirements requir ements requirements requirements
Process
It is a four-step process, which includes
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
Feasibility Study
Feasibility is defined as the practical extent
to which a project can be performed
successfully.
Feasibility Study in Software Engineering is a
study to evaluate feasibility of proposed
project or system.
It is a measure of the software product in terms
of how much beneficial product
development will be for the organization in
a practical point of view.
Feasibility Study
Feasibility study is carried out based
on many purposes to analyse whether software product will be
right in terms of development,
implantation, contribution of project to the organization
etc.
Types of Feasibility Study
Technical Feasibility
Operational Feasibility
Economic Feasibility
Legal Feasibility
Schedule Feasibility
analysis
Next phase after feasibility is gathering
requirements from the user.
Analysts and engineers communicate with the
client and end-users to know their ideas on
what the software should provide and
which features they want the software to
include.
Requirement gathering phase is the first
software engineering activity.
Requirements gathering is also popularly
known as requirements elicitation.
Requirement Gathering
The primary objective of the requirements
gathering task is to collect the requirements
from the stakeholders.
A stakeholder is a source of the
requirements and is usually a person, or a
group of persons who either directly or
indirectly are concerned with the software.
Requirement Elicitation
Process
Requirement Elicitation
Process
Requirements gathering - The developers discuss
with the client and end users and know their
expectations from the software.
Organizing Requirements - The developers
prioritize and arrange the requirements in order
of importance, urgency and convenience.
Negotiation & discussion - If requirements are
ambiguous or there are some conflicts in requirements
of various stakeholders, if they are, it is then
negotiated and discussed with stakeholders.
Requirements may then be prioritized and reasonably
compromised.
Documentation All formal & informal, functional and non-functional
requirements are documented and made available for next phase processing.
Requirement Elicitation
Techniques
Interview
Structured (closed) interviews, where every single
information to gather is decided in advance, they follow
pattern and matter of discussion firmly.
Non-structured (open) interviews, where information to
gather is not decided in advance, more flexible and less
biased.
Oral interviews
Written interviews
One-to-one interviews which are held between two
persons across the table.
Group interviews which are held between groups of
participants.
Requirement Elicitation
techiniques
Surveys
Organization may conduct surveys among various
stakeholders by querying about their expectation and
requirements from the upcoming system.
. Questionnaires
A document with pre-defined set of objective questions
and respective options is handed over to all
stakeholders to answer, which are collected and
compiled.
Observation
Team of experts visit the client’s organization or workplace. They
observe the actual working of the existing installed systems.
Requirement analysis
After requirements gathering is complete,
the analyst analyses the gathered requirements
to form a clear understanding of the exact
customer requirements and to weed out
any problems in the gathered
requirements.
It is natural to expect that the data collected
from various stakeholders to contain several
contradictions, ambiguities, and
incompleteness, since each stakeholder
typically has only a partial and incomplete view
of the software.
Requirement analysis
The main purpose of the requirements
analysis activity is to analyse the
gathered requirements to remove all
ambiguities, incompleteness, and
inconsistencies from the gathered
customer requirements and to obtain a
clear understanding of the software to
be developed.
Requirement analysis
Questions which are clearly understood by the
analyst before carrying out analysis
What is the problem?
Why is it important to solve the problem?
What exactly are the data input to the system and what
exactly are the data output by the system?
What are the possible procedures that need to be followed
to solve the problem?
What are the likely complexities that might arise while
solving the problem?
If there are external software or hardware with which the
developed software has to interface, then what should be
the data interchange formats with the external systems?
Requirement analysis
Different types of requirements problems in detail:
Anomaly: It is an anomaly is an ambiguity in a
requirement. When a requirement is anomalous, several
interpretations of that requirement are possible.
Example 1 While gathering the requirements for a process
control application, the following requirement was
expressed by a certain stakeholder: When the temperature
becomes high, the heater should be switched off. Please
note that words such as “high”, “low”, “goo d”, “bad” etc.
are indications of ambiguous requirements as these lack
quantification and can be subjectively interpreted.
Software Requirement
Specification
SRS is a document created by system analyst after the
requirements are collected from various stakeholders.
SRS defines how the intended software will interact with
hardware, external interfaces, speed of
operation, response time of system,
portability of software across various
platforms, maintainability, speed of recovery
after crashing, Security, Quality, Limitations
etc.
The requirements received from client are written in
natural language.
Who is writing Requirement?
First Client and second Developer.
Software Requirement
Specification
After requirement specifications are developed, the
requirements mentioned in this document are
validated.
User might ask for illegal, impractical solution or
experts may interpret the requirements incorrectly.
Requirements can be checked against following
conditions -
If they can be practically implemented
If they are valid and as per functionality and
domain of software
If there are any ambiguities
If they are complete
Software Requirement
Specification
Software Requirement
Management
Requirement management is the process of
managing changing requirements during the
requirements engineering process and system
development.
New requirements emerge during the process
as business needs a change, and a better
understanding of the system is developed.
The priority of requirements from different
viewpoints changes during development
process.
The business and technical environment of
the system changes during the development.
01/22/25 38
