There is a well-cited figure in software project research: fixing a defect found in production costs roughly thirty times more than fixing the same defect found in requirements. The exact multiplier varies by study and context, but the direction is never contested. Requirements defects compound. Every phase downstream builds on what was specified, so a wrong requirement isn't one mistake: it's a foundation that everything above it inherits.
Most projects don't fail because the team couldn't build what was specified. They fail because what was specified wasn't what was needed. That gap almost always opens in elicitation, and it almost always opens quietly. Nobody announces that they misunderstood the stakeholder. The misunderstanding becomes visible weeks or months later, in a UAT session, or in a meeting where someone says the words "that's not what I asked for."
What follows is how I structure elicitation to close that gap before the specification is written.
The five questions I ask before anything else
Before I run any elicitation session, I need to answer five questions about the initiative. Not from the specification. From conversations with the right people, read against the organizational context.
- Who decides? The person who says yes, and the person whose no ends the project, are rarely the same. Knowing both shapes everything: which concerns to surface early, whose language to use in the spec, where to invest relationship time before the review meeting.
- What changes if this exists? This is the business case in one sentence. If nobody can answer it, the initiative doesn't have a reason yet. A system, a process, a report: none of these are ends. They're means. The end is a decision that becomes better, a cost that becomes lower, a risk that becomes visible. Find the end first.
- What does success look like in six months? Not "what does the system do." What does someone observe, in the business, that tells them the initiative worked? This question surfaces the acceptance criterion that lives above the product level, and it's the one most specs never write down.
- What are the constraints I'm not allowed to question? Budget, timeline, technology choice, regulatory boundary. Every project has non-negotiables, and it's better to find them in elicitation than to present a technically excellent option that gets rejected for a reason the stakeholder assumed you already knew.
- What are you explicitly not asking for? Scope is defined as much by what's excluded as by what's included. The out-of-scope list is rarely written down, and when it isn't, every stakeholder fills it with their own assumptions. Agreements that live only in someone's mental model are deferred arguments.
Elicitation techniques and when to use each
Elicitation is not interviewing. Interviewing is one technique. The choice of technique depends on the kind of knowledge you need and where that knowledge lives.
Structured interviews are best for tacit knowledge, opinions, and concerns people won't say in a group. A stakeholder who would never challenge a proposed solution in front of their director will tell you privately that the approach won't work. One-on-one conversations before group sessions surface the real landscape before the political one takes over.
Workshops are best for building shared understanding and surfacing conflicts. The conflict that emerges when two business units articulate their version of the same process in the same room is information. It's also uncomfortable, which is why workshops need a facilitator whose only job is to keep the conversation productive rather than polite.
Observation (job shadowing, process walkthrough) is the technique most often skipped and most often worth doing. People describe their work as they think it works. Watching it reveals the workarounds, the informal steps, the exceptions that happen so frequently nobody thinks of them as exceptions. A workaround that has been running for three years is a requirement, even if nobody wrote it down.
Document analysis gives you the institutional memory that predates every person in the room: existing specifications, process manuals, audit reports, error logs. It also reveals what was decided before and why, which prevents the team from rediscovering the same trade-off and making the opposite choice without knowing it.
Prototyping is best when the stakeholder cannot describe what they want but will recognize it when they see something wrong. A low-fidelity mockup is a requirements elicitation tool. Showing someone a screen and watching where their eyes go and what they say first tells you more about their mental model than two hours of questions.
The mistakes that cost me the most
The most expensive mistake is passive listening. Writing down what the stakeholder said instead of what they meant. A stakeholder says: "I need a dashboard showing all the customer data." That sentence contains at least four ambiguities (which customers, which data, all at once or on demand, for whom), and none of them will resolve themselves by the time the spec is reviewed. Passive listening produces a specification that is internally consistent and entirely wrong.
The second mistake is conflating the solution with the need. A stakeholder who says "I need a report" often means "I need to know X so I can do Y." The report is their proposed solution to that need. Accepting the solution as the requirement forecloses every alternative: the notification that would have been faster, the process change that would have made the report unnecessary, the existing report that already shows the number if you add one column. Requirements at the need level keep options open. Requirements at the solution level close them at the worst possible time.
The third mistake is treating non-functional requirements as secondary. Performance, security, availability, auditability: these rarely appear in the first conversation, because the stakeholder's mental model runs at the feature level. But they're the requirements that most often cause production failures and the requirements that are most expensive to retrofit. Asking explicitly and early is the only way to surface them.
The fourth mistake is single-stakeholder input. Every project has more than one legitimate perspective, and requirements that come from one voice tend to optimize for that voice's priorities at the cost of everyone else's. The operations team has requirements the business owner didn't mention. The end user has constraints the project sponsor didn't anticipate. The compliance team has a list of things the solution isn't allowed to do. Finding all of them before the spec is written is easier than reconciling conflicting requirements after development starts.
A validation checklist
Before I call a requirement set ready for specification, I run through five properties. A requirement that fails any of them isn't done yet.
| Property | The test | Common failure |
|---|---|---|
| Complete | Does this requirement say everything needed to build and test the feature? | Implied constraints that only the author knows |
| Consistent | Does this requirement contradict anything else in the set? | Two requirements optimizing for different stakeholder goals |
| Feasible | Can this be built within the known constraints? | Requirements written without input from the technical team |
| Testable | Can I write an acceptance criterion that would definitively confirm or deny this? | Adverbs: the system shall respond "quickly," data shall be "accurate" |
| Unambiguous | Does this mean exactly one thing to every reader? | Business jargon that means different things to different teams |
The difference between a requirement and a wish
A requirement is a statement of what the system, process, or service must do or must not do, traceable to a business need, testable against an observable outcome, and agreed upon by the stakeholders who have authority over the scope. A wish is everything else.
Wishes appear in every requirements workshop, and they have real value: they reveal priorities, preferences, and future needs worth understanding. The mistake is promoting them to the requirements list before they have a business case, a sponsor, and a test. An undifferentiated mix of requirements and wishes produces a specification nobody can prioritize, because everything is on the same list at the same level of obligation.
Separating them is not dismissing the wish. It's making a clean commitment: this is what we're building, and this is what we've heard and may build later. That distinction is what makes a scope defensible when someone asks, two months into development, why their item isn't included. The answer isn't "it's not on the list." The answer is "it's on the future list, here's why it didn't make the current scope, and here's what it would take to change that."
Requirements engineering is ultimately a discipline of managing decisions: which ones to make now, which ones to defer, and which ones to surface so the right person can make them. The specification is the record of those decisions. Getting elicitation right is how you make sure the record reflects what was actually decided, rather than what one person assumed.