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 →MoSCoW or WSJF: Prioritising When Everything Is a Must
Five requirements all marked Must, put through MoSCoW's own test and then scored with WSJF: what each method decides, and what it cannot see.
Read →Requirements Governance: Who Approves What, and When
Nine items on a status ladder, four approval gates and ten changes I counted in the case, replayed against a change policy. Reviewed is a rung below approved.
Read →Turning Acceptance Criteria Into a UAT Script
A UAT script names who acts, what they do, the result they should see and the acceptance criterion each step proves. One scenario, filled in and blank.
Read →Splitting a User Story Without Losing the Value
One story from a published case, run through nine splitting patterns. Which slices keep the point, which lose it, and what each has to carry.
Read →Discovery Deliverables That Decide Whether Build Starts
One published case read against two public discovery checklists. Which deliverables can stop a build, which only prepare one, and the gap that decides.
Read →Business Analyst or Product Owner: Who Owns the Requirement
One requirement cut into lines, and who can change each. The product owner holds the order, the analyst the wording, the rule owners the numbers.
Read →Writing an Integration Requirement Without Designing the API
An integration requirement names the fact that crosses, the event, the owner and the failure. Eight crossings in one case, and the design words to strike.
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.