Like all requirements, the nonfunctional ones can come to light at any time. However, there are places where we can look that give us better opportunities to discover them. Blogging the RequirementsWhen you are trying to elicit nonfunctional requirements, blogs and wikis can be immensely useful. Start a blog (or any other form of online collaborative thread) using the template's nonfunctional sections and subsections as headings. That is, don't just say "Usability Requirements"; instead, use the subsections "Ease of Use," "Personalization and Internationalization," "Ease of Learning," "Understandability and Politeness," and "Accessibility." Invite and encourage your team and your stakeholders to contribute what they think are the right properties for the product to have in these categories. You will inevitably receive a number of solutions instead of requirements, but they will provide you with the basis from which to make the abstraction to find the requirement. Do not place any limits on what people can contributeaccept that you will need to analyze the ideas to discover the underlying requirements. Use CasesYou can consider each use case from the point of its nonfunctional needs. For example, the IceBreaker product has a product use case called "Detect icy roads." This produces the road de-icing schedule showing the roads to be treated and the trucks allocated to them. The relevant stakeholders tell you that the schedule will be used by a junior or medium-grade engineer. For each of the nonfunctional requirements types, interview these stakeholders about the product's needs. For exampleand we list these requirements in the order they appear in the templatethe look and feel of the schedule should be such that new engineers (they have a high turnover) can immediately feel comfortable with it:
This requirement is slightly more difficult to quantify, but you will be able to write a suitable fit criterion for it after you have read Chapter 9. For the moment, the stakeholders' intention is sufficient. The usability and humanity requirements for the product use case are next. The stakeholders want the schedule to allow an engineer to easily direct the trucks to the correct roads. The requirement looks like this:
The rationale shows us that the reason for wanting an easy-to-read schedule relates to accuracy of the road treatment. Thus, when you write the fit criterion for this requirement, you would add a quantification to measure that the correct roads have been treated. Performance requirements focus on issues such as how many, how fast, and so on. In this case, the schedule has to be produced within a few seconds of the engineer wanting it:
And here's another performance requirement:
Operational and environmental requirements deal with the physical operating environment. In the IceBreaker example, they will be the same for all the product use cases. Naturally, you need write them only once, and they describe the mandated computers, the database, and so on for the product as a whole. Maintainability and support requirements specify any special conditions that apply to keeping the product up to date or adapting it to another environment. The client for the IceBreaker product intends to monitor roads for different road authorities, so a maintainability requirement is written like this:
Also, this product use case is usually activated at night:
Security requirements deal with access to the product. For the IceBreaker product, the client does not want unauthorized people running the schedule:
There is also an audit need here, as road authorities must be able to prove they treated the roads correctly:
Cultural and political requirements are not considered important to this product use case. The client believes the engineers are fairly thick-skinned:
And finally we reach the legal requirements. Many road authorities have a statutory obligation to prove that they have exercised due diligence in monitoring and treating the roads under their control:
The TemplateUse the template as a checklist of nonfunctional requirement types when interviewing your stakeholders. Go through the template looking at each of the subtypes and probe for examples of each. Refer to the template (found in appendix B) for more explanation and examples of the nonfunctional requirements. Prototypes and Nonfunctional RequirementsYou can use prototypes to help drive out nonfunctional requirements. The prototype at requirements time is usually a whiteboard sketch, a paper prototype, or some other quick-and-dirty mock-up of what the product might be like. The intention is not to design the product, but rather to ensure you have understood the needs by reverse-engineering the requirements from the prototype. In the case of the scheduling product use case, your stakeholders respond favorably to a sketch of a screen showing the roads to be treated in a glowing, cold blue color; the safe roads in green; and the treated roads in yellow. The engineers are delighted they can see the topography of the district and the roads.
See Chapter 12 for detailed guidance on building requirements prototypes.
You do not yet know that "a glowing, cold blue color" is intuitiveyou need some ergonomic input or user surveys for that. But the intention is clear from the prototype. Go over your own prototypes using the template. For each of the nonfunctional types, which requirements does the prototype suggest? Go through the prototype carefully, and keep in mind that it is not the requirement, but a simulation of the requirement. It is far too risky to hand over the prototype to the developer and expect the correct product to emerge. The ClientThe client for the product may also have expectations that are relevant here. In many cases, the reason for building a new product is to provide a service to the users or to the customers of the business, and the attractiveness of that service depends on one or more nonfunctional qualities. For example, providing portable, or highly usable, or secure functionality may be crucial to the development effort. Alternatively, your client may say that if you cannot provide an interactive and graphic display of the current trading position, then he does not want the product. Thus your client becomes the prime source of the critical nonfunctional requirements. Once the functional requirements are met, it may be the nonfunctional qualities that persuade a potential customer to actually buy your product. Consider the nonfunctional properties of products that you admire, or you have bought. Table 8.1 summarizes the questions you should ask for a use case or a functional requirement. Ask your client to what degree these questions are relevant to the product that you are specifying. Your client, or the marketing department, is the source of what will make customers buy the product. Make use of them.
For each use case or the product as a whole, consider the factor in the first column. When you have an adequate knowledge of the factor, use it as a trigger to raise questions about the requirement types in the second column. The numbers in parentheses correspond to the sections in the Volere Requirements Specification Template. |