The Community Blog for Business Analysts


How to make the most of Requirement Elicitation

What Does Success Look Like?

I challenge Business Analysts to view requestors’ requirements as an opportunity to define success. Too often, teams fall into a trap focused on requestors’ prescriptive requirements that are meant to serve as roadmaps for developers and testers. When you limit your view of requirements to this prescriptive lens, you lose sight of the overall objective and stifle the natural creativity that comes from marrying old problems to new, fresh solutions.

Why Do We Need Requirements?

Requirements unite the customer and the solution; they define expectations and how to meet them. Requirements illustrated through user stories or waterfall documentation play a critical role in shaping technical solutions and implementation steps. They also lay out acceptance criteria and use-cases for said requested change. This leads to test scenario creation and the team signing off, saying, “Yes, this is what I requested; it checks all the boxes.” Pretty standard.

But what if we offered more with our requirements? What if we connected those requirements to broader objectives the customer’s trying to solve? What if requirements solved problems customers never realized they had? These solutions ultimately lead to increases in productivity, profits and/or customer satisfaction. When you shift away from the mindset that requirement-gathering sessions are order-taking sessions for technical specifications and move toward the mindset they’re an opportunity to learn about a problem and bring it back to the group for creative solutions, meaningful technical solutions emerge. This process creates solutions that are readily (and enthusiastically) adopted by users and integrated into their processes.

How Do I Get More Out Of Requirements Sessions?

Early in my Business Analyst career, I’d leave requirements-gathering sessions thinking, “How am I supposed to do this when requestors don’t even know what they want?” These thoughts came from requirements-gathering sessions that generally went like this:

BA: “So let’s talk about what ‘xyz’ will look like and what it will do.”

Requestor: “Well, we don’t really know what it can do until you build it.”

Sound familiar? There came a point where I realized it isn’t the customer’s job to know how to give me requirements; it was my job to ask the right questions to find the problem they’re trying to solve and generate solutions. Requestors are hired to be the best accountant, lawyer, analyst, etc.; BA’s are hired to ask the right questions that drive solutions to problems, and sometimes this requires creative, well-placed questions that make the most of requirements-gathering sessions.

Eliciting Requirements

The best questions to use in a requirement-gathering session are those that create dialogue and conversation centered around problem-solving. The more people talk about a requested change, the more information can be gathered by the Business Analyst, bringing everything back to developers/testers for a solution.

Even better than a rousing conversation is a moment of contemplative silence. If you ask a question that causes customers to pause for a beat and say something like, “I hadn’t thought of that before.” you’ve asked a well-placed, creative question. These questions require customers to think through what they’re looking for, how it’ll look if it’s successful and how they’ll ultimately adopt the solution.

Here’s a list of some well-placed, creative questions that drive sound requirements, which lead to technical solutions that are readily (and enthusiastically) adopted:

  • What are the top problems/challenges your business faces? Why?
  • Why do we need “xyz”? How did we get here?
  • What have you tried in the past?
  • If this system/change looked exactly how you picture it, what would it look like?
  • What’s your best measure of success?
  • Is there anything in this process/system you wouldn’t change?
  • If this project/enhancement doesn’t happen, what’ll be the impact?

Finding the right time to ask any number of these well-placed, creative questions takes practice, and there’s no better time than now to start.

This entry was published on Oct 11, 2020 / m_anst. Posted in Project Management, Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  20 members liked this article

Related Articles


Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC