requirements-scoping

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

在任何设计的第一步，绘制第一个框图或命名第一个工具之前。每当需求宽泛（如「设计YouTube」）、模糊（如「实时系统」），或是未提及规模、一致性或受众时。在设计过程中，如果出现可能推翻早期假设的新约束，也应再次使用该方法——重新界定范围比重构成本更低。最明显的信号是，你还无法用一句话说明要解决的问题，就急于采用熟悉的架构。这种反应正是陷阱：将记忆中的解决方案套用到无人真正理解的需求上。

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.

不要无休止地盘问。目标是获得足够的清晰度以选择第一个假设，而非完整的规格说明——通常3到5个尖锐的问题就足够，其余部分记录为书面假设。不要过度扩展范围：每接受一个功能，就意味着要设计并维护它，因此将锦上添花的功能归入范围外（YAGNI原则）。也不要遇到每个挑战都重新界定范围：要区分真正的约束变更与澄清性提示。

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.

对设计影响最大的问题，按优先级大致排序：

**谁使用它？如何使用？**受众（消费者/内部/企业级）、客户端（移动端、网页端或两者），以及一到两个核心用户旅程。这会限定所有其他内容。
**必备功能有哪些？**强制列出排序后的短名单；长尾功能在核心功能正常运转前属于范围外。
**规模如何？**日活跃用户数(DAU)/月活跃用户数(MAU)、增长预期（3/6/12个月）、读写比、对象大小。这些是
```
back-of-the-envelope
```
工具计算每秒查询率(QPS)和存储需求的输入——在此处记录，在该工具中量化。
**延迟与可用性目标是什么？**与用户旅程绑定的p99延迟数值和可用性等级（信息流读取与支付场景的要求不同）。
数据必须有多新鲜？数据丢失的影响有多大？强一致性与最终一致性、持久性预期会决定后续最艰难的权衡；在此处记录需求（读取的数据可以过时吗？近期的写入可以丢失吗？），将一致性模型理论交给
```
consistency-coordination
```
处理。

如果用户无法回答，就明确提出假设并继续（如「假设日活跃用户数为1000万，读密集型，最终一致性即可」）——书面假设可修改；未说明的假设则是隐患。用用户的原话记录每个答案（如「最多5000个好友」、「必须能抵御区域故障」）：现在一个不起眼的细节往往会成为后续迫使架构做出选择的约束条件。

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.

从需求到明确范围问题的可重复流程：

用一句话重述需求。「用户可以发布短消息，并查看其关注者的逆时间序信息流的服务。」这会立即暴露隐藏的假设，并获得早期认可。
列出功能需求，以动词开头的用户可见能力：发布消息、关注用户、查看信息流、搜索。这些回答了「系统能做什么」——每个都是参与者可执行的操作。确保需求可测试，且不包含实现细节（「存储在数据库中」不是需求；「查看信息流」才是）。
**排序并聚焦核心功能。**选出两到三个定义产品的核心功能。明确推迟其余功能——推迟是一种决策，而非遗漏。核心功能是设计成败的关键；其他所有功能都可以作为后续迭代内容。
从澄清后的答案中推导非功能约束。功能需求说明系统能做什么，非功能约束则说明系统必须做得有多好：规模（DAU、QPS输入）、延迟（p99）、可用性（等级）、一致性、持久性，以及任何成本/合规限制。这些是衡量设计的数值，也是在任何功能之前就迫使架构做出选择（分片、缓存、队列）的因素。
**明确列出范围外事项。**说明不打算构建的内容（分析、广告、审核、多区域部署），使设计保持专注，边界清晰而非模糊。
重述三份清单并确认，再开始设计。这是后续所有工作的评判依据；将其视为假设，若约束变更则重新审视，而非固定的规格说明。

输出是三份简短的清单，而非散文。接下来将非功能数值交给

back-of-the-envelope

处理。

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.

范围界定不当比跳过更糟，因为它会制造虚假的信心。注意以下情况：

解决方案导向的需求。「我们需要Kafka/缓存/分片」是将答案伪装成需求。回归到实际需求（「承受写入峰值」、「快速响应读取」），让设计后续自行决定使用何种工具。
未量化的非功能需求。「大规模」、「低延迟」、「高可用」无法指导决策。没有数值的需求只是愿望——在它影响选择前，通过
```
back-of-the-envelope
```
将其量化。
**伪装成严谨的范围蔓延。**接受所有功能看似认真，但会稀释设计并浪费时间。满足目标的最小范围才是最优选择。
**虚假的范围外事项。**为了规避难题而排除内容（因难度大而放弃一致性）会掩盖真正的问题。排除内容是为了聚焦，而非逃避需求实际要测试的难点。
**将答案视为最终结论。**需求是一种假设。当约束变更时（如「现在p99延迟需<50ms」、「现在要应对区域故障」），说明哪些假设被推翻，并重新界定受影响的部分，而非临时修补。
**先问低影响力的问题。**在确定读写比之前先问按钮颜色。先问能影响架构的问题；完美回答一堆无关紧要的问题仍无法明确系统的真实形态。
**单方面界定范围而非确认。**范围界定是双向对话。重述三份清单和假设，然后等待修正——将澄清性提示视为对范围的攻击，会导致最终设计维护的是错误的问题。

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.

务必用一句话重述需求，先问影响力最高的问题（受众、核心功能、规模、延迟/可用性、数据新鲜度）。
务必写出三份清单——功能需求、非功能约束、范围外事项——并将每个未回答的问题记录为可修改的假设。
务必量化所有非功能需求（如「p99<200ms」、「1000万DAU」），然后将原始数值交给
```
back-of-the-envelope
```
计算。
务必在真正的约束变更时重新界定范围，说明哪些假设被推翻。
切勿将解决方案伪装成需求（如「我们需要Kafka」）；先说明需求，让设计自行决定使用何种工具。
切勿接受所有功能；将长尾功能推迟到范围外，不要为了规避难题而排除关键部分。
切勿无休止地盘问或单方面界定范围——获得足够清晰度以形成第一个假设，然后确认并推进。

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.

需求范围界定负责记录输入，而非计算。确定原始数值——DAU/MAU、每位用户每日操作数、读写比、对象/负载大小、留存率、峰值系数、p99延迟目标、可用性等级——并将其交给

back-of-the-envelope

，该工具负责延迟/QPS/存储表格及转换计算。有两个数值需原封不动记录，因为它们会决定后续大多数决策：读写比（95%读密集型系统适合缓存；写入峰值型系统适合队列）和规模预期（针对1k QPS和1M QPS的设计是完全不同的系统）。每个数值旁需记录单位和假设。

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.

范围界定的输出是三份清单，而非图片——保留文本形式，使其成为所有工作可追溯的可编辑契约。当明确范围后的需求支撑第一个高层级设计时，再用插件内的

architecture-diagram

Skill绘制图表；需求本身无需图表。

Related building blocks

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.

references/clarifying-question-catalog.md
——按类别（功能、规模、延迟/可用性、一致性/持久性、约束）分组的完整问题库，一个模糊需求→明确需求的示例，以及可填写的需求模板。当为真实需求界定范围，或上述五个问题不足以覆盖陌生领域时，可参考该文档。