10. Quality Requirements¶

Help: This section contains all quality requirements as a quality tree with scenarios. The most important ones have already been described in Section 1.2 (Quality Goals).

Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved.

Motivation: Since quality requirements will have a lot of influence on architectural decisions, you should know for every stakeholder what is really important to them, concrete and measurable.

Form: Use a quality tree and quality scenarios following the ISO 25010 quality model or a similar quality model.

10.1 Quality Tree¶

Help: The quality tree (as defined in ATAM -- Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leaves. The quality tree provides a high-level overview of the quality goals and requirements, using a tree structure with quality categories as roots and concrete quality scenarios as leaves.

Content: The top-level quality attributes (from the ISO 25010 model or a custom model) with refinements and concrete quality scenarios.

Quality
├── Performance Efficiency
│   ├── Time Behavior
│   │   └── <Scenario P1>
│   ├── Resource Utilization
│   │   └── <Scenario P2>
│   └── Capacity
│       └── <Scenario P3>
├── Reliability
│   ├── Availability
│   │   └── <Scenario R1>
│   ├── Fault Tolerance
│   │   └── <Scenario R2>
│   └── Recoverability
│       └── <Scenario R3>
├── Security
│   ├── Confidentiality
│   │   └── <Scenario S1>
│   ├── Integrity
│   │   └── <Scenario S2>
│   └── Accountability
│       └── <Scenario S3>
├── Maintainability
│   ├── Modularity
│   │   └── <Scenario M1>
│   ├── Testability
│   │   └── <Scenario M2>
│   └── Modifiability
│       └── <Scenario M3>
├── Usability
│   ├── Learnability
│   │   └── <Scenario U1>
│   └── User Error Protection
│       └── <Scenario U2>
└── Portability
    ├── Adaptability
    │   └── <Scenario PT1>
    └── Installability
        └── <Scenario PT2>

10.2 Quality Scenarios¶

Help: Concretization of (sometimes vague or implicit) quality requirements using quality scenarios.

These scenarios describe what should happen when a stimulus arrives at the system: - Source of stimulus: Who or what generates the stimulus? - Stimulus: What is the event or condition? - Environment: Under what conditions does the stimulus occur? - Artifact: What part of the system is stimulated? - Response: What should the system do? - Response measure: How is the response measured?

Motivation: Quality requirements tend to be abstract and vague. Scenarios make them concrete and communicable. They also serve as acceptance criteria for architecture evaluations.

Performance Scenarios¶

ID	Scenario	Stimulus	Response Measure	Priority
P1	\<e.g., Under normal load, the system responds to user requests>	\<1000 concurrent users>	\<95^th percentile response time < 200ms>	\<High>
P2	\<e.g., During peak load, the system continues to function>	\<5x normal traffic spike>	\<No errors, response time < 2s>	\<High>
P3	\<e.g., Batch processing completes within the processing window>	\<1M records to process>	\<Complete within 4 hours>	\<Medium>

Reliability Scenarios¶

ID	Scenario	Stimulus	Response Measure	Priority
R1	\<e.g., System remains available during single-node failure>	\<One compute node crashes>	\<Zero downtime, automatic failover < 30s>	\<High>
R2	\<e.g., System recovers from database failure>	\<Database becomes unavailable for 5 minutes>	\<Automatic reconnection, no data loss>	\<High>
R3	\<e.g., System recovers from complete outage>	\<Full system restart required>	\<RTO < 15 minutes, RPO < 5 minutes>	\<Medium>

Security Scenarios¶

ID	Scenario	Stimulus	Response Measure	Priority
S1	\<e.g., Unauthorized access attempt is blocked>	\<Invalid credentials submitted>	\<Access denied, event logged, alert after 5 attempts>	\<High>
S2	\<e.g., Sensitive data is protected in transit>	\<Network traffic intercepted>	\<All data encrypted with TLS 1.3>	\<High>
S3	\<e.g., User actions are auditable>	\<Compliance audit requested>	\<Full audit trail available for past 12 months>	\<Medium>

Maintainability Scenarios¶

ID	Scenario	Stimulus	Response Measure	Priority
M1	\<e.g., Adding a new business rule>	\<New requirement from product owner>	\<Changes isolated to single service, < 2 days effort>	\<High>
M2	\<e.g., Upgrading a dependency>	\<Security patch for library>	\<Update and deploy within 4 hours>	\<Medium>
M3	\<e.g., New developer onboarding>	\<New team member joins>	\<Productive within 1 week using documentation>	\<Medium>

Usability Scenarios¶

ID	Scenario	Stimulus	Response Measure	Priority
U1	\<e.g., First-time user completes key task>	\<New user without training>	\<Task completed within 5 minutes>	\<Medium>
U2	\<e.g., User makes input error>	\<Invalid form submission>	\<Clear error message, no data lost, easy correction>	\<Medium>

Based on the arc42 architecture template (https://arc42.org).
Created by Dr. Peter Hruschka and Dr. Gernot Starke.
Licensed under CC BY-SA 4.0.