requirement gathering

12.04.2023 Business Analytics 1
Weiden Business School
International Business
Summer Semester 2023
SAEID MATINFAR
April 12th , 2023
Business
Analytics

Session 3, Objectives
1. Understand the different types
of requirements and their
importance in the Business
Analysis process
2. Learn techniques for gathering
and analyzing requirements
3. Understand how to prioritize
requirements based on
business value and feasibility

What is a requirement gathering?
• Requirement Gathering or commonly known as the Discovery Phase is
basically a process in which we understand and identify a business’s
project technical requirements and proceed with a well-defined plan.
• Requirement gathering is a process of understanding what needs to be
developed and the reason behind developing the product or services,
and understanding the pain point of the client and the problems they
are facing in the current environment.

The Importance of Requirements Gathering
1. Eliciting Project Requirements
• As a business analyst, requirement gathering helps you in eliciting
project activities from your client so that you can effectively deliver a
complete product that will meet all their specifications.
• Depending on the type of project methodology you implement
(agile or waterfall), this step is carried out during the project initiation
or discovery phase or every meeting/sprint cycle.

When a project falls short of expectations, the following things
happen:
➢Scope Creep: Scope creep is typically caused by key project
stakeholders changing requirements or sometimes by internal
miscommunication and disagreements.
➢Project Deadline gets extended due to Rework
➢Team Members find it hard to stay motivated to finish the project
deadline

2. Increases the level of Satisfaction of Business Client
• Requirements Gathering helps a business analyst to satisfy the needs
of the client, but if it is not done correctly, then there is a high
probability that the project deliverables (service or product) will not
meet the business requirements, hence leaving the client to be left
unsatisfied.
• When issues are detected in regards to following the requirements
properly, it can lead to an extension of the project deadlines which in
turn leads to an increase in the working hours out by the
development team. This will ultimately not only lead to wastage of
time, but of money, and resources.

3. Provides Opportunity to generate Real Improvements to Business
Operations
As a business analyst working in a large organization, business
requirements provide you with the opportunity to generate real
improvements to business operations with clients. Most projects in
large organizations arise from a response to some need or some
current failing.
A sizable amount of resources are then used to complete these
projects. This means it is crucial that they deliver what was actually
needed or it would have been a waste of time and money.

4. Helpful in operating a Business Requirement Document (BRD)
This will also help you as a business analyst to utilize the information in
preparing a Business Requirements Document (BRD). The Business
Requirement Document is the foundation for all subsequent project
deliverables because it fully describes what inputs and outputs are
related to each process function.
The BRD includes documentation of customer needs and expectations
which is essentially gotten from Requirements Gathering

Stages of Requirements Gathering Process
1. Identify the right stakeholders
2. Define the Project: Understand the project goals and scope
3. Elicit the requirements from the stakeholders
4. Document the requirements
5. Confirm the Requirements with the client and stakeholders to
ensure transparency
6. Prioritize the needs based on discussion with the clients

Stages of Requirements Gathering
1. Identify Key Stakeholders
Identify the key people who will be affected by the project. Start by
clarifying exactly who the project's sponsor is. This may be an internal
or external client. Either way, it is essential that you know who has the
final say on what will be included in the project's scope, and what
won't.
Then, identify who will use the solution, product, or service. These are
your end-users. Your project is intended to meet their needs, so you
must consider their inputs.

• Project stakeholders are those who are impacted by
the project outcomes. These may include:

Use the RACI matrix for business analysis
• RACI stands for Responsible, Accountable, Consulted, and Informed.
• It’s basically a chart that shows the different responsibilities people hold
on your project.
• You and the stakeholders should create the matrix together to ensure
that it’s accurate and that everyone is on the same page.
• Each letter corresponds to a level of responsibility:
oResponsible: The actual person performing the work.
oAccountable: The one ultimately answerable for the correct completion of the
deliverable or task.
oConsulted: Those whose opinions are sought, typically subject matter experts.
oInformed: Those who are kept up-to-date on progress.

2. Project Definition
Project definition is the stage where we define the project’s objectives
and try to understand the goal and the scope of the project so that
once we jot down all the necessary requirements based on the
interaction with the stakeholder and the client, we can start the
process of project initiation.

2. Project Definition
Things that take place in this stage:
1. Defining the project scope and goals
2. Clearing all the assumptions, assessing the risks, and identifying the
dependencies of the project
3. Identifying the business stakeholders to elicit all the requirements based on
interaction
4. By performing a Cost-benefit analysis, we can identify if the benefits of the
project outweigh the underlying costs.
5. Defining how the business analyst will handle changes in the requirements and
what would be the process for approval in case of changes.
6. The budget required and available budget for the project.
7. Identifying the success criteria of the project

