Adrian Reed | Blackmetric Business Solutions
When it comes to requirements analysis, functional requirements tend to take the limelight. After all, what the product does tends to be a key area of focus, and the functionality that it will provide will often be one of the key things that stakeholders want to talk about.
Yet product and project teams ignore Non-Functional Requirements (NFRs) at their peril. It is quite possible to deliver something that is functionally fantastic, that users absolutely hate. In the worst case, people might actively find a way of avoiding using it.
You’ve almost certainly experienced this yourself as a consumer. I bet there are websites or products that you hate using because they are too slow, too hard to use, or unreliable. Sure, the functionality is there, but the non-functional elements let the product down. This is even more of an issue where other options are just a click (or touch) away. Is the online shopping experience too slow or unwieldy? No bother, customers will abandon their baskets and go elsewhere…
Equally, there are probably products and services that you love using because of their non-functional elements. Perhaps you love using your phone because it’s reliable, easy to use, looks fantastic and fits in your pocket. It might be functionally identical to a cheaper, chunkier model, but you chose the slimmer, more reliable version (even though the functionality is similar).
These patterns hold true of systems, processes and products within and beyond organisations too. And the consequences of getting things wrong can be severe. For example, when an information system is processing the personal data of customers, issues with availability, security and resilience are crucial.
Learn more with Adrian REED. Online courses coming up…
Master the Requirement Process, 6 – 7 March 2024
Non-Functional Requirements Workshop, 2 May 2024
NFRS can seem scary
This is where we need to call out the elephant in the room. NFRs can be hard to define, people often don’t want to talk about them and even the term “non functional” can cause confusion. As a BA they can seem elusive and even somewhat scary, and it can be difficult to know where to start or even how to define what an NFR is. Yet, whether we call them “NFRs”, “quality attributes” or something else entirely is less important than actively working to analyse them and ensuring that the products and services we deliver meet them.
This is where the challenge starts. Let’s take performance as an example: ask a user of a product how fast they want a solution to be and they’ll likely reply “really fast” (or “at least as fast as what I have at the moment”). That’s an understandable response, but it’s not the most useful for defining a requirement. This highlights an unspoken truth of NFR analysis: we might need to engage additional stakeholders and utilise different techniques. To know what “really fast” means we might need to work with an expert who can benchmark existing (or competing) systems and give a view. Security experts can help provide guidance and direction on information security and cybersecurity issues. The NFR landscape is broad, and engaging the right people is key. It’s important to know what questions to ask.
It helps to have a list of NFR types, with examples, as a starting point. This shouldn’t be seen as restrictive or prescriptive, but more as a starting point to build from. Words like “security” and “disaster recovery” can act as prompts. It prompts teams to ask questions such as “do we have these covered?” Or “do we need to consider these types of NFR in this initiative” and “what other types of NFR might be relevant? “
Don’t ignore them
Whatever approach is taken, ignoring NFRs is a dangerous approach. This is an area where suitably experienced business analysts can add significant value. A good BA will bring NFRs into the conversation throughout the project, will ask the hard questions and ensure that the product meets the needs and expectations of its consumers and stakeholders.
