System Design · core
Requirements Scoping
Separating functional from non-functional requirements and cutting scope to something buildable.
Mental model
Functional requirements say what the system does; non-functional ones say what it must survive — and only the second kind changes the architecture. 'Users can post' does not tell you anything, while 'reads outnumber writes 100:1 and p99 must stay under 200ms' picks your caching and replication strategy outright. Scoping is an act of subtraction: naming what you are explicitly not building is what makes the rest defensible.
How to study Requirements Scoping
Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use Site Reliability Engineering — Service Level Objectives to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.
Next, compare Requirements Scoping with Capacity Estimation, Observability. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Split functional from non-functional and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.
Proof of understanding
- Explain the mechanism from first principles and identify the state it reads or changes.
- Give one situation where the concept is the right choice and one where it is not.
- Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
- Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.
Where it matters
The skill the interview actually grades in the first ten minutes, and the same conversation that precedes any real design doc.
Common mistakes
- Starting to design before agreeing what is out of scope, then re-architecting mid-answer
- Treating a latency or availability target as a detail to add later, when it is the constraint that selects the design
- Collecting requirements without a scale number, so every later decision is unfalsifiable
- Accepting 'highly available' as a requirement instead of pinning an availability target and its cost
Learn from primary sources
Practice and explain it back
Split functional from non-functional
Implement classify(requirements) returning { functional, nonFunctional } — two arrays preserving input order. A functional requirement states what the system DOES; a non-functional one states a quality or constraint it must hold (latency, availability, throughput, durability, consistency, cost, security posture).
Expected evidence: 'Users can upload a photo' -> functional; 'p99 read latency under 200ms' -> nonFunctional
Open the interactive drill →Review prompts
- Two requirements: 'users can follow each other' and 'reads outnumber writes 100 to 1'. Which one changes the architecture, and why is that the whole point of the split?
Build evidence
Use a roadmap capstone to turn this concept into working evidence.
Prerequisites
None assigned yet.