The Nonfunctional Requirements

Following are the nonfunctional requirement types we use. The numbers are the identifier allocated to that type of requirement in the requirements specification template.

10.	Look and Feel: the spirit of the product's appearance
11.	Usability and Humanity: the product's ease of use, and any special usability considerations needed for a better user experience
12.	Performance: how fast, how safe, how many, how available, and how accurate the functionality must be
13.	Operational: the operating environment of the product, and any considerations that must be taken into account for this environment
14.	Maintainability and Support: expected changes, and the time needed to make them; also specification of the support to be given to the product
15.	Security: the security, confidentiality, and recoverability of the product
16.	Cultural and Political: special requirements that come about because of the culture and customs of people involved in the product's operation
17.	Legal: the laws and standards that apply to the product

We look at each of these categories in more detail later in this chapter. In some cases, the nature of the nonfunctional requirement suggests how you might go about finding any requirements of the type that apply to your product. If nothing suggests itself, there will be a discussion later in the chapter on how to go about eliciting the nonfunctional requirements.

As you read though these requirement types, keep in mind that sometimes it is difficult to say exactly what type a requirement is. When this sort of confusion arises, it might indicate that you have several requirements posturing as one. Identification of the precise type is not the most important thing. What matters is that you identify all the requirements. The categorization of the requirement is meant to help you to find the requirements; you can think of the requirement types as a checklist.

The requirement type is a device to help you to find the requirements; think of it as a checklist.

One other thing to keep in mind as you go through the various nonfunctional requirements: For the moment, we are dealing only with the description and rationale of the requirement. Some of the examples we give might seem a little vague, ambiguous, or loosely worded. The method of attack is to initially capture the stakeholder's intention for the requirement. Later you will add a measurementwe call it a fit criterionto each requirement to clarify it and make it testable. We discuss fit criteria in Chapter 9, but for the moment we ask you to accept that it is possible to measure such things as "attractive," "exciting," "easy," and other adjectives that appear in the descriptions of nonfunctional requirements.

Later you will add a fit criterion to the requirement to clarify it and make it testable.