Finding the Nonfunctional Requirements


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 Requirements

When 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 Cases

You 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:

Description: The product shall appear familiar to new engineers.

Rationale: We frequently have new junior engineers and want the product to have an appearance that is acceptable to them.


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:

Description: the product shall produce a schedule that is easy to read.

Rationale: It is important that only the correct roads are treated.


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:

The product shall produce the schedule within 3 seconds of the user's request.


And here's another performance requirement:

The product shall be able to do ice prediction calculations for 5,000 roads.


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:

The product shall enable the addition of new road authority areas within two days.


Also, this product use case is usually activated at night:

Description: The product shall be self-supporting.

Rationale: There is no help desk, nor will other users be available.


Security requirements deal with access to the product. For the IceBreaker product, the client does not want unauthorized people running the schedule:

The product shall allow access only to junior and higher-grade engineers.


There is also an audit need here, as road authorities must be able to prove they treated the roads correctly:

The product shall retain all ice predictions for all occasions the schedule is run.


Cultural and political requirements are not considered important to this product use case. The client believes the engineers are fairly thick-skinned:

The product shall be acceptable to the engineering community.


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 product shall produce an audit report of all road schedules and their subsequent treatments. This must comply with ISO 93.080.99.


The Template

Use 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 Requirements

You 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.


The product shall distinguish clearly between safe and unsafe roads The product shall make any unsafe roads obvious.


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 Client

The 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.

Table 8.1. Finding Nonfunctional Requirements

Who or What Is (Are) . . .

Do They (Does It) Have These Requirements?

The users (3)

Look and Feel (10)

Usability (11): Are there any special considerations for this kind of user?

Security (15): Do you have to protect, or protect against, the users?

Cultural and Political (16)

The operating environment (4, 6, 7, 8)

T Operational (13): particularly collaborating products

Performance (12): demands made by the environment.

Maintenance (14): Consider proposed changes to the environment.

The client, the customer, and other stakeholders (2)

Cultural and Political (16)

The adjacent systems (7, 8)

Legal (17): Include special rights for this kind of adjacent system.

Operational (13)

Performance (12)


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.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net