Functional vs Non-Functional
also called Behaviour vs Quality of Behaviour
Functional requirements say what the system does; non-functional requirements say how well, and only the second constrains structure.
Almost any structure satisfies the functional requirements. A publishing platform that stores an article and shows it to a reader can be a PHP script on one box. The structure is decided entirely by the non-functional layer: how many readers, arriving how fast, tolerating how much staleness, at what cost.
Why this is the load-bearing distinction
Functional requirements are additive — you can bolt on another feature. Non-functional requirements are structural — you cannot bolt on p99 latency, and you certainly cannot bolt on availability. This is why a design review that spends its time on features is not an architecture review.
Industry example
The New York Times has an unremarkable functional specification: journalists publish articles, readers read them. The architecture is entirely shaped by two non-functional facts. First, reads outnumber writes by an enormous margin. Second, traffic on an election night or a breaking story arrives as a step function, not a ramp.
That pushes the design toward a hard split: a write-side publishing system optimised for editorial workflow and correctness, and a read-side distribution system that is mostly static assets behind a CDN. The read path can survive the origin being down; that property is not a feature anybody requested, it is a consequence of taking the non-functional requirement seriously.
Failure scenarios
- NFRs discovered in production. Nobody stated a latency target, so nobody designed for one, so the first time it matters is when a customer complains.
- NFRs stated without conditions. "p99 under 200 ms" is meaningless without "at what load, measured where". Measured at the service, it excludes the network the user actually experiences.
- Conflicting NFRs never reconciled. "Strongly consistent globally" and "sub-50 ms reads worldwide" cannot both hold. Someone will discover this during implementation.
Trade-off
Every NFR you tighten is paid for by another. Availability is bought with redundancy, which costs money; consistency is bought with coordination, which costs latency. State the exchange rate.
Interview question
"Give me an example of a non-functional requirement that would force you to reject an otherwise correct design, and explain the mechanism."