Diagnose the requirement
Read the product spec and the outcome signal, then decide what the requirement does not settle, ranked by the cost of shipping without an answer.
Requirement risk map
From a silent requirement to a named decision
Every gap names the decision that is missing, not the code that is wrong.
Sibling repository../payments-validation-fixture836a75dShared with course 301. You work from specs/product/payments.md rather than the diff.
Why this stage exists
The defect that survives every check is the one nobody specified. A requirement that says nothing about a behavior produces code that is correct against it.
The fixture spec is silent on whether a second submission with the same idempotency key is a no-op or a second refund. That silence is F8, and it is the one failure class reserved for a person.
What you start from
Work from these inputs only. Anything not on this list is either a later stage’s concern or a decision you do not own.
- Product spec
- specs/product/payments.md, the requirement as written.
- Outcome signal
- Duplicate refunds in the ledger after a client retry, raised by operations rather than by a test.
- Technical spec
- specs/tech/payments.md, which assumes the policy question was already answered.
- Failure classes
- F1 through F8, and which of them a specification can cause.
From a silent requirement to a named decision
One worked pass, so the shape of the work is visible before you do it on your own.
- Read the requirement for behavior it does not settle.
- Separate ambiguity from absence. A vague sentence and a missing sentence fail differently.
- Name the decision each gap needs, and the role that would own it.
- Rank the gaps by the cost of shipping without the answer.
What this turns onA requirement gap is a missing decision, not a missing sentence. More words around an undecided policy produce a longer spec that is equally silent.
Do the work
- Complete the requirement risk map for Round 0.
- Mark each gap as ambiguous, absent or out of scope.
- Find the gap the engineers escalate as F8.
- Do not write the fix yet.
You produce
Requirement risk map
- Behavior
- Ambiguous, absent or out of scope
- Decision required
- Likely owner
- Cost of shipping without it
Challenge your own result
The spec says refunds must be correct. Is that a criterion?
Show how this resolves
No. It names a quality rather than an observable behavior, and nothing can settle it. A criterion states what can be observed and what would show it false.
Ready to continue when
- Every gap names the decision that is missing.
- Each gap has a likely owner who is not you.
What transfersRead any requirement by asking what it refuses to decide.
Source · 05 Organizational handshake