Linking the Supplementary Specification to the Use Cases

We've described the role that use cases play in defining the functional behavior of the system, and we've defined how the nonfunctional requirements are captured in the supplementary specification. Some questions naturally arise: How do these nonfunctional requirements apply to the use cases? Do specific use cases have associated nonfunctional requirements, and, if so, how could we indicate that?

One way to do so is to define certain classes of nonfunctional requirements. For example, we might define "Quality of Service" classes for response time as follows :

• Class 1 : 0 to 250 milliseconds

• Class 2 : 251 to 499 milliseconds

• Class 3 : 0.5 to 2 seconds

• Class 4 : 2.1 to 12 seconds

• Class 5 : 12.1 seconds to 60 minutes

Then we could associate these classes with special requirements recorded in the use case itself. For example, Use Case A might record

Response time:

Class 2 for main flow of events

Class 4 for all exceptions

Use Case B might record

Response time:

Class 5

You can do the same for other classes of nonfunctional requirements (such as reliability, safety, and so on) and map these requirements to the specific use cases.

Alternately, if you have traceability tools, you can simply trace the nonfunctional requirements to those use cases to which they are applied. (We'll explore traceability in detail in Chapter 27.)