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.
(By the way, we’ve pulled together a collection of feature-specific questions and made them available in our Requirements Discovery Checklist Pack.)
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 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.