Over on the IIBA LinkedIn group, Tammy Goslant asked if anyone could share an industry standard template for non-functional requirements (NFR). I have never seen one, and suspect this is because there is not best way to represent needs: it's always situational. Every organization finds itself modifying someone else's template to address the organization's industry, change methodology, maturity, and BA competencies (across all BAs).
Still, all templates for NFRs should do a few things really well. The most important, to my mind, is to ensure that measures for non-functional requirements make it easy to account for the ranges of acceptable operation for the solution.
Requirements MeasuresIn general, there are a spectrum of requirements measures related to the type of value that the requirements are supposed to deliver:
- Functional Requirements tend to describe some potential gain to be sought.
- Non-Functional Requirements tend to describe some potential loss of value to avoid.
Note the use of 'tend to' in this discussion. This is a spectrum, not a set of absolutes, and all requirements represent some mixture of potential gain and avoidance of potential loss.
Any kind of requirement measure can be placed in some range on the spectrum above.
- Measures for potential gains tends to be relatively absolute. At the most basic level of individual features, the measure is 'works / doesn't work'. The functional requirements for a login process at the ATM are measured this way.
- Measures for avoidable losses tends to be a range of acceptable - and unacceptable - behaviours. The ATM might log me in, but the response time should be
- within 5 seconds 90% of the time,
- within 10 seconds 99% of the time,
- within 15 seconds 99.999% of the time,
- within 20 seconds 100% of the time.
Many requirements should be measured based on both kinds of measures - the potential gain, and the avoidable loss. The broader the scope of the requirement, the more common it is for both kinds of measures to be relevant. For example, business objectives generally involve a range of potential benefits and a range of avoidable losses (or ideal operating conditions).
Risk-Benefit vs Loss-GainAnother way to consider this spectrum is to think in terms of solution benefits and solution risks:
- functional requirements tend to focus on potential solution benefits.
- non-functional requirements tend to focus on solution risks.*
Unlike change risks, which are managed as part of the process of making the change, solution risks should be managed as part of the solution. This may take the form of feedback or control loops, error trapping, performance reporting, or other mechanisms - but something needs to be built to address the risk. If you're an IIBA member, you can see a detailed, peer reviewed discussion of this in article CARRDS: Constraints, Assumptions, Risks, Requirements, and Dependencies in the Best Practices for Better Business Analysis (BP4BBA) publication; a shorter version appeared for the public in the December 2012 BA Connection Newsletter, under the same title.
Using these terms can be useful, especially when discussing the importance of non-functional requirements with stakeholders who are sceptical of their importance.
Acceptable RangesIn the ATM example, the lower limit of the acceptable range was zero seconds. In many solutions there is both a minimum and a maximum to the acceptable range. Jacob Nielsen mentions one such case in his article, Response Times: The 3 Important Limits. Nielsen says,
"Normally, response times should be as fast as possible, but it is also possible for the computer to react so fast that the user cannot keep up with the feedback. For example, a scrolling list may move so fast that the user cannot stop it in time for the desired element to remain within the available window."Servers should operate in a temperature range. Supply chains should be optimized so outputs of one process happen at a rate very similar to the inputs for the next process. Sales demand that drastically exceeds the capacity of the manufacturing facility can lead to angry customers and lost profits.
ConclusionThere may be no industry standard template for the recording of non-functional requirements - but there are some things that all templates should have. Coherent, clear, useful measures are at the top of my list.
* From a Business Analysis Core Concept Model (BACCM) point of view, the term 'risk' and 'potential loss event' are essentially the same, so the 'solution risks' can be rephrased 'events with the potential to case a loss of solution value'.