Design Method & StylesChapter 15 · Open the room
Requirements and scope
Requirements and scope
Before designing, pin down what the system must do — the few features in scope (functional requirements) — and how well it must do them — scale, latency, availability, consistency, durability (non-functional). Ask the questions whose answers would change the design, write the answers down as numbers, and list what you're leaving out. "Fast and scalable" isn't a requirement; "99% of album opens under 300 ms at 2 million daily users" is.
- Use when
- The first minutes of any design interview, before a single box is drawn · Starting a real design — before choosing any technology · Two people arguing about a design — often they hold different unstated requirements
- Avoid when
- As an interrogation — a question whose answer wouldn't change anything spends minutes and shows nothing · Gold-plating — designing for requirements nobody stated ("it might go global") without asking first
- Trade-offs
- Every tighter target — lower latency, more nines, stronger consistency — costs money and complexity · Cutting scope buys depth on what's left, and risks dropping the feature the interviewer cared about — say the cut out loud and confirm it · A stated assumption keeps you moving when no number is given, and can anchor you on a wrong one — so say it, so it can be corrected
- Requires
- Interview & rubric
3 objectives · 6 misconceptions
- explain Explain the difference between functional and non-functional requirements, and name the five non-functional ones that most often shape a design — scale, latency, availability, consistency, durability.
- choose Choose the clarifying questions whose answers would change the design, skip the ones that wouldn't, and state an assumption when the interviewer leaves a number to you.
- predict Predict how a design changes when one non-functional requirement changes — stale reads allowed or not, 99.9% or 99.99% available — and write each requirement as a number with a list of what's out of scope.
- Not true: The more clarifying questions you ask, the better you score.
- Not true: "Highly available, scalable and fast" is a complete set of non-functional requirements.
- Not true: A good design covers every feature the product has.
- Not true: Every part of a system needs the same availability, latency and consistency.
- Not true: Once the requirements are written down, they can't change during the interview.
- Not true: A stricter target than anyone asked for — more nines, lower latency — is always the safer choice.
Practice
No katas practise this yet.