Skip to content

It’s Functionally Fantastic, But We Still Hate It: The Importance Of NFRs

When considering buying or designing a new product, it is often the functionality that dominates the conversation. Cast your mind back to the day that you got your first smartphone. If you’re anything like me, you were excited about the new features that you’d be able to use: suddenly there was the ability to send emails, play games, look up train times and much more besides. Yet for any of those features to be useful, certain other non-functional aspects have to be met too. As a consumer, I take for granted that my smartphone will be quick (imagine if it took 20 seconds to swipe the screen) and have a reasonable battery life (if the battery didn’t last a full working day that would be a major issue).  

An AI generated image of an old mobile phone. It looks like a combination between a landline and a mobile, with a polaroid camera lens on the top. It is a horrible brown colour, with worn keys, and a coiled cable.
Image courtesy of Stable Diffusion XL Pro AI

These implicit non-functional aspects play a huge part in whether the product will actually be used once it’s purchased, and whether anyone will actually like using it.  The harsh truth is that a product can be functionally fantastic, but if the non-functional aspects aren’t right, whoever has to use it might still end up hating it!

In the example of a smartphone, many of these aspects are implicit and taken for granted. Having a phone that is speedy to load apps is normal so (unless they’ve had bad experiences in the past) it’s unlikely that a customer is going to specifically ask for it.  We could almost consider some of these aspects to be ‘hygiene factors’.  Customers are unlikely to get excited if these requirements are met, but they are likely to be extremely disappointed if they aren’t met!

The Non-Functional Challenge

The implicit nature of these expectations hints at the challenge of eliciting and analysing Non-Functional Requirements (NFR).  Before we discuss this further, it is valuable to provide a definition. The International Institute for Business Analysis (IIBA®)’s Business Analysis Body of Knowledge (BABOK®) guide v3 define an NFR as:

“A type of requirement that describes the performance or quality attributes a solution must meet. Non-functional requirements are usually measurable and act as constraints on the design of a solution as a whole.”

As well as implicit expectations of stakeholders, this definition highlights another challenge: breadth. Aspects such as ‘performance or quality attributes’ can be very broad indeed, covering seemingly disparate topics such as security, performance, sustainability & ethics, and much, much more besides.

While it’s clear that getting the NFRs wrong (or missing them entirely) can have severely negative consequences, a related question is how on earth can we elicit them in the first place?  Ask an end-user about performance, and they’re likely to say “I want it to be fast”. But how fast is “fast”, and what trade-offs need to be made? 

Stakeholders Matter: It’s A Balancing Act

Stakeholder analysis and engagement is a core part of business analysis, and NFR analysis is no exception. In fact, it is likely that there will be additional or different stakeholders involved in defining and analysing NFRs.

For example, end-users and business domain subject matter experts are often excellent sources of potential functional requirements. Yet ask them about security or data, and unless this happens to be their particular area of expertise, they will likely struggle. The same is true if you were to ask them about backup, disaster recovery, and other topics. They might well have a view that something needs to be done, but they’re unlikely to be able to specify a detailed set of requirements.

This is where other specialist expert stakeholders often help fill the gap. Compliance, security, business continuity experts and so forth can often provide a view on the company-wide policy towards certain non-functional aspects. Technical subject matter experts may be able to benchmark the performance of an existing solution. That way, if the business stakeholders say “it needs to be at least as fast as what we have today”, you have a metric to benchmark against!

Yet, as with all requirements, there is a balancing act. With many types of NFR it’s possible to ‘dial up’ and ‘dial down’ the requirement. Think of availability: a solution that needs to achieve 99.99% availability between 08:00 – 18:00, and 80% outside those hours is subject to a whole different set of constraints to one that must meet 99.99999% 24/7, 365 days of the year.   The maintenance and “run” cost is likely to be different, so there is a trade-off. Right-sizing the NFRs is an area where business analysis plays a crucial role.

NFRs Don’t Have To Be Scary.

NFRs can seem scary at times. We’ve probably all been in situations where nobody wants to talk about them, they are deferred to later, and are very easy to ignore. They become “important but not urgent”… until suddenly they are urgent because an IT system falls over, there’s a security breach, or some other unfortunate event.

Yet, counter-intuitively, the analysis mechanisms for eliciting NFRs are pretty much the same as for functional requirements, albeit techniques might be used with a different ‘spin’. The key is that NFR elicitation and analysis requires planning, and relies on the stakeholder net being spread widely. It relies on product or project stakeholders proactively shining the spotlight on these topics, rather than letting them lurk in the shadows.


By doing this, we increase the chances of the product being used, liked or even loved. And reduce the risk of delivering something functionally fantastic that they absolutely hate.

And surely that’s worthwhile?


Interested in sharpening your approach to NFRs? Join Adrian for a one-day, live, online NFR course which examines this topic in more detail. Find out more and register your place.


What are your views? Please add a comment below, and let’s keep the conversation flowing!

If you’ve enjoyed this article don’t forget to subscribe.


About the author:

Adrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.

To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com

Blackmetric: Logo. Word "Blackmetric" with a ruler beneath it

© Blackmetric Business Solutions, published exclusively on www.adrianreed.co.uk. May not be republished on any other site without permission.

2 thoughts on “It’s Functionally Fantastic, But We Still Hate It: The Importance Of NFRs”

  1. Spot on Adrian, imagine having a functional customer service desk with an AI BOT yet however hard I try I can never get the answer I want. I spend half an hour trying to obtain what I need and then futilely trying to find a human being who understands what other humans need, then it is highly unlikely that I will buy anything from that Supplier again. So, usability is a key non-functional requirement that is not your standard performance, volume, stress, latency NF requirement yet truly neglected when it comes to quality versus cost? 🤔

    1. That is so true, Trevor, when these types of things are neglected, it causes all sorts of issues!

      The irony when it comes to scrimping on usability, is that it probably costs more in the long run. If a product or service is hard to navigate, there’s more failure demand (calls to the call centre, complaints etc). So any savings made on implementation are totally negated by the additional operational expenses of supporting the thing!

      And totally feel your pain with some chatbots!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.