SimonStapleton.com

NFRs: The mysterious requirements of a business

Estimated reading time: 2 mins

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.

Share this...
Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Pin on Pinterest0Share on Reddit0Share on StumbleUpon0Digg thisEmail this to someone
 

About the author /


Simon is a creative and passionate business leader dedicated to having fun in the pursuit of high performance and personal development. He is co-founder of Applied Change, a Business Change consultancy based in the UK. Simon is also an Ambassador for Gloucestershire business. Simon is an Associate Member of the Chartered Institute of Professional Development.

Post your comments

Your email address will not be published. Required fields are marked *

Affiliate Promotion

simonstapleton.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com. Amazon, the Amazon logo, AmazonSupply, and the AmazonSupply logo are trademarks of Amazon.com, Inc. or its affiliates.

Polls

When answering Employee surveys, do you always answer completely honestly?

View Results

Loading ... Loading ...
SimonStapleton.com located at Watledge , Stroud, UK . Reviewed by 18,205 readers rated: 1 / 10
My latest book: ACE Your Performance Appraisal$4.99 on
How Am I Doing?

Did this discussion solve your problem?

Then please rate this post or leave a comment.