Professional Business Analysts / Writing it down

A requirement that cannot be wrong is not a requirement

If no possible system fails it, it is decoration.

Requirements documents are full of statements that nothing could violate. The system shall be user friendly. The process shall be efficient. Reporting shall be timely. Each is agreeable, each survives every review, and none of them can be tested, which means none of them constrains a decision. They occupy space and provide reassurance and do no work.

The test is simple and worth applying mechanically: describe a system that satisfies everything else and fails this one. If you cannot construct that description, the statement is not doing anything. Timely becomes within one working day of the transaction. User friendly becomes completable by a new starter without reference to a manual, which is at least observable.

This is not pedantry about wording. An untestable requirement transfers the decision silently to whoever builds the thing, and they will resolve it according to what is convenient. Then a disagreement surfaces at acceptance, when it is expensive, and both parties can point at the same sentence as supporting their position.

The corollary is that a shorter document of testable statements beats a longer one of agreeable ones, even though the longer one feels more thorough and reviews more smoothly.

The other test worth applying to a requirement is whether anybody would notice if it were removed. A document full of statements that could all be deleted without changing what gets built is not a specification, it is a record of consultation. That may be needed for other reasons, and it should not be confused with the thing that constrains the work, because the two get merged into one document and the constraining parts become hard to find among the reassuring ones.