Before you sit down with a stakeholder, you need a question plan. Not a script, but a deliberate structure that tells you what you’re trying to learn, from whom, and in what order. Getting your requirements elicitation questions right is not about memorising a list of prompts. It’s about understanding who is in the room, what they care about, and how to draw out the information that actually matters for your analysis. I’ve been doing this work for over 25 years across government, health, utilities, education, and enterprise environments, and the quality of my questions has always determined the quality of what I delivered.
This article is structured around the task you have right now: preparing for an elicitation session. Whether that’s a workshop, a one-to-one interview, or a working group, the same principles apply. I’ll give you a framework for structuring your questions, show you the difference between a poor and a productive line of questioning, walk through a real example where things got difficult, and point you to the deeper resources that will make your elicitation practice sharper over time.
Why Your Question Plan Matters More Than Your Question List
Most BAs go into elicitation sessions with good intentions but the wrong starting point. They arrive with a list of questions about the system, the process, or the proposed solution. The stakeholder barely understands what’s being asked, gives vague answers, and the session winds up generating more confusion than clarity.
The core mistake is leading with the solution space rather than the business space. Your stakeholders are experts in their own domain. They are not experts in business analysis, systems thinking, or requirements documentation. The moment you ask them whether they want a dashboard or a report, or whether a given field should be mandatory or optional, you’ve lost them. Worse, you’ve signalled that you’re not really interested in their world.
Good elicitation questions keep the stakeholder talking about what they know and care about. That gives you the raw material you need to derive the actual requirements yourself, which is your job. Theirs is to tell you about their business. Yours is to translate that into something that can be designed, built, or changed.
A Framework for Structuring Your Elicitation Questions
I structure my initial elicitation questions around six dimensions. These work regardless of the project type, the sector, or the methodology. Before I go into any elicitation session, I have at least one strong question prepared for each of these areas:
- Who: Roles, responsibilities, and relationships within the business area you’re investigating.
- What: The services, products, or outputs the business area produces and is accountable for.
- How: The processes, procedures, and steps involved in delivering those outputs.
- When: The events, triggers, schedules, and timeframes that govern the work.
- Where: The physical or digital locations where the work happens, including any distributed or remote context.
- Why: The goals, drivers, constraints, policies, and values that shape decisions in this area.
Once I’ve worked through these, I move to pain points. Issues don’t always surface naturally from the six dimensions above, so I ask directly. Something like: “What is your biggest frustration with the way this currently works?” or “Where does the process break down most often?” These are the questions that generate the most honest and useful responses, provided you’ve already built enough rapport that the stakeholder feels safe answering candidly.
The Most Important Word in Elicitation
It’s “why”. I ask it constantly, across every level of stakeholder, in every sector I’ve worked in. Not the confrontational “why did you do that?” version, but the curious, exploratory version: “Why does that happen?” or “Why does it take three weeks to get that approved?” or “Why is that information kept in a spreadsheet rather than the system?”
Each “why” takes you one layer deeper. The surface answer is rarely the real requirement. The real requirement lives underneath, in the reason behind the reason. I keep asking until I’m confident I’ve reached the root cause or the genuine business need. If you’re not familiar with the Five Whys technique, it’s worth understanding how it applies to BA practice. There’s a solid worked example at “Why” is the How of Getting to the Root Cause of a Problem that shows exactly how this plays out in analysis.
Pitching Questions at the Right Level
One of the most common errors I see from early-career BAs is asking the same questions regardless of who is in the room. Senior stakeholders and operational stakeholders need very different lines of questioning, and confusing the two wastes everyone’s time and damages your credibility.
| Stakeholder Level | What They Care About | Right Question Types | Questions to Avoid |
|---|---|---|---|
| Senior leaders and executives | Strategy, risk, investment, outcomes | Goals, drivers, constraints, success criteria, risk appetite | Step-by-step process detail, system configuration, operational procedures |
| Middle managers | Performance, reporting, resource, team outputs | Information needs, decision-making, pain points, team structure | Highly granular task detail or broad strategic framing without operational grounding |
| Operational staff | Daily tasks, tools, workarounds, process friction | What, how, when, who, where questions about specific tasks and activities | Strategic initiative questions, organisational goals, investment rationale |
When I’m preparing for a session, I review the attendee list and categorise each person. I then adjust my question plan accordingly. In a mixed session, I’ll often open with the senior stakeholder’s framing questions and then invite operational staff to ground those answers in day-to-day reality. That contrast is often where the most useful friction surfaces.
A Worked Example: Where Good Questions Saved a Failing Elicitation
On Project X, a government client in the utilities sector, I was brought in mid-stream to support requirements elicitation for a new operational reporting platform. The project had already been running for six weeks. The previous BA had been holding sessions, but the requirements were thin and largely driven by the vendor’s demo capabilities rather than the client’s actual needs.
The first session I attended had a senior operations manager present. The incumbent BA opened with: “Do you want the reports to auto-refresh or will you pull them on demand?” The operations manager looked blank and said he didn’t really mind, whichever was easier. The session moved on without anything useful being established.
I asked to take over the next session with the same stakeholder. I started with: “Can you walk me through a typical Monday morning? What’s the first decision you make, and what information do you need to make it?” That opened twenty minutes of genuine, detailed explanation about how the manager monitored overnight safety incidents across three sites, coordinated with shift supervisors, and flagged anything requiring executive escalation before 9am.
The friction came when I tried to document what I’d learned. The operations manager reviewed my draft and said it was wrong. He insisted the escalation process I’d described applied only to environmental incidents, not safety incidents, which had a completely separate reporting chain. He was right. I’d conflated two separate workflows because I hadn’t asked “who receives that report, and what do they do with it?” clearly enough. I had to go back, re-run that section of the elicitation, and bring in a second stakeholder who owned the safety reporting chain.
That extra session added three days to the schedule, which the project manager was not pleased about. But it also prevented a system being built that would have merged two legally distinct reporting obligations into a single workflow. The rework cost of fixing that post-build would have been significant. The point of friction was painful in the moment. The outcome justified it entirely.
From those sessions, the requirements I derived were specific and grounded: the system needed to surface safety and environmental incidents in separate, independently configurable views; reports had to be accessible on mobile devices before 7am; and the escalation workflow needed to support different distribution lists depending on incident classification. None of that came from asking about dashboards versus reports. It came from asking about Monday mornings.
Comparing Productive and Unproductive Question Lines
The scenario above mirrors a pattern I’ve seen repeatedly. Here’s a direct comparison of how the same information need can be approached badly or well:
| Unproductive Approach | Productive Approach |
|---|---|
| “Do you want Business Objects or Cognos?” | “What decisions do you make daily, and what information do you need to make them?” |
| “Do you want a report or a dashboard?” | “How do you currently get the information you need, and what’s frustrating about that process?” |
| “Should this field be mandatory?” | “What happens if that information isn’t available when someone completes this step?” |
| “Do you want email or SMS notifications?” | “When something goes wrong, who needs to know and how quickly does that need to happen?” |
| “How many users will access the system?” | “Who needs access to this information, and are there any people who currently can’t get it but should be able to?” |
Building Your Question Plan Before Every Session
I never go into an elicitation session without a written question plan. It doesn’t need to be long, but it needs to be deliberate. Here’s how I build one:
- Identify what you don’t yet know: Review what’s already been documented and list the genuine gaps. Your questions should target those gaps, not rehash what’s already confirmed.
- Map questions to stakeholders: Each attendee has a different vantage point. Assign at least two or three questions specifically to each person’s area of expertise or accountability.
- Sequence from broad to specific: Open with contextual, exploratory questions before drilling into detail. Let the conversation warm up before you push for precision.
- Prepare your “why” follow-ups: For each primary question, note at least one “why” follow-up you’ll use if the answer is shallow or incomplete.
- Build in a pain point question: Always include at least one direct question about what isn’t working. This is where the most valuable requirements often hide.
If you’re working on a project where you’re still getting oriented, it’s worth reading How to Start a Business Analysis Project: What to Do on Day One before you plan your elicitation sessions. Getting the context right before you start asking questions makes your questions significantly sharper.
For the elicitation sessions themselves, the technique you use to run them matters as much as the questions you bring. Types of Elicitation Techniques for the Business Analyst gives a practical overview of interviews, workshops, observation, and other approaches, which helps you choose the right format for the right stakeholder group.
How Many Questions Do You Actually Need?
More than you think, and fewer than you’ll use in any single session. The Requirements Discovery Checklist Pack, developed by Laura Brandenburg (CBAP), contains over 700 questions categorised across 18 checklists covering core business process areas and software features. I’d recommend it not as a session script but as a preparation resource. Before a session on a new domain, I’ll scan the relevant checklist to make sure I haven’t missed an angle that’s obvious to an experienced BA but invisible to someone new to that domain area.
The value of a resource like that isn’t in reading it end to end. It’s in using it to pressure-test your own question plan. If you can get to the Requirements Elicitation: How to Ask Better Questions as a Business Analyst page, you’ll find more detail on how to use that kind of structured resource in your practice.
The skill that takes the longest to develop isn’t knowing which questions to ask. It’s reading the room well enough to know when to pause, when to push deeper, and when a stakeholder’s hesitation is telling you something more useful than their words. That only comes with practice, and you build it one session at a time. The more deliberately you plan your requirements elicitation questions, the faster that skill compounds.
Frequently asked questions
What are the best requirements elicitation questions to ask stakeholders?
The most effective questions start with who, what, how, when, where, and why to understand the business before touching solution detail. Follow up every answer with ‘why’ to get beneath the surface and reach the real requirement. Questions about pain points and current frustrations consistently generate the most useful material.
How do I structure elicitation questions for different stakeholder levels?
Senior stakeholders respond best to questions about strategy, risk, outcomes, and decision-making. Operational staff need detailed process-level questions about tasks, triggers, and workarounds. Mixing question levels in the wrong direction, such as asking operational staff about strategic goals, wastes time and damages your credibility.
How many questions should I prepare for a requirements elicitation session?
Prepare more than you expect to use, typically ten to fifteen per session, but plan to use only six or eight depending on how the conversation flows. The goal is depth of understanding, not coverage of a list. A single well-explored question often produces more useful requirements than ten shallow ones.
What is the difference between open and closed questions in elicitation?
Open questions invite the stakeholder to explain, describe, or elaborate, and are essential for exploratory elicitation. Closed questions, which invite a yes or no, are useful for confirming specific facts or validating what you’ve already documented. Most of your session should use open questions, with closed questions used deliberately to pin down detail.
How do I handle a stakeholder who gives vague or unhelpful answers during elicitation?
Vague answers usually mean the question was pitched at the wrong level or was too close to the solution space. Reframe the question around the stakeholder’s daily reality: what they do, what they need, and what gets in their way. Following up with ‘can you give me an example of when that happens?’ almost always unlocks more concrete information.
Try Ash, Your Virtual BA
If you’ve just read this and you’re preparing for an elicitation session, Ash can help you plan your questions before you walk into the room. Tell Ash about your project, your stakeholders, and what you’re trying to understand, and it will help you build a structured question plan tailored to your context, so you arrive prepared rather than improvising. Try Ash Virtual BA and get your elicitation session planned today.
Further reading
- How Business Analysts Use AI to Improve Requirements, Elicitation, and Stakeholder Alignment | IIBA
- 4.1 Prepare for Elicitation
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.