arc42 Quality Requirements

Explanation

Chapter 10 of the arc42 template (see “arc42 Architecture Documentation Template”) is where a team writes down its quality requirements. Quality requirements describe how well a system must work, for example how fast or how reliable it must be.

Quality scenarios. Vague wishes are hard to check. So chapter 10 makes each requirement concrete as a quality scenario. A scenario lets you decide whether the requirement is fulfilled. If you cannot decide, the scenario is still too vague.

Link to section 1.2. The most important quality requirements already appear in section 1.2, the quality goals (see “arc42 Introduction and Goals”). Chapter 10 does not repeat them in full. It references them and adds further requirements of lower priority.

Why it matters. Quality requirements have a lot of influence on architectural decisions. Specific, measurable wording gives the people who decide something solid to work from.

Example

Section 1.2 names “fast search” as a top quality goal. Chapter 10 references that goal and attaches a scenario to it. The scenario states the situation and the result to check, such as a stated response time under a stated load. Chapter 10 also lists a lower-priority requirement, such as a minor reporting convenience, as its own scenario.

Trade-offs

Writing scenarios for lower-priority requirements adds documentation effort. The gain is that every quality requirement, not only the top goals, can be checked. Measurable wording also takes more work than a general statement like “the system should be fast”.

Checks

Quality requirements in chapter 10 are written as concrete scenarios that allow deciding whether each one is fulfilled.
Chapter 10 references the top quality goals from section 1.2 and adds further, lower-priority requirements.
Quality requirements are stated in specific, measurable terms.

Sources

10 - Quality | arc42 Documentation — docs.arc42.org, accessed 2026-11-08