3. Requirement Elicitation
Requirement elicitation is a process of gathering the correct information from the internal
and external stakeholders. Requirement elicitation can be performed in several ways:
• Surveys
• Questionnaires
• Interviews
• One-on-one meetings
• User stories
• Brainstorming sessions
• Process diagramming
• Follow-Up Meetings
• Workshops etc
This step helps ensure taking
information from the right people
and taking notes, enabling you to
prepare the documents based on
the requirements gathered during
these elicitation techniques.

4. Requirement Documentation
• In this stage, we document the requirements that we have gathered.
Proper documentation is required to understand the
stakeholder/client’s needs and ensure the same is communicated to
the development team who is involved in project deliverables.
• The documents include product requirement documents, system
requirement documents, business requirement documents, etc.
• Ensure to prepare the document in such a way that the development
team can easily interpret the requirements and prioritize the work
based on the requirements specified.

✓Categorize Requirements
To make analysis easier, consider grouping the requirements into these four
categories:
1. Functional Requirements. These define how a product/service/solution
should function from the end-user's perspective. They describe the
features and functions with which the end-user will interact directly.
2. Operational Requirements. These define operations that must be carried
out in the background to keep the product or process functioning over a
period of time.
3. Technical Requirements. These define the technical issues that must be
considered to successfully implement the process or create the product.
4. Transitional Requirements. These are the steps needed to implement
the new product or process smoothly.

✓Interpret and Record Requirements
Once you have gathered and categorized all of the requirements, determine
which requirements are achievable, and how the system or product can
deliver them.
To interpret the requirements, do the following:
➢Define requirements precisely. Ensure that the requirements are:
• Not ambiguous or vague.
• Clearly worded.
• Sufficiently detailed so that everything is known. (Project over-runs and problems
usually come from unknowns that were not identified or sufficiently well-analyzed.)
• Related to the business needs.
• Listed in sufficient detail to create a working system or product design.

➢Analyze the impact of change. Carry out an Impact Analysis to make sure
that you understand fully the consequences your project will have for
existing processes, products and people.
➢Resolve conflicting issues. Sit down with the key stakeholders and resolve
any conflicting requirements issues. You may find Scenario
Analysis helpful in doing this, as it will allow all those involved to explore
how the proposed project would work in different possible "futures".
➢Analyze feasibility. Determine how reliable and easy to use the new
product or system will be. A detailed analysis can help identify any major
problems.

5. Confirmation of the Requirements
• Once the requirements are adequately documented, take approvals
from the clients and stakeholders so that you can start the project.
• Without taking approvals from the client, you may delay the project.
• Furthermore, as requirements might change with time and without
proper permissions, scope creep, project delays, or even cancellation
will occur.

6. Prioritizing the Requirements
• Prioritizing requirements involves determining which requirements are most
important to the project's success and need to be developed and implemented first.
The following are some of the prioritization techniques used in business analysis:
• MoSCoW: MoSCoW stands for Must have, Should have, Could have, and Won't have.
This technique prioritizes requirements based on their importance and urgency.
• Kano Model: The Kano Model prioritizes requirements based on the customer's
satisfaction level. It categorizes requirements into three categories: Must-haves,
Performance Attributes, and Delighters.
• Cost-Benefit Analysis: Cost-benefit analysis evaluates the costs and benefits of each
requirement to prioritize them based on their feasibility and impact on the project's
success.
• Business Value Analysis: Business value analysis prioritizes requirements based on
their impact on the organization's goals and objectives.

Techniques for Requirement Gathering
• Requirements gathering techniques are considered successful when
they are complete, non-ambiguous, verifiable, traceable, and
modifiable.
• Since every project scope is different, the techniques that might be
chosen to elicit requirements will be based on the project type,
complexity, and types of stakeholders involved.

1. One-on-One Meeting/Interview:
This is one of the most commonly used gathering techniques. Here the
business analysts need to plan interviews with the key stakeholders and
probe a set of questions that gives the BA an idea about the project.
These interviews usually involve both open-ended and closed-ended
questions. Questions like who will interact with the system, what
processes can impact the modules, what are the pain points of the
current system etc.

2. Group Meetings:
• This happens when all the key stakeholders have issues scheduling
one-on-one interviews and may request a group meeting to answer
all the questions you might have about the project.
• This is a great way to gather different requirements in one go. Thus
plenty of valuable ideas and thoughts are generated. All the team
members participating will come to a consensus to fasten the project
initiation process.

3. Brainstorming:
• This technique is primarily used during the project discovery phase,
wherein the project’s requirements are not clearly identified.
• In this session, make sure that you include the stakeholders who are
aware of the system and also identify the project needs, benefits, and
costs incurred.

