Requirements gathering challenges and solutions

Requirements gathering is an essential part of any project, but it can easily become a challenging endeavour. This article focuses on some common problems when gathering requirements and suggestions on how to overcome them.

Undocumented processes

In many organisations there is often no or very poor documentation available about existing processes. In this situation, requirements gathering becomes a two-step process. Firstly, back-engineering of existing process, and then identifying areas for improvement and optimisation.

To ensure requirements are full and correct, it’s critical to identify key stakeholders and subject matter experts and engage with them directly. This helps eliminate any assumptions and provides a full picture. Drawing business process maps and visualising workflows are effective techniques that can be used in this situation.

Conflicting requirements

Uncertainty about exiting process or different priorities for different stakeholders, often leads to conflicting requirements. If this is the case, the role of a business analyst is to document all requirements, identify contradictory requests and let stakeholders decide on priorities.

As a business analyst you may have some recommendations about what should be prioritised, but it’s still important to hear stakeholders’ opinion. Setting up a poll can be one of the ways to get clarity about what is important to the majority of stakeholders.

Lack of access to end users

Unavailability of end users may occur due to a few reasons and requires appropriate resolution. Sometimes end users are too busy with their day-to-day work and unwilling to participate in requirements gathering activities.

In such situations the best a business analyst can do is to minimise the number and length of engagements. Doing as much research as possible prior to the engagement will help to make the conversation more structured and insightful. It is almost like turning requirements gathering into requirements validation sessions. Defining focus groups and finding the most suitable end-users in each group will also help.

Another common scenario is when IT or the project team ‘know’ what end-users want and discourage direct communication. To convince the team about the necessity of such engagements, try identifying and presenting examples of day-to-day tasks and problems that different users may encounter. Spotlight the differences, the environment they are working in, KPIs they have, technology they are using, etc. Such details often uncover unique requirements that could not be assumed or revealed by one group of users.

Focusing on visual aspects rather than on functional

Often stakeholders and end-users have a clear picture of how the new solution should look but don’t have understanding of what it should do. The user interface is an important aspect of any system, but it should not define or hinder the functionality.

Business analyst should make sure there is a clear distinction between design and functional requirements in their documentation. To keep focus on functional aspects use more abstract tools such as diagrams, user stories and low-fi prototypes rather than design drafts.

Stakeholder design

This is the case when the stakeholders or end-user have the urge to dictate how the system should work rather than providing details about what the system should do. Listening to stakeholders about potential solutions can be insightful but may also divert from actual problems and better solution designs. To prevent such situations, validate each potential ‘false requirement’ by asking ‘why?’, eventually it will reveal the ‘true’ requirement.

Communication problems

This category included language barriers, wrong assumptions, unclearly defined vocabulary, and excessive use of professional terminology that can lead to misunderstandings between stakeholders and a business analyst.

The best strategy to avoid such situation is to communicate often and establish two-way communication. Document gathered requirements and send them for review and feedback to multiple subject matter experts, create and share a glossary of terms, and always verify assumptions.

In summary

These are just some of the challenges of the requirements gathering process. Being able to identify these challenges and manage them appropriately is the key to overall project success.