When writing a specificiation, it is sometimes tempting to use non-testable text for normative requirements; indeed, making sure a text is testable requires much more work than using simple text without caring about testability (see also TestableOrNot).
But using non testable text as normative requirements has many drawbacks:
- mandating something that cannot be tested is a no-op; how can you check whether something was indeed implemented if you cannot test it?
- non-testable requirements means that implementations are likely to differ on the said requirement, meaning that interoperability will be loose at best
- leaving a requirement in a fuzzy non testable state means leaving the disambiguation work to the implementors, making it much more costly and much more likely to generate confusion for the end users
See also a thread on www-qa.