Are you looking for a simple way to get more out of your requirements elicitation sessions? Would you like to make better use of yours and your stakeholder’s time? Would you be interested in learning a simple technique for improving your stakeholder meetings?
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.
Here’s a video I recorded about preparing requirements questionnaires.
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 engage your stakeholders, and also that you truly discover and not merely “gather” the 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 and save you time in the long run. 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. You can also download a sample checklist absolutely free of charge.)
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 your stakeholders 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? Or, what are the success criteria?
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? Are they at home? In the office? Offsite?
- 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?
- When does this need to be completed by?
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?
- What device will the stakeholder be using when they use this feature?
- What other questions should I be asking? (This is always a good one for yielding unexpected answers!)
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?
- When we implement this feature, what will be true?
- What’s the most important thing about this feature?
- And also, 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 half of the questions on the list. The rest the stakeholder typically answers indirectly through conversation.
>>Get Your Free Checklist
Learn exactly what a sample requirements checklist looks like, with one sample from our Requirements Discovery Checklist Pack, which includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.
Agreed, Isabella…. I’ve found that if the client/stakeholder/CEO can list 5 of the most pressing issues with procedural functionality, that it is a great starting point for discussion and focus of the scope of engagement.
Great ideas, folks!
I was re-reading the list and thought : why not extend the list to the non-functional and often implicit requirements as well?
So questions like : ‘how much’ (data, responsiveness (wait time) and ‘how secure’ might be added too.
Great point Chris. These are nice additions. Though I do find that many stakeholders have trouble answering those questions directly it’s good to be on the lookout for related information during your elicitation interviews and then follow-up to confirm those requirements.
Excellent list of questions. Well done and its a great list that All project Managers should have right in front of them all the time, no matter, what field one works on. Perfect.
I do believe that I am the same way 🙂 change must be my way – hee hee
Michelle, My thoughts on this question:
“I wonder why some of us can see the benefits of a new process/change in process/new tool and have a vision of what benefits it can bring while others remain stuck in their present world. Is it a gift of the business analyst or is it a fear of change on behalf of the stakeholder.”
I think it is a bit of both. Also, in a way, change is easier for us. It’s what we do. It’s our job to maneuver change. For some SMEs change is a negative because it might mean more work or less fulfilling work or letting go of something they are holding onto.
In a class on how communication styles, there was this joke about my communication style (which I’ve found to be common amongst BAs). She said “yes, your communication style loves change, as long as the change is your idea.” Upon reflection, I thought that was fairly accurate and quite revealing about how I approached change.
Laura
Very insightful post, Laura.
I think the main fear of change though is fear of job loss. Many systems have built in redundancy, and streamlining an operation may mean loss of jobs/functions.
I too agree that change is in my blood, and seeing the ‘big picture’ is perhaps a talent, or perhaps the ability to simplify complex issues.
Great post Laura! I always try to keep my questions open ended – that way you received better answers. I agree that the ‘whys’ can help but I also feel some of the stakeholder’s frustration from a why question. They often feel they are being attacked because they have not bought into the change or are not fully engaged to the point where they see the benefits of the change. I wonder why some of us can see the benefits of a new process/change in process/new tool and have a vision of what benefits it can bring while others remain stuck in their present world. Is it a gift of the business analyst or is it a fear of change on behalf of the stakeholder.
Michelle
Thanks, Sachin, you might check out these two posts on user interface requirements:
https://www.bridging-the-gap.com/how-to-create-a-user-interface-specification/
https://www.bridging-the-gap.com/using-wireframes-or-prototypes-to-elicit-analyze-and-validate-software-requirements/
Hi,
The list above is very comprehensive. It would be great if you can share your experiences in capturing User Interface requirements for a software product.
Thanks Chris, and yes I do find that sometimes too many “why” questions can put people on the defensive. I know it puts me personally on the defensive, that’s for sure!
One way I’ve reframed the question when the why is coming from the top is to ask it this way. “So, I know that executive XYZ really wants this project to happen because …. But, you are dealing with this system (or this problem) every day. If we could use this project to solve one pain point for you what would it be?” This kind of question can sometimes help discover new whys that the executives aren’t fully aware of, or new problems related to the big problem at hand. And it takes the burden off a subject matter expert to justify an entire project, positioning them to just share their pain with the hope that maybe a piece of it will be addressed.
An excellent post as always. Do you come into situations that people are behaving defensively when you ask ‘why’ questions? Because if you ask ‘why’ on the process you (implicitly) also ask to the role of ones work contribution.
What I also come across is that the why question is not considered important, because ‘someone else, most of the time someone ‘higher in the food chain’, are ‘allowed’ to think about the why’ the rest (including BAs !) are there to ‘do their job and consider it ‘as is’ ’….
So BAs assignments end up being not more than only an inventory of process description, rather than their relation with the whole business context.
Thanks, Doug. I agree, the “why” questions are definitely the most important. I tend to use them the most, however, when scoping the project and probably a lot less (maybe less than I should) when getting into the details. Whys are also good follow-up questions. So if an answer to a “how” or “what” question doesn’t make sense, you can always ask, “Why is that?” It’s a great generic follow-up question that helps keep the conversation moving forward and helps stop the BA from making assumptions about the “why”.
Hi Laura:
Great list of questions! Asking the correct probing questions is a really important activity in order to get to the meat of the problem, and you’ve captured a lot of good ones to get the process started. I think that this list has the potential to become a resource for your analysts looking for ways to improve on elicitation results that you should look at posting on the sire here.
Even though I could add a few other questions like many others could, I really wanted to note that the “Why?” question has become my favorite over the years and has taken on a life of its own. In fact, I use the 5 Whys technique from the BABOK quite often in elicitation, as well as in standard root cause analysis. I’ve found that it really works well when repeated over-and-over in determining needs versus desires.
Anyhow, thanks so much for this!
Doug