Non-Functional Requirements (NFRs) can be difficult to define and track. We often treat them as after-thoughts and only near the end of the project.
We usually focus on functional requirements. These represent system behaviors. They define what a system is supposed to do and how the inputs and outputs will appear.
NFRs are more varied. They define characteristics of systems rather than behaviors. Here are a few of the more common types of NFRs:
- Availability (e.g. 24x7x365)
- Capacity (planned)
- Compliance (legal and/or regulatory)
- Efficiency (resource consumption)
- Interoperability (inter-system data exchanges)
- Performance (response time)
- Portability (cross-system functionality)
- Resource usage (processor, memory, disk space, network bandwidth, etc.)
- Scalability (user count and data volume growth)
- Security (e.g. login, encryption)
Traditional business requirements documents have a section devoted to NFRs. They may even be captured in a separate document. Either way, it can be a bit awkward in that the business often doesn’t specify NFRs. They tend to focus on what a system must do making the implied assumption that the system will be able to handle the workload thrown at it in a secure and robust manner.
Agile software development teams often have a difficult time with NFRs too. How should they be captured? What do they look like? Here are a few ideas.
Capture NFRs as user stories. While most NFRs don’t fit nicely into the story metaphor, capturing them this way makes them highly visible and easy to manage. They are just like any other requirement. An NFR story might read something like…
As an impatient and over-worked data analyst, I want to process 10,000 records in under 60 seconds so I can get more done in less time.
As a claims adjuster handling sensitive information, I want my data to be password protected and encrypted so that I meet compliance obligations.
As a marketing executive, I want the software to operate in Windows, OSX and Ubuntu so that the company maximizes its revenue potential.
Capture NFRs as technical stories. These stories are different from user stories in that they don’t originate from the business community. Thus, they don’t have the visibility and discussion associated with user stories. There is nothing wrong with this approach though I’d argue that sacrificing visibility and discussion does not lead to positive outcomes.
Capture NFRs in the acceptance criteria for each story. This is a little more work in that it forces the team to think about NFRs while implementing each story. This may make some of the acceptance criteria repetitive. In addition, some NFRs may be difficult to test story by story. It may be best to only reference an NFR in the acceptance criteria if it is essential to the implementation of the story.
Write a Non-Functional Requirements Specification. Such a document would serve as an umbrella or wrapper over the project. This could work but using two methods for capturing requirements might be confusing. There will always be gray areas. For example, if I want to run the software on a touchscreen, is that functional or non-functional? It’s both because of the many issues and nuances introduced.
There really isn’t a right-way or wrong-way to define NFRs. Pick an approach or a combination of approaches that works for your team. The most important point is conditioning the software development team and the business community to recognize the importance of NFRs and document them.