Building Effective Processes For Requirements Gathering

Strong business requirements are essential to solution delivery. Inadequate and unclear requirements are the number one reason that projects fail. Organizations need a consistent, repeatable, and prescriptive set of guidelines that inform how business requirements gathering should be conducted. 

Requirements gathering demands involvement from a variety of stakeholders. Inaccurate requirements definition can lead to significant amounts of project rework and hurt the organization’s performance. It will also damage the relationship between the vendor, the organization and IT.   

The following information outlines best practices and provides a guide for those who are gathering business requirements for an application or system review.   

What are Business Requirements? 

A business requirement is a statement that clearly outlines the functional capability that the business needs from a system or application. There are several attributes to consider in requirements. Requirements should be  

  • Verifiable or stated in a way that can be easily tested 
  • Specific, unambiguous, and free from subjective terms 
  • Complete with all relevant information 
  • Consistent, achievable, traceable from inception through testing 
  • Agnostic without inclination towards any specific vendor or product. 

Having a standard process for defining requirements gives your organization a frame of reference for gathering them. Building an effective process will save you time and money in the future as you determine the best systems and applications for your digital transformation. 

The Role of the Business Analyst 

Many associations and non-profits do not have dedicated Business Analysts (BA) on staff. Often the IT Director or a project manager plays the BA role to gather requirements for a project. In this role, their job is to elicit, analyze, specify, and validate the business needs of stakeholders. 

  • Collaborate with project sponsors to determine project scope and vision. 
  • Conduct interviews to gather user requirements via workshops, questionnaires, surveys, site visits, workflow storyboards, use cases, scenarios, and other methods. 
  • Research, review, and analyze the effectiveness and efficiency of existing requirements gathering processes to develop strategies for enhancing or further leveraging these processes. 
  • Complete ongoing analysis of requirements conformity to standards. 

A successful requirements gathering practitioner is someone who has found balance between communication, documentation, collaboration, and control. In associations, that balance should sway towards communication and collaboration. 

The Requirements Gathering Framework 

A robust process for business requirements gathering is essential for project success.  However, most organizations do not take a strategic approach to optimize how they conduct business analysis and requirements definition. The following graphic outlines how this process is ideally conducted. 

Phase 1: Planning the Target State for Requirements Gathering  

Determine Your Objectives 

The main objective is to understand the target business needs for the requirements process. Start by examining the business process, then tackle technology. When gathering business requirements, it's critical not to assume that layering on technology to a process will automatically solve your problems. Proper requirements gathering views projects holistically (i.e., not just as an attempt to deploy an application or technology, but as an endeavor to enable new or re-engineered business processes). Neglecting to see requirements gathering as business process enablement leads to failure.  

Start by identifying the challenges you are currently experiencing. A great way to do this is via a whiteboarding activity. Work with the subject matter experts to come up with challenges, write them on sticky notes, and place them on the whiteboard. As a group, review all the sticky notes and group them into themes. What objectives will help you overcome these challenges? 

Now let's turn these objectives into goals. Visualize how you want requirements to be gathered in your organization. Do not let elements of the current process restrict your thinking. Articulate the motivation for optimizing requirements management and establish clear goals.  

Then, select the project specific KPIs used to track the value of requirements gathering optimization. You need to ensure your requirements gathering procedures have the desired effect and adjust course when necessary. Establishing an upfront list of key performance indicators that will be benchmarked and tracked is crucial. Without following up on requirements gathering by tracking project metrics and KPIs, organizations will not be able to accurately gauge if the requirements process re-engineering is having a tangible, measurable effect. They will also not be able to determine what changes (if any) need to be made to SOPs based on project performance. 

"Without requirements that correctly articulate the underlying needs of your business stakeholders, projects will fail to deliver value and involve significant rework. In fact, An Info-Tech study found that over two-thirds of projects fail due to poorly defined business requirements." 

-Ben Dickie
Director, Enterprise Applications, Info-Tech Research Group

Read More: How to Write IT Standard Operating Procedures

Identify Stakeholders 

You have defined your goals for requirements gathering and what KPIs for how you will measure the performance of our requirements gathering process. Before you can dive into most elicitation techniques, you need to know who you're going to speak with. Not all stakeholders hold the same value. 

