I have found that non-functional requirements (NFRs) can be hard to define for a given solution. I’ve seen teams struggle with NFRs. However, to ensure I’m speaking the same language as everyone else, let’s look at a common definition to work with. This is taken from the Scaled Agile Framework (SAFe):
Nonfunctional Requirements (NFRs) are system qualities that guide the design of the solution and often serve as constraints across the relevant backlogs.
As opposed to functional requirements, which specify how a system responds to specific inputs, nonfunctional requirements are used to specify various system qualities and attributes, such as:
- Performance: How fast a system should respond to requests
- Scalability: How well a system can handle an increase in users or workload
- Security: How well a system protects against unauthorized access and data breaches
- Usability: How easy a system is to use
- Maintainability: How easy it is to update and modify the system
Of course, there’s more, because when we’re talking about qualities and attributes, there are others we need to consider for any technical solution. Recoverability is a good example. For critical systems, resiliency could be another. Some of these are easier than others to properly define. For instance, recoverability can be defined using Recovery Point Objective (RPO) and Recovery Time Objective (RTO). Others are tough. For instance, let’s take a look at performance.
Performance, based on the SAFe is how fast a systems responds. Here’s the million dollar question: “How fast is fast enough?” It sounds easy at first glance, but it turns out that unless you have a mature system, that can be an extremely hard question to answer. We have ways to quantify and measures. For instance, we could capture transactions per second. We could record response time for a web page or time to load. But even if we know what to measure, do we know what the target should be?
How do we get to a definition of “fast enough?” One of the easier ways, if you have the setup to do so, is to have users test before production. When the users say, “It’s fast enough,” we can just record that and call it good, right? Not necessarily. One user, all alone on a system might get blazing fast speeds. Of course that is “fast enough.” But in production, what if there are several thousand concurrent users? That user test isn’t valid. We need to test with production load. Actually, we need to test with production load, using product like quantity of data (the old 10 rows in development versus 10,000,000 rows in production problem), executing production like workflows/processes. If we are doing that, we have a better chance to answer the question of what fast enough looks like.
So what happens if we can’t properly define that non-functional requirement? Have you ever deployed a system and the business comes back and indicates the system is too slow? How do they know it’s too slow? How do you respond back? If you’re just now dealing with the question, “How fast is fast enough,” it’s too late to be able to say to business that the system is running fast enough. There’s no foundation to make that claim.
If you’re in production and you haven’t already answered the question, then baselining the system is critical. Actually, baselining the system if you have answered, “How fast is fast enough,” is critical, too. You need to know if the system is meeting the non-functional requirement. So getting the baseline allows you to get the numbers you need to compare against “fast enough.” The baseline also allows you to deal with the “the system is slow” situation if it should come up and you hadn’t answered the question, “How fast is fast enough?” When you have the baseline, you can ask if the system is fast enough. Then you can define and record the NFR. If, later on, business says the system is slow, you can check against baseline. If you see that you aren’t meeting the numbers captured in your baseline, you can agree and investigate. If the numbers are still in line with baseline, that gives you the ability to lead off the conversation with the fact that you have numbers, but if business is saying performance is bad, you want to narrow down on what specifically is bad and see what kind of numbers you have.
I’ve focused in on one NFR, but we can take a planned and methodical approach with each NFR that’s relevant to that particular platform. Without the NFRs, how do we know that we are meeting the business needs for the organization? And keep in mind that in discussing the NFRs, such as performance and availability, business may have a certain level of expectations. There’s a cost based on the solution. By giving business those numbers, they can make the decision. For instance, if they want performance for 5,000 concurrent users with a page load of XXX ms, there’s a certain cost to support that. It may be that the cost isn’t worth that level of performance. The more data we can provide related to the NFR, especially around cost, the better equipped business will to be to make a decision. Document the decision, the hows and whys, and keep that handy. Because you may need them to justify why you are at YYY ms page load, which was greater than the XXX ms page load, but that’s what business agreed to due to cost.