Preparing for requirements gathering

One of the basic tasks of a business analyst is requirements gathering. As the saying goes “Well begun is half done” and a well conducted requirements gathering session will go a long way in ensuring smooth delivery of the project. Most of the requirements will come from the stakeholders. However a good business analyst will definitely have to do his / her homework before getting into requirements gathering mode. Some of the aspects to take care of prior to requirements gathering are listed below

• Domain Knowledge: This is the most important aspect to understand. The BA may or may not be an SME on the domain. However it would serve the BA well to read out as much as possible on the domain / industry for which requirements are to be gathered. This has multiple benefits. Stakeholders may be very used to using terms that is specific to the industry. It will help if the BA is already aware of the meaning and builds the confidence of the stakeholders. If the BA is a domain expert he can also suggest some additional functionality based on industry best practices which could be good for the business.

• Identify Stakeholders: Another important aspect to consider to identify who are the stakeholders who can provide the requirements. This is more crucial in case the requirements gathering sessions are going to be conducted onsite. Since stakeholders may not be available full time it is always a good idea to catch up with them (over emails etc.) prior to the actual visit and block times for meetings. It is also a good idea to have an agenda in place for the meetings so that everyone is clear on what is expected from the meet rather than to just leave it open ended.

• Predefine templates: Where ever possible have some pre- defined templates prepared and approved from the client. This helps to channelize the requirements gathering towards meeting a specific issues or addressing a particular pain point. Also sharing this before starting the actual requirements gathering will be beneficial. Not only can stakeholders provide their inputs on how the templates can be made better, it also helps them to be prepared with any extra information that may be needed for the requirements gathering sessions. 

• Review any material available: As part of preparation for requirements gathering, a BA should also request for any existing material that is available regarding the topics under scope. This could be in the form of training materials, user manuals, forms or process flows etc. A review of such documents should give the BA a good feeling on the sort of pain points the users may be experiencing and what direction the requirements gathering sessions will lead to.

• Understanding various techniques: A BA should be able to use all available techniques to gather the requirements. Not all requirements can be clearly spelt out. The key is to understand the unsaid word. The BA should make sure that they also notice user actions and identify issues / pain points that may need to addressed and get it confirmed from various stakeholders.

• Listen first, analyze later: An aspect that a BA should try to avoid doing is confuse requirements gathering with requirements analysis. Many a time the tendency is to start evaluating what the requirement means in terms of development / coding etc. Ideally the focus should remain on just understanding the requirements clearly and analysis of the requirements should be only from the perspective of getting clarifications or eliciting detailed requirements.

• Prioritize requirements: It is also a good idea to understand the priority of the requirements. Some requirements may be easily attainable but not a priority. In some cases, requirements may just be a nice to have feature but not really something that is essentially needed for a “GO LIVE” scenario. It is important that the BA is able to understand the requirements along with the priority and get it aligned with the stakeholders. This is an important aspect even from the overall project planning perspective.

• Conclude the session: The most important aspect of the requirement gathering phase is the conclusion of the phase. At the end of the phase, a clearly documented list of requirements should be agreed upon by the BA and the various stakeholders. This could be in the form of a simple excel sheet or a BRD / SSRS etc. Whatever the format is should be formally signed of and forms the basis of project scoping, effort estimation, timelines and not to forget costs!!

The above mentioned pointers are by no means exhaustive. Also these are just generic guidelines which can help a BA in gathering and consolidating requirements in a more efficient way. This can lead to significant reduction / savings in time and effort of both, the BA as well as the stakeholders. It can also ensure that all requirements get captured within a specified time frame. A well listed out set of requirements also helps developers, project managers and QA tests to ensure that the final delivery meets stakeholder’s expectations in terms of functionality and quality

About Author:

 Ashish Akulkar is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: 

ashish.akulkar@spluspl.com