What Questions Do I Ask During Requirements

Elicitation?
A critical part of preparing for requirements elicitation is identifying a list of
questions. You definitely want to avoid securing valuable stakeholder time
only to be lost about what questions to ask! Some stakeholders will talk your
ear off (forcing you to gently interrupt them to keep the meeting on track), but
others need to be led through a structured conversation.

Regardless of who I’m interviewing, I’ve found that preparing a list of

requirements questions helps me keep the conversation on track.

This article is about identifying targeted questions for a project that has
already been scoped, called a requirements questionnaire. If the scope of
your project is not yet defined, you might want to check out “5 questions to ask
before starting any technology project” for some generic elicitation questions
that work on most any project.

What is a Requirements Questionnaire?

A requirements questionnaire is a list of questions about the project
requirements. Typically the questions are organized by feature (or business
requirement or project objective). Essentially each high-level requirement from
your scope document should have a list of questions to further refine your
understanding.

Investing time in a requirements questionnaire will help ensure you not merely
gather up requirements, but also that you discover undreamed of
requirements.

And while it might seem like this would take a lot of time, the reality is that a
well-thought-out questionnaire helps you run a more effective stakeholder
meeting. One of our course participants reported eliminating several follow-up
meetings by using our requirements questionnaire checklists and active
listening techniques.
 What Requirements Questions Should I Ask?
When creating a requirements questionnaire, I work through each feature one
at a time. I write down what I know about that feature (or what I assume to be
true about that feature). Then I go about drafting questions. Most of the time,
the questions evolve naturally as I think through the implications of a feature.
But sometimes I need to spur my thinking a bit.  Just like a good story,
requirements will answer all the important questions. Think about the how,
where, when, who, what, and why.

Here’s some generic questions you can use to spur your thinking.

How requirements questions

 How will you use this feature?
 Is this feature a process and, if so, what are the steps? Or, what
questions can I ask to ascertain the steps?
 How might we meet this business need?
 How might we think about this feature a bit differently?
 How will we know this is complete?

Where requirements questions
 Where does the process start?
 Where would the user access this feature?
 Where would the user be located physically when using this feature?
 Where would the results be visible?

When requirements questions
 When will this feature be used?
 When do you need to know about…?
 When will the feature fail?
 When will we be ready to start?

Who requirements questions
 Who will use this feature?
 Who will deliver the inputs for the feature?
 Who will receive the outputs of the feature?
 Who will learn about the results of someone using this feature?
 Who can I ask to learn more about this?
 What requirements questions
 What do I know about this feature?
 Or, what assumptions am I making about this feature that I need to
confirm?
 What does this feature need to do?
 What is the end result of doing this?
 What are the pieces of this feature?
 What needs to happen next?
 What must happen before?
 What if….? Think of all the alternative scenarios and ask questions
about what should happen if those scenarios are true.
 What needs to be tracked?

Why requirements questions
Why questions are great wrap-up questions as they help confirm that the
requirements you just elicited map back to a need you identified when you
scoped the project.

 Is there any other way to accomplish this?

 Does this feature meet the business need and solve the problem we’re
trying to solve?
 Or check out these 10 ways to discover what the problem really is.
(You’ll notice that we don’t typically ask a why question by using the word
“why”. Among other reasons that’s because we don’t want to sound like a 2-
year-0ld and annoying our stakeholders, even as we apply the 5 Whys
Technique.)

You Won’t Ask the Questions One-by-One

The last thing you want to do with this list is run down your list of questions
one-by-one. That can be a big waste of meeting time and often doesn’t lead to
an engaging discussion.

Instead, I typically select a few core questions off the list and ask them to get
the stakeholder talking. Then, as they are talking about their vision for the
feature, I use this questions list to guide the conversation and ensure we’re
discussing the feature completely. I would say I typically only actually ask
about a half of the questions on the list. The rest the stakeholder typically
answers indirectly through conversation.