Requirements Elicitation

Turn a vague operator ask into requirements that are observable, testable, and confirmed — surfacing every silent assumption as either a stated default or a blocking question before any scope is cut.

When to use

• The ask is goal-shaped but fuzzy ("build X", "make Y better", "add support for Z") and would otherwise go straight to design.
• Stakeholder statements conflict, or the "done" condition is unstated.
• Before scope-decomposition: decomposition of an unelicited ask bakes the wrong goal into every slice.

Inputs

• The operator's stated goal, verbatim, plus any constraints already given (deadline, stack, dependencies, budget).
• Existing context: what already exists, what must not change, prior decisions on record.

Steps

1. Restate the ask as one sentence of observable outcome from the operator's perspective. If you cannot, that gap is your first question — do not paper over it with a plausible guess.
2. Climb the question ladder, one rung per gap: goal (what does success look like; what breaks if this doesn't happen), actors (who uses it, who operates it), scope edge (what is explicitly out), constraints (stack, deadline, dependencies, budget), acceptance (how will you check it's done). Ask 2–3 targeted questions per round, batched — a drip of single questions stalls the task; an interrogation of twenty exhausts the operator.
3. Surface assumptions instead of silently making them. Write each one down marked DEFAULT ("proceeding with this unless corrected") or BLOCKING ("cannot proceed without an answer"). Defaults keep momentum; blockers justify a blocked status. An assumption that never got written down is the one that sinks the build.
4. Convert every requirement to testable form: an observable behavior plus a measurable threshold. Rewrite each quality adjective — fast, robust, clean, simple, secure — into a number or a checkable condition ("p95 under 200ms on the current dataset", "restart resumes without data loss"). An adjective that survives into the requirements is a future dispute.
5. Hunt the requirement classes operators reliably omit: error paths, empty/zero/first-run states, permissions and roles, concurrent use, migration of existing data, rollback, non-functional bounds (performance, cost), and operational reality (who runs it, where it logs, who gets paged).
6. Frame acceptance criteria as checkable outcomes, each naming its verification method — a test, a command, an observation. "Criterion passes when <check> shows <result>" is the shape; a criterion no one can run is a wish.
7. State negative scope item by item: OUT means named exclusions, not silence. Every named exclusion is a scope-creep argument that never has to happen.
8. Play the requirements back for confirmation. A requirement the operator has not confirmed is still an assumption — record sign-off, or record the DEFAULT and move on. If two stakeholder statements genuinely conflict, surface the tradeoff with both options and their costs; never average them into something nobody asked for.

Outputs

• A requirements document: goal (one paragraph, operator's perspective), IN/OUT scope lists, acceptance criteria with verification methods, constraints, done-definition.
• The assumption log: every DEFAULT and every BLOCKING question, with resolutions as they land.

Failure modes

• Interrogation stall — endless clarifying rounds instead of DEFAULT-marked assumptions; elicitation is meant to converge in one to two rounds.
• Solutioning during elicitation — recording "use Postgres" when the requirement was durability; capture the need, leave design to the architect.
• Surviving adjectives — "should be fast" reaching the criteria list untested and unmeasurable.
• Averaged conflicts — merging contradictory stakeholder asks into a middle thing instead of escalating the tradeoff.
• Positive-only scope — nothing named OUT, so every later "obviously that was included" succeeds.
• Phantom confirmation — treating your own restatement as agreed because nobody objected to what nobody read.

Worked example

Ask: "make the dashboard faster." Restated outcome: "the ops dashboard becomes responsive enough that the on-call engineer stops opening raw logs instead." Ladder round one: which page and which percentile ("initial load of the incident view; it's the p95 that hurts"), what threshold counts as fixed ("under 2s on the office connection"), what's out ("don't touch the admin views"). Assumptions logged: DEFAULT — current data volume is representative; BLOCKING — none. Adjective conversion: "faster" → "incident view p95 initial load < 2s at current data volume, measured by the existing synthetic check". Omitted-class sweep adds two requirements the operator confirms: the empty state (no incidents) must not regress, and the fix must not raise infra cost. OUT: admin views, historical-data archive page, any visual redesign. Acceptance: synthetic-check p95 < 2s for seven consecutive days; empty-state render test passes; infra cost delta ≤ 0. Played back; operator confirms; decomposition starts from a goal that is now checkable.

Acceptance

• The goal is restated as an observable outcome and confirmed, or the blocking gap is escalated rather than guessed.
• Every silent assumption is written down as DEFAULT or BLOCKING; no unlogged assumptions.
• No quality adjective survives without a measurable or observable form.
• Every acceptance criterion names its verification method.
• Scope has named exclusions; conflicts were surfaced as tradeoffs, never averaged.