There are two broad categories of stakeholders: 

  • Customers: Those who ask for a system/project/change but do not necessarily use it. These are typically executive sponsors, project managers, or interested stakeholders. They are customers because they may provide the funding or budget for a project and may have requests for features and functionality, but they won't have to use it in their workflows. 
  • Users: Those who may not ask for a system but must use it in their routine workflows. These are your end-users, those who will interact with the system, and who may interact with other systems that will require inputs or outputs from the proposed solution. Understand their needs to best drive more granular functional requirements. 

Phase 2: Preparing, Conducting and Confirming Elicitation  

The elicitation phase is where the BAs meet with project stakeholders and uncover the requirements for the application. 

Determine Elicitation Techniques 

A mediocre requirements practitioner takes an order taker approach to elicitation: they elicit requirements by showing up to a meeting with the stakeholder and asking, "What do you want?" This approach frequently results in gaps in requirements, as most stakeholders cannot free-form articulate an accurate inventory of their needs. A strong requirements practitioner first decides on an elicitation framework – a mechanism to anchor the discussion about the business requirements. The BA can work through several key questions:  

  • What processes will this application need to support? 
  • What does the current process look like? 
  • How could we improve the process? 
  • In a target state process map, what are the essential functional requirements necessary to support this? In other words, what do you want the application to do that your current system may or may not accomplish? 

One key element to elicitation is using the right blend of tactical techniques to gather information.  Interviews are the most popular means, but focus groups, application design sessions, and observational techniques can often yield better and more expedient results. There is a time and place for each technique. Diversify your approach based on the elicitation goal. 

Conducting elicitation typically takes the most significant part of the requirements management process. During elicitation, the designated BA(s) should review documentation and conduct individual and group sessions with key stakeholders. Providing a guide for your BAs with a shortlist of recommended/mandated elicitation techniques based on business scenarios can be helpful. Your guide should also suggest the order in which BAs use the techniques for initial elicitation. Generally, document review comes first, followed by group interviews, individual discussions, and observational techniques. 

Structure Elicitation Output 

You will need to record and capture requirements in solution-oriented formats. Unstructured notes for each requirement are challenging to manage and create ambiguity. Using solution-oriented formats during elicitation sessions ensures that the content is digestible to IT and business users. 

A typical elicitation output may take the form of a requirement matrix or process narrative.  In addition, this table shows other solution-oriented formats for recording requirements. Determine which formats the development team and BAs are comfortable using and create a list of acceptable formats to use in projects. 

Read More: Role of Consulting in AMS Vendor Selection

Phase 3: Analyzing and Validating Requirements  

Phase 3 covers the analysis and validation sections of the framework. At this stage, you must determine how you will analyze the results and validate the requirements package with stakeholders. 

First, categorize requirements to identify and highlight requirement relationships and dependencies. The table below shows examples of requirements by various categories. 

Graphical user interface

Description automatically generated with medium confidence

Analyze: Organize, Prioritize and Analyze 

After elicitation, it is very common for an organization to end up with redundant, complementary, and conflicting requirements. Consolidation will make managing a large volume of requirements much more manageable. When collapsing redundant or complementary requirements, it is imperative that the ownership and priority metadata be preserved for future reference. Avoid consolidating complementary requirements with drastically different priority levels. 

Conflicting requirements are unavoidable; identify and resolve them as early as possible to minimize rework and grief. Conflicting requirements occur when stakeholders have requirements that partially or fully contradict one another. As a result, it is not possible or practical to implement all the requirements. Resolve conflicts whenever possible during the elicitation phase using cross-functional workshops to facilitate discussions that address and settle conflicts in the room. 

Prioritization is the process of ranking each requirement based on its importance to project success. The implementation subject matter experts will use these priority levels to ensure efforts are targeted towards the proper requirements and plan features available on each release. Use the MoSCoW Model of Prioritization to order requirements effectively. 

The MoSCoW Model of Prioritization:

  • Must Have - Requirements must be implemented for the solution to be considered successful.
  • Should Have - Requirements are high priority that should be included in the solution if possible.
  • Could Have- Requirements are desirable but not necessary and could be included if resources are available.
  • Wont Have - Requirements wont be in the next release but will be considered for future releases.

