Non-Functional Requirements
Latency, security, availability, accessibility, cost, auditability, scale — the qualities of a system, each of which is a requirement only when it has a measurement and someone who cares about it. The skill is finding the ones this system actually has, and refusing the ones it does not.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
Which qualities does this system genuinely need — measured how, for whom — and which ones are being added because they sound like what serious systems have?
The store's functional requirements are written. Someone says "and it needs to be fast, secure, scalable and highly available". Everyone nods. You have no idea what any of those four words means for this store, and you suspect the person who said them does not either.
Take each word as a requirement and design for it. Fast means a cache; secure means an auth framework and a security review; scalable means horizontal services behind a load balancer; highly available means multiple regions. Each one is a recognised concern with a recognised answer, and adopting the answers looks like diligence.
Every quality gets the enterprise-shaped answer regardless of whether the store has the enterprise-shaped problem. A store with a few hundred orders a day gets a multi-region deployment because "highly available" was said in a meeting, and the team spends its first month on infrastructure for a load that does not exist.
- Every quality gets the enterprise-shaped answer regardless of whether the store has the enterprise-shaped problem. A store with a few hundred orders a day gets a multi-region deployment because "highly available" was said in a meeting, and the team spends its first month on infrastructure for a load that does not exist.
- Without a measurement, the quality can never be met. "Fast" has no finishing line, so the cache is added, then a second cache, then a CDN, and the page is still "not fast enough" because nobody said what fast was.
- The qualities that actually matter for this store are missed because they are not on the standard list. Nobody said "auditable" — but a store that cannot reconstruct why a customer was charged what they were charged has a real problem the first time a dispute arrives.
- Security becomes a phase rather than a requirement. "We'll do a security review before launch" means the design was made without asking which data is sensitive and who may see it, and the review finds problems the design cannot fix.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- A non-functional requirement is a quality plus a measurement plus a reason. "Fast" is not one; "the product page renders its first content within a time we agree on, measured at the median on a mid-range phone, because customers leave when it is slow" is. For each quality word, ask: measured how, at what threshold, and what happens if we miss it? A quality that survives those questions is a requirement; one that does not is a mood.
- Walk the standard list — latency, security, availability, accessibility, cost, auditability, scale — not as a checklist to satisfy but as a set of questions to ask of *this* system. For each: does this system have a specific reason to care, and who is the person who would notice if it were missing? A store cares about payment security because money moves; an internal dashboard mostly does not.
- Look for the qualities the standard list misses, by asking what would embarrass the business. For a store: "we could not explain a charge" (auditability), "a customer with a screen reader could not check out" (accessibility), "our hosting bill exceeded our margin" (cost). These arrive from the domain, not from the list.
- Refuse the qualities the system does not have. Refusing is an engineering act with a written reason: "Not multi-region in V1: the store has one country of customers and the cost of an hour of downtime is less than the cost of the infrastructure." A refusal with a reason can be revisited; a quality silently skipped cannot.
Seven questions, not seven requirements
The matrix walks the standard list against the store. The point of the middle column is that it is different for every row and every system: the same word means a different measurement, or no requirement at all, depending on who would notice. The last column is what keeps the list honest — a refusal with a trigger is a decision; a blank is a hope.
| Quality | For the store, measured how | Who notices if missing | V1 verdict |
|---|---|---|---|
| Latency | Product and cart pages at the median on a mid-range phone; checkout allowed to wait for the provider | Customers, by leaving | Yes — measured on a real device before launch |
| Security | Card data never on our servers; customers see only own orders; admin authenticated | Customers and the business, catastrophically | Yes — a design input, not a phase |
| Availability | Hours of downtime per month, against the sales lost per hour | The founder, in the sales figures | Single monitored server plus backups; trigger: downtime cost exceeds redundancy cost |
| Accessibility | Checkout completable with keyboard only and with a screen reader | Customers who cannot buy; regulators | Yes — checked on the checkout path first |
| Cost | Hosting per month against margin per order | The founder, on the invoice | Yes — a ceiling on how many services V1 may run |
| Auditability | Any charge reconstructable: order, items, prices, amount, time, who changed what | Support, on the first dispute | Yes — captured prices and an order history from the start |
| Scale | Sustained traffic against the server's measured limit | Nobody, until the trigger fires | Refused for V1; trigger and plan written |
Why "highly available" was not the requirement
The ladder below takes the quality word that most often arrives as an architecture and asks it why until a requirement appears. The device is not "availability does not matter"; it is that the requirement was a number about lost sales, and the number decides the architecture rather than the word.
“The store needs multi-region deployment for high availability.”
- ↓Why multi-region? So that the store stays up if a region goes down.
- ↓Why must it stay up through a regional outage? Because downtime loses sales and looks unprofessional.
- ↓How much does an hour of downtime lose, and how often does a region go down? A knowable amount of sales, given the order rate; regional outages are rare and short compared with our own deploy mistakes.
- ↓So what is the actual requirement? That the cost of downtime we experience stays below what we would spend preventing it — and that we know when it is happening.
the claim was right when The store is the only sales channel for a business whose hourly revenue exceeds the redundancy cost, or has a contractual availability commitment, or sells during events where an hour of downtime is the whole campaign. Then the number says multi-region and the word was right.
Which qualities are launch requirements
Not every quality that survived the questions needs to be met before the first customer. The decision below separates what must be true at launch from what must be true when a trigger fires — and names what each choice costs, because deferring a quality is only free if the trigger is actually watched.
When must this quality be met?
when Missing it harms a customer or the business on the first day and cannot be retrofitted — payment security, customers seeing only their own orders, auditable charges, an accessible checkout.
cost Time before launch, and design choices made early; but the alternative is a redesign under pressure or a dispute that cannot be answered.
when The quality matters only under a condition that can be measured — sustained traffic near the limit, customers in a second country, an hour of sales exceeding the redundancy cost.
cost Somebody has to watch the trigger, and the plan for when it fires must be written now, while the design is still cheap to change.
when Nobody specific would notice its absence and it was on the list because serious systems have it — multi-region for a single-country store, sub-second search over a small catalogue.
cost Owning the consequence if the reason turns out wrong; the written reason is what makes that a decision rather than an accident.
How to do it
Most important first.
- For every quality word in the brief, write three things beside it: the measurement, the threshold, and the consequence of missing it. If any of the three is blank, that word is not yet a requirement.
- Ask "who would notice?" for each quality. If the answer is "nobody in particular", it is probably a borrowed requirement from a system that is not this one.
- Ask the embarrassment question: what could happen in the first month that would make the founder wince? Each answer is a quality that was missing from the list.
- Separate what must be true at launch from what must be true eventually. Payment security is a launch requirement; handling a marketing spike is an eventual one with a trigger attached (Add Complexity Only When Required).
- Write the refusals down with reasons and revisit triggers. "Not until we have customers in more than one country" is a trigger; "later" is not.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store, quality by quality. Latency: the product and cart pages must feel immediate on a phone — measured at the median, threshold agreed with the founder, consequence: customers leave. Checkout can take a few seconds because it is waiting on the provider and customers expect it. Security: card data never touches our servers (the provider's hosted fields), customers see only their own orders, admins are authenticated — each is a launch requirement because money and personal data are involved. Availability: the store being down for an hour costs a known amount of sales; a single well-monitored server with backups is acceptable until that number grows.
- The ones the list missed. Auditability: every change to an order and every charge must be reconstructable — which order, what amount, which price, when — because disputes and refunds will need it and it cannot be added retrospectively. Accessibility: checkout must work with a keyboard and a screen reader, because a checkout that excludes people is both a legal exposure and lost orders. Cost: hosting must stay well under the margin on an average order — a real constraint on how many services the store may run.
- The refusals. Scale: not designed for a viral spike in V1; a spike is a good problem, the trigger is "sustained traffic near the server's measured limit", and the plan is written (Constraints Shape Architecture). Multi-region availability: refused, reason written, revisit when there are customers in more than one region. Sub-second search: refused; V1 search is filter-by-name over a small catalogue.
- The result is a short list where every line has a number or a yes/no beside it, and a short list of refusals with triggers. The word "scalable" does not appear anywhere on either.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every quality has a measurement, a threshold and a consequence, and at least one quality on the list came from the domain rather than from the standard set.
- Some qualities were refused, in writing, with a trigger for reconsidering them.
- The architecture has not grown a component whose only justification is a quality word.
- Security and auditability appear as design inputs — which data is sensitive, what must be reconstructable — rather than as a phase before launch.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?For this quality word: measured how, at what threshold, and what happens if we miss it?
- ?Who, specifically, would notice if this quality were absent — and is that a real person or a borrowed one?
- ?What would embarrass the business in the first month that is not on the standard list?
- ?Which qualities am I refusing, why, and what trigger would make me reconsider?
What can go wrong
- Every quality gets a precise number that nobody measured and nobody will. Fake precision is worse than an honest "must feel immediate, checked on a real phone"; a number should come from a measurement or an agreement, not from the desire to look rigorous.
- The refusals become an excuse. "Not in V1" applied to security or auditability is not a refusal with a reason; it is ignoring what cannot be ignored (What Cannot Be Simplified).
- The standard list is treated as complete. A store that satisfied latency, security, availability and scale and forgot auditability has a beautiful system that cannot explain a charge.
- Non-functional requirements are written once and never re-read. Each carries a trigger, and the triggers have to be checked — a refused quality whose trigger fired silently is the outage nobody planned for.
- Asking "measured how?" of every quality word takes a meeting the team wanted to spend building, and produces a document that some stakeholders read as pushback.
- Refusing a quality with a written reason means owning the consequence when the trigger fires; silently skipping it would have let the outage look like bad luck.
- Qualities that arrive from the domain — auditability, accessibility — are often more work than the ones from the standard list, because no library provides them for free.
- "Non-functional means less important." It means "a quality of the system's behaviour" rather than "a behaviour". Whether card data touches our servers is non-functional, and it is the most important requirement the store has.
- "If we are not designing for scale we can ignore performance." A single server still has a limit, and the store needs to know roughly where it is — a measurement, not a redesign. Refusing to scale early is not the same as refusing to measure.
- "The standard list is the requirement list." The standard list is a set of questions. The store's real non-functional requirements are the answers that had a measurement and a person attached — and some of the most important came from asking what would embarrass the founder.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- DOMAIN-SPECIFICThe qualities that survive "measured how, who cares?" differ by domain: a payments system keeps auditability and security and may refuse latency targets; an internal analytics dashboard keeps latency and may refuse availability; a chat app keeps availability and realtime latency and may refuse auditability entirely.
- SCALE-SPECIFICAt a few hundred orders a day a single server and a backup meet the store's availability need; the calculation flips when an hour of downtime costs more than the redundant infrastructure, and the requirement should carry that number as its trigger.
- ILLUSTRATIVEThe store's thresholds, the "few seconds" for checkout and the hour of downtime are invented for the shape of the argument; a real store agrees its own numbers with whoever pays for misses.
Where the depth lives
This domain asks the question and hands the answer off by name.