Eliciting from People Who Disagree
Overview
Section titled “Overview”Your tree is only as good as what people told you, and what people tell you is not requirements. It is positions, functions, and occasionally complaints.
Module 1 established the distinction between a stated position and the interest underneath it. This topic is the working technique: how to get from one to the other, how to treat formal blockers and informal vetoes differently, and what to do when two requirements cannot both be satisfied.
Why workshops produce functions
Section titled “Why workshops produce functions”Ask a group what they need and you will get a list of things they would be able to see. That is not evasion — it is how people describe systems. Functions are visible; qualities are invisible until they are violated.
So stop asking for qualities. Ask about failure instead. Nobody can describe an availability requirement from a standing start, and everybody can describe what happens on the day it breaks.
The question ladder
Section titled “The question ladder”Three questions, each converting the previous answer into something more useful:
graph TD P["<b>Position</b><br/>'It has to go live<br/>this quarter'"] --> Q1["<i>What happens<br/>if it doesn't?</i>"] Q1 --> I["<b>Interest</b><br/>'I've already<br/>committed the date<br/>externally'"] I --> Q2["<i>What would make<br/>you switch it off<br/>after launch?</i>"] Q2 --> F["<b>Failure threshold</b><br/>'If customers start<br/>complaining it's wrong'"] F --> Q3["<i>How many, and<br/>how would we know?</i>"] Q3 --> S["<b>Scenario</b><br/>a stimulus, an<br/>environment and a<br/>response measure"] classDef pos fill:#D8D3CB,stroke:#B8B2A8,stroke-width:2px,color:#3F3F3F classDef ask fill:#7C7C7C,stroke:#5E5E5E,stroke-width:2px,color:#ffffff classDef mid fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff classDef out fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff class P pos class Q1,Q2,Q3 ask class I,F mid class S out
Three questions, each one rung. You start with something undesignable and finish with something you can test — and the person you asked now owns the number.
Two further questions produce requirements nothing else will reach:
“What must this never do?” Forbidden behaviour is where constraints hide. People volunteer desired behaviour fluently and forbidden behaviour not at all.
“What happened last time something like this shipped?” A previous failure leaves behind unwritten requirements — conditions the organisation now imposes without ever having documented them. You will not find these in any system; you find them in how people react to your proposal.
Formal blockers and informal vetoes need opposite treatment
Section titled “Formal blockers and informal vetoes need opposite treatment”Both can stop you. The technique differs completely.
Someone with formal blocking authority gives you constraints. Their criteria exist, they are stated, and they are stable. Your job is to get them early, in writing, and convert them into scenarios you can design to. Then never surprise them: a blocker who learns about a design in month six will block it on principle, regardless of merit.
The cost of going early is that you hear “no” early, and lose options you were enjoying. That is the trade you want. A constraint discovered in month one removes options; discovered in month seven, it removes work already done.
Someone with informal power gives you objections, not requirements. They will not hand you a criteria list, because they do not think of themselves as a gatekeeper. What arrives instead is sustained technical scepticism.
The move is to treat each objection as a requirement in disguise, and then to hand it back:
“You think it will degrade quietly, like the last one. What measurement would have caught that, and what number would you want it to hold?”
This does two things. It converts a vague doubt into a response measure, and it makes the sceptic a co-author of the requirement rather than a critic of your design. People rarely veto their own numbers.
Its cost is that you give up control of part of the specification, and sometimes the number you get back is stricter than you would have chosen. Accept it anyway. A strict requirement you can point at beats a lenient one nobody believes in.
Conflict is the deliverable
Section titled “Conflict is the deliverable”Two requirements that cannot both be satisfied are not a failure of elicitation. They are the most valuable thing it produces.
The failure mode is averaging: splitting the difference into something that satisfies neither party, chosen because it offends nobody in the room. An accuracy bar set halfway between what one stakeholder needs and what another will pay for produces a system that is too unreliable to trust and too expensive to justify.
Instead, keep a short conflict register — for each pair: the two requirements, who holds each, which one the architecture serves first, and who decided. The last column is the one that makes it useful. An unresolved conflict with a named decision-maker is a managed risk. An unresolved conflict with nobody’s name on it is an ambush scheduled for month six.
Naming conflicts also protects you. When the trade-off bites later, the question will be “who decided this?” — and a register answers it without anyone needing to reconstruct a meeting from memory.
Feeds the workbook
Section titled “Feeds the workbook”This topic feeds the requirements catalog and the Utility Tree. Two checks from the module rubric land here: at least two requirements genuinely conflict and the conflict is named, and the tree reflects more than one stakeholder’s priorities. If your catalog is internally consistent, you have most likely interviewed only the people who agree with you.
→ That closes Section 1. The machinery works on requirements you can enumerate. Next: specifying behaviour you cannot. — Intent formulation