You can also prioritize requirements by category as shown below.  

  • Regulatory and Legal Compliance
  • Policy Compliance
  • Business Value Significance
  • Business Risk
  • Likelihood of Success
  • Implementation Complexity
  • Alignment with Strategy
  • Urgency
  • Dependencies

Validate: Translate, Allocate, Approve 

Before final sign-off, ensure that you have pulled together all the relevant documentation in a user-friendly requirements package. The requirements package is a compilation of all the business analysis and requirements gathering. The document will be distributed among major stakeholders for review and sign-off.  

Some may argue that the biggest challenge in the validation phase is getting the stakeholders to sign off on the requirements package; however, the real challenge is getting them to actually read it. Often, stakeholders sign the requirements document without fully understanding the application's scope, deployment details, and how it affects them. Remember, this document is not for the BAs; it's for the stakeholders. Make the package with the stakeholders in mind. Create multiple versions of the requirements package where the length and level of technical details are tailored to the audience. Consider creating a supplementary PowerPoint version of the requirements package to present to senior management. 

Before proceeding with the process, requirements should be verified by domain subject matter experts to ensure that the analyzed requirements continue to meet their needs. This step is often overlooked because it is laborious and can create additional work; however, the workload associated with verification is much less than the eventual rework stemming from poor requirements. 

Use the sign-off process as one last opportunity to manage expectations, obtain commitment from the stakeholders, and minimize change requests. Procurement of the application cannot begin until all have approved the requirements package of the critical stakeholders. This will be the third time that the stakeholders are asked to review the requirements; however, this will be the first time they are asked to sign off on them. The stakeholders must understand the significance of their signatures. This is their last opportunity to see precisely what the solution will look like and make change requests. Ensure that the stakeholders also recognize which requirements were omitted from the solution that may affect them. 

The sign-off process needs to mean something to the stakeholders. Once a signature is given, that stakeholder must be accountable for it and should not be able to make change requests. Note that some requests from senior stakeholders can't be refused; use discretion when declining. 

Phase 4: Managing and Communicating 

Finally, Phase 4 focuses on managing and any changes to the requirements package and communicating the application/system changes. 

Manage: Create Control Processes for Requirements Changes  

Once the stakeholders sign off on the requirements document, any changes need to be tracked and managed. To do that, you need a change control process. Thoroughly validating requirements should reduce the number of change requests you receive. However, eliminating all changes is unavoidable. The BAs, sponsors, and stakeholders should have agreed upon a clearly defined scope for the project during the planning phase, but there will almost always be requests for change as the project progresses. Even many small changes can negatively impact the project schedule and budget. Route all changes, including small ones, through a formal change control process to avoid scope creep. 

Build Requirements Governance and Communication  

Analysts and developers will run amok with their own processes if appropriate governance oversight doesn't exist to create and enforce operating procedures. One of the best ways to properly govern your requirements gathering process is to establish a working committee within the framework of your existing IT steering committee. This working group should be responsible for policy formulation and oversight of requirements gathering operating procedures. Both business and IT sponsors (e.g., a director, BA, and "voice of the business" line manager) should comprise the governance body. The governance team will not be executing the requirements gathering process, but it will decide which policies to adopt for elicitation, analysis, and validation. The team will also be responsible for ensuring – either directly or indirectly through designated managers – that BAs or other requirements gathering processionals are following the approved steps. 

Before implementing any changes, you will need to communicate the reason for the transition to all staff and stay on message throughout the change. Successful change leaders spend considerable time developing a powerful change message: a compelling narrative that articulates the desired end state and makes the change concrete and meaningful to staff. They create the change vision with staff to build ownership and commitment. The change message should: 

  • Explain why the change is needed. 
  • Summarize the things that will stay the same. 
  • Highlight the things that will be left behind. 
  • Emphasize the things that are being changed. 
  • Explain how the change will be implemented. 
  • Address how the change will affect the various roles in the organization. 
  • Discuss staff’s role in making the change successful. 


With all parts of the process considered you should now have an guide for requirements gathering that is comprehensive and effective with concrete steps for all parts of the framework. Those managing the requirements gathering process have a clear roadmap of best practices to plan, monitor, manage and communicate applications and systems changes as well as the elicitation, analysis, and validation of requirements. 

If you’re interested in creating a requirements gathering program for your IT department or organization, give us a call or shoot us a message.

Subscribe to our Newsletter

Contact Us