What elicitation is
Elicitation is not asking questions. Asking questions is part of it, but the word comes from the Latin elicere — to draw out — and that distinction is significant. People often cannot tell you what they need because they do not have it in conscious, articulable form. They know what frustrates them. They know what takes too long. They know what they have to work around. The BA's job is to draw that knowledge out, give it structure, and reflect it back in a form that can be acted on.
By the end of this section- Explain why BABOK v3 renamed the knowledge area to "Elicitation and Collaboration".
- Describe the distinction between what stakeholders say they want and what they need.
From elicitation to collaboration
BABOK v2 called this knowledge area simply "Elicitation." Version 3 renamed it "Elicitation and Collaboration." That change reflects a matured understanding of how good requirements work actually functions. Requirements that stakeholders have actively participated in building are requirements they will defend. Requirements that were extracted from them and presented back as a document are requirements they will contest when they see them implemented.
The question behind the question
What people say they want is rarely the same as what they need. A sales director who says "we need better pipeline visibility" may actually need a way to have a credible conversation with the board each month without spending three days preparing. The pipeline dashboard is one possible solution to that need — but it is not the only one, and it may not be the right one. The elicitation technique that surfaces the real need is not the one that asks "what do you want?" but the one that asks "what would be different if you had it?"
The 9 BABOK elicitation techniques
BABOK v3 defines nine elicitation techniques. They are not ranked by importance — they serve different purposes and produce different kinds of information. A competent BA selects and combines techniques based on the question they are trying to answer, the stakeholders available, and the time and access they have.
1. Brainstorming
Generating ideas in a group, typically with a "no criticism during generation" rule to prevent premature convergence. Useful for identifying options, surfacing problems, and generating solution candidates.
Works well when the goal is breadth rather than depth. Tends to be dominated by the most vocal participants unless the facilitator actively manages contributions. Better used to open a conversation than to close one.
2. Document Analysis
Reviewing existing artefacts — reports, process documentation, system specifications, org charts, policy documents, previous requirements — to understand the current state before speaking to anyone.
Document analysis is often underused because it is less visible than interviews and workshops. Done well, it means the BA arrives at elicitation sessions already knowing what is in the documents and asking about the gaps, contradictions, and things that are not written down.
3. Focus Groups
A moderated group discussion with a defined set of participants, narrower in scope than a requirements workshop. Focus groups are useful for exploring attitudes, perceptions, and reactions rather than for agreeing requirements.
The risk is groupthink: participants moderate their views in the presence of others, particularly if there is a seniority gradient in the room. The facilitator's job is to create conditions where honest responses are possible.
4. Interface Analysis
Examining system boundaries and data flows — what goes in, what comes out, what passes between systems, what format it takes. Particularly valuable for technology change programmes where integration is a key risk.
Interface analysis is often done too late, when the build has already made assumptions about interfaces that turn out to be wrong. Start it during requirements, not during technical design.
5. Interviews
One-to-one or small-group conversations with stakeholders. Structured interviews use a fixed question set — useful for consistency across multiple interviewees. Unstructured interviews follow the conversation — useful when you do not yet know what you do not know.
Most effective BA interviews are semi-structured: a prepared set of questions used as a scaffold, with the discipline to follow unexpected threads when they appear. An interview where the BA does more than 30% of the talking has gone wrong.
6. Observation
Watching people do their actual work, either actively (participating alongside them) or passively (shadowing without intervening). Observation is the technique that reveals what documents miss and what people forget to mention because it has become too familiar to notice.
People describe their work as they believe it works or as they think it should work. Observation shows how it actually works. The gap between the two is frequently where the most important requirements live.
7. Prototyping
Creating a tangible artefact — a wireframe, a mock report, a process sketch, even a hand-drawn screen — to prompt concrete feedback. The same stakeholder who says "yes, that sounds right" to a verbal description will immediately identify problems when they see a prototype.
Even a rough sketch produces qualitatively different responses than a written description. Prototyping is not about getting the design right — it is about surfacing requirements that words alone cannot uncover.
8. Requirements Workshop (JAD)
Joint Application Development sessions bring all relevant stakeholders into the same room to elicit, discuss, and agree requirements collaboratively. The requirements workshop is the flagship BA technique — when it works well, it compresses weeks of back-and-forth into a single structured day.
The key success factors: the right people in the room (decision-makers, not just representatives), a clear question to answer, a skilled facilitator who is not the BA, and a scribe who captures decisions in real time. The BA's role is to guide the conversation and ensure requirements are precisely stated, not to present a pre-formed view.
9. Survey / Questionnaire
Collecting information at scale through structured questions, typically when the stakeholder population is too large for interviews or when quantitative data is needed to complement qualitative findings.
Surveys scale breadth but lose depth. They cannot follow an unexpected thread. They are only as good as the questions asked — which means they require prior elicitation work to know what to ask about. Used well, surveys validate hypotheses generated by other techniques. Used poorly, they generate noise.
Document analysis first (to know what exists). Interviews next (to find the gaps and contradictions). Observation where access allows (to see what people don't say). Workshop to converge (to agree, not just to gather). Survey to validate at scale if needed. This sequence is not mandatory — it is a starting point that works in most contexts.
Designing a requirements workshop
A poorly designed requirements workshop is one of the most expensive things an organisation can do: the wrong people, no clear question, no facilitation, and two hours of discussion that produces a list of things to discuss further. A well-designed workshop is one of the most effective: the right people, a clear question, skilled facilitation, and decisions made in real time.
Start with the question
The most important thing you determine before designing a workshop is the question you need the room to answer. Not "gather requirements" — that is an activity, not a question. A question looks like: "What are the top five things that prevent our sales team from accurately forecasting a deal within 48 hours of it moving to negotiation stage?" That question tells you who needs to be in the room, what preparation is needed, and how you will know when you have a useful output.
Roles in the room
A well-run requirements workshop has four distinct roles. The BA may hold one of them but should not hold more than one.
Facilitator
Manages the process, keeps time, ensures all voices are heard, and prevents the conversation from being dominated or derailed. Ideally someone who is not the BA and has no stake in the outcome. Their job is the quality of the conversation, not the content.
Scribe
Captures decisions, requirements, and action points in real time, visible to the room. Not note-taking for later — live capture that participants can correct as the session proceeds. The output is a record of what was agreed, not a summary of what was said.
SME sponsor
A senior stakeholder with authority to make decisions and resolve conflicts on the spot. Without this person in the room, the workshop produces candidate requirements rather than agreed requirements. Everything goes back for sign-off, and the value of bringing the group together is lost.
Subject matter experts
The people who do the work. They know the current state in detail and can identify what would and would not work. Typically 3–8 people — enough for diverse perspectives, few enough for a coherent conversation.
The 90-minute structure
For a focused requirements session, 90 minutes is the optimal unit. It is long enough to get to depth and short enough to maintain concentration. Here is a structure that works:
Context — 10 minutes
The BA frames the question, confirms who is in the room and why, and establishes the ground rules. The goal: everyone starts from the same place and understands what a good output looks like.
Current state — 25 minutes
What happens now: the process, the pain points, the workarounds, the things that work and the things that do not. The BA listens more than they speak. The scribe captures everything.
Pain points and root causes — 20 minutes
Which of the current state problems are genuinely painful, and why do they exist? This is where the real requirements begin to emerge. Prioritisation happens here — not every pain point is worth solving.
Future state — 25 minutes
What would the process look like if the agreed pain points were addressed? The BA steers towards requirements (what it needs to achieve) rather than solutions (how it should work) — though solution ideas that emerge are captured as candidate approaches, not requirements.
Next steps — 10 minutes
What has been agreed? What needs further investigation? Who owns each next action? The scribe reads back the captured decisions. The SME sponsor confirms or corrects them. Everyone leaves knowing what happens next.
Think about a workshop or meeting you have run or attended that was meant to gather input for a change. Which of the four roles was missing? What did that cost the session?
The five-pass engagement template
The five-pass template is a structured approach to organisation understanding engagements — the sequence of activities that takes a BA from initial scope to a prioritised, validated set of findings. Each pass builds on the previous one and uses the elicitation techniques most appropriate to the information needed at that stage.
Pass 1 — Strategy and context
Techniques: Document analysis, executive interviews.
Output: Stakeholder map, strategy summary, agreed scope.
Before anything else, understand what the organisation is trying to achieve and why this engagement exists. Read everything that is available: strategy documents, annual reports, previous project outputs, org charts. Then interview the most senior stakeholders — not to gather requirements, but to understand intent and establish the scope of the analysis. The output is a one-page strategy summary and a stakeholder map that every subsequent pass references.
Pass 2 — Capabilities and value streams
Techniques: Leadership workshop.
Output: Capability map L1–L2, top 5–10 value streams.
Run a half-day workshop with leadership to build the L1 and L2 capability map and identify the primary value streams. This is often the most politically sensitive session — different leaders have different views of what the organisation does and how it is structured. The BA's job is to facilitate convergence, not to impose a framework. The resulting capability map becomes the spine for all subsequent analysis.
Pass 3 — Work and tasks
Techniques: Observation, interviews, document analysis.
Output: Process maps (BPMN), decision points, service blueprints.
Go to where the work happens. Observe people doing their jobs. Interview frontline practitioners, not just managers. Review the actual documents people work with — not the policy documents that describe how they should work, but the spreadsheets and email chains that reveal how they actually work. Map the L3 processes for the capabilities and value streams that matter most. Document the decision points, the data inputs and outputs, the handoffs, and the workarounds.
Pass 4 — Skills, tasks, and AI suitability
Techniques: Structured analysis against the process maps produced in Pass 3.
Output: Roles mapped to tasks, tasks mapped to AI-suitability scores.
Using the process maps from Pass 3, identify the discrete tasks within each process and map them to the roles that perform them. Assess each task against AI-suitability criteria: volume and frequency, structure and predictability, quality of available data, consequence of error, and regulatory or ethical constraints. The output is a scored, prioritised view of where AI-enabled automation or augmentation is viable and where it is not.
Pass 5 — Validation and prioritisation
Techniques: Workshop with mixed stakeholder group.
Output: Prioritised opportunity list, agreed next actions.
Bring the findings from Passes 1–4 back to a cross-functional group for validation and prioritisation. The BA presents; the stakeholders challenge, correct, and prioritise. Nothing is final until this session. The output is a prioritised opportunity list — the agreed set of changes or investigations that represent the best return on effort — with named owners and next steps.
The five passes are a default sequence, not a rigid process. For a smaller engagement, Passes 2 and 3 might collapse into a single workshop. For a complex programme, Pass 3 might run across multiple teams over several weeks. The template provides a starting point and a checklist — it does not replace judgement about what the engagement actually needs.
Unit review
Two questions and a reflection to close the unit.
Which BABOK elicitation technique is most useful when there is reason to believe what is documented does not reflect what actually happens?
In the five-pass engagement template, what is the primary output of Pass 2?
For the last piece of work you scoped or were involved in scoping: which of the nine BABOK elicitation techniques did you use, deliberately or otherwise? Which ones were missing? What would each missing technique have surfaced that you did not find — and when did that gap become visible?
End of Course 03
You have completed the Organisation Understanding series. You should now be able to describe the BA role and its boundaries, apply strategy analysis and business architecture frameworks to a real engagement, and select and sequence elicitation techniques to draw out what stakeholders know but have not yet said. The next step is practice — take the five-pass template and apply it to an organisation you know.