Understanding nonfunctional requirements

By Andrew Stellman
February 17, 2010 | Comments: 6

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.
-- Applied Software Project Management, p114 (O'Reilly 2005)

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:

Nonfunctional requirement index card (front)

and on the back I'll write a specific test to make sure the requirement is implemented:

nf_index_card_back.jpg

Once you've got a reasonable set of non-functional requirements written down like this, you can use them with a task board or to help with Agile planning techniques like Planning Poker.

I hope this additional material helps you understand nonfunctional requirements a little better. As usual, definitely post comments if you've got more questions.


Andrew Stellman is the author of several popular O'Reilly titles, including Applied Software Project Management and Beautiful Teams. You can read more of Andrew's posts at Building Better Software.


You might also be interested in:

6 Comments

Hello,
firstofall a great thx for this beautiful article.
I study computer science at the technical University of Berlin (Germany). I'm writing my thesis about Software as a service and the basic question in this work is "how to evaluate SaaS?". My question is: could one specify the NFR you wrote above for the SaaS too?. I think the most of them could refer to SaaS, but not scalability (for exmaple) because if this characteristic is not available, so we could not speak about Software as a service.

Thx
Marouen

Thank you for the excellent article. Non-functional requirements is an area of great interest to me. I felt couple of things would complement your post.

1. Audit requirements: I have worked on some governance(UK) and Finance(US) projects earlier. Some of the non-functional requirements that are not explicit but were expected included audit ability of various interactions / transactions that the system provides. For a project manager, it is important to identify such a requirement and include in the scope baseline very early on. As such building Audit capability is significant amount of work as it is feature you are most likely required to implement throughout the system. Unless caught early, then can affect the project performance.

2. Roll Back requirements: Simple case is where this is a part of good usability attribute that forgives end user when they make a mistake and let them roll back. More complex scenario is where a set budget is frozen for an loan-application at some state and certain pre-processing is done; then for what ever reason, the application gets rejected. All the processing should be rolled back. End user just assumes that we would do that.

Also, I have an observation to make: I think there is some Grey area around Reliability, Robustness and Availability. In my opinion Reliability can cover a scenario where a system's data/state being reliable after crash/ recovery. Robustness is where the system handles exceptions well and rock-solid. Robustness keeps it up, but admin might still need to take it down for maintenance. If we have system that is built such that Summary reports/ maintenance/ back up / hot fixes etc does not require the system to be taken down, then we call it high available system.

The NFO covered here are traditional one. With progress in technology and understanding of software capabilities and engineering new breed of NFO has emerged. I have tried listing some of the contemporary NFO at my blog (http://architecture-soa-bpm-eai.blogspot.com/2010/10/contemporary-non-function-requirements.html)

Hello,

Thank you very much for this artical I am studying Web Technology and first I didnt understand what non-functional req, but now it's cristal clear.

Again THANKS A LOT.

Ahu

Thanks! Post helped me in my analysis tasks. Have a great day :)

News Topics

Recommended for You

Got a Question?