Requirement Analysis

What is Requirements Analysis?

● Requirements analysis or requirements

engineering is a process used to
determine the needs and expectations of
a new product.
● It involves frequent communication with
the stakeholders and end-users of the
product to define expectations, resolve
conflicts, and document all the key
requirements.
● One of the greatest challenges faced by
any organization is to share the vision of
the final product with the customers.
Hence, a business requirements analysis
involves a team effort of all the key
stakeholders, software developers, end-
users, and customer managers to
achieve a shared understanding of what
the product should do.
● This is always done in the early phase of
any project to ensure that the final
product conforms to all the requirements.
● Requirements analysis (requirements
engineering) is the process of
determining user expectations for a new
or modified product.
● It is usually a team effort and demands a
variety of human soft skills, such as
critical thinking, communication and
judgment.
● Requirements analysis is a common and
essential concept in software
development and software project
management.
● At the start of every software project,
the project team must understand,
finalize and document the features and
functionalities required of the end
product.
● These required features and
functionalities are often called functional
specifications, and the process of
determining and understanding them is
called requirements gathering and
analysis.
● Requirements must be quantifiable, as
detailed as possible and relevant to the
end product.
● In addition, they should be clearly
documented so the development team
has clear expectations and understands
required specifications from the
beginning.

Requirements analysis in software

engineering does the following:

● Clarifies the required features and

overall vision of a new product.
● Clarifies stakeholder expectations for
that product.
● Prevents conflict and communication
gaps during development and testing.
● Ensures that the final product conforms
to requirements.

Defining Requirement:

IEEE defines a requirement as, “a condition

or capability needed by a user to solve a
problem or achieve an objective/goal.”

“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
documents.”

“The process of studying a user needs to

arrive at a definition of a system, hardware
or software requirements”.

The requirements are classified into three

categories:
- Requirements help to understand the
behavior of a system, which is described
by various tasks of the system.
- For example, some of the tasks of a
system are to provide a response to
input values, determine the state of data
objects, and so on.
- Note that requirements are considered
prior to the development of the software.
- The requirements, which are commonly
considered, are classified into three
categories, namely, functional
requirements, non-functional
requirements, and domain requirements.
1. Functional Requirements:

IEEE defines functional requirements as ‘a

function that a system or component must
be able to perform.’
- These requirements describe the
interaction of software with its
environment and specify the inputs,
outputs, external interfaces, and the
functions that should be included in the
software.
- Also, the services provided by functional
requirements specify the procedure by
which the software should react to
particular inputs or behave in particular
situations.
To understand functional requirements
properly, let us consider the following
example of an online banking system.
■ The user of the bank should be able to
search the desired services from the
available ones.
■ There should be appropriate documents
for users to read. This implies that when a
user wants to open an account in the
bank, the forms must be available so that
the user can open an account.
■ After registration, the user should be
provided with a unique acknowledgement
number so that he can later be given an
account number.
The above mentioned functional requirements
describe the specific services provided by the
online banking system.

With the help of these functional requirements,

users can easily view, search and download
registration forms and other information about
the bank.

On the other hand, if requirements are not

stated properly, they are misinterpreted by
software engineers and user requirements are
not met.
- The functional requirements should be
complete and consistent.
- Completeness implies that all the user
requirements are defined.
- Consistency implies that all requirements are
specified clearly without any contradictory
definition.

