Requirement Gathering is the first phase of the project and it’s also a key to successful projects. Missing or incomplete requirements lead the project nowhere, hence successful projects focus more on requirement gathering process. Business Analyst is the person who generally gathers and analyses the requirements in order to fulfill 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.
Let’s get started.
This is 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:
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?
Drill down to detail or pull up to higher level questions
Talk to the right stakeholders to get the right outcome.
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 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.
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 participant’s role and responsibilities.
JAD sessions are similar to commonly facilitated sessions. However, the group typically stays in the session until the session objectives are completed. For a requirements JAD session, the participants stay in session until a complete set of requirements is documented and agreed to.
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 or paper-based approach of collecting needs from stakeholders.
It’s a modern 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 the clear understanding of their requirements. In such 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.
You must be aware of 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.
This is the 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.
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:
1. Discovering requirements
2. Refining requirements
3. Prioritizing requirements and
4. Scoping requirements
This is good for gathering useful requirements with everyone’s agreement and you can baseline your requirement quickly but it needs proper planning and management skills.
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 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
Other Awesome Reads: