requirements-scoping

Requirements Scoping

Turn a vague prompt ("design a news feed") into three written lists: what the system does (functional requirements), the numbers and qualities that shape it (non-functional constraints), and what is deliberately excluded (out-of-scope). Skipping this step is the most common way a design goes wrong — it ends up solving a different problem than the one in front of it, and every later decision rests on an unchecked assumption. The discipline is not about being slow; it is about making the problem concrete enough that the design choices have something to be measured against. Without it, every component is a guess, and the first hard follow-up question collapses the whole picture.

When to reach for this

At step 1 of any design, before drawing a single box or naming a single tool. Any time the ask is broad ("design YouTube"), ambiguous ("a real-time system"), or silent on scale, consistency, or audience. Reach for it again mid-design when a new constraint appears that may invalidate an earlier assumption — a re-scope is cheaper than a rebuild. The clearest signal is the reflex to reach for a familiar architecture before being able to state, in one sentence, what problem it solves here. That reflex is exactly the trap: applying a remembered solution to a prompt no one has actually read.

When NOT to

Don't interrogate forever. The goal is enough clarity to choose a first hypothesis, not a complete spec — three to five sharp questions usually suffice, with written assumptions for the rest. Don't gold-plate scope: every accepted feature is one to design and defend, so push the nice-to-haves into out-of-scope (YAGNI). And don't re-scope on every challenge; distinguish a genuine constraint change from a clarifying nudge.

Clarify first

The questions that change the design the most, asked in rough priority order:

• Who uses it and how? Audience (consumer/internal/B2B), client (mobile, web, both), and the one or two core user journeys. This bounds everything else.
• What are the must-have features? Force a ranked shortlist; the long tail is out-of-scope until the core works.
• What scale? DAU/MAU, growth horizon (3/6/12 months), read:write ratio, object sizes. These are the inputs back-of-the-envelope turns into QPS and storage — capture them here, quantify there.
• What latency and availability targets? A p99 number and a nines target, tied to the journey (a feed read vs a payment differ).
• How fresh must data be, and how bad is loss? Strong vs eventual consistency and durability expectations drive the hardest later trade-offs; capture the requirement (can a read be stale? can a recent write be lost?) here, and leave the consistency-model theory to consistency-coordination.