Skip to content
Software Architecture Guide

Quality attributes in use case descriptions

Explanation

Section titled “Explanation”

Some quality requirements apply to the whole system. Others apply to one use case only. System-wide requirements need their own place, separate from the use cases. Use-case-specific requirements can sit in the use case text itself. Most non-functional requirements in a system are of this second kind.

Linking function to quality. A quality requirement is easier to act on when it names the feature it applies to. A useful question is: which functional requirement needs this quality property? Use-Case 2.0 builds this link in. Each slice of a use case inherits the non-functional requirements of its parent use case.

Refining into scenarios. A line such as “must be fast” is vague. A quality attribute scenario makes it concrete and measurable (see Quality Attribute Scenario). arc42 says such scenarios let you decide whether a requirement is fulfilled. They should be specific and measurable.

The use case supplies raw material for the scenario:

  • Its functional context gives the sources and stimuli. Splitting a story into smaller pieces gives the same kind of input.
  • Operating conditions go under “environment”.
  • The behavior goes under “response”.

Finding gaps. Writing the scenario forces you to ask which environment applies. Is it normal operation, peak load, or an error situation? If the use case does not say, you have found a gap in the requirements.

Traceability. arc42 section 10 describes quality scenarios. It builds on the top quality goals from section 1.2. It also mentions the quality tree (also called utility tree). Scenarios derived from use cases can be listed there.

Example

Section titled “Example”

A use case “Place order” has a field for its own non-functional requirements. It says only “must be fast”. The team asks which environment this applies to and writes a scenario: a customer submits an order (stimulus) during peak load (environment). The system confirms the order (response) in under a set time (response measure). While writing it, the team notices the use case never said what should happen when the payment service fails. That is a gap to close.

Trade-offs

Section titled “Trade-offs”

Scenarios make requirements measurable, but they are also a bit repetitive. Keeping requirements inside each use case is convenient, but system-wide requirements must still be written down separately. Otherwise they get lost or are repeated in every use case.

Checks

Section titled “Checks”
  • System-wide quality requirements are stated separately from the use cases.
  • Each use-case-specific quality requirement names the functional requirement it applies to.
  • Each quality requirement for a use case states which environment applies, such as normal operation, peak load or error.
  • Quality requirements from use cases are refined into specific, measurable scenarios.
Section titled “Related”

Sources

Section titled “Sources”