Collection
Turn ambiguous work into requirements that can be checked
Separate need from implementation, make conditions measurable, expose assumptions and interfaces, define acceptance evidence and prototype uncertainty before it hardens into rework.
10 elements · Explore in any order.
2 checklists · 1 concept · 1 heuristic · 4 protocols · 1 question · 1 template
10 elements
Write the need before naming the implementation
A solution written too early can hide the requirement it was supposed to satisfy.
Read the idea HeuristicGive each requirement one behavior to prove
One sentence can hide three different definitions of done.
Read the idea ProtocolReplace quality adjectives with observable conditions
An adjective cannot fail a test until the team agrees what it means.
Read the idea ProtocolWrite acceptance evidence before implementation starts
Late acceptance criteria turn testing into negotiation.
Read the idea TemplateTurn an assumption into a named temporary requirement state
An unlabeled assumption quietly becomes a permanent fact.
Read the idea ChecklistSpecify the interface where responsibility changes hands
Many ambiguous requirements live in the space between two owners.
Read the idea ChecklistSpecify what happens when the happy path cannot complete
If failure behavior is unspecified, the implementation will invent it.
Read the idea QuestionTrace every costly requirement back to the need it protects
Traceability is a reason chain, not a spreadsheet decoration.
Read the idea ProtocolChoose the verification method while the requirement is still editable
A requirement that cannot be verified cheaply enough may be badly shaped for the project.
Read the idea ConceptPrototype the uncertain part instead of specifying it by imagination
Some ambiguity should be tested, not polished into a longer specification.
Read the idea