A while ago I participated in the drafting of a standard for an enterprise set of non-functional requirements for one of my customers. You might wonder how did I get involved in this endeavor. The initial incarnation was in my opinion “slightly” flawed and I bluntly shared this view with my manager and the manager responsible for its creation. Although my approach was not one of the best demonstrations of tact and diplomacy and it probably damaged the relationship with my manager, it did land me a seat in the team drafting the next iteration

We used the ISO 25010 standard as a starting point. This standard was too limiting for us and we also needed to incorporate service management, architectural and security QRs, as these are enabling secure and reliable operation in an enterprise environment. Initially, we often got stuck discussing whether a requirement was non-functional or functional or that it was part of our organizations’ process or management structure and thus should not have a place in a requirements list to begin with. Because of this struggle we came up with the three golden rules as a cleansing mechanism.

Q: Does it describe a requirement that disappears if compute and storage resources are unlimited and free?

Q: Can it be translated in a (part of a) product or service?

Q: Can it be verified?

If the three question cannot be answered with a YES, it is either not a quality requirement or it is too ambiguous and there is no value in including the requirement.