Writing requirements for systems that get argued with

Most requirements describe what a system should do. In civil enforcement, that is not enough. The system also has to be able to explain, months later, why it did it — to somebody who disagrees.

The appeal is part of the workflow

When we worked on the Vehicle Management System, the thing that reshaped my approach was realising that a notice is not the end of a process. It is the start of one. Notices get appealed. Officers get challenged. A record that says violation: yes is worthless if it cannot also say which rule was applied, what the input was, and who reviewed it.

So we stopped writing acceptance criteria that ended at the outcome. Every rule got a second criterion: given this decision, can a reviewer reconstruct how it was reached from the record alone?

Rules belong to the client, not the codebase

Parking conditions differ by site. Grace periods differ by shift. Leave entitlements differ by grade. The instinct is to encode the first version you are told about, and the consequence is a change request every time policy moves.

The better question during discovery is not "what is the rule?" but "who changes this rule, and how often?" If the answer is anyone other than an engineer, it belongs in configuration. That one question has saved more delivery time than any process I have introduced.

Ask who changes the rule, not just what the rule is. The answer tells you where it belongs.

Override, never overwrite

Every operational system needs a way for a human to disagree with it — to excuse a late arrival, reverse an automatic absence, correct a record entered in error. The failure mode is letting that override erase the original.

Keep both. The system's calculation, the human's decision, the reason and the reviewer. It costs almost nothing at write time and it is the only thing that makes a difficult conversation fair — and provable.