requirements-scopinglisted

# 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 suf