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.