Requirements you can test

“The system should handle stock accurately” is the kind of line that survives every review meeting, because there is nothing in it to disagree with. It is also impossible to test. When the system goes live and the counts are still wrong, both sides can point at that sentence and be right.

A requirement that cannot fail cannot be signed off either. What gets signed off instead is a demo — a well-rehearsed path through the software, on data chosen by the person demonstrating it.

The fix is to write requirements as conditions, actions and consequences. Given a sale is completed at the till, when the order is closed, then stock for that SKU falls by the quantity sold.

It reads like a test because it is one. Anyone can run it: pick a product, sell it, look at the stock figure. Nobody needs to understand the configuration to know whether it passed.

The format also exposes disagreement early, while it is still cheap. Writing the “then” forces someone to say what the number should actually be — and that is often the first time two departments discover they were describing different processes.

When criteria exist, user acceptance testing stops being a meeting and becomes a script the client runs themselves. They test against the sentences they agreed to, in their own words, on their own data.

That shifts the decision. Go-live is no longer something a consultant declares; it is something the business confirms, one criterion at a time.

Criteria written after configuration are not criteria — they are a description of whatever was built. The sequence matters more than the format.

The other failure is volume. A hundred criteria nobody reads is worse than fifteen that cover the paths the business actually runs every day, plus the handful of awkward cases: the refund, the split order, the thing that breaks on Fridays.