第 4 章 需求分析：业务诉求如何翻译成技术需求
副题：功能、非功能、约束——把"做一个社区交易产品"变成一份可以开发、可以验收、可以用来选型的清单
第 1 章我们拿到了地图，第 3 章我们认识了贯穿全书的案例产品。现在，业务线正式启动：你手里只有一句话需求，身后是一个等不及的开发周期。本章跟着案例完成从"一句话"到"需求清单"的翻译——这是全书业务线的第一站，也是第 5 章技术选型的输入来源。
本章要建立的认知
- 需求分析不是"问清楚要什么"，是把业务诉求翻译成三种东西：功能需求、非功能需求、约束——三者缺一，开发就会走偏；
- 翻译的关键动作是可度量：业务说"快"，你要问"多快？在什么场景下？谁觉得快？"——不可度量的需求等于没需求；
- 需求分析有明确的代价与边界：它防止返工，但也会变成拖延的借口；需求永远不会完整，接受变化是常态（第 27 章回收）。
4.1 一句话需求
故事从一句很普通的话开始。
阶段 1 的你——一个人，一个想法，预算只有一台服务器——决定做一个自己的产品。你在产品笔记里写下：
做一个社区交易产品：有人发内容、评论，也能上架商品、下单付款。
这不是案例独有的起点。几乎所有项目——大到企业系统，小到一个工具脚本——都从一句话开始："做个管理系统""帮我们把数据导出来""像某某产品一样，但更简单"。一句话需求不是问题，问题是大多数人直接拿它开工了。本章的案例只是把这条路走了一遍，让你看到一句话到一份合格需求清单之间，到底发生了什么。
这句话看起来很清楚。有内容、有评论、有商品、有订单、有支付——五个词，五个功能。你甚至已经在脑子里看到了界面：首页是内容流，商品在侧边栏，下单按钮是橙色的。
然后你做了大多数 1-3 年开发者都会做的事：直接开干。建项目、建表、写接口、画页面。两周后，你拿着第一版去找你的第一个用户（你的朋友老周）验收，老周看了十分钟，说了一句话：
"这……不是我要的。"
"哪里不对？"你问。
"我要的是社区，你给的是货架。"老周指着页面说，"我打开就想看大家聊了什么、谁分享了什么——结果一进来全是商品列表。还有，你说的'下单付款'呢？我点了购买，直接跳转账页面，我都不知道买的是哪家的东西。"
你解释："交易我还没做完，先做了浏览和列表……"
"那你让我验收什么？"老周走了。
这不是老周难伺候，这是需求分析的经典事故：你实现的是你理解的需求，不是用户要的需求；而你没有一份需求清单可以证明你理解对了。两周的开发，一半白做——列表页重做、交易流程推倒、信息架构调整。返工的代价从来不是"多写两星期代码"，而是：你已经在这条错路上写了两星期，而错误的方向感会跟着代码一起留下来。
把这次事故拆开看，其实犯了三个独立的错。方向错：你把"社区交易"理解成了"交易为主、社区为辅"，而老周要的是"社区为主、交易为辅"——页面信息架构完全不同；优先级错：你把浏览和列表放在前面，交易放后面，而老周的验收顺序是先看到社区氛围、再走通一单交易；理解错：你说"下单付款"就是调通支付，老周的"下单付款"包含"知道买的是谁家的东西"——一个信任问题，你当成流程问题做了。三个错没有一个是代码 bug，全是对需求的理解偏差；而理解偏差是测试测不出来、代码 review 看不出来的——唯一能拦住它的，是在写代码之前把需求说清楚。
为什么 1-3 年的开发者特别容易跳过需求分析？因为学习的路径决定了习惯：教程教的是"怎么实现"，从来不是"怎么确认要什么"；个人项目练的是"想到就做"，从来不是"先写需求清单"。需求分析在教科书里是产品经理的事，但现实里 1-3 年的人就是需求的第一接收人——产品一句话丢过来，你翻译成系统。跳过翻译的代价，就是老周那十分钟的验收。
老周走后，你花了一天做需求分析——重新拆分类、写验收标准、砍功能。这一天值不值？对比一下：一天分析 vs 两周返工。而且返工的损失不只是时间：重做的功能会带着第一版的错误假设一起重做——你第二次做列表页时，脑子里还是"货架优先"的直觉。需求分析买的不是"不返工"，是"返工之前先知道自己要什么"。
返工的成本还不只是时间。两星期的返工会消磨掉开发的信心——重做同一个功能时，你开始怀疑"这次理解对了吗"，而这种怀疑会让开发变慢、变犹豫；返工过的代码也更容易长成技术债——因为重做时总想"先快点做完，反正以后还要改"。需求分析挡住的不是一次返工，是一串连锁反应。
为什么会这样？因为"做一个社区交易产品"这句话，看起来是一个需求，实际上只是需求的起点。它没有回答任何关键问题：
- 用户进来第一眼看到什么？（信息架构）
- "社区"和"交易"哪个是主、哪个是次？（优先级）
- 多快算快？多少人同时用？钱怎么算？（非功能需求）
- 一个人开发，几周上线？（约束）
这句话到可开发的清单之间，隔着一次翻译。本章就是教这次翻译怎么做的。
4.2 需求的三分类：功能、非功能、约束
需求分析的第一个动作，是学会把"要什么"拆成三类。这个分类来自一个朴素的事实：开发中走偏的需求，走偏方式只有三种——做错了功能、没达到性能/安全等隐形标准、忽略了边界条件。
功能需求（Functional Requirement）：系统要做什么。用户能发内容、能评论、能上架商品、能下单——这些是功能需求。它们通常是用户直接说出来的，最容易收集，也最容易做错（做错的方式见 4.1：理解偏了）。
功能需求做错的方式有三种，各有各的防法：做偏——理解错，4.1 的老周事故；做多——用户没要的做了一堆（"顺手把后台管理也做了"），每多做一样，就多一份维护和测试成本；做少——用户要的没做（下单流程只做了"调通支付"，没做"让用户知道买的是谁的"）。做偏靠翻译防（4.3），做多靠砍需求防（4.4），做少靠验收标准防——4.3 的"场景"写法就是防做少的：场景逼你把用户完整走一遍的路径写出来。
非功能需求（Non-Functional Requirement）：系统做得怎么样。多快、多稳、多安全、多好用、多容易维护。用户很少直接说非功能需求，但它们决定了系统能不能用：页面 10 秒才打开，功能再全也没人用；下单丢单，功能再顺也没人敢用。非功能需求是"做好了没人夸，做坏了全怪你"的那类需求。
非功能需求可以再细分成四类，每类对应一种"做好了没人夸、做坏了全怪你"的场景。性能：多快算快——对应"打开慢"导致的流失；安全：数据会不会丢、会不会被人搞——对应用户对平台的"信任"；可用性：挂了多久能恢复——对应业务对系统的"依赖"；可维护性：三个月后改得动改不动——对应团队的"未来"。四类里，前两类用户能直接感知（慢、被盗号），后两类只有开发者能感知（上线第二天改不动、半夜被叫起来）。需求分析时最容易漏的是后两类——因为没有人会跟你说"请让我三个月后改得动"。
非功能需求还有一个特点：它的验收时机和功能需求不同。功能需求上线当天就能验收（按钮能不能点、订单能不能建）；非功能需求里，性能要等到有真实流量才能验证（开发环境的"快"不算数，第 16 章会看到第一次性能危机），可用性要等到挂了才能验证（第 24 章高可用），可维护性要等到三个月后改需求时才能验证（第 20 章的技术债就是它的账单）。所以在需求分析阶段写下的非功能验收标准，有一部分是写给未来自己的——现在写清楚"什么叫快、什么叫不能丢"，将来验收时才有依据。
约束（Constraint）：不是系统要做什么，而是你做这件事的前提条件。时间（三周上线）、人力（就你一个人）、预算（一台服务器）、技术前提（团队只会 Node）、合规（交易要牌照/实名）。约束不可协商——它不是需求，是需求的地基。
约束和需求的区别值得强调：需求可以被砍、被改、被排序，约束不能。三周上线不能变（除非你接受老周更晚看到第二版），一个人开发不能变（除非你找人），一台服务器不能变（除非你花钱）。约束是需求分析里唯一"不用讨论对错、只需要确认"的部分——它的作用不是限制你，是让后面的所有决策（第 5 章的技术选型）有真实的输入：第 5 章选型时的每一条约束，都来自这里。
把这三类分开，是需求分析的第一道工序。回到案例，老周走后，你重新坐下来，把"一句话需求"拆成三份草稿：
功能需求（草稿）：
- 用户能注册、登录、发布内容、评论内容；
- 卖家能上架商品、编辑商品、下架商品；
- 买家能浏览商品、下单、付款。
非功能需求（草稿）：
- 首页内容流加载要"快"；
- 交易过程"不能出错"；
- 用户数据"不能丢"。
约束（草稿）：
- 一个人开发，三周后给老周看第二版；
- 一台服务器；
- 数据量目前很小，但内容会增长，将来要收钱——数据不能丢、交易不能出错；
- 内容和商品的属性可能会变（标签、规格），表结构不想频繁改；
- 技术栈：就用手头会的（第 5 章再定）。
三份草稿里的功能需求还有一处要单独说："付款"写的是"买家能下单、付款"——这个词在需求清单里只是一行验收标准，它的全部复杂度（状态机、幂等、回调、对账）要到第 17 章才展开。需求清单不负责实现，只负责把"做到什么程度"说清楚；实现是后面每一章的事。
注意草稿里的三个引号——"快""不能出错""不能丢"。它们不是需求，是情绪的占位符。下一节处理它们。
草稿到正式清单之间还有两道工序：4.3 的翻译（把引号里的情绪词变成指标）和 4.4 的砍需求（把清单裁到三周能做完）。所以 4.2 的草稿不是终点，是原料——先分类，再翻译，再砍，才是成品。
分类本身还可以做一次完整性检查：用户走查——把产品从用户视角完整走一遍：注册 → 登录 → 发第一条内容 → 收到第一条评论 → 浏览商品 → 下单 → 付款 → 看订单。每一步问"这一步的功能需求写了吗？非功能需求写了吗？"——走查漏掉的步骤，就是将来返工的地方。走查不需要工具，需要的是把自己当成那个十分钟后就要走的用户。
三分类不是三个抽屉，边界模糊的需求也有——比如"交易要合规"：它一半是功能（实名认证流程），一半是约束（不实名不能卖）。分不清的时候，记住分类的目的：功能需求决定"做什么"，非功能需求决定"做到什么程度"，约束决定"在什么前提下做"——一个需求问三次，落在哪类就归哪类；归错了也不可怕，可怕的是不分。
最后把三分类和第 5 章接上：需求分析产出的这三类东西，恰好就是第 5 章九步决策模型的输入——功能需求回答"要做什么"（第 3 步技术问题的来源），非功能需求回答"做到什么程度"（第 5 步评价维度的来源：性能→延迟指标、安全→一致性要求、可维护性→复杂度容忍度），约束直接进第 2 步"业务约束"。
4.3 翻译：业务语言 → 技术语言
三类分好了，第二步是把每一类里的"人话"翻译成"可度量的技术语言"。这一步是需求分析的核心，值得单独一节。
翻译的对象，是那些听起来清楚、实际上含糊的词。业务语言里充满了这种词："快""稳""安全""好用""像淘宝一样""和微信差不多"。它们的问题不是错，而是不可度量——不可度量的需求无法验收：你说"快"，开发做到了 2 秒，你觉得快吗？你说"像淘宝一样"，淘宝有首页推荐、有购物车、有直播，你到底要哪个？
翻译的动作只有一个：追问度量。每个含糊的词，问三个问题：多少？什么场景？谁来判断？
三个问题要按顺序问，各有各的讲究。多少？——把程度问出来："快"是多少秒？"稳"是百分之几的可用？数字的选择本身也是需求："P95 加载 < 2s"和"平均加载 < 2s"是两个需求，前者管最慢的 5% 用户，后者只管平均——对体验来说，P95 比平均诚实得多，因为平均值会被最快的 1% 拉低。什么场景？——把条件问出来："快"是 4G 网络下快、还是 Wi-Fi 下快？是首屏快、还是整页快？场景不同，指标不同，实现手段也不同（首屏快靠渲染优化，整页快靠数据量控制）。谁判断？——把裁判问出来："快"是开发觉得快，还是老周觉得快？验收标准的最终裁判必须是用户侧的人——开发自测的"快"永远是快的。
| 业务语言 | 追问 | 可度量的技术语言 |
|---|---|---|
| 首页要"快" | 多快？什么场景？ | 首页内容流在 4G 网络下 3 秒内首屏可读；P95 加载时间 < 2s |
| 交易"不能出错" | 什么算错？出错怎么办？ | 下单与扣款必须一致；重复请求不重复扣款；失败可重试可对账 |
| 数据"不能丢" | 丢什么程度不能接受？ | 已发布内容和已支付订单零丢失；数据库每日备份 |
| "像淘宝一样" | 淘宝的哪个部分？ | （具体到功能：商品详情页、下单流程、订单列表） |
把"快"翻译成"P95 加载时间 < 2s"，开发就知道做到什么程度算完；把"不能出错"翻译成"重复请求不重复扣款"，测试就知道要测什么；把"像淘宝一样"翻译成三个具体功能，产品就知道要砍掉什么。翻译的目标，是让每个需求都有"做到什么程度算完成"的答案——这个答案，就是验收标准。
验收标准是需求分析的产出物，不是附赠品。它通常长这样：
场景：用户在商品详情页点击"立即购买"。 验收：点击后 1 秒内进入确认页；订单创建成功（order_no 唯一）；库存扣减与订单创建要么都成功要么都失败；重复点击只产生一个订单；网络中断可重试，重试不产生重复订单。
这条验收标准直接来自 4.2 的"不能出错"——它把情绪变成了可以测试的句子。第 18 章的测试体系会讲怎么把这些句子变成测试用例；这里只需要记住：需求分析写下的验收标准，就是未来的测试用例。需求分析不是开发前的一次性谈话，它是整个工程的"宪法"。
场景化验收标准的写法，可以借用测试界的一句口诀：Given——当什么前提，When——做了什么操作，Then——应该看到什么结果。"前提：商品库存为 1；操作：两个用户同时下单；结果：一个订单成功、一个提示库存不足"——这一句话同时是需求、是验收标准、是未来的测试用例（第 17 章会看到它怎么变成代码）。写验收标准时如果发现"Then 写不出来"，说明这个需求还没想清楚——这本身就是需求分析的价值：它逼你在开发前把"完成"定义出来。
拿"交易不能出错"做一次完整演练，看看翻译的全过程。第一步，追问"什么算错"：扣了钱没订单算错、订单重复算错、库存超卖算错、用户付了钱订单不动算错——四个场景，四个"错"的定义。第二步，每个"错"问"多少/什么场景/谁判断"：重复下单在"用户连点、网络重试"场景下发生，裁判是用户（他收到两条扣款短信）；库存超卖在"两个用户同时下单"场景下发生，裁判是卖家（他发不出货）。第三步，翻译成验收标准："重复点击只产生一个订单；库存扣减与订单创建要么都成功要么都失败；金额以'分'存储"。第四步，这些验收标准变成第 17 章的防线：幂等接住重复、事务接住超卖、整数存储接住金额误差。一次翻译，四步走完——需求分析在这里和第 17 章完成了闭环：需求清单里的每一行验收标准，最终都变成了一道防线。
验收标准还有一个粒度问题：一条标准只装一个场景。"库存为 1 时两个用户同时下单"是一条；"库存为 0 时下单提示缺货"是另一条；"重复点击只产生一个订单"又是另一条。把十个场景塞进一条验收标准，等于没有验收标准——测试没法测，返工照样发生。粒度的判断标准：一条标准对应一个 Then。
图 4-2 把这一节的翻译过程画出来：
翻译还有两种失败模式，先说在前面。过度指标化：把每个词都翻译成指标，"快"翻译成三个指标，"稳"翻译成五个——指标太多等于没有指标，用户和开发都被数字淹没。翻译的粒度原则：每个需求一个主指标，最多两个辅指标，再多就是装饰。指标错位：翻译的指标不是用户真正在乎的——用户说"快"指的是"操作反馈快"（点击有响应），你翻译成"加载快"（数据加载快），指标再精确也是精确地错。防指标错位的办法和防翻译错误一样：把指标拿给用户看，让老周说"对，我说的就是这个"。
非功能需求的翻译比功能需求难，因为功能需求有"用户做过的事"做参照，非功能需求常常没有。性能指标没有历史数据怎么定？三个来源：竞品参照——淘宝首页多快，我们至少不能比它慢一个量级；经验值——业界共识：首屏 3 秒、交互反馈 100ms 内；用户可感知的底线——超过 X 秒用户会流失，X 就是底线。"安全"怎么度量？把"不能丢"翻译成"备份策略 + 恢复演练"（每天备份、季度演练恢复），把"防搞"翻译成"攻击面清单"（登录、支付、上传是攻击面，各自要什么防护）——非功能需求的度量单位不一定是秒和百分比，也可以是策略和清单。
翻译也不是需求分析阶段的一次性动作，它会在开发中反复发生：老周发来一条消息"加个导出功能"，你的第一反应不是"好的，加在哪"，而是先问"导出给谁看？什么格式？多久一次？"——三问出口，需求就清楚了一半。把翻译练成条件反射，是需求分析留给你的长期技能：以后任何人丢给你一句含混的话，你的第一反应都是追问度量，而不是打开编辑器。
4.4 砍需求：MVP 与复杂度预算
需求清单翻译完，你面对一个残酷的现实：清单里的每一行都合理，但加起来不可能在三周内做完。一个人、三周、一台服务器——这是 4.2 的约束，它不会因为需求合理就放宽。
所以需求分析还有一个职责：决定什么先做，什么后做，什么不做。这不是"砍需求"，是给需求排序。排序的依据不是喜好，是两件事：
第一，验证核心假设。产品的第一版不是"做完所有功能"，是"用最小成本验证产品假设"。怎么找核心假设？一句话：产品假设 = 产品为什么存在的那句话。社区交易产品为什么存在？因为它让"社区里聊得来的人"顺便完成交易——所以核心假设是"社区先成立"：有人发内容、有人评论、有人回来，交易才有土壤。反过来，如果产品是"帮二手卖家快速出货"，核心假设就是"交易先成立"，社区反而是引流工具。两个方向没有对错，但对同一个产品只能选一个——选了社区优先，MVP 就该砍掉一切与社区氛围无关的功能，哪怕交易功能再赚钱。MVP 的本质，就是"围绕一个假设的最小实验"。
但 MVP 也有砍过头的时候。砍到极致的标准不是"功能最少"，是"假设还能不能被验证"：如果砍完的 MVP 连"有没有人愿意发内容"都测不出来——比如连发布入口都藏起来了——那这个 MVP 就不是最小，是残废。MVP 的裁剪边界：砍掉的功能可以后置或不做，但核心假设的验证路径必须完整。案例的 MVP 砍掉了交易，但保留了下单入口的占位（第 6 章会看到：订单、支付对象在阶段 1 就建模，只是不启用）——砍功能，不砍验证路径。
把 MVP 放回五阶段故事线（第 3 章）：MVP 是阶段 1 的产物——先社区后交易，交易在阶段 3 才开启。后置不是丢弃：阶段 2 用户增长会逼出缓存和索引（第 16 章），阶段 3 收钱会逼出事务和幂等（第 17 章）——每个阶段都有自己的一轮"需求分析"：新需求来了，重新走一遍三分类、翻译、砍需求（第 27 章的迭代循环）。MVP 只是第一次翻译，不是最后一次。
看这张图：先做的是假设验证的路径，后置的是需要流量才能成立的功能，划掉的是验证之前不存在的复杂度——三层砍法，对应三种不同的"不做"。
第二，复杂度预算。每个功能都有成本，不只是开发时间，还有它带来的复杂度——下面拆给你看。第 17 章我们会看到，交易功能的复杂度不是线性的——每一个"加上去很简单"的功能，都在为未来的状态组合和测试场景加码。MVP 的砍法不是"把功能砍小"，是"把复杂度预算花在验证假设上"：先做一单一件的"立即购买"，不做购物车；先做人工上架，不做后台审核流；先不做搜索，用标签筛选顶住。
把"加上去很简单"的功能逐个拆开，看看它们的隐藏复杂度：购物车——订单从"一单一件"变成"一单多件"，金额重算、库存合并、下单流程全变，测试场景翻倍；优惠券——金额计算从"单价×数量"变成规则引擎，对账场景从"金额一致"变成"优惠后金额一致"；搜索——从"列表筛选"变成"分词、索引、排序"，还要考虑搜索结果和标签筛选的叠加；多端——每个端都有自己的渲染、登录、支付回调处理，复杂度不是加一，是乘一。砍需求砍的不是"功能"，是这些隐藏复杂度——砍掉一个功能，省下的不只是一周开发，是它未来十年的维护和测试成本。
砍需求有三个层次，力度不同。不做：搜索、推荐、多端——核心假设验证之前，它们不存在；后置：交易、通知——它们属于产品的一部分，但放在社区验证之后（阶段 3 再开启）；简化：交易本身做成"一单一件的立即购买"，不做购物车、不做优惠——用最简形态先走通。三层砍完，剩下的就是下面的清单。
功能需求里还藏着一类容易被漏的东西：业务规则。它不是"用户能做什么"，是"业务允许什么"——库存不能为负、价格必须为正、订单金额是下单时的快照（商品改价不影响已下订单）、金额以"分"为单位存储。业务规则翻译成技术语言，就是数据约束和校验逻辑（数据库约束、服务端校验）。漏掉业务规则的后果和漏掉功能需求一样：开发做完才发现"库存能减成负数"。需求清单里值得给业务规则单独留一行——它是功能需求里最像"技术需求"的部分，也是第 6 章数据建模和第 17 章交易系统的直接输入。
砍完之后值得做一次自查，三个问题：每个保留的功能都有验收标准吗？——没有验收标准的功能，会在开发中悄悄长成别的东西；核心假设的验证路径完整吗？——从注册到发内容到回来，路径上缺一环，假设就测不出来；砍掉的东西有记录吗？——后置的功能写进"将来"清单（案例的订单/支付对象在第 6 章建模时就预留了位置），不做的东西写进"不做"清单——记录砍掉的决策，和记录做掉的决策一样重要（第 5 章的决策记录就是同一个习惯）。
砍完之后，案例阶段 1 的需求清单长这样：
| 类型 | 需求 | 验收标准（可度量） |
|---|---|---|
| 功能 | 用户注册/登录 | 邮箱+密码注册；密码以哈希存储；登录态 7 天有效 |
| 功能 | 发布/浏览/评论内容 | 发布后立即可见；列表按时间倒序；评论可嵌套一层 |
| 功能 | 商品上架/浏览/下单 | 卖家可上架（标题/描述/价格/库存）；买家可下单（一单一件） |
| 非功能 | 首页"快" | 4G 下首屏 3s 内；P95 列表加载 < 2s |
| 非功能 | 交易"不能出错" | 重复点击只产生一个订单；库存与订单同事务；金额以"分"存储 |
| 非功能 | 数据"不能丢" | 内容与订单零丢失；每日备份 |
| 约束 | 一个人、一台服务器、三周 | 技术栈在第 5 章选型时确定 |
这张表就是第 5 章的开场——第 5 章开头说"第 4 章我们把一句话需求翻译成了需求清单"，指的就是它。注意表里的两个衔接点：非功能行的"交易不能出错"验收标准，会在第 17 章变成状态机、幂等、事务的设计输入；约束行的"技术栈在第 5 章选型时确定"，把接力棒直接交给了第 5 章的九步决策模型。
顺便说一句需求清单的形态：它不是 40 页的文档，一页表就够——本章的清单就是全部。需求清单的读者有三类：开发（按它实现）、测试（按它写用例）、三个月后的你自己（按它回忆当初为什么这么做）。一份一页纸的清单，三个读者都够用；40 页的文档，三个读者都没时间读。
4.5 需求分析的代价与边界
把需求分析说得这么重要，现在必须说它的反面：需求分析不是做得越多越好。它有两笔真实的成本。
**第一笔：过度分析。**需求是永远分析不完的——每个"多快"都能再追问一层，每个场景都能再展开一个分支。如果需求分析的目标是"把需求彻底搞清楚再动手"，那这个目标永远达不到，项目会死在分析阶段。这就是"分析瘫痪"（analysis paralysis）：一份完美的需求文档，配上零行代码。它有个典型样本：需求文档写了 40 页，每个字段都定义了，每个流程都画了图，但项目三周没动一行代码——文档越完美，越不敢开始，因为"需求还没分析完"。防分析瘫痪的检查方法很简单：看验收标准能不能写出来。能写出第一条验收标准，就说明可以开始开发第一条功能了；需求分析的目标不是文档完整，是"第一批验收标准可用"。需求分析的正确停止点不是"分析完了"，而是"可以开始试错了"——第一版需求清单只需要精确到"能开发、能验收、能选型"三个程度，剩下的事情交给迭代（第 27 章会看到，迭代循环就是需求的第二次、第三次翻译）。
第二笔：翻译也会错。业务说"快"，你翻译成"P95 < 2s"——但也许用户的"快"指的是"操作反馈快"，不是"加载快"；你翻译错了，验收标准再精确也是精确地错。翻译错误是需求分析里最难防的错误，因为它披着"专业"的外衣。防它的办法不是更仔细地翻译，而是让验收标准尽早被用户看到——把"P95 < 2s"写成"首屏 3 秒内可读"给老周看，他点头了，翻译才算通过。这也是为什么 4.3 的验收标准写法里要有"场景"：场景是给用户看的，指标是给开发看的，两者一起，翻译才有对照物。
还有一个现实问题：需求分析是谁的活？1-3 年开发者面对的现实是：小团队里没有专职产品经理，需求分析就是开发者的活；大团队里有产品经理，但产品经理给你的是"需求文档"而不是"需求"——翻译依然是你的事。所以需求分析不是"产品经理的岗位"，是"开发的工序"：不管需求从哪来、经过谁的手，落到你手上要变成系统的那一天，你就在做需求分析。区别只是：有清单地做，还是凭直觉地做。
边界：需求分析能防止"做错了方向"，防不了"需求本身变了"。老周看了第二版说"社区不错，现在加个二手拍卖"——这不是需求分析失败，这是业务在生长。需求永远不完整，接受变化是常态；需求分析的价值不是让需求不变，而是让每次变化都有据可查——有一份需求清单，你才能说清楚"这次变化改了什么、影响哪些验收标准、代价多大"。
需求变了怎么办？有一份需求清单的好处，是把"变化"从"重来"变成"增量"：老周说"加个二手拍卖"，你打开清单看——新增功能需求"拍卖：出价、截止、成交"，影响非功能"交易不能出错"（拍卖的截止时间是并发敏感点），约束不变。于是你知道这次变化要动哪些验收标准、哪些设计、哪些代码——这就是变更的代价清单。没有需求清单的团队，一次需求变化就是一次全员恐慌；有清单的团队，一次需求变化是一次有据可查的增量。第 27 章的迭代循环，就是在这个基础上转起来的。
到这里可以总结需求分析的三笔收益，和两笔代价（过度分析、翻译错误）放在一起看：返工减少——方向错在开发前被拦住（老周事故的教训）；边界清晰——功能/非功能/约束各归其位，开发、测试、未来的自己都有据可查；选型有输入——第 5 章的九步模型终于有了真实的约束和评价维度，而不是靠猜。三笔收益对两笔代价：需求分析不是免费的，但它比返工便宜得多——一天分析对两周返工，这笔账在 4.1 算过。
反过来看，没做需求分析的团队长什么样？返工循环（做完发现不是要的）、需求蔓延（谁都能加一句"顺便"，没有清单就没有拒绝的依据）、技术债堆积（返工和蔓延的代码没人愿意重构）。这三个症状在第 20 章技术债的讨论里会再次出现——需求分析欠的债，最后都在代码质量上还。
4.6 本章对应表
| 业务诉求 | 技术选择 | 为什么 | 代价/取舍 |
|---|---|---|---|
| 一句话需求说不清 | 需求三分类（功能/非功能/约束） | 三类走偏方式对应三类需求，拆开才可开发可验收 | 分类本身要判断，边界模糊的需求可能分错 |
| 业务词含糊（"快""像淘宝"） | 业务语言→技术语言翻译（追问度量） | 不可度量=无法验收；翻译成指标+场景 | 翻译需要领域知识，可能精确地错 |
| 验收标准缺失 | 场景化验收标准 | 验收标准=未来测试用例（第 17 章） | 写验收标准要时间，要拉用户确认 |
| 什么都想要、三周做不完 | MVP 最小集（验证核心假设 + 复杂度预算） | 约束不可协商，复杂度预算花在假设上 | 砍错核心功能的风险，靠尽早试错对冲 |
| 需求会变 | 迭代式需求管理 | 需求永远不完整，变化是常态 | 变更管理成本（第 27 章回收） |
每一行都在本章正文里有完整的论证：三分类在 4.2，翻译在 4.3，验收标准在 4.3，MVP 在 4.4，迭代在 4.5。和前面章节的对应表一样，这张表的读法也是先看"业务诉求"列——需求分析的所有方法，都是被"说不清需求的代价"逼出来的。
这张表还可以和第 5 章那张表连起来看：第 4 章的表是分析工具（把业务诉求拆成可度量的需求），第 5 章的表是决策工具（把需求翻译成技术方案）——两张表合在一起，才是"业务 → 技术"的完整翻译：先分析出要什么，再决策出怎么做。这也是第二部分（第 4-7 章）的整体结构：本章分析需求，第 5 章做选型，第 6 章把业务模型变成数据模型，第 7 章把业务动作变成接口——四章合起来，就是"从业务到系统"的完整流水线。
本章小结
需求分析速查（后续章节回指本章时翻回这里）：
- 三问：多少？什么场景？谁判断？——把情绪词翻译成可度量；
- 三分类：功能（做什么）/非功能（做到什么程度）/约束（什么前提下）——每类分开列；
- 三层次砍需求：不做（验证前不存在）/后置（阶段后开）/简化（最简形态先走通）；
- 验收标准：Given-When-Then，写不出 Then 就是没想清；验收标准 = 未来的测试用例；
- 停止点：能写出第一条验收标准就可以开始，过度分析是另一种拖延。
（前三条是核心，后两条是分寸——记住前三条，本章的功夫就到手一半。）
- 需求分析是把业务诉求翻译成三类东西：功能需求（做什么）、非功能需求（做得多好）、约束（前提条件）——三者缺一，开发就会走偏；
- 翻译的关键动作是追问度量：多少？什么场景？谁判断？不可度量的需求等于没需求；产出的验收标准就是未来的测试用例；
- 砍需求不是砍功能，是把复杂度预算花在验证核心假设上（案例：先社区后交易）；砍的依据是假设，不是喜好；
- 需求分析有边界：过度分析会变成拖延，翻译可能精确地错（靠尽早给用户看验收标准防），需求本身会变（迭代是常态，第 27 章回收）；
- 本章的产出——那份需求清单——就是第 5 章选型的输入：业务线从这里出发，走向技术决策。
下一章
需求清单在手：功能是什么、要快成什么样、不能错到什么程度、一个人三周做完。但清单回答了"做什么"，没回答"怎么做"——用什么语言？什么框架？什么数据库？
下一章，技术决策：从业务约束到技术方案——第 5 章的九步决策模型，将在这份需求清单上完成全书第一次完整选型。读完第 5 章再回来看一眼本章的约束行，你会发现选型的结果，早就被约束写好了。