Put a tick in the box

Lack of forethought by people who know what they are doing is the reason most non-functional requirements are of near zero practical value. People fill out templates with meaningless, soft, unmeasurable requirements. They aren’t written with the objective of preventing a problem, they are written to put a tick in a box.

Target a problem

Non-functional requirements should target an identified probable problem. This is the only way to control their numbers and it is the only way to ensure useful requirements are written.

Think about it

Spending time thinking about how to achieve the right outcome is essential. How is the requirement couched in a way that will prevent the problem, or at least lead to the detection of the problem, if it is not prevented? This is how the real requirements is understood and how an approach to documenting it that will ensure it is understood by others is prepared.

Practical requirements

Ensuring requirements are practical is key. Practical means lots of things. It means achievable given the state of the art and the amount being invested. It means useable by all disciplines, specifiers can understand the implication of compliance and non-compliance, designers and developers can understand the implications on what they do and the assurance team can work how to measure the extent of compliance.

Resilient requirements

Resilient requirements are hard to fudge. Too often it is possible to comply with the requirement whilst delivering a solution that is not fit for purpose. Resilient requirements are ones that resist this, that are hard to comply with the letter of whilst falling far short of the spirit of.