Reference Files
references/elicitation-techniques.md - Lookup table of 15+ elicitation techniques with when to use, participants, output format, and time needed. Read this in Step 2 when selecting techniques and in Step 3 when planning sessions.
Overview
Based on the BABOK Guide v3 (IIBA) - Elicitation & Collaboration knowledge area, which defines 50 standardized techniques across 6 knowledge areas. Also draws on Mastering the Requirements Process by Suzanne & James Robertson for the Volere "trawling" approach - their term for iterative elicitation driven by business events, not document templates. The key insight: elicitation is not a phase you complete; it is a continuous activity that starts with business events and stakeholders, not with a blank requirements template.
Workflow
Step 1: Identify stakeholders and business events
List every person, role, and adjacent system that touches the problem space. Use the BABOK's stakeholder categories: customer, end user, sponsor, domain expert, regulator, implementation team. Then list the business events that trigger the process or system under analysis - Robertson's Business Event List is the elicitation backbone.
Step 2: Select elicitation techniques
Match techniques to stakeholder type and information need (see references/elicitation-techniques.md). Use a mix:
- Interviews for deep individual knowledge
- Workshops for cross-functional alignment and conflict surfacing
- Observation/Apprenticing (Robertson) for tacit knowledge users cannot articulate
- Document Analysis for existing rules, policies, and constraints
- Prototyping for validating understanding with users
Step 3: Plan and schedule sessions
For each session, define:
SESSION: [type - interview / workshop / observation]
STAKEHOLDER(S): [names and roles]
OBJECTIVE: [what you need to learn]
TECHNIQUE: [from reference table]
DURATION: [estimated time]
PREPARATION: [materials, context docs, pre-reads]
Step 4: Conduct elicitation
During sessions:
- Start with open-ended context questions ("Walk me through how you do X today")
- Progress to specific probes ("What happens when Y fails?")
- Capture requirements using Robertson's Volere Snow Card format: requirement number, type, description, rationale, source, fit criterion
- Note assumptions, constraints, and conflicts separately
- Record who said what - source traceability starts here
Step 5: Confirm and validate
After each session:
- Write up findings within 24 hours
- Send back to stakeholders for confirmation (BABOK's "confirm elicitation results")
- Flag conflicts between stakeholders - do not resolve silently
- Identify gaps that need follow-up sessions
Step 6: Organize and classify requirements
Classify using BABOK's hierarchy:
- Business requirements - why the organization needs this
- Stakeholder requirements - what users need to do
- Solution requirements - functional + non-functional
- Transition requirements - what's needed to move from current to future state
Anti-Patterns
1. Template-first elicitation
Bad: Sending a requirements template to stakeholders and asking them to fill it in.
Good: Conduct interviews and workshops first, then organize findings into a structured format.
2. Single-technique reliance
Bad: Only conducting interviews, missing tacit knowledge that observation would reveal.
Good: Use at least 3 techniques per project - interviews for depth, workshops for alignment, observation for reality.
3. Eliciting solutions instead of needs
Bad: "The user wants a dropdown menu." (That's a solution.)
Good: "The user needs to select from a constrained set of valid values." (That's a requirement.)
4. No source traceability
Bad: Requirements listed without noting who requested them or why.
Good: Every requirement links back to a stakeholder, business event, or document source.
5. One-pass elicitation
Bad: Running a single round of interviews and declaring requirements "complete."
Good: Iterative trawling - each round reveals gaps that drive the next round.
Quality Checklist