Mission
- Measurable outcome: By the end, you can convert six vague quality claims into measurable scenarios, expose two trade-offs, and assign evidence and risk authority.
- Prerequisites: Chapters 2.1–2.2.
- Work product: A quality-attribute scenario sheet and trade-off record.
- Time: 60–75 minutes.
Before you read: Predict → Commit → Connect
Meridian Pay can reduce migration time by disabling dual-write reconciliation for low-value transactions. It would lower cost and latency but weaken recovery evidence. Predict whether to accept the change. Commit to the evidence and authority needed. Connect this to Chapter 1.1’s outcome guardrails.
Qualities are behavior under conditions
Functional requirements say what a system does. Quality attributes describe how well it behaves under meaningful conditions. “The service must be scalable and secure” is not yet actionable. A useful scenario names a stimulus, environment, affected system, expected response, and response measure.
Examples:
- Reliability: during loss of one regional dependency, approved-payment success remains above the defined threshold and reconciliation completes within the recovery window.
- Latency: at forecast peak load, 99% of eligible authorization responses complete within the agreed duration measured at the customer boundary.
- Security: an authenticated support agent cannot retrieve documents outside the customer’s entitlement, and denied attempts are logged and alerted within policy.
- Maintainability: a supported schema change can be deployed and rolled back independently without coordinated downtime.
Accessible diagram label: A quality-attribute claim becomes testable when a stimulus and environment lead to an expected response, measure, and evidence.
Do not optimize each attribute independently. Caching may improve latency and cost while creating staleness or privacy concerns. Redundant regions may improve availability while increasing operational complexity and consistency risk. Stronger authorization checks may add latency. Faster release cadence may improve learning while requiring stronger automation and rollback.
Accessible diagram label: One technical decision creates consequences across several quality attributes that must be compared in an accountable option record.
The TPM’s job is not to compute every engineering threshold. It is to make quality goals comparable across teams and ensure trade-offs reach the correct authority. Ask four questions:
- Whose experience? Customer, operator, developer, regulator, or finance?
- Under what conditions? Normal load, peak, dependency failure, attack, recovery, or change?
- At which boundary? Component, service, region, or end-to-end?
- What evidence and window? Test, production measurement, audit, cost model, or operational rehearsal?
Thresholds must connect to consequence. “Five nines” without a customer journey, measurement window, and cost is theater. Likewise, a mean latency can hide a damaging tail. Use percentiles or distribution views when appropriate, but let qualified owners choose the measure.
For Meridian, settlement accuracy may be a harder guardrail than authorization speed. During migration, Product values faster regional expansion; Engineering values simpler cutover; Finance watches duplicate infrastructure cost; Compliance requires traceability. The TPM integrates these into a visible decision rather than allowing the easiest team-local metric to dominate.
Cost deserves system treatment. Include variable usage, reserved capacity, data transfer, licenses, vendor minimums, support labor, and incident cost where material. Treat forecasts as models with assumptions, not precise facts. Maintainability also needs proxies: change lead time, dependency coupling, test duration, cognitive load evidence, or upgrade effort. No single metric universally captures it.
Decision rights: Who owns what?
Product and business owners define customer and economic priorities. Engineering and architecture own technical tactics and feasibility. SRE often owns or advises service-level objectives; Security and Privacy own policy and risk processes; Finance owns approved financial methods. The TPM integrates scenarios, conflicts, evidence, and decision timing.
If a trade-off exceeds delegated tolerances, the residual-risk authority decides. The TPM must not accept a security or reliability exception merely because the schedule is threatened.
I do
I rewrite “Meridian must be fast and reliable” as two scenarios with baselines and measurement boundaries. I ask SRE for failure conditions, Product for customer consequences, Finance for cost assumptions, and Compliance for accuracy constraints. The proposed reconciliation reduction saves cost but weakens detection of duplicate settlement. I frame three options: full, sampled with bounded exposure, or delayed region. I then route the decision with evidence to the named authority.
We do
Helios Product wants the AI assistant to answer within two seconds. Security proposes a permission check and content scan that adds measured tail latency. Together write quality scenarios and create an option that avoids “speed versus security” as a slogan.
Show the model answer
Model answer
Define customer-perceived latency at the interface, including retrieval and policy checks, under forecast peak load. Define the security scenario: an agent with one customer entitlement cannot retrieve or act on another customer’s data, including stale-index and tool-call paths. Compare measured options such as parallel safe checks, progressive response, or restricted feature scope; do not waive authorization. Product sets experience priority, Security governs policy, Engineering owns the design, and the launch authority accepts only residual risk allowed by policy.
Scoring rubric (0–4)
- 0: Chooses speed or security by opinion.
- 1: Names both attributes without measurable scenarios.
- 2: Defines conditions and measures for each.
- 3: Compares feasible options, evidence, owners, and residual risk.
- 4: Also identifies measurement boundary, tail behavior, degraded mode, and a reversible experiment.
You do
Take one “-ility” statement from a real plan. Rewrite it with stimulus, environment, response, and measure. Add five neighboring attributes and mark positive, negative, or unknown consequence. Ask the correct experts to validate the two highest-consequence cells.
Pause & Recall
From Chapter 2.2, name two asynchronous risks that can affect reliability. From Chapter 2.1, explain why measuring only at a component boundary can misrepresent customer latency. Retrieve the output–outcome–benefit chain and place quality evidence on it.
Production lens
Quality attributes become real in degraded modes, upgrades, traffic spikes, attacks, and operator actions. Require preproduction tests where credible, then production signals and rollback triggers. Revisit targets when user behavior, architecture, or regulation changes.
Workplace artifact: quality scenario and trade-off card
Attribute / stakeholder consequence:
Stimulus and source:
Environment and load/failure condition:
System boundary:
Expected response:
Measure, baseline, threshold, and window:
Evidence owner and source:
Neighboring attributes affected:
Options and assumptions:
Reversibility / rollback:
Policy constraints:
Decision owner / residual-risk owner:
Review date and production trigger:Chapter compression
Quality attributes are measurable behavior under conditions. Define actor, stimulus, environment, boundary, response, and evidence. Optimize the system of qualities, not one metric. Engineers own design; domain authorities own policy; the TPM integrates trade-offs and proof.
Retrieval deck
- Q: What turns “reliable” into a scenario? A: Stimulus, environment, system, response, measure, and evidence.
- Q: Why can averages mislead latency decisions? A: They can hide harmful tail behavior and boundary differences.
- Q: Is cost purely a Finance concern? A: No; Finance governs methods while architecture, usage, operations, and vendors create cost drivers.
- Q: Who accepts a quality exception? A: The authority named by policy or charter, within permitted risk tolerance.
- Q: What is the TPM’s quality role? A: Integrate scenarios, trade-offs, evidence, owners, and decision timing.
Spaced review
- Now: Turn one vague “-ility” into a full scenario.
- 1 day: Write that scenario again from memory.
- 3 days: Add a neighboring attribute and explain the trade-off.
- 7 days: Revisit the scenario under a dependency failure.
- 14 days: Compare the predicted trade-off with production or test evidence.