Understanding what non-functional requirements are, how they work, how to write them, and how to use them in real-life projects
When I help people learn about non functional requirements, I draw a lot of material from the first book that Jennifer Greene and I wrote for O'Reilly, Applied Software Project Management. So when I recently wrote a Q&A about non-functional requirements, I realized that a few especially relevant things that Jenny and I wrote in our chapter on understanding requirements that could be really helpful to readers. I'll post them here, and try to tie them in to the questions we've been getting.
For anyone who's curious, a lot of the questions we got from readers were in response to popular post I wrote called Using nonfunctional requirements to build better software. It's relevant here because it shows a step-by-step guide for creating an easy, practical technique to use nonfunctional requirements on a real software project, treating them in a way that's similar to how a lot of Agile teams treat user stories, scenarios and other functional requirements: by sticking them on index cards and using them to do some lightweight planning. My goal, between these excerpts and those posts, is to give you a lot of information that will help get to the heart of non-functional requirements.
Q: What are nonfunctional requirements?
A lot of people ask that question -- and if you haven't used them on a project, it's easy for nonfunctional requirements to seem a little abstract or esoteric. Jenny and I wrote this about nonfunctional requirements in Applied Software Project Management to try to help make things more concrete:
Users have implicit expectations about how well the software will work. These characteristics include how easy the software is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected conditions arise. The nonfunctional requirements define these aspects about the system.
The nonfunctional requirements should be defined as precisely as possible. Often, this is done by quantifying them. Where possible, the nonfunctional requirements should provide specific measurements that the software must meet. The maximum number of seconds it must take to perform a task, the maximum size of a database on disk, the number of hours per day a system must be available, and the number of concurrent users supported are examples of requirements that the software must implement but do not change its behavior.
-- Applied Software Project Management, p113 (O'Reilly 2005)
Q: Is there a nonfunctional requirements checklist that I can use?
In my blog post, I outline a requirements checklist. I wanted to give a little more detail about each of the items on that list, and there's a good excerpt that I think will help.
- Availability: A system's availability, or "uptime," is the amount of time that it is operational and available for use. This is specified because some systems are designed with expected downtime for activities like database upgrades and backups.
- Efficiency: Specifies how well the software utilizes scarce resources: CPU cycles, disk space, memory, bandwidth, etc.
- Flexibility: If the organization intends to increase or extend the functionality of the software after it is deployed, that should be planned from the beginning; it influences choices made during the design, development, testing, and deployment of the system.
- Portability: Portability specifies the ease with which the software can be installed on all necessary platforms, and the platforms on which it is expected to run.
- Integrity: Integrity requirements define the security attributes of the system, restricting access to features or data to certain users and protecting the privacy of data entered into the software.
- Performance: The performance constraints specify the timing characteristics of the software. Certain tasks or features are more time-sensitive than others; the nonfunctional requirements should identify those software functions that have constraints on their performance.
- Reliability: Reliability specifies the capability of the software to maintain its performance over time. Unreliable software fails frequently, and certain tasks are more sensitive to failure (for example, because they cannot be restarted, or because they must be run at a certain time).
- Reusability: Many systems are developed with the ability to leverage common components across multiple products. Reusability indicates the extent to which software components should be designed in such a way that they can be used in applications other than the ones for which they were initially developed.
- Robustness: A robust system is able to handle error conditions gracefully, without failure. This includes a tolerance of invalid data, software defects, and unexpected operating conditions.
- Scalability: Software that is scalable has the ability to handle a wide variety of system configuration sizes. The nonfunctional requirements should specify the ways in which the system may be expected to scale up (by increasing hardware capacity, adding machines, etc.).
- Usability: Ease-of-use requirements address the factors that constitute the capacity of the software to be understood, learned, and used by its intended users.
There are other categories of nonfunctional requirement as well, but this list is a solid, core list that makes a good starting point.
Q: How do I write down a nonfunctional requirement? Is there a nonfunctional requirements template I can use?
While my post outlines a good non-functional requirements template, I wanted to recap the technique I described in the blog post I mentioned earlier, Using nonfunctional requirements to build better software. It's especially relevant to O'Reilly Community readers because many of them are using or interested in Agile methodologies and processes, and this technique has worked well for me on Agile projects.
Here's a very quick recap of how it works. First, I write the requirement itself on the front of an index card:
and on the back I'll write a specific test to make sure the requirement is implemented:
I hope this additional material helps you understand nonfunctional requirements a little better. As usual, definitely post comments if you've got more questions.