A Guide to Gathering Requirements as Business Analyst

The first and foremost phase of SDLC, aka software development life cycle, is requirements gathering. They offer a concise set of client requirements that the product/service should provide at the end of the project cycle. In the next steps, we will learn more about what is requirement gathering, why is important and how to prepare a requirements document successful. No matter, what kind of project methodology you follow, knowing the right way to procure requirements will help you accomplish the projects goals in line with client’s needs successfully.

What is a requirement gathering?

Requirement gathering is a process of understanding what needs to be developed and the reason behind developing the product or services. Basically, as a business analyst, your role is to understand the pain point of the client and the problems they are facing in the current environment. Thus, understanding why they want to build a product or a service in place. Defining the project requirement’s scope and goals early on during the project initiation can help you solve the risk factors and issues much more intuitively than without proper understanding.

Who is responsible for gathering requirements?

Business analysts, system analysts, product owners, and project managers are mainly responsible for meeting with stakeholders and clients and jotting down the project’s requirements, goals, and scope.

Why is Requirement Gathering Important?

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.

If requirement gathering is not done correctly, then there is a likely chance that the project deliverables(product/service) will not meet the business requirements, and hence the client will be left unsatisfied. The project deadlines can also extend the working hours of the development team if there are issues in following the requirements properly. This issue will ultimately lead to the wastage of time, money, and resources. Once the requirements are gathered, the business analyst will utilize the information for preparing BRD, aka Business Requirement Document, and SRS, aka System Requirement Specifications. These documents will include the client’s vision or mission statement, which defines the overall objectives and business plans.

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

Stages of Requirements Gathering Process

As we have already discussed, gathering business requirements is the critical step for the project. A business analyst needs to thoroughly understand the business needs and align them with business objectives to bridge the gap between business and technical requirements. Also, a responsible BA has to communicate the needs to the stakeholders and the development team.

Stages of Requirement Gathering:

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

Identify the Right Stakeholders:

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

• Clients

• Decision Makers

• Senior Managers

• End-Users

• Marketing Department

• Subject Matter Experts

• Engineering Team

• Product Owners

• Suppliers

• Other partners and associations

There might be other stakeholders who might add value to the project’s definition and scope. Ensure to probe essential questions to internal stakeholders like project managers, product owners, and business owners to gather more data as to who can help streamline the requirement gathering processes.

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.

Things that take place in this stage:

• Defining the project scope and goals

• Clearing all the assumptions, assessing the risks, and identifying the dependencies of the project

• Identifying the business stakeholders to elicit all the requirements based on interaction

• By performing a Cost-benefit analysis, we can identify if the benefits of the project outweigh the underlying costs.

• Defining how the business analyst will handle changes in the requirements and what would be the process for approval in case of changes.

• The budget required and available budget for the project.

• Identifying the success criteria of the project

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.

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 decipher the requirements and prioritize the work based on the requirements specified.

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.

Prioritizing the Requirements

Although the clients may give you many requirements for a project, it is your job to simplify the tasks by understanding the high-priority and not-so-important tasks. This helps you determine how to plan the task and prioritize tasks one by one.

Also, requirements change with time, so whenever a customer requests changes in the scope of the project, try to understand how it will impact ongoing tasks in the project and if the project timeline and budget will be impacted. Based on this discussion, prioritize the new requirement accordingly to ensure successful completion.

Techniques for Requirement Gathering

Requirements gathering techniques are deemed 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. They are explained below:

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.

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.

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.

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

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

Prototyping/ Wireframing

Prototypes and wireframes are visual techniques that are used as a vital requirement gathering method. Here, Wireframe refers to the blueprint of the system to be developed, thus giving an idea about the function and layout. Prototype is considered the system’s model that explains the system’s behavior and functionalities.

This method helps both the business team and users to understand and relate to the requirements & expectations of the future system. This also allows the users to recommend any visible changes that can make the system design even more robust and desirable as a part of the project outcome. Once everything is finalized, the final prototype is referred to build the system.

Key Benefits

• 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.

Surveys/Questionnaire

Gathering requirements from key stakeholders can be difficult if the stakeholders are residing in multiple places. Also, collecting feedback from focused groups of end-users can seem hectic if there are plenty of existing customers of the system. Hence, 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.

Shadowing/User Observation

There are times when the client is very busy and can’t find dedicated time to offer individual interviews. In such cases, 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.

Tools For Gathering Requirements

It is important to have the right set of tools to gather the requirements effectively

1. Microsoft Tools like Excel & Word

2. Jira

3. Monday.com

4. Notion

5. Doc Sheets

6. Caliber

7. Jama Software

Use the toolbox approach to elicit requirements

By implementing the toolbox approach, the project teams can use various tools to define the current & ongoing business requirements. Depending on the type of project methodology implemented, requirements tools can be different.

