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: