Non-Functional Requirements (NFRs) are often the ‘unsaid’ requirements of a new product or system. NFRs should describe an important business context. Organizations who express new requirements of an IT system or a product tend to be much better at describing how something should work rather than the conditions in which it should work. For IT departments, this can lead to conflict late on in a delivery process when unstated assumptions are tested on a prototype or beta release. In other words, ‘what ain’t said don’t get delivered.’
For example, a simple requirement of a system might say “the system must add value x to value y and produce value z”. Great. Now we know what the new system must do. But what is often missed out, so I have experienced, are requirements that state “… and it must produce the value within a seconds and the calculation can only be conducted by person b.” What is missing in this example are the NFRs.
The conflict I mentioned happens when the unstated NFRs are tested by end users of the new system. Often, the NFRs are inferred by organizational design, organizational culture, and knowledge of the business context. In many cases, they are assumed, and moreover, the client of the new system assumes everyone else knows these assumptions! When these assumptions are tested, and the system fails, all hell breaks loose. Particularly as (again using the example above)
NFRs such as performance and access control are generally much more difficult and therefore more expensive to realize. NFRs, therefore, are subtle but powerful statements that describe the desired system. Their importance is assumed but not specifically stated. So disappointment results.
What should a technical department responsible for delivering a technical product or service do in these situations? Well knowing there maybe a gap is a good start. One might get a sense of a gap by using a simple filter on requirements: Who, What, Where and When? Do requirements state the desired system in these terms? A technical department with these responsibilities should also not accept requirements without first delving into them to extract the NFRs, so an end-user study maybe conducted. The language that will emerge are requirements that state the criticality, performance, accessibility and integrity of the desired functions.
Technical departments who get good at this will typically have good relationships with the subject matter experts in the client organization where this information can be obtained. I’ve found that they also have a standard template they provide client’s Business Analysts to complete. You’re likely to find that organizations that have adopted ITIL as an IT framework, for example, are much better at expressing NFRs.
Stating requirements, designing, building and deploying systems that meet stated NFRs is typically the sign of a mature organization who is experienced enough to know the impact of not having them. A step towards maturity is having skilled analysts to know what questions to ask. An indication that your organization isn’t there yet is the disproportional number of issues a product in final test stages (e.g. at business acceptance) against those found in previous stages.
I’d be very interested to hear your thoughts on this, and your view on your organization’s level of maturity.
