Software · 6 min
Describe the behaviour the system must produce and the rules it must obey, not the screens. Requirements written as interface descriptions constrain the solution before anyone understands the problem.
How it works
'When an order is cancelled after dispatch, the stock is not returned and finance is notified' is a requirement. 'A cancel button on the order screen' is a design decision wearing a requirement's clothing.
Rounding, time zones, what happens on the boundary, which record wins in a conflict. These are the details that cause rework, and they are almost never in the first draft because everyone assumes their own answer is obvious.
What happens when the external service is unavailable, when the input is malformed, when the same request arrives twice. Most of the cost overrun in software projects lives in cases the requirements did not mention.
Two or three concrete cases with real values are worth several paragraphs of prose, and they double as acceptance tests. Where a rule is complex, a small table of inputs and expected outputs removes the ambiguity entirely.
Explicit exclusions prevent the most common scope disagreement, which is not about what was promised but about what everyone assumed was implied.
Detailed on rules and edge cases, loose on interface. The rules are what cause rework when wrong; the interface is better resolved with a working version than a document.
Enough to start, not all of it. Requirements written before anyone has used a working version are the least reliable input available, which is why increments beat complete specifications.
Describe the behaviour the system must produce and the rules it must obey, not the screens. Requirements written as interface descriptions constrain the solution before anyone understands the problem.
You have read what we think. If you want to know what it means for your case specifically, describe it and we will tell you which parts of how to write software requirements actually apply — and which do not.