2. Non-Functional Requirements:
The non-functional requirements (also known as
quality requirements) are related to system
attributes such as reliability and response time.
Non-functional requirements arise due to user
requirements, budget constraints, organizational
policies, and so on. These requirements are not
related directly to any particular function
provided by the system.
Non-functional requirements should be
accomplished in software to make it perform
efficiently. For example, if an aeroplane is
unable to fulfill reliability requirements, it is not
approved for safe operation.
The description of different types of non-
functional requirements is listed below.
1. Product requirements: These
requirements specify how the software
product performs. Product requirements
comprise the following.
2. Efficiency requirements: Describe the
extent to which the software makes optimal
use of resources, the speed with which the
system executes, and the memory it
consumes for its operation. For example, the
system should be able to operate at least
three times faster than the existing system.
3. Reliability requirements: Describe the
acceptable failure rate of the software. For
example, the software should be able to
operate even if a hazard occurs.
4. Portability requirements: Describe the
ease with which the software can be
transferred from one platform to another. For
example, it should be easy to port the
software to a different operating system
without the need to redesign the entire
software.
5. Usability requirements: Describe the
ease with which users are able to operate the
software. For example, the software should
be able to provide access to functionality with
fewer keystrokes and mouse clicks.
6. Organizational requirements: These
requirements are derived from the policies
and procedures of an organization.
Organizational requirements comprise the
following.
7. Delivery requirements: Specify when
the software and its documentation are to be
delivered to the user.
8. Implementation requirements:
Describe requirements such as programming
language and design method.
9. Standards requirements: Describe the
process standards to be used during software
development. For example, the software
should be developed using standards
specified by the ISO and IEEE standards.
10. External requirements: These
requirements include all the requirements
that affect the software or its development
process externally. External requirements
comprise the following.
11. Interoperability requirements: Define
the way in which different computer based
systems will interact with each other in one
or more organizations.
12. Ethical requirements: Specify the rules
and regulations of the software so that they
are acceptable to users.
13. Legislative requirements: Ensure that
the software operates within the legal
jurisdiction. For example, pirated software
should not be sold.

3. Domain Requirements:

● Requirements which are derived from the

application domain of the system instead of
the needs of the users are known as domain
requirements.
● These requirements may be new functional
requirements or specify a method to perform
some particular computations.
● In addition, these requirements include any
constraint that may be present in the
existing functional requirements.
● As domain requirements reflect the
fundamentals of the application domain, it is
important to understand these requirements.
● Also, if these requirements are not fulfilled, it
may be difficult to make the system work as
desired.
● A system can include a number of domain
requirements. For example, it may comprise
a design constraint that describes the user
interface, which is capable of accessing all
the databases used in a system.
● It is important for a development team to
create databases and interface designs as
per established standards.
● Similarly, the requirements of the user such

as copyright restrictions and security

mechanism for the files and documents used
in the system are also domain requirements.
Need of Requirement Analysis:

The following are the important points which

describe need of requirement analysis:

1. Requirements analysis helps in defining

system objectives or goals.

2. Requirements analysis helps to identify

system boundaries.

3. It helps to understand the system’s

importance.

4. Requirements analysis helps to identify

the nature of the system.
5. It helps to maintain the interface of the
existing system with other systems.

6. Requirements analysis helps to motivate

the users to the new environment.

7. It helps to understand resource needs

such as hardware and software.

8. Requirements analysis helps to

understand the feasibility of the new
system.

Activities in requirement analysis

1. Requirements Elicitation
- Consists of gathering information,
understanding the stakeholder needs.
- Discover the requirements via
interviews, workshops, observations,
documents analysis.
2. Requirements Analysis
- Examines high level requirements and
determines if they are clear, complete
and free of contradictions.
- Then define the strategy to address
these issues.
3. Requirements Specification
- Defines behavior of a system in
development and determines the
method for requirements
documentation.
4. Requirements Validation
- the requirements are checked
carefully for consistency and
completeness before project move
into the development phase
Eliciting Requirements

Eliciting requirements is the process of

determining what the customers actually
need a proposed system to do and of
documenting that information in a way that
will allow us to write a more formal
requirements document later.

Problems of requirements analysis

1. Problems of Scope - Stakeholders
don’t know what they really want. They
express requirements in their own terms.

Specifying unnecessary technical detail

rather than overall system objectives.

2. Problems of understanding -
information that is related to the problem
domain is often omitted.
3. Problems of volatility - This is because
the requirements may change during the
analysis process.
● Elicitation is seeking information about
the software, the system and the
business.
● The process of eliciting requirements is,
fundamentally, an exercise in
communication between developers and
stakeholders.
The questions for requirement elicitation:
● Who will use this program?
● How many users will be there?
● Which tasks will the program perform?
● Where will you use this program?
● What are the objectives of the software
project?
● Why is the software needed?
Steps in eliciting requirements are:
1. Requirement Gathering: The
developers discuss with client and end
users and know their expectations from
the software.
2. Organizing Requirements: The
developers prioritize and arrange the
requirements in order of importance,
urgency.
3. Negotiation and Discussion: The
requirements come from various
stakeholders. To remove the ambiguity
and conflicts they are discussed for
clarity and correctness. Unrealistic
requirements are compromised
reasonably.
4. Documentation: All formal and
informal, functional and non-functional
requirements are documented and made
available for next phase processing.
Approaches for Requirements Elicitation

