Requirements Scoping Agent Skill

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:

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

• 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).

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

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

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

• 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. "High scale", "low latency", "highly

available" decide nothing. A requirement without a number is a wish — convert

it via back-of-the-envelope before it shapes a choice.

• Scope creep disguised as thoroughness. Accepting every feature feels

diligent but dilutes the design and burns the clock. The cheapest scope that

meets the goal wins.

• Phantom out-of-scope. Excluding things to dodge hard parts (cutting

consistency because it's hard) hides the real problem. Cut for focus, not to

avoid the difficulty the prompt is actually testing.

• Treating answers as final. Requirements are a hypothesis. When a constraint

changes ("now p99 < 50ms", "now we lose a region"), say which assumptions it

invalidates and re-scope the affected part rather than patching around it.

• Asking low-leverage questions first. Color of the button before

read:write ratio. Lead with the questions that move the architecture; a tidy

list of trivia answered perfectly still leaves the real shape of the system

unknown.

• Monologuing the scope instead of confirming it. Scoping is a dialogue.

Restate the three lists and the assumptions, then pause for correction —

treating a clarifying nudge as an attack on the scope is how a design ends up

defending the wrong problem.

Dos and don'ts

• Do restate the prompt in one sentence and lead with the highest-leverage

questions (audience, core features, scale, latency/availability, freshness).

• Do write the three lists — functional, non-functional, out-of-scope —

and treat each unanswered question as a stated, revisable assumption.

• Do quantify every non-functional ("p99 < 200ms", "10M DAU"), then hand the

raw numbers to back-of-the-envelope to compute.

• Do re-scope when a genuine constraint changes, naming which assumptions it

invalidates.

• Don't smuggle a solution in as a requirement ("we need Kafka"); state the

need and let the design earn the tool.

• Don't accept every feature; defer the long tail to out-of-scope, and don't

exclude hard parts just to dodge them.

• Don't interrogate forever or monologue the scope — get *enough* clarity for

a first hypothesis, then confirm and move on.

Numbers that matter

Requirements scoping *captures* the inputs; it does not compute. Pin down the raw

quantities — DAU/MAU, actions per user per day, read:write ratio, object/payload

sizes, retention, peak factor, p99 latency target, and an availability nines

target — and hand them to back-of-the-envelope, which owns the latency/QPS/

storage tables and the conversion math. Two figures to record verbatim because

they gate the most decisions downstream: the read:write ratio (a 95%-read

system invites caching; a write-burst system invites a queue) and the **scale

horizon** (a design for 1k QPS and one for 1M QPS are different systems). Keep

units and assumptions written next to each number.

Diagram

Scoping output is three lists, not a picture — keep them as text so they stay the

editable contract everything traces back to. When the scoped requirements justify

a first high-level design, draw *that* with the in-plugin architecture-diagram

skill; the requirements themselves don't need a diagram.

Related building blocks

• back-of-the-envelope — *feeds into* it: the non-functional numbers captured

here (DAU, ratios, SLAs) become its QPS, storage, and server-count math. The

next step.

• scaling-evolution — *feeds into* it: the growth horizon scoped here defines

the next bottleneck to plan for, and re-scoping mid-design hands it new limits.

• api-design and data-storage — *feed into* them: the functional requirements

and access patterns named here become concrete contracts and schemas there.

• consistency-coordination — *owned-concept lives there*: capture the freshness

and durability *requirement* here; the consistency-model theory belongs to it.

• system-design — *called by* the orchestrator at step 1, before estimation and

high-level design.

References

• references/clarifying-question-catalog.md — the full question bank grouped

by category (functional, scale, latency/availability, consistency/durability,

constraints), a worked vague→concrete example, and a fill-in requirements

template. Read when scoping a real prompt or when the five questions above

aren't enough for an unfamiliar domain.