Recap: Requirements and Trade-offs

Two kinds of requirement, four qualities, and the two ways a list goes wrong.

System design is choosing parts and trade-offs to meet stated requirements, in a loop: requirements, estimates, high-level design, deep dive, and back (System Design: Choosing Parts Against Requirements).
Functional requirements say what the system does; non-functional ones say how well. Deleting a functional one removes a feature; deleting a non-functional one leaves the feature, worse (Functional and Non-Functional Requirements).
The ranking depends on who waits. A food delivery app puts latency first; a payroll job puts correctness first (the two Requirements Example cards).
Four qualities cover most second lists: latency, availability, durability and scalability. Durability is keeping data; availability is answering at all (Quality Attributes).
A requirement needs a number, a percentile and a load, or no test can fail it (Vague Requirements).
Design for the stated scale, plus a margin, and name the point where the design would change (Over-Engineering for Traffic You Do Not Have).

← → move through sections and cards