9 Successful Requirement Gathering Techniques Of A Successful Business Analyst

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 the requirement gathering process. 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. 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.


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.


4) Joint application development (JAD):

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.


5) 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 or paper-based approach to collecting needs from stakeholders.


6) Prototyping:

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


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


8) 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.


9) 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:

  1. Discovering requirements
  2. Refining requirements
  3. Prioritizing requirements and
  4. 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


We had conducted voting to find the most commonly used techniques and I'm very thankful to readers who have contributed by voting and helping in achieving below result.


Please be noted that the techniques are based on the development model followed i.e. successful techniques in Waterfall model could not be that successful in Agile.

I hope you liked this article and found it useful.

9 Comments

  1. Very good & helpful stuff for BA.

    ReplyDelete
  2. I'm glad you liked the stuff.. Like our Facebook page to get the updates on latest post.. Don't forget to share the content ??

    ReplyDelete
  3. Anyone else notice that the date at the top says that this was posted in the Future: "Wednesday August 31 2016"

    ReplyDelete
  4. Future date was selected to keep the post on TOP.. Nice observation ?

    ReplyDelete
  5. Good article, very informative and useful. Thanks.

    ReplyDelete
  6. You are welcome!! Do share with your friends and don't forget to like our Facebook page to get latest post as soon as it arrives??

    ReplyDelete
  7. Sweet blog! I found it while searching on Yahoo News. Do you have any tips on how to get listed in Yahoo News? I've been trying for a while but I never seem to get there! Thanks

    ReplyDelete
  8. Hello there, I found your web site via Google while searching for a related topic, your site came up, it looks good. I have bookmarked it in my google bookmarks.

    ReplyDelete
  9. This excellent website certainly has all the information I needed concerning this subject
    and didn't know who to ask.

    ReplyDelete

Post a Comment

Previous Post Next Post