The three golden rules for formulating quality requirements
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.
A business could, hypothetically, run using chisels and clay tablets. It would be cumbersome and labor intensive but could be done. Automation and technology deliver speed, accuracy, capacity, and accessibility. And this essentially sums up what are called NFRs. Where you might have a business rule that specifies a percentage of excess capacity to accommodate growth or surges, there needs to be some sort of element or mechanism within whatever framework is being used to address method (what?) and implementation/adoption (how?).
Technology assessment and transformation for critical software products.
8 年I suggest we all stop using the oxymoronic "non-functional requirements ". There are many well-defined quality attributes which cover all these aspects. They are defined in the ISO 25010 standard and in many publications from the SEI on architecture analysis including https://www.sei.cmu.edu/architecture/start/reasoning.cfm
A mí me va bien, si a Ud. le va bien
8 年Sorry, but please let me say. As buiness analyst we need to understand that the whole organiztion is a system as a whole. So, NFRs requirements apply to whole organization too. In that case, question 1 has no sence.
In my experience, focusing on reaching a goal (outcome) with little or no regard to method is dangerous and encourages aggression and competition - not good when population increases or crowds start gathering which is a reality in the 9 billion plus 21st century.
Isn't "values intent and outcome over method and precedent" the same as "the ends justify the means" which is really both old and classic - we've already exercised that principle over and over again in the 20th century business and practice model. In the 21st century, in the spirit of innovation and change we either need refinement or something new or even opposite - like "the means to an end are meaningful"