Requirements Analysis and Modeling

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.
 Purpose of Requirements Analysis?
• Requirements Analysis is used by software developers
to understand
 The functions of the application to be developed.
 What the client/user expects the application to do.
 The relative importance of each function of the system to
the client user.
 Necessary details of the application domain
 The scope of the project
 Requirements Analysis Process
Step 1: Identify Key Stakeholders and End-Users
The first step of the requirements analysis process is to
identify key stakeholders who are the main sponsors of
the project. They will have the final say on what should
be included in the scope of the project.

Next, identify the end-users of the product. Since the

product is intended to satisfy their needs, their inputs are
equally important.
 Requirements Analysis Process
Step 2: Capture Requirements
Ask each of the stakeholders and end-users their requirements for the new product. Here are some
requirements analysis techniques that you can use to capture requirements:

1. Hold One-On-One Interviews

Interview each stakeholder and end-user individually. This technique will help you gather specific
requirements.

2. Use Focus Groups

Conduct group interviews or group workshops to understand the flow of information between different
stakeholders and end-users. This technique will ensure that there will be no conflict of interest later on
during the project.

3. Utilize Use Cases

Use cases provide a walkthrough of the entire product through the eyes of the end-user. This technique will
help visualize how the product will actually work.

4. Build Prototypes
A prototype provides users a sample look and feel of the final product. This technique will help address
feasibility issues and identify problems ahead of time.
 Requirements Analysis Process
Step 3: Categorize Requirements
Since requirements can be of various types, they should be grouped to
avoid confusion. Requirements are usually divided into four categories:

• Functional Requirements: Functions the product is required to

perform.
• Technical Requirements: Technical issues to be considered for the
successful implementation of the product.
• Transitional Requirements: Steps required to implement a new
product smoothly.
• Operational Requirements: Operations to be carried out in the
backend for proper functioning of the product.
 Requirements Analysis Process
Step 4: Interpret and Record Requirements
Once the requirements are categorized, determine which requirements are actually
achievable and document each one of them. Here are some techniques to analyze and
interpret requirements:

Define Requirements Precisely

Ensure that the requirements are clearly worded, sufficiently detailed, and related to
business needs.

Prioritize Requirements
Prioritize requirements and list them out based on which ones are the “most critical” and
which ones are just “nice-to-have”.

Carry Out an Impact Analysis

Carry out an impact analysis to make sure that you fully understand the consequences of
the requirements.
 Requirements Analysis Process
Resolve Conflicts
Arrange a meeting with key stakeholders and resolve conflicting
requirements. You can also perform a scenario analysis to explore how
the requirements would work for different possible scenarios.

Analyze Feasibility
Perform a detailed analysis of the product based on the requirements
gathered to determine its reliability and to identify any major problems.

Once all the requirements are analyzed, create a detailed written

document and circulate it among the key stakeholders, end-users and
development teams.
 Requirements Analysis Process
Step 5: Sign off
Once a final decision is made on the requirements,
ensure that you get a signed agreement from the key
stakeholders. This is done to ensure that there are no
changes or uncontrolled growth in the scope of the
project.
 Requirements Engineering Process
• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation
 Requirements Engineering Process
• Feasibility study

When the client approaches the organization for getting

the desired product developed, it comes up with rough
idea about what all functions the software must perform
and which all features are expected from the software.

This feasibility study is focused towards goal of the

organization.
 Requirements Engineering Process
• Requirement Gathering
• 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.
 Requirements Engineering Process
• 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,
Security, Quality, Limitations etc.

->The requirements received from client are written in natural language.

 Requirements Engineering Process
• SRS should come up with following features:

User Requirements are expressed in natural language.

Technical requirements are expressed in structured language, which is used inside

the organization.

Design description should be written in Pseudo code.

Format of Forms and GUI screen prints.

Conditional and mathematical notations for DFDs etc.

 Requirements Engineering Process
• Software Requirement Validation

After requirement specifications are developed, the requirements

mentioned in this document are validated.
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

 Requirement Elicitation Process
• Requirement elicitation process can be depicted using the
following diagram:
 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.
 Requirement Elicitation Process
• The requirements come from various stakeholders. To remove
the ambiguity and conflicts, they are discussed for clarity and
correctness.
• Documentation - All formal & informal, functional and non-
functional requirements are documented and made available for
next phase processing.
 Requirement Elicitation Techniques
• Requirements Elicitation is the process to find out the
requirements communicating with client, end users, system users
and others in the software system development.
 Requirement Elicitation Techniques
• Interviews
• To collect requirements. Organization may conduct several types
of interviews such as:
• 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
 Software Requirement
• Broadly software requirements should be categorized in two
categories:
Functional Requirements Examples
• Search option given to user to search from various invoices.
• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given
separate rights
 Software Requirement
• Non-Functional Requirements
• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Accessibility
 Requirements are categorized logically as
• Must Have: Software cannot be said operational without them.
• Should have: Enhancing the functionality of software.
• Could have: Software can still properly function with these
requirements.
• Wish list: These requirements do not map to any objectives of
software.
 User Interface Requirements
UI is an important part of any software or hardware or hybrid
system. A software is widely accepted if it is
 easy to operate
 quick in response
 effectively handling operational errors
 providing simple yet consistent user interface
 User Interface Requirements
FEASIBILTY STUDY

Feasibility is defined as the practical extent to which a project can be performed

successfully

Types of Feasibility
• Technical feasibility
• Operational feasibility
• Economic feasibility
• Schedule Feasibility
 Feasibility Study
Feasibility is defined as the practical extent to which a project can be
performed successfully

Types of Feasibility
• Technical feasibility
• Operational feasibility
• Economic feasibility
• Schedule Feasibility
Feasibility Study
 Feasibility Study
Technical feasibility also performs the following tasks.

Analyzes the technical skills and capabilities of the software

development team members
 Feasibility Study
Operational feasibility

Performs a series of steps to solve business problems and user

requirements. Operational feasibility also performs the following
tasks.

Determines whether the solution suggested by the software

development team is acceptable
 Feasibility Study
Economic feasibility

Financial gains for an organization

estimated cost of hardware and software, cost of performing feasibility
.

Schedule Feasibility
Does the company currently have the time resources to undertake
the project? Can the project be completed in the available time?