/requirements-scoping

name: requirements-scoping
description: This skill should be used when the user needs to "clarify requirements", separate "functional vs non-functional requirements", "scope the problem", figure out "what questions should I ask", state the "requirements for <X>", or otherwise pin down a vague design prompt before building. It turns an ambiguous ask into functional requirements, non-functional constraints, and an explicit out-of-scope. Use it whenever a prompt is broad or under-specified ("design Twitter", "build a chat app") even if the user doesn't say "requirements".

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`.

If the user can't answer, state an assumption out loud and move on ("assuming 10M DAU, read-heavy, eventual consistency is fine") — written assumptions are revisable; silent ones are landmines. Capture each answer in the actual words used ("up to 5,000 friends", "must survive a region loss"): a stray detail now often turns out to be the constraint that forces a structural choice later.

The method (recipe)

A repeatable pass from prompt to scoped problem:

1. **Restate the prompt in one sentence.** "A service where users post short messages and read a reverse-chronological feed of people they follow." This surfaces hidden assumptions immediately and gets early buy-in. 2. **List functional requirements** as user-visible capabilities, verb-first: *post a message, follow a user, view a feed, search.* These answer "what does the system *do*" — each is an action an actor can take. Keep them testable and free of implementation ("store in a DB" is not a requirement; "view a feed" is). 3. **Rank and cut to the core.** Pick the two or three that define the product. Explicitly defer the rest — deferral is a decision, not an omission. The core is what the design lives or dies by; everything else can be a follow-up. 4. **Derive non-functional constraints** from the clarifying answers. Where functional requirements say what the system does, non-functional ones say *how well* it must do it: scale (DAU, QPS inputs), latency (p99), availability (nines), consistency, durability, and any cost/compliance limits. These are the numbers a design is measured against, and the ones that force structural choices (sharding, caching, queues) long before any feature does. 5. **Write the out-of-scope list explicitly.** Name what is *not* being built (analytics, ads, moderation, multi-region) so the design stays focused and the boundary is visible, not accidental. 6. **Restate the three lists and confirm** before designing. This is the contract the rest of the work is judged against; treat it as a hypothesis to revisit if constraints change, not a fixed spec.

The output is three short lists, not prose. Hand the non-functional numbers to `back-of-the-envelope` next.

Pitfalls / where it misleads

Scoping done badly is worse than skipped, because it manufactures false confidence. Watch for:

• **Solution-shaped requirements.** "We need Kafka / a cache / sharding" is an

answer smuggled in as a requirement. Strip it back to the need ("absorb write bursts", "serve reads fast") and let the design earn the tool later.

• **Unquantified non-functionals