Nonfunctional Requirements

Let's look at an example. One of the IceBreaker product's functions is to record the road temperatures and moisture levels each time the data is transmitted by the weather stations. Recording data is a functional requirement. Suppose that the data has to be recorded within half a second; once recorded, no one except a supervising engineer is allowed to alter the data. These are performance and security requirementsthat is, they are nonfunctional requirements. They are not part of the functional reason for the product's existence, but they are needed to make the product perform in the desired manner.

Nonfunctional requirements do not alter the product's essential functionality. That is, the functional requirements remain the same no matter which properties you attach to them. To confuse matters even more, the nonfunctional requirements might add functionality to the product. For example, the product might have to do something for it to be easy to use, secure, or intuitive. Think of the basis of this functionality: It exists because of the nonfunctional requirements. It exists to make the product have the desired characteristics. Perhaps it is easier to think of the functional requirements as those that cause the product to do the work, and the nonfunctional requirements as those that cause the product to give character to the work.

Nonfunctional properties may be the difference between an accepted, well-liked product and an unused one.

Nonfunctional requirements make up a significant part of the specification. Provided the product meets its required amount of functionality, the nonfunctional propertieshow usable, convenient, and inviting it is (see, for example, Apple's iPod, shown in Figure 8.1)may be the difference between an accepted, well-liked product and an unused one. Keep in mind that a large part of what people see or feel with your product is there because of the nonfunctional requirements. The usability of a product makes a huge difference to the user's or customer's acceptance of it. The look and feel is important to a significant number of users. The maintainability (or lack thereof) eliminates a lot of frustration for managers of your product. Don't be misled by the namenonfunctional requirements are as important as any other type of requirement.

Figure 8.1.

Apple's iPod music player is a runaway success, largely due to its nonfunctional requirements. The look and feel is simple and elegant, the usability is legendary (no one ever reads the instruction book), and the performance (the capacity of the hard disk, battery life, and so on) is impressive. Not to mention it is downright cool (a nonfunctional requirement). While other music players offer similar functionality, the iPod has won its dominant market share thanks to its nonfunctional qualities. (Photo courtesy Apple Computer, Inc.)

The nonfunctional requirements describe the character, or the way that functions behave.

Every product has a character that separates it from other products. You may have bought your music system because it has a different feel or is easier to use than another. You may prefer the look and feel of one personal computer or operating system to another. You might have bought your electric toaster not because it makes the toast taste any different, but because you thought that the experience of using it would be better, you liked the look of it more than the other toasters on display at the store, or you thought it was safer for children. This experience, or look, or usability is the character of the product. The nonfunctional requirements describe the character, or the way that functions behave. So what nonfunctional requirements do you need for your product?

We went back over the many requirements specifications we have written and extracted a list of the most useful properties for products to have. For convenience, we grouped these into eight major nonfunctional requirement types, and within those, subtypes or variations on the type. You can see these nonfunctional types and their identifying number in the Volere Requirements Specification Template.

There is nothing sacred about the categories we have assigned to the nonfunctional requirements. Feel free to make your own. We identified these particular categories because we have found it makes requirements gathering a lot easier if you have a checklist of the potential types of requirements. Once you are aware of the different types of requirements, you ask questions about them.

Don't spend too much time when it is difficult to precisely categorize a requirement. If in doubt, categorize it with your best guess at the type, or give it both types when it appears to belong to two categories. No harm will come from a few requirements with ambiguous types.

appendix B contains the Volere Requirements Specification Template.