1. Collaborative Requirements Gathering

● Gathering the requirements by
conducting the meetings between
developer and customer.
● Fix the rules for preparation and
participation.
●The main motive is to identify the
problem, give the solutions for the
elements, negotiate the different
approaches and specify the primary
set of solution requirements in an
environment which is valuable for
achieving the goal .
2. Quality Function Deployment
● Quality function deployment (QFD) is
a quality management technique that
translates the needs of the customer
into technical requirements for
software.
● To accomplish this, QFD emphasizes
an understanding of what is valuable
to the customer and then deploys
these values throughout the
engineering process.
QFD identifies three types of
requirements:

Normal requirements

● The objective and goal are stated for the

system through the meetings with the
customer.
● For customer satisfaction these
requirements should be there.
● Ex. Requested types of graphical
displays, specific system function
● normal requirements for a result
management system may be entry of
marks, calculation of results, etc
Expected requirement

● These requirements are implicit.

● These are the basic requirements that
not be clearly told by the customer, but
also the customer expects that
requirement.
● Ex. ease of human/machine interaction,
overall operational correctness
● protection from unauthorized access.

Exciting requirements

These features are beyond the

expectation of the customer.

The developer adds some additional

features or unexpected features into the
software to make the customer more
satisfied.
For example, the mobile phone with
standard features, but the developer
adds few additional functionalities like
voice searching, multi-touch screen etc.
then the customer is more excited about
that feature.

when unauthorized access is detected, it

should backup and shutdown all
processes.

3. Usage Scenarios
● Until the software team does not
understand how the features and
functions are used by the end users it is
difficult to move technical activities.
● To achieve the above problem the
software team produces a set of
structures that identify the usage for the
software.
● This structure is called 'Use Cases'.

4. Elicitation Work Products:

The work products produced as a

consequence of requirements elicitation will
vary depending on the size of the system or
product to be built.

For most systems the work products

include:

1. A bounded statement of scope for the

system or product.
2. A set of usage scenarios that provide
insights into the use of the system under
different operating conditions.
3. A list of customers, users and other
stakeholders who participated in
requirement elicitation.
4. A description of the system's technical
specification.

Some commonly used techniques for

requirement elicitation are:

Brainstorming

- This technique is used to generate new

ideas and find a solution for a specific
issue.
- The members included for brainstorming
can be domain experts, subject matter
experts.
- Multiple ideas and information give you a
repository of knowledge and you can
choose from different ideas.

Interview
- This is the most common technique used
for requirement elicitation.
- Interview techniques should be used for
building strong relationships between
business analysts and stakeholders.
- In this technique, the interviewer directs
the question to stakeholders to obtain
information.
- One to one interview is the most
commonly used technique.
- If the interviewer has a predefined set of
questions then it’s called a structured
interview.
- If the interviewer is not having any
particular format or any specific
questions then it’s called an
unstructured interview.

Document Analysis/Review

- This technique is used to gather business

information by reviewing/examining the
available materials that describe the
business environment.
- This analysis is helpful to validate the
implementation of current solutions and
is also helpful in understanding the
business need.
- Document analysis includes reviewing
the business plans, technical documents,
problem reports, existing requirement
documents, etc.
- This is useful when the plan is to update
an existing system. This technique is
useful for migration projects.
- This technique is important in identifying
the gaps in the system i.e. to compare
the AS-IS process with the TO-BE
process. This analysis also helps when
the person who has prepared the existing
documentation is no longer present in
the system.

Observation

- The main objective of the observation

session is to understand the activity,
task, tools used, and events performed
by others.
- During the session, the observer should
record all the activities and the time
taken to perform the work by others so
that he/she can simulate the same.
- After the session, the BA will review the
results and will follow up with the
participants.
- Observation can be either active or
passive.
Active observation is to ask questions and try to attempt the work that
other persons are doing.