The below-mentioned tools can be beneficial in eliciting excellent requirements and offer clarity in transforming the business needs into solutions.

1. Context Diagrams: A context diagram created for the system primarily defines its boundary, surrounding environment, and entities. The system is put in the middle of the diagram, and the interaction between customers, end-users, suppliers, and stakeholders is identified.

2. Functional decomposition: This diagram helps validate all the functions the systems should provide and do. It allows the end-user to relate to the model easily.

3. Use Case Diagram: Use Case Diagram helps depict the interaction between the user and the system where each user is called an actor and processes/functions are available in the diagram.

4. Sequence Diagram: This shows the interactions between objects over some time. The objects here can be actors or systems within the systems. It provides a top-to-bottom view of where the messages are being delivered to and from between objects.

5. User Stories: It is a general explanation of a product feature written from the end-user’s perspective. It helps understand how the feature will offer value to the customer.

Tips for Writing a Requirements Document as a Business Analyst

Usually, a project requirement document can include a short, concise document or a lengthy record explicitly specifying the scope, the goal, and the objectives of the project.

Nonetheless, here are the following things your document should have to understand the project requirement more clearly:

1. Name of the Project

2. Project Goals & Objective (What the client wants and why they want it)

3. Scope of the Project( define the work that needs to happen to complete the project)

4. Stakeholders- (Individuals who are impacted by the project outcome & who make informed decisions in every step of the project).

5. Project Deliverables (end product or service you will create for the client)

6. Project Timeline- (Approximate time needed to complete the project)

7. Business Requirements- (any specific requests defining the business objectives)

8. System/Technical Requirements-( softwares/items needed to build the UI/interface/deliverables)

9. Approximate budget- ( As mentioned by the client)

10. Resources for the project- ( identifying the project team who can help deliver the project according to skill sets)

11. Identifying the success criteria-(How successful was the project in meeting the project goals)

Tips for Collecting Requirements as a Business Analyst

Gathering requirements effectively is considered as an incredible art with a hint of organization skills. There are a few tips that can help you document the requirements with minimal error:

1. Define project goals during the discovery phase: Even though project requirements keep changing during the project life cycle, it is crucial to identify the project’s primary goal and set the framework for the project.

2. Document every step during eliciting requirements: It is crucial to jot down important pointers that you gain from every meeting that you plan with the stakeholder team. Once that is done, you can formulate a formal document based on all the discussions.

3. Summarise your understanding when documenting requirements: Even though you might be confident that you understood the project requirements, it is crucial that you summarise the things you understood at the end of every meeting or workshop you conduct during elicitation.

4. Identify the Right Stakeholders & End Users: Don’t forget to ask questions during your kickoff/initial meetings to get a grasp of who the end-users are of the product or services and arrange a feedback/survey session with them to understand their problems and requirements. After all, the client requires an upgrade in their product or services to satisfy their current and future customers. You might be surprised to find additional pain points that the client may not be able to identify initially.

5. Never make assumptions about any project requirements: A simple requirement like wanting to build a survey form can mask a lot of underlying requirements. Hence, instead of assuming things, you need to probe questions like what is the purpose of creating the survey form and what you want to achieve by collecting feedback/data from the survey form. Because if you don’t probe important questions, the results received would be poor and ultimately lead to the failure of the project

6. Confirm before executing: After preparing the meeting notes, it is important to officially prepare a document and take approvals in writing rather than a verbal heads up to avoid getting into any issues with the clients in the future. This holds true for documents, meeting notes, user stories, wireframes, etc.

7. Prioritize the product’s features: No matter which project methodology you follow, it is always important to prioritize features/requirements based on the discussion that takes place with all the stakeholders. Practice active listening and understand the pain points, desires, and goals of the project. Based on that, create a listicle that describes which product features are must-have, nice-to-have, or may have.

Conclusion on Business Analyst

Even though requirement gathering techniques can be lengthy and quite detailed procedure, it is still important to initiate the project plan with this process. A successful requirement gathering can help you control the budget of the project, avoid scope creep due to changing requirements, and help you execute every step of the project with clarity.

Key Takeaways on gathering requirement as a Business Analyst

• 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.

I hope this detailed guide on gathering requirements as a Business Analyst is helpful for you to collect client requirements clearly and concisely. I will come back with more insightful blog topics in the future. For more updates you can follow me in LinkedIn

The media shown in this article is not owned by Analytics Vidhya and is used at the Author’s discretion.

Ananya Chakraborty

A passionate business analyst who analyzes people and data alike! I am also working my way into data science. Taking one step at a time, learning one skill at a time to be able to deliver my quality work consistently! E-Commerce, Digital Marketing, Health and Finance are some of the domains I hold expertise on!