TL;DR Elicitation is archaeology, not shopping — requirements are hidden, unstated, and often contradictory. [1] Use structured interviews and workshops as your backbone (widest surface area, fastest), add observation for tacit process knowledge, and prototype to crystallise fuzzy ideas. [6] [5] Combine ≥3 techniques per project [8] and layer AI tools for transcription and gap detection. Always follow up in writing — requirements confirmed verbally die at sprint planning. [7]
Gathering ≠ Eliciting
“Requirements gathering” implies requirements already exist waiting to be collected. They don’t. [1] Stakeholders know their pain, not the solution — your job is to draw out unstated needs, surface contradictions, and translate business problems into actionable specifications. The BA profession has largely replaced “gathering” with “elicitation” to reflect this active, investigative role. [2]
BABOK Framework: Three Technique Categories
IIBA’s BABOK v3 classifies all elicitation activity into three types [3]:
| Category | What it covers | Typical techniques |
|---|---|---|
| Collaborative | Direct stakeholder interaction; draws on their judgment | Interviews, workshops, brainstorming, focus groups |
| Research | Discovering information from materials, not people | Document analysis, benchmarking, reverse engineering |
| Experimental | Controlled tests to find information that can’t be told | Prototyping, observation / job-shadowing |
Sequence: start with Research (cheapest, no stakeholder time) → Collaborative → Experimental to validate.
Core Techniques Reference
| Technique | Best for | Optimal size | Primary output | Key watchout |
|---|---|---|---|---|
| Structured interview | Deep expertise from a single SME | 1–3 | Detailed use cases | Wandering scope; always prepare a question agenda [6] |
| Requirements workshop | Rapid alignment across multiple stakeholders | 8–12 | Consensus requirements | >12 becomes an audience, not a workshop [5] |
| Observation | Tacit knowledge, undocumented workarounds | 1 analyst | Process maps, gap list | Only schedule during peak load — quiet periods hide real demand [5] |
| Prototyping | Fuzzy functional requirements, UI/UX scope | 2–8 | Confirmed / rejected UX | Use lo-fi wireframes to prevent design debates [5] |
| Survey / questionnaire | Broad validation, large user populations | Unlimited | Quantified patterns | Requires prior domain knowledge to write good questions [4] |
| Document analysis | Existing systems, regulated domains | Solo | Gap list vs. current | Documents describe the past, not current reality [5] |
| Brainstorming | Early problem framing, innovative ideas | 4–10 | Long-list of candidates | Structured facilitation required to prevent groupthink [4] |
| Focus group | UX/CX feedback, diverse user segments | 6–10 | Prioritised themes | Dominant voices skew results; use anonymous voting [4] |
| Interface analysis | System integration, data handoffs | 1–3 (tech) | Data flow + API scope | Requires system access and technical participants [4] |
Structured interviews are the most widely used technique in practice [6]; a state-of-practice study across 12 companies confirmed interviews and workshops as near-universal, with observation underused despite its unique ability to surface tacit process knowledge. [18]
No single technique is sufficient — combine 3–5 per project. [8]
The Elicitation Process
Five stages — each builds on the previous [7]:
- Plan — identify knowledge gaps, select techniques, schedule sessions
- Prepare — domain research, question templates, workshop materials
- Conduct — run sessions; probe for the “why” behind every stated need
- Document — structure findings into user stories, use cases, or BRD sections
- Confirm — circulate to stakeholders; undiscovered gaps always surface here
Plan for multiple iterative rounds. Stakeholders rarely deliver complete requirements in one session, and what they say they want often changes once they see a prototype. [8]
Modern Collaborative Discovery
Three techniques bridge the gap between high-level goals and development-ready stories:
User Story Mapping arranges stories horizontally by user journey and vertically by priority, making release scope visible at a glance. Best for product teams with defined user flows. [11]
EventStorming walks domain experts and developers through the business process using sticky notes (orange = domain events, blue = commands, yellow = actors). Surfaces policies, constraints, and bounded contexts that interviews miss. [13] Attaching EventStorming board photos directly to LLM prompts produced 3× more domain concepts in a prototype than unstructured prose — same model, richer input. [12]
Domain Storytelling has actors narrate domain scenarios using a pictographic language. The resulting artifacts are machine-readable, closing the loop between discovery workshops and AI-assisted code generation. [12]
Use EventStorming for complex domain discovery; User Story Mapping for UX-centric feature planning. They’re complementary. [13]
Common Pitfalls
| Pitfall | Why it bites | Fix |
|---|---|---|
| Single-technique reliance | Interviews miss tacit process knowledge; observation misses strategy | Combine ≥3 techniques per project [8] |
| No pre-session prep | Pleasant conversations but inconsistent coverage | Prepare agenda + question checklist before every interview [5] |
| Surveys as first technique | Can’t write useful questions before establishing baseline understanding | Use surveys for validation only, after interviews/workshops [4] |
| No written follow-up | Verbally confirmed requirements die between sessions | Send summary within 24 hrs; require stakeholder sign-off [7] |
| Ignoring tacit knowledge | Workers use undocumented workarounds that invalidate stated requirements | Schedule observation during peak load periods [9] [10] |
| One-shot elicitation mindset | Stakeholders don’t know what they want until they see what they don’t want | Plan iterative rounds; treat each session as refining a draft [8] |
Requirements defects found at UAT cost many times more to fix than those caught during elicitation; the damage surfaces weeks or months after the conversation where the requirement was missed. [19]
AI Augmentation
AI compresses preparation and post-processing time — it doesn’t replace the elicitation conversation itself.
Pre-session
- ChatGPT or Claude generates a structured interview guide from a domain brief in minutes. [20] 67% of PMs report documentation takes more time than stakeholder meetings — AI addresses that asymmetry. [20]
- The open-source Claude BA skill automates stakeholder analysis, RACI matrices, and acceptance criteria drafting from rough notes. [14]
During session
- Fireflies.ai auto-transcribes calls with speaker labels and creates a searchable archive — requirements stop dying in meeting notes. [15]
- Grain timestamps and clips key moments from user interviews, tagging by theme for pattern analysis across sessions. [15]
Post-session
- aqua creates a structured requirement from 15 seconds of voice input and detects duplicates (~20% of typical backlogs); auto-generates test cases from requirements. [16]
- Notion AI converts raw meeting notes into structured requirement drafts inline. [15]
- Copilot4DevOps checks requirements quality against INCOSE standards inside Azure DevOps, scoring each work item before it enters a sprint. [17]
- Whimsical AI converts requirement text into mind maps, wireframes, and user story diagrams without design skills. [15]
Treat AI output as a junior analyst’s first draft — review every generated requirement for accuracy and completeness before the backlog. [17]
EventStorming + LLMs: the tightest loop
Attaching EventStorming board artifacts directly to LLM prompts — rather than re-describing them in prose — yields the highest fidelity domain transfer. A three-step pipeline (domain story + glossary → EventStorming board → bounded context OpenAPI specs) roughly tripled domain concept coverage at each step, with the same underlying model. [12] LLMs fail at domain work not from lack of capability but from lack of context — collaborative discovery workshops are now the most direct way to provide it.