5 Critical Questions for Better Requirements Gathering

How would you rate yourself and/or your team at gathering requirements? 

For many project teams, “requirements capture” occurs early on, within a few sessions near the project’s beginning. It’s the time when everyone is most excited about the project, what it will achieve, and the positive change they believe it will bring to the organization.

The reality is that we often find ourselves identifying the requirements much later, such as during the User Acceptance Testing (UAT). We then find ourselves in a “blame game” between the customer and the provider, rushing to “just finish the project” as quickly as possible. In this scenario, no one leaves the project satisfied. You’re just relieved that it’s finally over.

Teams are eager to start running towards a solution. It’s a natural tendency to want to fix the problem as soon as we identify it.

Here’s the good news: It doesn’t have to be this way!

Regardless of your requirements gathering and business analysis method (i.e., user stories, use cases, “it shalls”) there are at least five key questions you should ask. These go beyond (or above) the basics of “what should the system do” and help ensure that your requirements are captured within context of value and the desired user experience. Here are my five key questions and why I find them to be valuable:

Question #1: What does success look like to the customer(s) when the project is done?

This is the most fundamental question in requirements gathering and the one I find that is most often missed. It goes to the heart of “What are we really doing?” The answer to this should align all stakeholders to the outcome it defines. Ask this question of the sponsor, the customer stakeholders, and the operational support team. Be sure they answer it in the context of, what does success look like after we are done— such that, what will this look or feel like a week after we deploy? 

Often, I find the answer is surprising and different from what we were told in the project request or kickoff meeting. And this defines the project.

Question #2: Do we understand our breadth of scope and impact for the change?

Teams are eager to start running towards a solution. It’s a natural tendency to want to fix the problem as soon as we identify it. Yet I see so many teams begin executing projects who soon realize they missed key stakeholder groups that must be supported. To mitigate this risk, early in the requirements gathering effort, the focus should be on identifying the boundaries of the scope, process(es), and impacts to ensure that we have a complete understanding of who and where the change may impact. From there, we can develop a requirements gathering plan to address them appropriately.

With the focus on usability the past 20 years, a blind spot has developed in most project teams around data.

Question #3: Have we captured the decisions and business rules in clear statements?

In requirement gathering sessions, I separate—but relate—business rules from functional requirements. I prefer to start with business flow diagrams, because they provide me context of the functions that users seek and enable the capture of decisions and their subsequent steps or “paths” to ensure I have captured the breadth of the requirements. These decisions are business rules—often feeding future workflow or process steps within the system. Capturing the business rules using clear logic and syntax will reduce confusion by the development team and identify potential contradictions in processes early. The syntax I use is: if x occurs (data, decision, function), then y happens (next step, calculation).

Question #4: What data do I need to perform this function?

With the focus on usability the past 20 years, a blind spot has developed in most project teams around data. For many, it is an afterthought that will be addressed “during development.” I find the opposite to be true—that data, along with business rules—are the essence of good requirements gathering. Data helps identify the minimum factors needed to perform a step or function and simplify the user experience and system design. This is especially true when modernizing or transforming from a legacy system to a future one.

Question #5: What happens if…

This is my “back pocket” question. I use it when users are giving requirements that sound absolute, but I question if it really is. For example, if a user says, “A customer can only submit a trouble ticket via the web page,” then I may ask, “What happens if they call the help desk via phone?” I am using this to test their initial requirement to ensure that it is well-rounded. This does not mean you need to focus on every exception—instead, it seeks to understand where there are firm rules and where there may need to be user-directed flexibility. It also helps open up the user’s perspective to provide better context.

Those are my 5 key questions. I hope they help your team reduce rework, improve their alignment with the stakeholders, and make amazing things happen in your organization!

(Business Analysts: Never miss a critical requirement again! Join our instructors for a special 2-day workshop at The Persimmon Group in Downtown Tulsa on December 11 - 12.)