How to deal with NFRs in Agile
Non-Functional Requirements. One of those things that few people really talk about in conversations about agile frameworks and processes, but NFRs are really vitally important to understand. If you fail to specify, for example, the expected volume of traffic on your site or sales of your product, or calls to your call-centre, the consequences can be dire. If you don’t understand the need for reliability, performance, security, usability, and many others, you could spend a lot of money for something you can’t use, or need to spend a lot more time and effort on upgrading them.
What are NFRs?
If you are not already familiar, the difference between Functional and Non-Functional requirements is this: Functional requirements describe what the system does (and are typically expressed in agile via user stories), while Non-Functional requirements describe how the system does it. For example, a Functional Requirement might be “As a First Time buyer, I want to save my preferences, so that I save time on subsequent visits”. A related Non-Functional Requirement might be that the customers preferences are stored safely / securely so that no other customers or unauthorised employees can access them.
In traditional projects, there would be a document describing all these system attributes and they would be factored into the system architecture during the design phase. But in agile, few people really consider these non-functional attributes early enough. Or when they do, they struggle with how to define and deal with them.
The problem is, User Stories are typically only used for the Functional stuff. So how do we describe the non-functional stuff when you can’t easily put an NFR for Scalability into a sprint and deliver it in two weeks?
Here’s what I advise teams:
How to deal with NFRs
Think of NFRs as falling into two distinct categories. There are some that are Global, i.e. they apply to the system or product as a whole. Then there are those that apply only to certain functions or features.
Let’s take the latter first — those that apply to individual user stories.
If you have a user story that deals with, for example, doing a search, it could have acceptance criteria about how many results to display at a time, that all results must be pertinent to the search criteria, etc.
There may also be a non-functional requirement that the results should be displayed within a certain time, say two seconds (response time). The best way to describe this would be to include it as just another acceptance criterion. It can then easily be included in test cases or BDD scenarios.
If you find that you are writing the same non-functional requirement into the acceptance criteria of dozens of user stories, it can quickly become tiresome, especially if you know that, as the project proceeds, there may be a hundred more similar user stories emerging.
In this case, one way to deal with it is to describe a Global NFR. An example might be:
“All online customer requests are satisfied by an appropriate response in under two seconds under all load conditions.”
Or:
“All sensitive customer data must be securely stored according to GDPR”
But that still leaves us with the problem of how to deliver and comply with these system attributes.
Having defined them, I recommend making them as highly visible as possible — index cards on the wall, EPICS in Jira, listed on your team’s Confluence page, whatever.
Then, make sure that each of them has acceptance criteria so that you know whether they are being met. For example:
“I can access only the customer data that pertains to me, and not anyone else’s”
or
“The system responds to an order request within two seconds, even with n concurrent users”
Now, here’s the special bit — ensure that you write repeatable test cases for them. And ensure that they are run repeatedly. The idea is that the suite of global NFRs are seen as a regression test pack. Repeated running of this test pack ensures that, as development proceeds, any change that causes an NFR to fail, will be immediately detected and corrected.
Let me know if you have any alternative ideas, or if you try mine let me know what your experience was.
