If you are about to plan your requirements elicitation approach and you are not sure which techniques to use, start here. The choice of elicitation techniques shapes everything that follows: the quality of your requirements, the time you spend in sessions, and the credibility you build with stakeholders. Getting it wrong costs more than most project managers want to admit. Getting it right does not require using every technique in the BABOK. It requires using the right ones for the context you are actually in.
In my experience, the mistake most early-career BAs make is treating elicitation as a single event rather than a planned sequence of activities. Requirements are almost never sitting in one place waiting to be collected. They are distributed across people’s heads, buried in outdated documents, embedded in the way a team currently works, and sometimes actively contested between stakeholders who have conflicting priorities. Your job is to surface them systematically. If you are still building out your overall approach to a project, the Business Analysis Plan Template is a useful place to anchor your elicitation planning before you get into technique selection.
Before You Choose a Technique, Analyse Your Stakeholders
I never select an elicitation technique without first doing some form of stakeholder analysis. The mix of people you are working with, their availability, their level of technical understanding, and their relationships with each other will have a direct bearing on what will work. A requirements workshop is a powerful technique. It is also a disaster waiting to happen if you have a dominant head of department who will talk over everyone else, or two business units that have been in conflict for the past eighteen months.
For each stakeholder, I document at minimum:
- Importance to the elicitation effort. Some stakeholders hold the critical requirements in their heads. Others are good to have in the room but not essential to every session.
- Impact of the project on their role. People whose daily work is being significantly changed will engage differently from those on the periphery. Expect more challenge, more detail, and sometimes more resistance from the former.
- Influence over the project outcome. A stakeholder who cannot sign off requirements but can quietly kill an initiative needs to be managed carefully, regardless of where they sit on the org chart.
- Preferred engagement style. Some people think well in group discussions. Others need one-on-one time to open up. Forcing an introvert into a brainstorming room of twelve people is not elicitation, it is performance anxiety.
- Potential blockers or sensitivities. I treat this as a confidential section of any stakeholder analysis. There are always things that the project needs to know and that should not be in a shared document.
A structured stakeholder analysis template will help you work through these dimensions consistently across a large project team.
The Nine Core Elicitation Techniques
The BABOK identifies nine main elicitation techniques. Below is a practical comparison of all nine, covering what each one is best suited for and where it falls short.
| Technique | Best used when | Main limitation |
|---|---|---|
| Brainstorming | You need a wide range of ideas quickly on a specific topic | Depends heavily on facilitator skill and participants thinking beyond the obvious |
| Document Analysis | You need background before running sessions, or a stakeholder is unavailable | Documents are often out of date and reflect the as-is, not the to-be |
| Focus Groups | You want attitudes and reactions to an already-refined idea or prototype | A small group may not represent the full user population |
| Interface Analysis | The project involves IT systems and you need to understand integration points | Does not capture stakeholder perspectives or business process requirements |
| Interviews | You need to go deep with a specific stakeholder or subject matter expert | Time-intensive and outcome quality varies with interviewer skill |
| Observation | You need to understand how work actually happens, not how people describe it | Only covers existing processes; may disrupt the team being observed |
| Prototyping | Stakeholders struggle to articulate requirements without something to react to | Can be expensive and may create unrealistic expectations for the final product |
| Requirements Workshops | You need to scope, analyse, and prioritise requirements across multiple stakeholders | Scheduling is hard; dominant participants can skew outcomes |
| Survey / Questionnaire | You have many geographically dispersed stakeholders and need quantitative input | No opportunity for follow-up; open questions can be difficult to analyse |
How Techniques Work in Combination
No technique works in isolation. In practice, I almost always use document analysis first, then interviews or workshops, then some form of validation. The sequence matters. If you walk into a workshop without having done your document analysis, you spend the first hour catching up on context that you should already have. If you run interviews before a workshop, your workshop questions are sharper and your stakeholders feel heard before being put in a room together.
Brainstorming often sits inside a workshop rather than standing alone. Prototyping works well as a trigger for a focus group. Observation gives you something concrete to bring into an interview. Surveys are most useful either at the very start to prioritise where to focus, or at the end to validate that what you have captured reflects the broader population’s views.
The question to ask yourself is not “which technique should I use?” but “what do I need to know next, and what is the most efficient and appropriate way to find it out?”
A Worked Example: When the Plan Had to Change
On Project X, a case management system replacement for a mid-sized public sector organisation, I planned a standard approach: document analysis to understand the current system, followed by a series of interviews with team leaders, then two full-day requirements workshops to synthesise and prioritise. It was a reasonable plan and one I had run successfully in similar contexts before.
The problem appeared about three weeks in. The operational team leader, who I had identified as the most important stakeholder in the elicitation, flatly refused to participate in the workshops. Her concern was that the project had been presented to her team as a foregone conclusion, and she did not want to be seen to be endorsing a direction she had not agreed to. She was not blocking the project out of obstruction. She had a legitimate grievance about how the project had been communicated to her team, and she was protecting her people from being put in a position of appearing to endorse a decision that had already been made above them.
I had to go back to the project sponsor and explain that the workshop approach was not going to work as planned, and that we risked producing requirements that did not reflect operational reality if we proceeded without her. The sponsor’s instinct was to escalate. I pushed back on that because escalating over the head of a senior operational manager in a public sector environment is rarely the right move, and it would have poisoned the well for the rest of the project.
Instead, I switched to a series of structured one-on-one interviews with the team leader and three of her senior staff, conducted over two weeks. I also ran passive observation sessions where I sat alongside two case workers for a morning each, watching the current process without intervening. What came out of those sessions was materially different from what the existing documentation suggested. There were three informal workarounds built into the daily workflow that the system documentation did not mention, and two of them had requirements implications that would have been missed entirely if we had proceeded with workshops based on the existing documentation alone.
The workshops did eventually happen, but they ran four weeks later than planned and with a revised agenda that incorporated what I had learned through the interviews and observation. The team leader participated in the final workshop. The requirements that came out of that process were far more grounded in operational reality than they would have been if I had stuck rigidly to the original plan.
That project reinforced something I have believed for a long time: the technique you planned for is not always the technique you need. For more on the kinds of questions that keep sessions on track regardless of which technique you are using, see Requirements Elicitation Questions for Business Analysts.
Practical Notes on the Techniques Most BAs Use Most Often
In my own practice over the years, I have returned to the same core combination most often: document analysis, interviews, requirements workshops, brainstorming within those workshops, and interface analysis on technology projects. The other techniques appear when the context calls for them, but these five do the heavy lifting in most environments I have worked in.
A few things worth knowing if you are developing your technique in any of these areas:
- In interviews, the follow-up question is your most important tool. The first answer a stakeholder gives you is rarely the complete picture. Probe with “can you walk me through what that looks like in practice?” and “what happens when that does not work as expected?” and you will get a significantly richer set of requirements.
- In workshops, preparation is what separates a productive session from a long meeting. I always do my document analysis and at least one or two warm-up interviews before running a workshop. Walking in with a draft process model or a set of draft requirements to validate is far more effective than starting from a blank whiteboard.
- In document analysis, treat everything as provisional. Process maps, system documentation, and policy documents often reflect how things were supposed to work, not how they do work. Always validate against stakeholder experience.
- In interface analysis, a context diagram is the fastest way to get everyone aligned. Drawing the system boundaries, the data flows, and the external entities in a single diagram gives you and your stakeholders a shared frame of reference that written descriptions rarely provide.
- In surveys, keep them short and focused. The IIBA recommends ten items or fewer. Anything longer sees completion rates drop and response quality deteriorate. Use surveys to validate, not to discover.
If you are early in your BA career and still building confidence in facilitation, the article on Business Analyst Facilitation Skills covers the specific behaviours that make the difference in live sessions.
Planning Your Elicitation Schedule
Once you have selected your techniques and understood your stakeholders, get time in diaries as early as possible. This sounds obvious, but it is consistently the thing that derails elicitation timelines. Subject matter experts are busy. Senior stakeholders are harder to pin down than their PAs would like you to believe. If you need four hours with a particular person over the course of two sessions, book those sessions before you finalise your plan, not after.
Build in buffer for sessions that overrun, for stakeholders who need a second conversation, and for the almost inevitable situation where something you learn in week two changes the questions you planned to ask in week three. Elicitation is not linear, even when you plan it as though it is.
Elicitation is the part of business analysis where the quality of your thinking shows up most directly in the quality of your outputs. The technique you choose matters less than your preparation, your willingness to adapt when the plan meets reality, and your ability to build enough trust with stakeholders that they tell you what is actually going on rather than what they think you want to hear. That last part is the hardest to learn and the most valuable thing you will develop over a career in this work.
Frequently asked questions
What are the main elicitation techniques used in business analysis?
The BABOK identifies nine core elicitation techniques: brainstorming, document analysis, focus groups, interface analysis, interviews, observation, prototyping, requirements workshops, and surveys or questionnaires. In practice, most BAs rely most heavily on document analysis, interviews, and requirements workshops, supplemented by others depending on the project context. No single technique is sufficient on its own for a complex requirements project.
Which elicitation technique is most effective for gathering requirements?
There is no single most effective technique because the right choice depends on your stakeholders, the nature of the project, and what you already know going in. Interviews go deep with individuals, workshops are efficient for multi-stakeholder alignment, and document analysis provides essential context before any live session. Most experienced BAs use a planned combination rather than relying on one method.
How do I choose the right elicitation technique for my project?
Start by understanding your stakeholders, the complexity of the requirements, and any constraints around time and access. If stakeholders are geographically dispersed, surveys or interviews may be more practical than workshops. If requirements involve existing IT systems, interface analysis and observation become important early steps. Matching the technique to the context is more important than following a fixed formula.
Can I use multiple elicitation techniques on the same project?
Yes, and in most projects you should. Combining techniques produces better requirements because each method surfaces different types of information. A common and effective sequence is document analysis first, then interviews, then a workshop to synthesise and prioritise, with observation used to validate what stakeholders have described. The sequence matters as much as the techniques themselves.
What is the difference between brainstorming and a requirements workshop?
Brainstorming focuses on generating a high volume of ideas on a specific question without filtering or evaluating them during the session. A requirements workshop is a more structured event that may include brainstorming as one activity within it, alongside scoping, analysis, and prioritisation. In practice, brainstorming almost always works better as part of a workshop than as a standalone session.
Try Ash, Your Virtual BA
If you are planning your elicitation approach right now and not sure where to start with your questions, Ash can walk you through a structured requirements questioning process built around real BA practice. Rather than staring at a blank interview guide or a workshop agenda that feels too generic, you can use Ash to generate targeted elicitation questions based on your specific project context, stakeholder profile, and the requirements you are trying to uncover. It is the kind of structured prompting that usually takes years of practice to develop instinctively. Try Ash Virtual BA and see how quickly your elicitation planning comes together.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.