The Importance Of NFRs
Adrian Reed
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).
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.
Adrian Reed is a true advocate of the analysis profession. In his day job, he acts as Principal Consultant at Blackmetric Business Solutions where he provides business analysis consultancy and training solutions to a range of clients in varying industries. He is editor-in-chief of the quarterly open-access magazine BA Digest, and he speaks internationally on topics relating to business analysis and business change. Adrian wrote the 2016 book ‘Be a Great Problem Solver… Now’ and the 2018 book ‘Business Analyst’
You can read Adrian’s blog at http://www.adrianreed.co.uk and connect with him on LinkedIn at https://www.linkedin.com/in/adrianreed/
