The Business Value of Non Functional Requirements
Nonfunctional system qualities
Both customers and teams often discuss the value of the functionality that should be delivered. However, one critical area often gets overlooked and that may lead to highly undesired consequences. Today we’re going to talk about the value of nonfunctional requirements.
First of all, what are they? These are the important qualities of the solution, such as reliability, accessibility, security, availability, usability, and plenty of other “-ilities”. There is a reason why nonfunctional requirements often get overlooked: You notice them only when you don’t have them. You may not think much about cyber-security of your solution until there’s a real threat or an actual breach. And then, suddenly, it becomes the most important item on the agenda. Similarly, the team and even their customer may not pay much attention to service availability until one day—for a pretty benign reason—the system goes down. And then multiple consumers get affected and it’s not even clear how long it will take to fully restore the service. We see a strong pattern here: hardly appreciated when everything works fine and once something goes wrong, everyone suddenly realizes how great is the value in that particular system quality.
How can we be more proactive about it? How can we assess the business value of the nonfunctional requirements more adequately, so that proper implementation would be prioritized?
Here are some things that we can do.
Productive approach to implementing nonfunctional qualities
First of all—and this is a very natural thing to do—is to simply have a generic checklist for your backlog refinement or planning events; the checklist that would include the typical nonfunctional requirements and would be used as a reminder to attend them. And then naturally, some of these system qualities would end up as a part of acceptance criteria for some backlog items. And those that apply to all backlog items would end up on the definition of done. So, this is good, but not quite enough to reveal the actual nature of those system qualities to the team and the stakeholders.
To better understand which nonfunctional requirements are relevant to our solution, and exactly in what way, we are going to do the following. Instead of just going down the typical path of incrementally developing functionality and then demonstrating it to the customer (in other words, creating some exposure for that functionality), we will try to create exposure for the nonfunctional aspects of the system. This requires a bit more intentional approach. For most of these qualities to be validated and demonstrated, the system and especially the environment where it executes, have to resemble the ultimate configuration as close as possible. This also pertains to the number of users that the system is exposed to, from early on. Certainly, when the system is only exposed to a very limited number of stakeholders, it is hard to assess certain qualities of the system. But as soon as there is a critical mass of users, a lot of things begin to transpire: there are suddenly people that find some functionality not very usable, there appear to be performance issues, availability problems and so on.
As an action item, consider the following. Determine, what nonfunctional system qualities may be under-attended in your development context. Plan some simple work to expose those qualities early on—maybe in the next iteration or two—and take it from there.