Quality Attributes and NFRs

A product manager writes the performance requirement for the new checkout service: 'The system shall be fast, highly available, and scalable.' The team implements something, ships it, and the first real argument happens in a incident channel at 2 a.m. — because 'fast' meant 200 ms to the frontend team, 50 ms to the mobile team, and 'fast enough that nobody complains' to the DBAs, and none of those were written down.

Quality attributes describe how a system behaves under conditions rather than what it does. Functional requirements say the service computes a discount; quality attributes say what happens to that discount calculation when 5,000 shoppers hit it during a flash sale, when the primary database region is unreachable, or when an attacker replays last year's tokens. The classic split calls these non-functional requirements (NFRs), but the more useful term is quality attributes because 'non-functional' tricks people into thinking they are optional polish rather than the properties users actually pay for.

The cure for vagueness is the scenario format from the SEI's attribute work. Every quality attribute scenario names six things:

The response measure is the load-bearing part. Without it, you have a story, not a requirement. Compare the two versions a reviewer sees:

Weak:  'Checkout must be fast and handle load.'
Good:  'During peak (3x median traffic, 5k concurrent sessions), the
       cart API completes 95% of add-to-cart calls in < 100 ms and
       99% in < 250 ms at the edge, with error rate < 0.1%, using
       read replicas; no request may be lost on replica failover.'

The good version can be turned into a load test, an SLO, and a capacity plan. The weak version can only be argued about.

Five attributes cover most of what you will be asked to specify, and each has a canonical measure worth memorizing because they come up in interviews constantly:

A discipline that separates juniors from seniors here: when someone hands you an NFR you cannot measure, the reply is a single question — 'what test would prove that to you?' If they cannot answer, the requirement does not exist yet, and writing it into the design is premature. Capture it as an open question, which is exactly the subject of Constraints, Assumptions, and Risks.

A design review where every quality attribute is 'critical' produces two failure modes. Teams optimize the attribute that is easiest to demonstrate — usually latency, because a benchmark graph looks impressive — while the attribute that actually governs revenue, often consistency of inventory counts, goes unspecified. Or they spread effort thin, bolting on a caching layer 'for performance' and a second region 'for availability', each half-finished. Ranking attributes with stakeholders prevents unbounded optimization of everything at once, and the ranking is a designed conversation, not a survey.

Start by eliciting each attribute independently, because stakeholders anchor each other if you put them in one room. Send five to ten scenarios and ask each stakeholder to mark each one must-have, should-have, could-have, or won't-have this quarter (MoSCoW), then bring the answers to a two-hour session. Expect the disagreements — that is the point of the session:

From there, build a small utility tree: each attribute, its scenario, a rough business weight (1–5), and a technical difficulty score (1–5). Weight divided by difficulty is crude, but it does its job — it makes visible that a must-have attribute with difficulty 5 is a project, while a could-have with difficulty 2 is a ticket. The output is a short list: typically two must attributes the architecture must be designed around, two to three that must be supported, and the rest explicitly deferred. Deferral is a deliverable: writing 'durability below 99.999% is acceptable for recommendation logs, not for orders' prevents the team from rediscovering the question every sprint.

Watch for three ranking traps in the session:

• Everything is a 5. Force ordering: 'if you could have only one of latency or availability this quarter, which one?' Pairwise comparison breaks ties that MoSCoW creates.
• The loudest stakeholder wins. Capture the reasoning in writing so the ranking survives their absence, and re-rank quarterly when the business changes.
• Attributes get ranked, scenarios do not. 'Availability' at 99.9% vs 99.99% is 43 minutes vs 4 minutes of downtime per month. The unit of ranking must be the full scenario with its measure, not the label.

Interviewers probe exactly this: 'how do you decide what to optimize first?' The strong answer describes eliciting scenarios independently, resolving disagreements by attaching each scenario to a business outcome, and producing an explicit deferral list. Hand-waving about 'balancing trade-offs' scores nothing. The deliverable of the session fits on one page: ranked scenarios, each with its measure, its owner, and a one-line business reason for its position, followed by the deferral list. That page comes back at every later design review, because the inevitable question - should we also add a cache for performance? - is answered by pointing at the ranking: caching serves the number-two attribute, while the number-one attribute, inventory consistency, would be harmed by a stale cache. The ranking does not end arguments about taste; it removes them from the agenda by pre-committing to what the business chose.

A ranked scenario with a response measure is still a document. It becomes architecture when three artifacts exist: an SLO the on-call can be held to, a test that reproduces the scenario, and an alert that fires when reality diverges from the measure. Walk the path with one attribute — peak-load latency — then compress the same recipe for the others.

Latency. Scenario: 5k concurrent sessions, cart API p99 < 250 ms at the edge. The SLO is written against what you can measure continuously, so edge latency (what the user sees) becomes the SLO, while server-side latency becomes the debugging dimension:

# slo.yaml — cart service
indicator:
  good:    p99(edge_latency_ms) < 250
  acceptable: p99(edge_latency_ms) < 400
window: 30d rolling
target: 99% of requests good
budget_burn_alert: > 2x expected burn rate over 1h

The load test is derived mechanically from the scenario: 5k sessions, a realistic mix (60% browse, 30% cart, 10% checkout), a ramp that holds peak for 30 minutes — long enough for caches, connection pools, and autoscalers to reach steady state. A 2-minute spike test that never lets pools warm is not this scenario. Then find the ceiling and write it down: 'the cart tier degrades past 8k sessions per node; adding a node is the documented scale step.' Capacity without a documented breaking point is another unmeasured NFR.

Availability. 99.95% monthly is 21.9 minutes of allowed downtime, so the SLO math forces the real discussion: what counts as down (5xx at the edge? health-check failure? partial degradation where checkout works but recommendations do not?), and what error budget buys. A team burning 60% of its budget in the first week should be freezing feature launches, and saying that in advance is the only way the policy holds under pressure.

Consistency and recovery. Finance's 'exactly-once ledger writes' becomes RPO: how much data can vanish in a failure? RPO 5 seconds means synchronous replication or a write-ahead shipping scheme; RPO 24 hours would allow nightly backups — an enormous architectural difference hiding behind one adjective. RTO (time to restore) similarly forces topology: 30-minute RTO may justify a warm standby; 4-hour RTO does not. Disaster recovery drills are the response measure — an untested failover plan is an assumption, and the risk register is where assumptions go to be tracked.

Security. The same format applies: stimulus is an attacker or a leaver, response is detection or prevention, and the measure is concrete — 'revoking an employee's credentials takes effect on every service within 60 seconds', 'all internal RPC requires mTLS, no exceptions', 'we detect credential stuffing within 5 minutes via anomaly rate alerts'. Vague security NFRs are the most common kind, and the scenario format is the most effective cure.

The final check before design work starts: every must-have scenario from the ranking session maps to exactly one test and one alert. Any scenario with no test is not committed to; any alert with no scenario is noise waiting to happen. Three habits keep the SLO honest once it is live. First, measure at the boundary the user experiences - edge latency, not server time - and keep server-side metrics as drill-down dimensions, because an SLO on internal numbers can read green while customers see errors. Second, set the alert on budget burn rate rather than on raw thresholds: a service missing its p99 target during a 10x spike for ten minutes is not a paging event, but burning a week of error budget in an hour is. Third, run the failover and revocation drills on a schedule, because the response measure of recovery and security scenarios is the only thing that proves the paper design survives contact with reality.