Getting to Know the Business Needs

As business analysts (BA), we are charged with the important role of understanding a business’s needs right from the beginning of a project. It is during the requirements elicitation effort that we capture, analyze and document project requirements. We then facilitate their communication and delivery to the appropriate stakeholders.

It’s important that business analysts be extremely cautious so as not to miss crucial information during the requirements elicitation, which occurs during the Discovery Phase of our development framework. The more accurately the requirements are represented, the less need for changes there will be across the project lifecycle. That serves the ultimate goal of reducing the impact of changes on the overall timeline.

Eliciting Requirements in Agile

Following an Agile methodology helps with gathering requirements on an ‘as-needed’ basis. In this way, Agile truly stands out from other methodologies. An Agile team will mostly gather requirements for a feature only as it’s ready to be addressed. I believe this is very efficient because the BA focuses on gathering a set of requirements that are needed for a prioritized feature as it’s in production, rather than spending time documenting requirements for work that might not be be needed until several months in the future, or which could even turn obsolete.

Success with Agile requirements elicitation relies on the stakeholders’ sharing their product knowledge with the team. In order to make this happen, there is a list of useful techniques that work out very well and are adaptable to each team and project as needed.

The Importance of Workshops

One of the techniques we use in order to gather all the necessary information is sharing workshops with our customers and team members. After all, they are the people who are most directly involved in acknowledging the business needs for the app we will need to develop.

Frequently, we tend to include design and development team members so they can hear from a customer and/or product owner directly, taking advantage of the opportunity to make deep inquiries about the project subject. This way, we have a diverse set of perspectives and insights, which is very significant for a comprehensive scope.

Some teams spend lots of hours per week with product owners, the facilitator, and the business analyst in order to review, discuss and ensure that each requirement is captured. Others – and this is to me the most beneficial approach – will perform what we call ‘interface analysis’ sessions. In these sessions, we carefully analyze and deconstruct the way a user interacts with an application, learning about the purpose of each interface involved and eliciting high-level details. As timing also matters, this technique enables us to maximize our time with the team so that participants do not lose concentration and enthusiasm.

For complex projects involving multiple stakeholders, a workshop is one of the quickest and most effective ways of eliciting requirements.

Tip: whenever possible – record your meetings. The first time you discuss needs with the stakeholders, you will cover a lot of important information that will be relevant later on. You will want to make sure you capture everything and have the conversation handy for review as needed.

Post Elicitation

It’s usually a good team exercise to perform requirements triage and backlog grooming. These activities provide great opportunities to make sure all the team members are on the same page and to ensure everyone understands why certain feature was prioritized.

In the end, it doesn’t matter which requirements elicitation techniques you choose for your project development. What’s more important is that you are implementing them the right way – one that allows your team to achieve a strong set of requirements that will successfully fulfill business needs and expectations.