Following are the nonfunctional requirement types we use. The numbers are the identifier allocated to that type of requirement in the requirements specification template.
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. |