4. Document Analysis:
In this technique, a business analyst collects the existing documents for a
deeper analysis. The benefits of using document analysis are:
• Helps identify key stakeholders
• Helps prepare the right set of questions for follow up meetings and
workshops
• It helps understand the existing process in place
• It helps find the missing information and redundant processes that could
be fixed
• It helps in understanding the unclear requirements that might be stated by
stakeholders

5. Workshops:
• Workshops aka JAD(Joint Application Development) can help you get
the design right the first time and decrease the number of iterations.
Benefits of using JAD sessions include:
• More structured approach
• Minimal conflict
• Helps quickly finalize the system design
• Identifying the underlying issues and stakeholders responsible for
resolving them

6. Prototyping and wireframing are visual techniques used in the
process of designing and building software, apps, and websites.
• Wireframing is a basic sketch or blueprint that shows how the system
or website will look and function, while a prototype is a more detailed
and interactive model of the system that explains how it will behave
and function.
• The purpose of these techniques is to help both the business team
and the end-users visualize and understand the requirements and
expectations of the system, identify potential issues or areas for
improvement, and ensure that the final product is user-friendly,
effective, and efficient.

Key Benefits Prototyping and wireframing
• Eliminates any confusion or assumption
• Easier to capture and identify missing requirements
• Allows the users to see how the model will work once the project is
executed
• Stakeholders are actively involved in suggesting changes and can work
efficiently alongside the business analysts till the project completion.

7. Surveys/Questionnaire
surveys seem like a viable option to send out to various people and
record their responses based on the project requirements.
Key Benefits:
• Valuable when time is limited and the focus group is enormous.
• Stakeholders do not reside at the same location and maybe in
different time zones, so scheduling an interview with the entire group
may be seemingly challenging to execute
• It helps in avoiding repeating the same questions and investing extra
time to gather input on feedback and feature enhancements.

8. Shadowing/User Observation
Shadowing the client for a couple of days seems helpful in understanding the office
environment, current system design, and processes in place, recording the user behavior
and understanding the underlying needs based on the problems in the current process.
Key benefits:
• Have a working knowledge of the current system in place
• Understanding the underlying requirements of the client based on the issues you
come across
• Being able to interact with the client’s team to have a deeper understanding and thus
bridge the gap between the stated and missing requirements.
• Understand how the end-users are using the systems
• Understand how the customers face issues by interacting with the support and the
maintenance team.

9. Use Cases are another way to define business requirements. It can
be simple or complex, depending on the depth of information being
sought. Many a time, teams focus on the “happy path, ” and that leads
to a lot of unhappy outcomes.
10. User stories are a particular form of requirements documentation
methods, applicable to Agile development methodologies. A user story
expresses a specific activity in the voice of the user.

Tools For Gathering Requirements
It is important to have the right set of tools to gather the
requirements effectively
• Microsoft Tools like Excel & Word
• Jira
• Monday.com
• Notion
• Doc Sheets
• Caliber
• Jama Software

Requirement Traceability
Requirement traceability refers to the ability to track and trace a
requirement throughout the project's lifecycle. It involves linking
requirements to other project artifacts, such as design documents, test
cases, and change requests, to ensure that they are properly implemented
and tested. There are different types of traceability:
Forward Traceability: This involves tracing requirements to the design and
development phase to ensure that the implemented system meets the
original requirements.
Backward Traceability: This involves tracing the design and development
back to the original requirements to ensure that all requirements are
implemented.
Bidirectional Traceability: This involves tracing requirements both forward
and backward to ensure that all requirements are implemented and tested.

Tips for Writing a Requirements Document
Your document should have following elements:
1. Name of the Project
2. Project Goals & Objective
3. Scope of the Project
4. Stakeholders
5. Project Deliverables
6. Project Timeline
7. Business Requirements
8. System/Technical Requirements
9. Approximate budget
10. Resources for the project
11. Identifying the success criteria

Key Takeaways on gathering requirement
• Documenting the important requirement during the meetings can
help you draft a brilliant requirement document which is helpful for
taking approvals from client and useful for taking reference by the
team.
• Identifying the right stakeholders can help you avoid any ambiguity on
project scope and goals, thus helping you deliver a successful project.
• Requirement documents help you prioritize important tasks and get it
done first.
• Always remember, for a successful project execution and client
satisfaction, Confirmation is better than Assumption.

Challenges in Requirements Gathering
• Lack of Clarity in Defining Criteria for Success
• Clients Change their Minds Often
• Lack of or Over Communication by Clients
• Clients get critical over certain Techniques/Solutions
• Stakeholders can have Conflicting Priorities

requirement gathering

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to requirement gathering

Similar to requirement gathering (20)

Recently uploaded

Recently uploaded (20)

requirement gathering