How do I gather and document good requirements? This is a typical inquiry posed both by junior and experienced Business Analysts (BAs) who manage more uncertain or complex issues, for example, substantial change programs.

Examining prerequisites for each development process will be different. The trick is realizing when you’ve caught sufficient data to have the option to present requirements to the development side of the project. Things being what they are, how could BAs ensure their requirements are ‘adequate?’

This article investigates gathering requirements forthright, yet this doesn’t mean I only refer to waterfall projects. It’s likewise fundamental in Agile to have undeniable requirements and comprehend the project’s scope before beginning development.

What is a good requirement?

A high-quality requirement should follow the below characteristics:

• Clearness
• Relevant
• Consistent
• Unambiguous
• Testable

These attributes are a solid foundation for reasonable business requirements. Each project will differ in the amount of ambiguity involved in the process of gathering data. This entails analysts become agile and make quick decisions within the budgeted time frame of the project.

Throughout my experience of business requirements gathering, I have refined the process into four main categories. The sections below will detail ways to collect data more effectively before heading to the development process.

1. Focus on the Main User

It’s impossible to know if you’ve uncovered all the requirements that will be needed. On many projects, you will be gathering data from many stakeholders. There’s a chance that not everyone will have been able to give their entire perspective on the issue consultants are trying to solve.

To mitigate this situation, it’s essential to focus on the highest priority items that each user will need. Your focus should be on building the requirements around the primary user and its impact on streamlining their current issue.

The best way to gather requirements is typically done in client meetings in an “interview” type style. It’s best to speak to multiple stakeholders as each client could potentially miss elements of the process. Gaps can be filled in by analysts who think through the user process and recognize missing pieces.

Depending on the project’s scope, you can observe user’s behavior with existing systems to see what requirements you could pull from present technologies.

2. Consult with the Development Team

This step is crucial to understand the boundaries and limitations of the proposed solution. You do not need all the requirements when speaking to the development team, but you should have key high-level key components to present.

Insight from the developers will help you adjust requirements based on the projection of work needed. With time limits on projects, some requirements may not be feasible based on deliverable and release schedules. This stage will help you refine the data and get a better handle on what high-level requirements can be completed.

Developers approach problems from a different angle than analysts, so this is a prime opportunity to hear potential requirements from the tech team. As mentioned before, stakeholders do not always know the whole issue, so developers can help close the gap based on their experience angle.

3. Brainstorm with other Consultants

By now, you have gathered enough requirements from stakeholders and developers to start working on design documentation. This document should be shared with other analysts and consultants so fresh eyes can help generate new ideas. Senior-level consultants with more experience can check if you have missed any areas where improvements can be made.

You will be in client interviews with other analysts and managers on many projects, so this process is not always done alone. Working in groups and brainstorming after speaking with stakeholders can help you check off all the boxes for needed requirements.

Feedback from other consultants is a great way to improve your abilities in gathering requirements.

4. Trust Your Judgment

As you gain experience as an analyst, the more you will trust your instincts on what requirements are the highest priority. Gathering requirements will become easier over time as you understand users and what pain points ensue. Below are some questions to ask yourself about the requirements you have gathered.

• Do I understand the process and end goal?
• Is the solution logical?
• Do I have too many or too few requirements?
• Am I able to support this solution when other analysts question it?

Over time you will develop your own requirements process that works best for your project and personal skills. The job of a business analyst can be challenging, especially with constant pressure to meet deadlines and deliverables. Keeping a solid structure is vital in ensuring that gathering and documenting requirements is quick yet effective.

Need More Help?

Many Momentum consultants are experienced business analysts. We can provide an objective review of your requirements or help you brainstorm. Contact us today!

Author Profile

Amy TownsonConsultant

Amy is a certified project manager with over 20 years of experience and expertise in the health and human services industry, transportation, state government sector, contract management, and project management techniques. She has successfully managed over fifty unique projects and multiple portfolios of projects. In addition, Amy has provided training for state and federal clients on a variety of topics. She has strong facilitation skills with the ability to tailor messages to fit the audience’s experience level and role. Amy is a skilled leader of in-person, virtual, and combination teams.

Latest entries

• BlogJuly 13, 2021Business Analysis: A Simple Guide to Gathering Good Requirements
• BlogApril 30, 2021Gen Z in the Workplace