Requirements That Survive Review
The acceptance criteria piece opens with five checks and points at the twenty-five in the scorecard. These notes go deeper: what to check, how to trace it, how to settle a dispute between two people who are both right, and when a requirement is ready at all.
Start with the pillar
Acceptance Criteria That Survive a Sprint Review
What an acceptance criterion actually is, six weak ones shown as they arrived and as they went out, and the three objections a reviewer raises first.
The notes, in reading order
Non-Functional Requirements Nobody Reads Until Production
What a non-functional requirement is, six of them rewritten from adjective into something that can fail, and who really knows the load figure.
Read →RACI for Requirements Sign-Off: Who Actually Approves
A sign-off matrix on a published returns case: one business rule walked through every role that can approve it, and what to write when nobody can be named.
Read →The Traceability Matrix That Survives a Change Request
What a traceability matrix actually is, one change request walked through it row by row in a quarter of an hour, and the questions it still cannot answer.
Read →Conflicting Requirements Are an Unmade Decision
Conflicting requirements are an unmade business decision. The one-page card I write instead of mediating, filled in on a 40 EUR refund threshold.
Read →Definition of Ready for a Requirement, Not a Ceremony
A definition of ready for requirements: seven conditions a stranger can check from the requirement itself, run backwards over three versions of my own register.
Read →The other two clusters
The Case File · The Document That Gets Read · All field notes
These notes stand on one worked case, and every figure in that case carries a source tag. What the tags mean.