Quality Attribute Checklist for Architects

Architecture is largely the management of quality attributes: performance, availability, security, modifiability and others, which are the non-functional properties users and operators care about. This track provides a checklist you can apply to any design review, along with a method for turning vague wishes into testable scenarios. Use it as a prompt for questions, not as a compliance form.

Learning goals

• Express quality requirements as concrete scenarios.
• Review a design systematically across the main quality attributes.
• Spot attribute conflicts and make trade-offs explicit.
• Build a repeatable review habit.

Step 1: Write quality attribute scenarios

A scenario has six parts, following the SEI approach: source, stimulus, artifact, environment, response and response measure.

Source:       A user in the EU
Stimulus:     Submits a checkout request
Artifact:     Order service
Environment:  Normal load, one availability zone down
Response:     Order is accepted and persisted
Measure:      p99 under 500 ms, no lost orders

Without a response measure, a requirement cannot be tested. "The system must be scalable" becomes "sustain 3,000 orders per minute with p95 under 400 ms, scaling horizontally within five minutes of a 3x spike."

Step 2: Apply the checklist

Work through each attribute, asking questions and noting evidence rather than opinions.

Performance and scalability

• What are the expected peak and average loads, and how were they estimated?
• Where are the bottlenecks: database, locks, network, a third-party call?
• Is there a load test, and does it reflect production data skew?
• What happens at ten times current load: degrade, queue, or fail?

Availability and resilience

• What is the availability target and the failure domains (instance, zone, region, dependency)?
• Are timeouts, retries with backoff and jitter, and circuit breakers defined for every remote call?
• Is there a defined degraded mode?
• Have recovery and failover been exercised, not only documented?

Security

• Where are the trust boundaries and what crosses them?
• How are authentication, authorisation and secrets handled?
• Which data is sensitive, and how is it encrypted in transit and at rest?
• Has a threat model, such as STRIDE, been done for the new components?

Modifiability and maintainability

• Which changes are most likely in the next year, and how many modules would each touch?
• Are dependency directions enforced?
• Can components be tested in isolation?
• Is there documentation or an architecture decision record explaining non-obvious choices?

Observability and operability

• Can an on-call engineer tell what is wrong from dashboards and traces in minutes?
• Are there service level indicators with alerts tied to user impact?
• Is deployment automated and rollback fast?
• Is there a runbook for each known failure?

Data integrity and consistency

• Which operations require strong consistency, and which tolerate staleness?
• Are writes idempotent, so retries are safe?
• How are backups verified by restoring?

Cost

• What is the cost per request or per customer at current and projected scale?
• Which components dominate the bill, and what is the plan if usage grows tenfold?

Step 3: Surface conflicts

Attributes pull against each other. Record the conflicts explicitly.

| Choice | Improves | Costs | |---|---|---| | Synchronous replication | Consistency | Latency, availability | | Aggressive caching | Performance, cost | Freshness, complexity | | More encryption layers | Security | Latency, operability | | Microservices | Team autonomy, scaling | Operational load, consistency |

State which attribute wins and why, in an ADR.

Step 4: Practice in four sessions

1. Session 1: Take a system you know and write five scenarios with measures.
2. Session 2: Run the checklist on its design and list gaps with evidence.
3. Session 3: Choose the two riskiest gaps and propose fixes with trade-offs.
4. Session 4: Review a colleague's design using only questions from this list, then compare findings.

Exercises

• Convert three vague requirements from a real backlog into full scenarios.
• Take one scenario and design a test that proves or disproves it, such as a game day or load test.
• Identify the single highest-risk attribute for your system and justify the choice with evidence.

Key takeaways

• Quality attributes only become useful when written as measurable scenarios.
• Review across performance, availability, security, modifiability, operability, data integrity and cost.
• Ask for evidence such as tests, drills and dashboards rather than assurances.
• Make attribute conflicts and the chosen trade-offs explicit.
• Repeat the review regularly; the answers change as the system and load change.