Comparisons
Pairs engineers genuinely confuse — goal and implementation, MVP and bad prototype, prototype and spike, reversible and irreversible. Neither column wins; what decides is the problem. Each record leads with the confusion, because the confusion is what it costs.
Functional vs non-functional requirements
Non-functional requirements are treated as optional polish to be added at the end, or as absent because nobody stated them — and they are the requirements that decide whether the architecture is right. A store that must serve five hundred concurrent customers and one that must serve five look identical on the functional list and are different systems. The cost of skipping them is the rewrite in month three; the cost of inventing them is designing for a million users nobody has. The honest position is to ask for every number and, where nobody knows, write "unknown" on the board rather than a guess, and design for the smallest plausible value with a measured path to the next.
To define the workflows, the slices and the acceptance tests. "Customer adds a product to the cart and sees the count change."
To shape the architecture. "Five hundred concurrent customers; a product page in under a second; an hour of downtime is acceptable; card numbers never touch our servers."
| Aspect | Functional — what the system does: an actor performs an action with an observable result | Non-functional — how well, for how many, how fast, how safely, and what happens when it fails |
|---|---|---|
| Answers | "What can a user do?" | "How many, how fast, how safe, how available?" |
| Comes from | Workflows and actors | Constraints, scale, law, operations |
| Tested by | A scenario with an expected result | A measurement under load, a failure injected, an audit |
| Decides | Which slices exist | Which architecture the slices sit in |
| When it usually appears | In the brief | In the incident |
| Typical mistake | Listed without failure cases | Never asked, then guessed as "a million users" |