Your Account

Search Shopping Cart

Home Shop Radar: News & Commentary Answers Safari Books Online Conferences Training School of Technology Community

Authors Blogs Forums User Groups Membership Community Guidelines 1-800-998-9938 / 707-827-7000 / accounts@oreilly.com

Understanding nonfunctional requirements Print NEWS TOPICS Recommended for You

By Andrew Stellman
February 17, 2010 | Comments: 6 Listen apple blogs
Tweet 9 Like 16 cloudcomputing ebooks
economy facebook flash flex
geo google gov20
government iphone
Understanding what non-functional requirements are, how they work, how to write them, and how
to use them in real-life projects javascript linux microsoft
mobile ooxml
When I help people learn about non functional requirements, I draw a Effective Modern C++
lot of material from the first book that Jennifer Greene and I wrote for opensource oscon Ebook: $42.99
O'Reilly, Applied Software Project Management. So when I privacy programming
recently wrote a Q&A about non-functional ✓ requirements, I publishing python
realized that a few especially relevant things that Jenny and I wrote in
security socialnetworking
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 standards twitter

web20 xml
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
Data Algorithms
it shows a step-by-step guide for creating an easy, practical technique Ebook: $59.99
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
Velocity Conference
nonfunctional requirements to seem a little abstract or esoteric. Jenny and I wrote this about
Santa Clara 2014:
nonfunctional requirements in Applied Software Project Management to try to help make things
Complete Video
more concrete: Compilation
Video: $799.99
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.
Got a Question?
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 Do you have a question
system must be available, and the number of concurrent users supported are examples of about O'Reilly's
products and services?
requirements that the software must implement but do not change its behavior.
Share an idea! Report a
problem...
-- Applied Software Project Management, p113 (O'Reilly 2005)

Q: Is there a nonfunctional requirements checklist that I can use? Continue

In my blog post, I outline a requirements checklist. I wanted to give a little more detail about each Active discussions:
of the items on that list, and there's a good excerpt that I think will help.
Loading...
Availability: A system's availability, or "uptime," is the amount of time that it is operational
Service and support
and available for use. This is specified because some systems are designed with expected
downtime for activities like database upgrades and backups. by Satisfaction
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:

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

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.

Tags: project management, software development, software engineering, software quality

 You might also be interested in:

RESTful Web APIs The Art of Memory Introducing GitHub

Print: $34.99 Forensics Ebook: $21.99
Ebook: $29.99 Ebook: $65

6 Comments
By Marouen Mhiri on May 26, 2010 6:56 AM

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

By Nagesh Tummala on May 27, 2010 5:20 AM

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.

By Tushar on October 19, 2010 1:04 PM

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)

By Ahu on November 10, 2010 7:56 PM

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

By tushar on February 8, 2011 11:58 PM

I have listed my version of non functional requirements at http://architecture-soa-bpm-

eai.blogspot.com/2010/10/contemporary-non-function-requirements.html

By Shafiul Azam on February 19, 2011 11:20 PM

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

Sign up today to receive special discounts, Privacy Policy >

Enter Email View All RSS Feeds >
product alerts, and news from O'Reilly. View Sample Newsletter >

About O'Reilly Community More O'Reilly Sites Shop O'Reilly

© 2011, O'Reilly Media, Inc. Academic Solutions Authors igniteshow.com Customer Service
(707) 827-7019 (800) 889-8969
Jobs Community & Featured Users makerfaire.com Contact Us
All trademarks and registered trademarks Contacts Forums makezine.com Shipping Information
appearing on oreilly.com are the property of
Corporate Information Membership craftzine.com Ordering & Payment
their respective owners.
Press Room Newsletters labs.oreilly.com The O'Reilly Guarantee
Privacy Policy O'Reilly Answers Partner Sites
Terms of Service RSS Feeds
PayPal Developer Zone
Writing for O'Reilly User Groups
O'Reilly Insights on Forbes.com