One of the key complaints when working on a project is that requirements are not explained properly or at times completely ignored or missed. Let it be the development team or the test team or the technical support team, each team depends on the business requirements document to complete their software development lifecycle (SDLC) process.

So if requirements gathering is the primary purpose/task of a BA, then is this entirely their fault? Is this that black and white? Or is there some gray area too which at times is not understood by other teams?

There are certain skill set that  BA needs as well as certain support framework for him/her to succeed. From a Manager’s perspective and having managed business requirements gathering during SDLC process, I believe that a BA needs a range of skill set and support to be successful.

As more organizations are moving towards an iterative methodology, BA needs to prepare themselves for that change. I have highlighted below some guidelines that will be beneficial for that change.

Process to gather requirements in iterative manner:

1. Have face to face discussion with business sponsor and SME to understand the objective
2. Ensure that you have a business requirement document (BRD) template
3. Ensure you know the sponsor, stakeholders and business SME
4. Adopt a phased approach for requirements gathering.
5. Phase 1 – Document 5-10 main objectives for the project
6. Phase 2 – Discuss each point in detail and document functional requirements for each point; include flowchart, user stories and use cases
7. Phase 3 – Add any other additional requirements necessary. Prepare the first draft and give a walk through to business and technical SME; elicit as much feedback as possible during the meeting/walkthrough
8. Phase 4 – Make changes to the draft version to incorporate the feedback received
9. Phase 5 – send to all stakeholders for initial review and feedback

Try to avoid doing below:

1. Do not get bogged down on one specific requirement in phase-1, instead try to capture the key objective/requirements
2. Do not put your own interpretation, instead followup by email to confirm what you have documented is what was requested by business. If you indeed make assumptions, include it in an activity list, clearly identifying what the assumption is about, if it is proved to be wrong, what would be consequence, identify who should be addressing this assumption and a date for resolution.
3. Avoid adding unnecessary detail and present only information that is necessary to produce a working solution
4. Functionalities that are not being impacted, identify them as BAU and include in out of scope. You don’t want to be redefining the BAU process in the BRD in order to prioritize time and project cost.
5. Do not try to shape the technical solution, instead leave that to the relevant IT teams. Your responsibility is to elicit requirements and sort through significant information to come up with an agreed deliverables.

Ensure that you have the necessary Skill Set:

1. Prior to start working on the BRD, learn about the existing project/process and BAU functionalities. You must understand how the existing business requirements work before you can elicit how the new system should behave replacing the old one
2. Continue to learn new technologies and tools that will be handy in your work. Review BA related new tools and compare products/tools using trial version
3. What to do when BA faces uncooperative stakeholders – This can happen under a number of scenarios:
   • Stakeholder thinks this issue is not worth wasting money on
   • Stakeholder is not convinced that this project is required at all
   • Stakeholder had bad experience with the last BA and does not think highly of the current BA
   • Stakeholder was not consulted about the project
   • Stakeholder is not involved with the project and this is not part of his/her position description (PD)
   • Stakeholder is too busy with other tasks and cannot be bothered to schedule a meeting

The way to resolve the above mentioned issues are as follows:

1. First seek out stakeholders or SME if they have document that defines the current process or user manual for an existing project
2. If available, this should provide significant information for you to kickstart your understanding of the existing business requirements
3. If you have a stakeholder who is dis-engaged or reluctant to share information, proceed with requesting some existing documentation to kickstart the process and to avoid delay
4. Ensure that you clearly identify and articulate what is the scope of the work and distinguishing the responsibility from that of Project Manager, product manager, system analysts and others who may play a leadership role in the effort. Ask questions such as:
   • What is my role?
   • What is my level of responsibility
   • What other resources are available to me
   • What will be the reporting relationships
   • What is the end goal in mind
   • What specific deliverables are expected
   • What is the expected timeline

There is a propensity on part of a BA to immediately start working on gathering the requirements as soon as he/she is assigned to a project. STOP. Do not rush into detailed requirements gathering. Ensure the following:

1. Ensure that you have access to a well-organized interview guides and templates to capture stakeholder feedback
2. Assess the list of all stakeholders from the start. All stakeholders are not equal and do not engage the same way. Take some time to analyse/prioritize them based on relevant criteria (e.g, influence level within the organization, amount of impact on the solution, availability for interviews etc.)
3. Decide how scope creep or changes to requirements will be handled, who will authorize the changes and what decisions will be used to schedule the change requests
4. Build trust with different teams or stakeholders. Take some time to introduce yourself and explain what you are trying to achieve and within what timeframes. A hostile stakeholder will cause much pain for the project. So try to avoid that at any cost. Setup a meting with the stakeholder and go out for coffee. Try to break the ice if possible. Also be considerate of the stakeholders concerns or feedback. And be honest with the stakeholder.
5. Sometimes stakeholder asks for more than they really need. Establish from the start the difference between a requirement and a solution.
6. Focus the stakeholder on the need, not necessarily the solution
7. Begin with broad questions (top 5-10 key requirements)
8. Ask Why, What, Where, Who, How and When
9. Ask if anything else you should have asked but didn’t
10. Always followup with email summary
11. Translate the benefit of the requirements to dollars and cents. While it is important to recognize benefits such as enhanced customer satisfaction, improved brand quality etc., it needs to be converted to quantitative benefits including cost, time and quality.

Please remember that the role of a BA evolves over time and works as a link between business and IT departments. So the BA must be willing to learn new tools and look for continuous improvement.

BA must have a support framework in place to be successful. This means that the Manager needs to ensure that BA is given all the tools of trade before being assigned to a project. A brief summary of the support framework is shown below.