Working with Nonfunctional Requirements

Nonfunctional requirements describe aspects of the system that do not map onto a single piece of functionality. Essentially, they're constraints you need to operate within. Allan Kelly details how running performance tests regularly can be the key to nonfunctional requirements, as well as how much value these constraints produce.

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.

User Comments

Keith Collyer's picture

One of the interesting things that is implicit in this article is that non functional requirements are ALWAYS qualifications on functional requirements. This is something that is often missed. In fact, when I first started teaching requirements management, I used to recommend that NFRs should be in a separate section in a specification document (yes, I know, documents, it was a long time ago). It took me a few years to realise this was wrong.

October 15, 2015 - 11:00am
Allan Kelly's picture


That is a very interesting comment, I hadn't thought of that myself but as you say it is implicit. I need to give it some more thought but my intuition says you are right, after all, if there are no functional requirements then the system does nothing and by definition there are no non-functional requiremnts.

I've seen the FR/NFR thinking split myself and always thought it was a mistake,

Thanks again,


October 16, 2015 - 1:37am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.