You're gathering requirements for a new claims-processing system from customer support, compliance, and engineering leads, and each group hands you a different, sometimes contradictory, list of needs. What elicitation techniques would you use, and how do you resolve the conflicts before they reach the architecture?
answer
- interviews for depth
- workshops/JAD for conflicts live
- shadowing catches tacit knowledge
- ask why, not just what
- document decisions so they don't get relitigated
basics
~20 sTalk to each group separately first (interviews, workshops) to understand their real needs, then bring the conflicting groups together with a shared list of options and trade-offs so they negotiate and agree, usually prioritizing by business impact, instead of the architect silently picking a side.
solid answer
~50 sTechniques used: one-on-one interviews for depth, facilitated workshops or JAD sessions for cross-functional alignment, document and process analysis (existing SOPs, tickets, audit reports) for tacit requirements nobody says out loud, observation or shadowing for workflows people can't fully articulate, and surveys for scale when there are too many stakeholders to interview individually. To resolve conflicts: capture every requirement with its source and rationale (why compliance wants it, why support wants it), classify by MoSCoW or a similar priority scheme against business goals rather than politics, surface direct conflicts explicitly in a joint session with a neutral facilitator, and get a documented, sponsor-approved decision so it isn't silently re-litigated later mid-build. The architect's job is translating 'I want X' into 'why do you need X,' which often reveals two stakeholders actually want the same underlying outcome via different mechanisms.
go deeper
Can conduct a structured interview using a prepared question list and accurately write down what a stakeholder says.
Recognizes when a stated requirement is really a proposed solution, asks 'why' to get to the underlying need, and can run a small workshop with guidance.
Independently designs an elicitation plan mixing techniques by stakeholder type, facilitates conflict-resolution sessions, and gets conflicting stakeholders to a documented, agreed decision without executive escalation.
Sets the elicitation approach and governance (decision logs, sign-off process) for a whole program, mediates conflicts that cross organizational or vendor boundaries, and recognizes when a conflict is really a signal that the business hasn't agreed on strategy yet.
## The techniques and the gap each one closes Stakeholder elicitation is the process of extracting the real requirements that live in people's heads, workflows, and institutional habits, as opposed to whatever they happen to write down when asked. The mechanism has several concrete techniques, each suited to a different kind of gap. - **One-on-one interviews** are best for depth: a compliance lead will say more candidly, one-on-one, about a regulatory gap they're worried about than they will in a room with engineering present. - **Facilitated workshops** (sometimes called JAD, Joint Application Design, sessions) are best for surfacing conflicts and getting cross-functional alignment in real time, because disagreements that would otherwise surface late, one email at a time, get argued out in front of everyone with a shared artifact (a whiteboard, a draft use-case list) as the anchor. - **Document and process analysis**, reading existing SOPs, support ticket categories, audit findings, incident postmortems, recovers tacit requirements nobody thinks to state out loud because 'that's just how we've always done it.' - **Observation or shadowing** catches requirements that even the people doing the work can't fully articulate, because much of real workflow is muscle memory. - **Surveys** trade depth for reach when there are dozens or hundreds of stakeholders and interviewing each individually isn't practical. ## Why the apparatus exists This apparatus exists because stakeholders are unreliable narrators of their own needs, not out of malice but because everyone reasons from their own local optimum. - **Customer support** wants a feature that reduces call volume. - **Compliance** wants a feature that produces an audit trail. - **Engineering** wants a design that's maintainable and doesn't blow up the delivery timeline. Each of these is a legitimate constraint on the system, but none of them, alone, is 'the requirements.' The elicitation process's real output isn't a list of what each group asked for - it's a map of the underlying business goals each ask is trying to serve, because two groups asking for apparently incompatible things (support wants a one-click refund button; compliance wants every refund to require a documented reason and manager sign-off) are often solvable with a single design (a one-click button that captures a mandatory reason code and auto-routes anything above a threshold for approval) once you understand the goal behind each ask rather than the literal ask. ## Depth versus coverage versus speed The trade-off in elicitation technique choice is depth versus coverage versus speed. - **Interviews and shadowing** produce high-fidelity, contextual requirements but don't scale past a handful of stakeholders and take real calendar time to schedule. - **Workshops** scale better and resolve conflicts faster because disagreement surfaces live instead of asynchronously across weeks of email, but they favor whoever is more assertive in the room, and quieter stakeholders (often the ones closest to the actual day-to-day pain, like frontline support agents rather than their managers) can get steamrolled unless the facilitator actively pulls them in. - **Document analysis** is fast and doesn't consume anyone's calendar time, but it only recovers what's already been written down - it's blind to anything tacit or recently changed. A competent requirements analyst mixes techniques deliberately: 1. interviews to build initial understanding and trust, 2. document analysis to cross-check what's said against what actually happens, 3. then a workshop to force the conflicts into the open once you already understand each side well enough to mediate productively. ## What skipping it looks like The failure mode when this process is skipped or done badly is entirely predictable and shows up late: a system gets built to the literal, unreconciled requirements each group handed over, the conflicts never get resolved, they just get built as separate, half-contradictory code paths, and the system ships something that satisfies no one - support's refund button exists, but compliance's audit trail wasn't wired to it, so it gets flagged in the next audit and has to be retrofitted under time pressure, in production, which is far more expensive and risky than resolving the conflict on a whiteboard before a line of code was written. A subtler version of this failure is 'requirements by loudest voice' - whichever stakeholder has the most organizational power gets their version built, and the quieter, correct concern (often from compliance or a frontline user) surfaces as a costly incident or regulatory finding months later. ## A claims-processing scenario A concrete scenario: a bank building a claims-processing system got: - 'auto-approve small claims under $500' from the business unit chasing speed metrics - 'flag anything above three claims per customer per year for review' from the fraud team - 'log every automated decision with the model version and inputs used' from compliance None of these are contradictory once elicited properly - the actual conflict only would have appeared if 'auto-approve' had been implemented first and the fraud-review and audit-logging requirements bolted on afterward as an afterthought, at which point the architecture (a single synchronous approve/deny call) wouldn't have had a clean place to insert an async fraud-review hold state, forcing a rework instead of an extension.
- A stakeholder gives you a requirement stated as a solution, e.g. 'we need a dropdown that filters by region.' How do you handle that during elicitation?Treat it as a clue, not a requirement - ask what problem the dropdown solves ('why do you need to filter by region?'). The underlying need might be 'reps should only see leads in their territory,' which could be better solved by role-based access rather than a UI filter the user has to remember to apply every time. Recording the solution as the requirement locks in one implementation prematurely and often the wrong one.
- How do you keep quieter but important stakeholders, like frontline support agents, from being drowned out in a workshop dominated by managers?Interview them separately beforehand so their concerns are already documented and can be raised even if they don't speak up in the room, use structured round-robin input during the workshop rather than open floor, and explicitly weight requirements by evidence such as ticket volume or incident data rather than by who argues loudest.
- What artifact do you produce at the end of elicitation to make sure conflicts don't resurface mid-build?A documented, sponsor-approved decision log or requirements baseline that records not just the final requirement but the rationale and the alternatives that were rejected and why, so if someone raises the same objection three sprints later, you can point to when and why it was already decided.
Eliciting requirements from multiple stakeholders is like a doctor taking a history from a patient and their family separately before the diagnosis meeting - each party reports symptoms from their own vantage point, and the diagnosis only becomes clear once you triangulate all the accounts against what's actually observable, not by taking any one account at face value.
saying these in an interview costs you the question
- only interviews the loudest or most senior stakeholder
- records the first requirement heard as final without cross-checking
- never asks 'why' behind a stated requirement
- treats a proposed solution as the requirement itself
- no documented rationale, so conflicts get re-litigated mid-project
- uses one elicitation technique for every situation regardless of stakeholder count or need for depth