Requirements and system-design trade-offs
Design begins by defining what a system must do and how well it must do it under stated constraints.
Learning objectives
- Separate functional requirements from quality attributes.
- Explain a trade-off rather than listing components without a reason.
Start with questions
A functional requirement describes behavior: “a learner can save a bookmark.” A quality requirement describes a property such as availability, latency, cost, privacy, or maintainability. Ask expected traffic, data sensitivity, failure consequences, and what “fast enough” means before drawing services.
Reasoning example
A read-heavy public course catalogue may benefit from caching. That decision can reduce origin work but creates a freshness question. A sound design says what data can be stale, for how long, and what happens after an update.
Common mistakes
- Do not call a technology choice a requirement.
- Do not optimize every quality at once; stronger consistency, lower latency, lower cost, and simpler operation can conflict.