Passive observation is silent observation i.e. you sit with others and just
observe how they are doing their work without interpreting them.

Prototyping

- Prototyping is used to identify missing or

unspecified requirements.
- In this technique, frequent demos are
given to the client by creating the
prototypes so that client can get an idea
of how the product will look like.
- Prototypes can be used to create a mock-
up of sites, and describe the process
using diagrams.

Survey/Questionnaire

- For Survey/Questionnaire, a set of

questions is given to stakeholders to
quantify their thoughts.
- After collecting the responses from
stakeholders, data is analyzed to identify
the area of interest of stakeholders.
- Questions should be based on high
priority risks. Questions should be direct
and unambiguous.
- Once the survey is ready, notify the
participants and remind them to
participate.
Two types of questions can be used here:

● Open-Ended: Respondent is given the freedom to provide

answers in their own words rather than selecting from predefined
responses. This is useful but at the same time, this is time-
consuming as interpreting the responses is difficult.
● Close Ended: It includes a predefined set of answers for all the
questions and the respondent has to choose from those
answers. Questions can be multiple choice or can be ranked
from not important to very important.

SRS (Software Requirements Specification)

●A software requirements specification

(SRS) is a document that describes what
the software will do and how it will be
expected to perform.
● It also describes the functionality the
product needs to fulfill the needs of all
stakeholders (business, users).
● You can think of an SRS as a blueprint or
roadmap for the software you're going to
build. The elements that comprise an
SRS can be simply summarized into four
Ds:
● Define your product's purpose.
● Describe what you're building.
● Detail the requirements.
● Deliver it for approval.
We want to DEFINE the purpose of our
product, DESCRIBE what we are building,
DETAIL the individual requirements, and
DELIVER it for approval. A good SRS
document will define everything from how
software will interact when embedded in
hardware to the expectations when
connected to other software. An even better
SRS document also accounts for the needs
of real-life users and human interaction.

Why Use an SRS Document?

An SRS gives you a complete picture of your
entire project.
It provides a single source of truth that
every team involved in development will
follow.
It is your plan of action and keeps all your
teams — from development and testing to
maintenance — on the same page.
SRS Format
SRS is the final work product produced by
the requirements engineer.
It serves as the foundation for subsequent
software engineering activities.
SRS is a formal document.
It uses natural language, graphical
representations, usage scenarios to describe
the software to be developed.
There are standard templates for presenting
requirement specifications in a consistent
and more understandable manner.
The SRS document should be well
structured.
A well structured document is easy to
understand and modify.
Building Analysis Model
● Analysis model operates as a link
between the 'system description' and the
'design model'.
● In the analysis model, information,
functions and the behaviour of the
system is defined and these are
translated into the architecture, interface
and component level design in the
'design modeling'.
Elements of the analysis model

1. Scenario based element

● The system is described from the user’s

point of view using a scenario-based
approach.
● They serve as input for the creation of

other modeling elements.

● Scenario based elements are use case

diagrams.

2. Class based elements

● Each usage scenario implies a set of

objects that are manipulated as an actor
interacts with the system.
● It defines the object,attributes and
relationship.
● The collaboration is occurring between
the classes.
● Class based elements are the class
diagram, collaboration diagram.
3. Behavioral elements

● Behavioral elements represent the state

of the system and how it is changed by
the external events.
● The behavioral elements are sequenced
diagram, state diagrams.
4. Flow oriented elements

● Information is transformed as it flows

