Before you walk into your next stakeholder session, open your requirements discovery checklist. Not a generic list of interview tips, but a structured set of coverage categories tailored to what you actually need to find out on this project, from this person, at this stage of the work. If you do not have that yet, this article will help you build one and use it properly.
The gap between a productive elicitation session and a frustrating one is rarely about methodology. In my experience, it almost always comes down to preparation. Specifically, whether you arrived knowing what categories of information you needed to leave with, and whether your questions were shaped around the person in the room rather than a script you recycled from the last project. The checklist is the tool that enforces that preparation before the session starts, not after.
Why a Checklist Works Better Than a Question List
There is an important distinction between a list of questions and a requirements discovery checklist. A question list is linear. You work through it, tick items off, and risk missing things that fall between the lines. A discovery checklist organises your elicitation around coverage categories, so you know which domains of information you need to address, and you use your questions as the means to get there. The checklist tells you what ground to cover. Your questions are how you cover it.
This matters because good elicitation is a conversation, not an interrogation. If you are mentally working through a list of questions, you are thinking about what to ask next while someone is still talking. If you are working through coverage categories, you can listen properly and trust that you will know when a topic has been adequately addressed versus when it needs more probing.
The Core Categories Your Checklist Should Cover
Over 25 years working across government, utilities, health, and enterprise environments, I have refined my discovery checklist down to a set of categories that applies across almost every project type. The specific questions within each category change every time. The categories themselves almost never do.
- Business context and drivers: Understanding why this project exists right now, what has changed or is about to change, and what problem the organisation is actually trying to solve.
- Strategic alignment: How the project connects to organisational goals, regulatory obligations, or investment priorities that leadership cares about.
- Current state and pain points: What is happening today, what is broken or inefficient, and where people feel the pain most acutely in their day-to-day work.
- Desired outcomes and success criteria: What does good look like when this is done, and how will the organisation know it has been achieved.
- Scope boundaries: What is explicitly in scope, what is explicitly out, and where the boundaries are genuinely unclear and need a decision.
- Functional requirements: What the solution needs to do, including the specific processes, tasks, and capabilities it must support.
- Non-functional requirements: Performance, security, availability, accessibility, and other quality attributes the solution must meet.
- Data and integration: What data is involved, where it comes from, what systems need to connect, and what the data quality and governance constraints are.
- Assumptions and dependencies: What the project is taking for granted, and what external factors or other workstreams it depends on.
- Constraints: Budget, timeline, technology, regulatory, or organisational constraints that limit the solution space.
- Risks and concerns: What stakeholders are worried about, what could go wrong, and what has already gone wrong on similar initiatives in this organisation.
- Stakeholder impact: Who is affected by the change, how significantly, and where resistance or adoption challenges are likely to emerge.
For a deeper look at how these categories translate into specific elicitation questions, the published guide on requirements elicitation questions for business analysts is a useful companion to this checklist.
Matching Your Checklist to the Audience
The most important thing I do before any elicitation session is decide which categories from the checklist apply to this particular stakeholder, and in what depth. Not every person in your stakeholder list can answer every category. Asking them to try wastes their time and yours.
| Stakeholder Type | High-Value Categories | Categories to Avoid or Keep Brief |
|---|---|---|
| Senior manager / executive sponsor | Business drivers, strategic alignment, desired outcomes, constraints, risks | Detailed functional requirements, data field-level specifics |
| Operational team leader | Current state, pain points, functional requirements, stakeholder impact | Strategic alignment, budget constraints, governance |
| IT / technical lead | Integration, non-functional requirements, data, technical constraints | Strategic vision, business driver narrative |
| End user / process worker | Current state, pain points, functional requirements, usability needs | Strategic context, regulatory obligations, budget |
| Compliance / legal | Regulatory constraints, non-functional requirements, assumptions, risks | Detailed functional design, user interface preferences |
I learned this the hard way early in my career. On a utilities billing system replacement at Organisation A, I ran the same structured session plan with the operations director as I did with the billing team supervisors. Within fifteen minutes the director had disengaged completely. She was not there to talk about how invoices were generated line by line. She was there to talk about the regulatory audit risk that had triggered the project in the first place. I missed that entirely in the first session and had to reschedule. The checklist now includes a column I complete before every session: which categories, and at what level of detail, for this person specifically.
A Worked Example: Where Pushback Revealed a Hidden Requirement
On Project X, a case management system replacement for a public sector client, I was three sessions into discovery when I hit a significant point of friction. The head of operations had signed off on the scope document, which clearly stated that historical case data would be migrated from the legacy system to the new platform. During my session with the data team, I went through the data category of my checklist and asked specifically about data volume, data quality, and migration approach. That is when the problem surfaced.
The data manager told me that roughly 40% of historical records were in a format that predated any structured schema. They were effectively free-text entries from a system that had been retired a decade earlier. Migrating them in any meaningful way would require a transformation effort that had not been scoped, budgeted, or resourced. When I raised this with the head of operations, she pushed back firmly. Her position was that the data migration was agreed and it needed to happen. The project manager backed her up, citing the signed scope document.
What my checklist had done was flag the gap. The data and integration category had a prompt specifically about data quality and legacy system constraints. Without that prompt, I might have accepted the scope statement at face value and only discovered the problem during build, at significantly greater cost. I escalated with a one-page options paper: migrate all records and accept the transformation cost, migrate structured records only and archive the rest, or defer the decision pending a data assessment. The client chose the second option. The scope was formally revised. It was not a comfortable conversation, but it was the right one to have in week three rather than week thirteen.
This is exactly the kind of friction that a well-structured scope management approach is designed to surface early, and it starts with asking the right questions in discovery.
How to Use the Checklist in Practice
The checklist is a preparation tool, not a session script. Here is how I use it in the days before a session and during the session itself.
- Pre-session preparation: Review the checklist categories and mark which ones apply to this stakeholder and this session, based on what you already know from prior sessions, documents, or kick-off conversations.
- Gap identification: Look at what has already been covered in earlier sessions and identify which categories still have thin or no coverage. Prioritise those in the upcoming session.
- Question planning: For each category you plan to cover, draft two or three specific questions that are open enough to allow the stakeholder to take the conversation somewhere useful, but focused enough to avoid vague responses. Plan follow-up probes for thin answers, such as asking for a concrete example or what that would look like in practice.
- During the session: Keep the checklist visible but off-camera if remote. Use it as a mental map rather than a document to work through sequentially. When a category has been adequately addressed, note it mentally and move on. When it has not, probe before changing topic.
- Post-session review: Immediately after the session, go through the checklist and mark what was covered, what was partially covered, and what remains open. That becomes the input to your next session plan.
If you are looking for a structured way to document what you find across these categories, the guide on how to document your findings at the start of a business analysis project walks through exactly that process.
When the Checklist Reveals What You Did Not Know to Ask
One of the less obvious benefits of working to a coverage checklist is that it highlights the questions you did not think to ask. If you finish a session and the assumptions and dependencies category has nothing in it, that is not because this project has no assumptions. It is because you did not get there, or the stakeholder did not surface them unprompted. That is a signal to go back.
Incomplete coverage in any category is a requirements gap waiting to become a delivery problem. The checklist does not guarantee complete requirements. Nothing does. But it significantly reduces the chance of walking away from discovery not knowing what you do not know.
The discipline of working to a requirements discovery checklist is what separates elicitation that produces a foundation you can build on from elicitation that produces a document nobody fully trusts. After 25 years I still use one on every project, because the categories are not the interesting part, what they reveal in each new context always is.
Frequently asked questions
What should be on a requirements discovery checklist?
A requirements discovery checklist should cover business context and drivers, strategic alignment, current state and pain points, desired outcomes, scope boundaries, functional requirements, non-functional requirements, data and integration, assumptions, constraints, risks, and stakeholder impact. The specific questions within each category change per project and per stakeholder. The categories themselves provide consistent coverage across almost any project type.
How do I use a requirements discovery checklist in a stakeholder session?
Use it as a preparation tool before the session, not a script during it. Review the categories in advance, mark which apply to this stakeholder, and plan specific questions for each. During the session, keep it as a mental map and probe any category that has not been adequately addressed before moving on.
What is the difference between a requirements checklist and a list of elicitation questions?
A requirements checklist organises your discovery around coverage categories, so you know which domains of information you need to address regardless of how the conversation flows. A question list is linear and risks missing gaps between predetermined items. The checklist tells you what ground to cover; your questions are the means to cover it.
How do I tailor a requirements discovery checklist for different stakeholders?
Before each session, identify which checklist categories this particular stakeholder can meaningfully contribute to and at what level of detail. Senior executives are most valuable on drivers, outcomes, and constraints. Operational staff are most valuable on current state, pain points, and functional needs. Asking the wrong category to the wrong person wastes time and produces thin answers.
When in a project should I be using a requirements discovery checklist?
The checklist is most valuable during the early discovery and elicitation phase, but it remains useful throughout. After each session, review which categories have been adequately covered and which still have gaps. That review becomes the input to planning subsequent sessions and helps you identify when discovery is genuinely complete versus when it just feels complete.
Try Ash, Your Virtual BA
If your requirements discovery checklist still has gaps after your stakeholder sessions, Ash can help you close them systematically. The Ash BRD Writer works through 14 requirement categories with you in a structured sequence, asking targeted questions, probing thin answers, and flagging what is missing before it becomes a problem in delivery. It is the same discipline as a well-built discovery checklist, built directly into the requirements writing process. Try Ash Virtual BA and see how much faster your discovery becomes when the structure is already there.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.