Quality Attributes

1Concept / Definition

A quality attribute (QA) is a measurable or testable property of a system that indicates how well the system satisfies the needs of its stakeholders — beyond the fact that it performs its functions. Examples: latency of checkout, availability of payments, time to add a new payment rail, time to detect a security breach.

2Why It Exists

Early software projects specified features in detail and qualities in one sentence ("the system shall be fast and reliable"). Systems then passed functional tests and failed in production — slow under load, down during peaks, impossible to change. The quality attribute concept exists to make those properties explicit, prioritised and verifiable so they can be designed in, not discovered late.

3Core Concepts

3.1 Definition

A good definition has three parts: a property (latency, availability, lead time), a stakeholder who cares about it, and a measure that shows whether it is achieved. Without the measure, the attribute is an opinion.

3.2 Functional vs Quality Requirements

Some requirements look functional but hide a quality: "the admin can export all orders" becomes architecturally significant when "all" means 400 million rows and the export must finish in under 10 minutes without slowing checkout.

3.3 Quality Attribute Scenarios

A quality attribute scenario turns a quality into a testable statement using six parts. Chapter 2 covers scenarios in depth; here is the shape.

3.4 Architecture Significance

Not every quality requirement shapes the architecture. An architecturally significant requirement (ASR) is one whose satisfaction depends on structural decisions — changing it later would require restructuring.

4How It Works Internally — From Stakeholder Need to Design

4ADeep Dive — Qualities Are Properties of the Whole System

A quality attribute is rarely owned by one component. Checkout latency is the sum of network, edge, service logic, dependencies and database; availability is the product of every component on the path. This is why qualities are architectural: they emerge from how components are arranged and interact, not from any single piece of code.

5APIs / Features / Syntax — Capturing Qualities

A lightweight way to keep qualities visible is to store them as a versioned quality requirements catalogue next to the code and link each entry to tests and dashboards.

# docs/quality/qr-catalogue.yaml  (versioned with the architecture)
- id: QR-07
  attribute: performance
  artifact: checkout-service
  scenario: >
    1,500 checkouts/s from mobile+web shoppers during sale peak, all AZs healthy
  response: order accepted and confirmed
  measure: { p95_ms: 800, p99_ms: 1500, error_rate_max: 0.001, window: 5m }
  priority: { business: H, risk: M }
  verified_by: [ k6/checkout-peak.js, grafana/checkout-slo ]
  owner: checkout-team

// Instrumenting the artifact so the measure can be observed (Micrometer, Spring Boot 4)
@Timed(value = "checkout.place", histogram = true,
       percentiles = {0.95, 0.99}, description = "QR-07 checkout latency")
public OrderConfirmation place(CheckoutCommand cmd) {
    return checkout.complete(cmd);
}

6Practical Examples

6.1 ShopNow: two stakeholders, one word

The business said "checkout must be fast". Marketing meant "the pay button responds instantly on 4G phones"; engineering assumed "server time under 2 s". Writing QR-07 as a scenario exposed the gap: the agreed measure became p95 ≤ 800 ms server-side and ≤ 2.5 s end-to-end on a 4G device profile, which added a CDN and a lighter mobile payload to the design.

6.2 A hidden quality becomes significant

The requirement "support can search any order" looked functional. Asking about scale revealed 400M orders and a 2-second search target. It became an ASR and led to an OpenSearch read model fed by order events instead of SQL LIKE queries on the transactional database.

6.3 Same features, two architectures

6.4 Worked example — classify requirements

Scenario. The product owner for ShopNow's coupon feature handed the architect a list of twelve "requirements". They mixed what the feature should do with how well it should do it, plus rules nobody could change, so the team could not tell which items should shape the architecture.

What it shows. Classifying each item separates three kinds of requirement. "A customer can apply a coupon" is functional: it describes behaviour. "Coupon validation p99 at most 50 ms" and "a new coupon type within three days" are quality requirements, for performance and modifiability, with measurable targets. "Coupons stored in the India region" is a constraint: a fixed boundary the design must respect, not a quality to trade off. Each category is handled differently: functions become features and tests, qualities become scenarios and tactics, and constraints narrow the solution space.

Takeaway. Classify requirements before designing. Quality requirements and constraints drive architecture far more than functional ones, and they are easy to lose when mixed into a feature list.

6.5 Worked example — from concern to scenario

Scenario. ShopNow's CISO said, "We must know quickly if someone abuses admin access." The statement was important but impossible to design or test as written.

What it shows. The architect turned the concern into a quality attribute scenario. The attribute is security, specifically detection. The stimulus is an admin account performing more than 50 reads of personal data within ten minutes; the environment is normal operation; the response is an alert and automatic suspension of the account; and the response measure is within five minutes. The scenario is now specific enough to choose tactics, such as audit events streamed to a detection rule, and to test them with a simulated abuse.

Takeaway. Convert stakeholder concerns into six-part scenarios with measurable responses. A concern becomes architecture only when you can test whether the system meets it.

6.6 Worked example — significance scoring

Scenario. ShopNow's backlog contained dozens of quality requirements, and the architects could not analyse all of them in depth before the first release.

What it shows. Scoring each requirement on business value and on the cost of changing the design later shows which ones are architecturally significant. Multi-region disaster recovery with a one-hour recovery time is high on both, so it must be decided now, because retrofitting it is very expensive. A checkout p95 of 800 ms is high value with moderate change cost, so it is also significant. Dark mode and CSV or Excel export are low on change cost, so they can be handled later without affecting the architecture.

Takeaway. Focus architecture effort on requirements with high value and high cost of change. Everything else can be decided later, when more is known.

6.7 Worked example — verifying QR-07

Scenario. ShopNow's quality requirement QR-07 states that checkout must keep p95 latency under 800 ms at 1,500 requests per second. Previously, nobody checked it until customers complained during a sale.

// k6 thresholds encode the response measure (verified in CI before each release)
export const options = {
  scenarios: { peak: { executor: 'constant-arrival-rate', rate: 1500, timeUnit: '1s',
                       duration: '30m', preAllocatedVUs: 2000 } },
  thresholds: {
    'http_req_duration{name:checkout}': ['p(95)<800', 'p(99)<1500'],
    'http_req_failed{name:checkout}': ['rate<0.001'],
  },
};

What it shows. The k6 script encodes the requirement directly. A constant-arrival-rate scenario generates exactly 1,500 requests per second for 30 minutes, regardless of how fast the system responds, which matches real open traffic. Thresholds on the p95 duration and on the error rate turn the response measure into a pass or fail result. The test runs in CI against a production-like environment before each release, so a regression blocks the release instead of reaching customers.

Takeaway. Make quality requirements executable. A requirement checked automatically on every release is a guarantee; one written only in a document is a hope.

6.8 Worked example — interview answer structure

Scenario. In interviews, ShopNow asks candidates, "What is a quality attribute, and why does it matter to an architect?" Many answer with a list of words such as scalability and security.

Why it works. The structure in the table builds a complete answer in four steps. Define it as a measurable property of how well the system serves its stakeholders. Contrast it with functional requirements: functions say what the system does, qualities say how well, and qualities drive the architecture. Give a concrete example, such as checkout p95 at most 800 ms at 1,500 requests per second, and the tactics it led to. Close with how the quality is verified, such as load tests in CI and production dashboards.

Takeaway. Answer with a definition, a contrast, a measurable example and how you verify it. That shows you can apply quality attributes, not just name them.

7Common Problems & Mistakes

8Performance & Production Considerations

9Architecture & Design Considerations

10Interview Questions & Answers