Working with Nonfunctional Requirements

Some years ago a bank asked me for advice on a project to change the processing of payments. This was a small piece of work, and the bank wanted to use some agile goodness to speed up development—but they didn’t want agile to disrupt anything else. Unfortunately, this is a common request: “Make us faster, but don’t change anything.”

Reviewing the requirements document—yes, they still had them—I asked, “How much time does this process have to operate in?”

“Oh, it runs in the early hours of the morning. The current process has a couple of hours to spare, so we are OK.”

“Well,” I responded, “let’s put the current run time and the maximum time available into the specification. At least then we know what we have to work within.”

This wasn’t popular. “But then we would need to test it to see the current time. Setting up a test is going to take time, but the test system is already maxed out and we don’t have any testers to do the test.”

I gave up. There comes a point when persisting isn’t going to help. But guess what? When put live, the new code functioned correctly, but it took so long to run that it hadn’t finished when the bank opened for business.

Analysts call constraints like a limited time window nonfunctional requirements, or NFRs. (Personally, I think this is more a specification, but let’s not get hung up.) The point is, there is a constraint that is independent of what functionality the system has. In this example, processing payments is well understood; the problem is whether it happens in one hour or four.

NFRs describe aspects of the system that do not map onto a single piece of functionality. Speed of execution is the most commonly cited NFR, but there are others. Ease of use is another common one, although how one measures ease is another question. Security is an increasingly common and important one, too.

Nonfunctional User Stories

Whether you see them right away or they appear as you discuss stories and acceptance criteria, you will inevitably have some NFRs.

With a little thought, regular user story format is fine for most NFRs:

As an accounts clerk, I want the balance sheet report to be delivered within two minutes.

But not all NFRs are so easy. If your effort to twist a requirement into a user story leads you to break grammar rules or write convoluted sentences, then abandon the “As a…” user story format. Write requirements so they are understandable, and follow up with discussion later. You can still write acceptance criteria on the back if you wish.

Sometimes, especially when a system already exists, NFRs are just like any other piece of work. Take the balance sheet example: If the clerk can already obtain a balance sheet report, then the story is really saying, “Make the current functionality faster.”

The key to NFRs is often tests. In the first instance, a NFR is a request for testing. Before you do any development work, create and run the tests. Be truly test-driven. This might lead you to split a story like the one above in two:

As an accounts clerk, I want the balance sheet report.

As an accounts clerk, I want the balance sheet report to be delivered within two minutes.

In the first story, you build the functionality; the second story necessitates a test that might create more work.

Once you have the tests in place, you will know whether any development work is necessary. Running the tests regularly ensures that any changes that break the requirement are quickly highlighted.

This is the catch with an NFR: Because they are cross-cutting, they can come back to bite you long after you consider them done.

One team I know had a performance requirement to return results in less than one second. First they created a test for this that passed; then they created a test that failed at 0.8 seconds. If this test broke in the future, they would take action to improve performance.

Specifying the Requirements

This approach demands quantifying NFRs: How fast is fast? How secure is secure?

This, in turn, means measurement tools. How do you measure secure? “The system can withstand a distributed denial of service attack for thirty minutes”?

It is useful here to borrow from the work of systems engineer and author Tom Gilb. He advocates using a “planguage” (planning language) based on well-defined rules for specification. He would ask:

• What is the unit of measurement? And what is the measuring tool?
• What is the current measurement?
• What is the desired measurement?

Perhaps the story answers these questions, or maybe the acceptance criteria do. If not, ask them in the conversation that follows. Without answers to these questions, tests, especially automated tests, become hard to create. Worse, NFRs become subjective—what is fast to me is not fast to you.

Constraints and Value

When you put tests in place for NFRs, it becomes clear that these items are not so much requirements as constraints:

As an accounts clerk, I want the balance sheet report to be delivered within two minutes.

NFRs provide parameters within which the system needs to operate, much like any other form of specification. Viewing requirements reveals they are not binary all-or-nothing requests. Rather than asking “Do we have function X or not?” ask “How much of this function do you need?”

All requirements become analog—are they more satisfied or less?

• How fast does the balance sheet need producing?
• How accurate should the balance sheet be?
• How current should the balance sheet be?

This gives us another tool with which to break stories down into smaller pieces. More importantly, it also brings us back to benefit and value. How much value do these constraints produce? In effect, how much more valuable is it for the clerk to have the balance sheet in two minutes rather than four?

Knowing the value of functionality opens more doors. It helps perform cost-benefit analysis and allows consideration of different engineering solutions. How much value does producing a balance sheet in two minutes add? If the first story produces a balance sheet in four minutes, is there enough value to make the second story worthwhile?

Illuminating these constraints changes our understanding of the story and demands the conversation continues. Closing the conversation prematurely hides opportunities to split stories, negotiate compromises, and maximize benefits.

Opportunities to Benefit

The real problem with constraints is not so much crafting a solution to meet them, but recognizing they are there in the first place. Creating tests and examples promotes conversations—a massive step toward flushing out nonfunctional requirements. It opens opportunities to further slice stories and consider benefit.