Skip to content
Software Architecture Guide

Quality Attribute

Explanation

Section titled “Explanation”

A quality attribute is a property of a system that shows how well it meets what stakeholders need. Stakeholders are the people with an interest in the system. ISO/IEC 25010 defines system quality as the degree to which a system satisfies stated and implied needs. See the article “ISO/IEC 25010 Product Quality Model” for details.

A catalog of qualities. The ISO/IEC 25010 product quality model lists nine quality characteristics. Examples are functional suitability, performance efficiency, compatibility and interaction capability.

Why the word “quality” alone is not enough. The term is vague and broad. A requirement like “the system must be of high quality” cannot be built or tested. Quality requirements must describe stakeholder expectations in a specific and measurable way.

Scenarios make qualities concrete. A quality scenario is a short description of a situation and the expected outcome. Scenarios turn vague quality requirements into concrete ones. They should be specific and measurable. They are a practical way to document what quality is required. Bass et al. at the SEI coined the term “quality attribute scenarios” for this kind of structured requirement. See “Quality Attribute Scenario”.

Two kinds of scenarios. arc42 separates two kinds:

  • Usage scenarios describe how the running system reacts to a stimulus.
  • Change scenarios describe a modification or extension of the system.

This maps to qualities that show up at runtime and qualities that show up when people change the system.

Influence on architecture. Quality requirements strongly influence architectural decisions. For this reason, arc42 gives them their own section. See “arc42 Quality Requirements”.

Example

Section titled “Example”

A team writes “the shop must be fast.” Nobody can test that. They rewrite it as a usage scenario: a customer submits an order, and the system confirms it within a stated time limit. They also write a change scenario: a developer adds a new payment method, and the work stays within a stated effort. Both statements are specific and measurable, so the team can check them and use them when choosing a design.

Trade-offs

Section titled “Trade-offs”

The supplied facts do not describe trade-offs between qualities. Writing scenarios takes effort, but it replaces vague wishes with statements that people can check.

Checks

Section titled “Checks”
  • Quality requirements are written as specific, measurable scenarios, not as vague terms like “high quality”.
  • The document separates usage scenarios (runtime reaction to a stimulus) from change scenarios (modifying the system).
  • Quality requirements have their own section, and architectural decisions refer to them.
Section titled “Related”

Sources

Section titled “Sources”