Communicating what to build.
WHAT REQUIREMENTS SHOULD CONVEY
The problem Who has it What the outcome should be How you will know it worked What is out of scope
WHAT THEY SHOULD NOT DO
Specify implementation, unless it genuinely matters.
WHY
The people building it usually know better how.
WHAT A USEFUL FORMAT IS
A description of the user, their goal and the benefit.
WHAT ACCEPTANCE CRITERIA DO
State observably what must be true for it to be complete.
WHY THEY MATTER
They prevent disputes about whether it is finished.
WHAT GOOD CRITERIA LOOK LIKE
Specific, testable statements.
WHAT POOR ONES LOOK LIKE
It should be fast It should be easy to use
WHY THEY FAIL
They cannot be verified.
WHAT TO INCLUDE ABOUT EDGE CASES
What happens when things go wrong What happens with no data What happens with very large amounts What happens when the user lacks permission
WHY EDGE CASES MATTER
They are where most defects and most rework originate.
WHAT TO DISCUSS RATHER THAN WRITE
Anything complex.
WHY
Written requirements are a record of a conversation, not a substitute for it.
WHAT TO KEEP SHORT
Everything.
WHY
Long specifications are skimmed, and the important part is missed.
WHAT TO ATTACH
Sketches, where they help.