through a computer-based system..
● The system accepts input in a variety of
forms, applies functions to transform it
and produces output in a variety of
forms.
● The flow elements are data flow diagram,
control flow diagram.
Analysis pattern
● A pattern is a solution template that has
proven useful for solving a concrete
problem.
● In software development, this concept is
known as a design pattern. It provides
code solutions.
● Analysis patterns are patterns that are
also used in software development.
● They describe solutions for problems in
specialist domains. These solutions are
class diagram models (a UML diagram
type) instead of code.
● It has been observed that the software
engineer ‘reuses’ certain functions,
classes, and/ or behavior across all the
projects, which mayor may not form a
part of the specific application domain.
For example, features and functions
described by a user interface are almost
common, regardless of the application
domain chosen.
Analysis patterns refer to classes, functions,
and other features that can be reused when
developing applications within a specific
application domain. The objectives of
analysis patterns are listed below.
● To quicken the requirements analysis
phase by providing reusable analysis
models with the description of both
advantages and limitations.
● To suggest several design patterns and
feasible solutions to common problems in
order to help the software designer
translate an analysis model into a design
model.
Analysis patterns have a unique pattern
name, which allows the development team
to refer to them with their pattern names.
These patterns are stored in a repository so
that the software engineer can refer to
these patterns and reuse them while
developing new software.
Information is stored in the analysis
pattern, which can be viewed in the form of
a template. The analysis pattern template,
which comprises the following sections.
● Pattern name: Consists of important
information (in the form of descriptor)
about the analysis pattern. This
descriptor is used within the analysis
model when reference is made to a
pattern.
● Intent: Describes the problem that is
addressed in an analysis pattern, which
facilitates the software engineer to use
analysis patterns in the specified
application domain.
● Motivation: Represents how an analysis
pattern can be used to address a
particular problem in the application
domain with the help of a scenario.
● External issues and contexts: Lists
the external issues that affect the
manner in which an analysis pattern
works. The external issues include
business related subjects, external
technical constraints, and so on. In
addition, external issues and contexts
specify the external issues that are to be
resolved by an analysis pattern.
● Solution: Describes the procedure by
which an analysis pattern is implemented
in the analysis model.
● Consequences: Describes the
implementation effects of an analysis
pattern into the application domain. It
also provides a description of limitations
that arises during its implementation.
● Design: Describes the procedure of
achieving analysis patterns by using the
known design patterns.
● Known uses: Provides information
about the uses of an analysis pattern
within the system.
● Related patterns: Lists the analysis
patterns that are related to the ‘chosen’
pattern.
Negotiating Requirements
● When multiple stakeholders are involved,
requirements will conflict.
● This activity is concerned with prioritizing
requirements and finding and resolving
requirements conflicts through
negotiation.
● The goal of negotiation is to create a
project plan that meets the objectives of
stakeholders while also reflecting the
real-world restrictions (e.g., time,
personnel, and budget) imposed on the
software team. The successful
negotiations aim for a “win-win”
outcome.
● That is, stakeholders benefit from a
system or product that meets the
majority of their needs, while you benefit
from working within realistic and
reasonable budgets and schedules.
● At the start of each software process
iteration, Boehm defines a series of
negotiating actions. Rather than defining
a single customer communication
activity, the following are defined:
1. Identifying the major stakeholders in the

system or subsystem.
2. Establishing the stakeholders’ “win

conditions.”
3. Negotiation of the win conditions of the

stakeholders in order to reconcile them

into a set of win-win conditions for all
people involved.

Validating Requirements

Each aspect of the requirements model is

checked for consistency, omissions, and
ambiguity as it is developed.
The model’s requirements are prioritized by
stakeholders and bundled into requirements
packages that will be implemented as
software increments.

The following questions are addressed by an

examination of the requirements model:
● Is each requirement aligned with the
overall system/product objectives?
● Were all requirements expressed at the

appropriate level of abstraction? Do some

criteria, in other words, give a level of
technical information that is
inappropriate at this stage?
● Is the requirement truly necessary, or is

it an optional feature that may or may

not be critical to the system’s goal?
● Is each requirement well defined and
unambiguous?
● Is each requirement attributed? Is there

a source noted for each requirement?

● Are there any requirements that conflict

with others?
● Is each requirement attainable in the
technical environment in which the
system or product will be housed?
● Is each requirement, once implemented,
testable?
● Does the requirements model accurately
represent the information, functionality,
and behaviour of the system to be built?
● Has the requirements model been
“partitioned” in such a way that
progressively more detailed information
about the system is exposed?
● Have requirements patterns been used to
reduce the complexity of the
requirements model?
● Have all patterns been validated
properly? Are all patterns in accordance
with the requirements of the customers?
Above and other questions should be
asked and answered to ensure that
the requirements model is an
accurate reflection of stakeholder
needs and that it provides a solid
foundation for design.