8 Successful Requirement Gathering Techniques Of A Successful Business Analyst

 

Business Analysis Requirements Gathering

Requirement Gathering is a key to successful projects. Missing or incomplete requirements leads the project nowhere, hence successful projects focus on the quality of requirement gathering process.

A Business Analyst is the person who generally gathers and analyses the requirements in order to fulfill the client’s needs. There are various methods to achieve your requirement gathering goal and it’s totally up to Business Analyst’s choice to pick one to finish the work.

Requirement gathering techniques are totally based on scenario i.e. sometimes you can finish your task by following only one technique but in some scenarios, you may need to use multiple techniques to baseline your requirements. Below are the most commonly used techniques by Business Analysts and this could be beneficial for you also to complete your project with quality.

NOTE: It is important to understand the methodology that your company uses (adaptive vs predictive). Business analysts should FIRST work to understand the background of the project and do a current state and future state analysis prior to capturing requirements. 

Let's get started.

1) Interviews (One to One):

This is the most common requirement gathering technique where Business Analyst sits down with the client and ask their requirements. Business Analyst asks various questions from business clients/stakeholder in order to understand the requirements. It should be planned ahead during the analysis phase of your project. It’s always good to start with open-ended questions to get the interviewee to start talking (Ask to explain their problem in day to day work.) and then ask probing questions to uncover requirements.

Some Tips for this technique:

1. Try to avoid Yes or No type of questions because it’s very difficult to understand the user’s or client’s problem with such answers. Always ask to explain with the example, could you please explain your daily work in your module?
2. Drill down to detail or pull up to higher level questions
3. Talk to the right stakeholders to get the right outcome.
4. Record your session so that you can review it after the interview - this helps you avoid having to remember everything.

2) Group interviews:

Group interviews are similar to the Interview i.e. Technique 1, except here more than one clients will be interviewed (usually two to four). It’s advisable to invite people having the same designation or role. Group interviews require more preparation and formality to get the information you want from all the participants. You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused. 

3) Facilitated sessions:

You can call it Group Interview ++ because here you invite a group usually more than 6 people for a common purpose. In this case, you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately. You need to prepare questions well in advance and get familiar with the participant’s role and responsibilities. Make sure you prepared and have a clear agenda. Attendees should be taught how to write their own requirements - while you facilitate the process. Don't get caught in the trap of being a note taker. Rather let your group use the white board.

4) Questionnaires:

This is a good way when you need to gather requirements from hundreds or thousands of stakeholders or stakeholder sitting in multiple locations. In this technique, you need to prepare and share the set of questions related to a particular process which could justify the requirements. Generally, this technique is an electronic collecting needs from stakeholders. Remember questionnaires are useful for quantitative capturing - ie gathering volume rather than individual feedback. Ensure that if you want qualitative data you include open questions.

5) Prototyping:

It’s a proactive requirement gathering technique in which you gather preliminary requirements that you use to build an initial version of the solution (a prototype). It’s a preferred approach when stakeholders don't have a clear understanding of their requirements. In such a scenario, several different prototypes are constructed with available requirement sets. It helps the clients to understand the system and further requirements. You will show the current prototype and based on stakeholder’s feedback you will modify the same. You will continue the same cycle until you have the final agreed prototype with baseline requirements.

6) Use cases:

You must be aware of the use case, it’s a high-level diagram which is being created to identify the stakeholders and to understand the process. It’s used to explain the process in the form of stories where you include people and name them actors and define their tasks. Use cases may be easier for the users to articulate, although the use cases may need to be distilled later into the more specific detailed requirements.

7) Document Analysis, Research & Observation:

This is a good technique to get to know the current system and process by analyzing all available documents. It helps him to understand the entire system and associated requirements. Sometimes it’s beneficial to participate in the actual work process to understand and capture requirements. This is good practice to prepare questions for validating the requirements. NOTE: don't be afraid to go on site and watch the process in action. So many business analysts think they have to 'stay in the office' - rather focus on getting great insight yourself then wait for someone to tell you.

8) Requirement Gathering Workshops:

This is difficult as compared to previous techniques. Business analysts have to do their homework well in advance in order to plan agenda, timing, understanding of stakeholders, process understanding, current system knowledge, and confidence. The responsibilities of the business analyst in this technique are as below:

• Discovering requirements
• Refining requirements
• Prioritizing requirements and
• Scoping requirements

This is good for gathering user requirements with everyone’s agreement and you can baseline your requirement quickly but it needs proper planning and management skills.

Guidelines for Requirement Gathering:

1. Pick the Interview Groups wisely. Business Analyst should consider various factors while group selections: Technical Maturity, Business Process Knowledge, Specialisation, Interest, Departments, Organization sections, and Time Availability.
2. Before starting the Requirement Gathering, it’s good to summarize the project and associated purpose, to avoid misconceptions of teams involved in this phase.
3. Business Analyst should follow up each question with a set of clarifying questions to dig it further.
4. Always take a collaborative approach while gathering the requirements.
5. Keep the questionnaire descriptive and simple to understand.
6. Initially, ask the Vendors for the list of requirements with associated details. This will help Business Analyst to frame questions.
7. Carry out the Polls, so that users rank their needs, and have a place to provide feedback

NOTE: It is important to understand the methodology that your company uses (adaptive vs predictive). Business analysts should FIRST work to understand the background of the project and do a current state and future state analysis prior to capturing requirements. 

Post sponsored by Agora Insights Ltd