需求调研

1 为什么先调研再画架构

接到“给 20 家门店做线上订单系统”的任务，很容易马上画出应用、数据库、缓存和消息队列。这张图能说明准备购买什么，却不能解释店员为什么会漏接订单、顾客在什么情况下重复付款、夜间出故障由谁恢复。组件越画越多，也可能只是把尚未理解的问题变成更长的产品采购清单。架构的起点应该是受影响的人、发生故障的场景，以及证明问题已经解决的证据。

P1 用问题、路径与验收解释解决方案。需求调研负责让其中的“问题”和“验收”落到现实：谁在什么时间做什么事，什么情况算失败，失败产生多少损失，谁有权确认结果。假设业务负责人说“上线后不能再漏单”，工程师直接把它理解成“必须部署消息队列”，就跳过了关键判断。漏单可能发生在支付回调、门店接单屏、交班记录或人工取消环节，不同原因需要的改动完全不同。

先把口号写成可以追查的事件。例如最近 1000 笔支付记录中，有 8 笔被投诉为“漏单”；它们对应的门店、支付时间、接单时间和退款状态分别是什么。只要还不知道这 8 笔发生在哪个环节，就不能把某种中间件写成已经确认的需求。调研不是承诺马上消除所有故障，而是缩小问题边界，让后续决策能够被证据支持或推翻。

调研也能发现“完成”的不同含义。经营负责人可能以退款投诉下降为成功，店员希望高峰期不再切换 3 个页面，值班人员关心告警是否能定位到具体门店，财务则要控制月度支出。这些目标并不天然一致。比如增加自动重试可能减少暂时失败，却让重复订单增加。只有把各方验收口径放在同张记录中，团队才能讨论取舍，而不是各自认领不同的“系统成功”。

可以给每条候选需求建立简短链路：“受影响角色→失败事件→业务影响→证据→验收负责人”。例如“晚班店员→已付款订单未出现在接单屏→顾客到店后等待→支付流水与接单日志对账→门店运营负责人确认”。这条链路仍不决定使用哪种数据库，却已经能排除很多无关设计。后面画架构时，每个主要能力都应能回到这条链路。

调研结束的标志也需要明确。会议开完、问卷收齐都只是活动完成；真正的出口是关键角色有代表、主要主张有证据、范围冲突有记录、需求有可复核的验收口径。若预算尚未得到财务确认，应标成待确认约束，不能把口头估计写成批准额度。这样得到的需求包，才能作为方案评审的输入。

2 调研对象：谁说话、谁买单、谁值班

至少覆盖 4 类角色：业务负责人、最终使用者、运维值班人员、财务或预算负责人。人数多不等于覆盖完整。连续访问 6 名管理者，仍可能不知道店员怎样处理打印机缺纸；采访 10 名店员，也不能代替预算审批。选择受访者时，应先画角色与决策关系，再安排姓名和时间。顾客不能到场时，可以让客服提供经过匿名处理的投诉记录作为代理证据，并注明这种代理的局限。

业务负责人回答“为什么现在做、收益如何判断”。例如运营负责人希望试点期间每 1000 笔支付关联的未接单投诉从 8 笔降到 2 笔以内。最终使用者回答“工作实际上怎样完成”：晚班只有 3 名店员，分别负责收银、出餐和交付，任何要求专人盯屏的流程都要说明人从哪里来。客户经理说操作方便，并不能替店员接受额外劳动。

运维值班人员回答“失败时怎样发现、怎样恢复”。假如夜间只有 1 名工程师同时负责 4 个系统，新方案每天增加 20 条无法行动的告警，就会挤占恢复时间。财务负责人回答“允许付出什么、费用记在哪里”：首季度每月总支出不超过 8000 元，且月度运维投入不超过 1 工程师周。云账单只是支出的部分，短信、网络、订阅和支持费用也要说明是否包含。

这里的指标都是访谈起点，尚未自动成为承诺。尤其是中位数，只说明典型操作，不能掩盖少数订单长时间未处理。记录时应区分“角色提出的目标”和“团队已确认的验收指标”，否则讨论稿中的数字会在转发后变成合同式要求。

可以轻量使用 RACI：R 表示实际执行，A 表示最终负责，C 表示需要征询，I 表示需要知会。不要为整份项目机械地填满表格，要围绕具体决策分配责任。例如改动试点门店数，由调研协调人整理影响，运营负责人周宁最终确认，财务与值班人员被征询，门店经理收到通知。对这项决策，只指定 1 名最终负责人，避免所有人都能否决却无人能够确认。

还要寻找指标之间的冲突。财务要求降低订阅费，可能把负担转移给店员；店员希望所有异常自动处理，可能增加运维复杂度。把“省下 1200 元订阅费，但每月新增 12 小时人工核对”写出来，比争论系统是否先进更有用。决定范围的人必须看到代价承受者的意见，不能把出席会议的资历当作证据强度。

3 访谈提纲：从目标到证据的 8 个问题

访谈应从最近发生的具体事件展开，再回到目标与约束。开场先说明会记录哪些信息、谁能查看、什么时候回访；涉及顾客信息时只保留分析所需字段。提问者负责澄清，记录者保留原话、数字、来源和疑点。下面的 8 个问题可以按实际流程调整顺序，但不要只勾选“已问”，要得到可追查的回答。

1. 为什么现在启动？ 坏追问是“是不是因为系统太落后”。好追问是“最近哪次事件让你决定投入，损失怎样记录”。示例回答为“上周末有 8 笔已付款订单被投诉未接单，样本是同期 1000 笔支付记录”。继续索取投诉编号与支付编号的对应关系，暂时称为疑似漏单，避免预先认定根因。
2. 谁在什么场景完成工作？ 坏追问是“新页面是不是做得简单点就行”。好追问是“请按最近 1 笔订单演示，从提示响起到交付经过谁”。示例回答为“晚班 3 人，收银员接单，出餐员看打印单，交付员核对取餐号”。再问忙时谁代接、交班时谁接手，以找到隐含的人员约束。
3. 忙到什么程度？ 坏追问是“每小时 200 单肯定够用吧”。好追问是“请给出统计时间、门店范围和最细时间桶”。示例回答为“20 家门店合计最高 200 单/小时”。继续取 5 分钟分桶数据：假设最忙的 5 分钟有 40 单，相当于该时段平均 8 单/分钟，不能用整小时平均约 3.33 单/分钟代替短时负载。
4. 失败怎样被发现？ 坏追问是“你们是不是也要上云”。好追问是“最近哪次顾客已付款而店员不知道，最先是谁发现的”。示例回答为“8 笔疑似漏单中，6 笔由顾客到店后指出，2 笔由客服发现”。追问发现耗时与通知路径，比询问部署地点更接近问题。
5. 现在怎样补救？ 坏追问是“加个自动重试就好了吧”。好追问是“请展示最近的补单或退款记录，哪些动作必须由人确认”。示例回答为“每笔异常核对约 6 分钟，需要比对支付流水和门店记录”。由此得到候选能力：展示关联证据与处理状态；是否自动重试，要等重复订单风险被看见后再决定。
6. 什么结果能接受？ 坏追问是“稳定可靠就算通过，对吗”。好追问是“由谁用什么样本验收，持续观察多久”。示例回答为“试点连续营业 7 天，每天对账；每 1000 笔支付的未接单投诉不超过 2 笔”。继续确认样本不足 1000 笔怎么办、投诉何时归属到订单，以及投诉目标能否代表完整性要求。
7. 资源和期限有哪些硬边界？ 坏追问是“预算以后再批也可以吧”。好追问是“谁批准，包含哪些费用，超出后谁选择缩范围”。示例回答为“首季度每月不超过 8000 元，运维不超过 1 工程师周，首批在 2026-11-20 前试点”。记录批准状态，不把申请额当成已批准额度。
8. 哪些还没有决定？ 坏追问是“大家都同意全部上线了吧”。好追问是“请各自复述首批范围，指出尚未确认的依赖”。示例回答为“运营说 20 家，项目经理说先 5 家，仓库还要求库存到秒”。当场建立冲突项、负责人和确认日期，不让含糊的点头代替决策。

每次访谈结束前，用 5 分钟复述“已知事实、候选需求、未知事项”。例如“200 单/小时”是受访者口述的负载，还不是已验证容量；“自动补单”是候选做法，还不是已批准范围。让受访者纠正记录，并约定后续证据入口。复述比增加更多抽象问题更能减少误解，也让没有参加访谈的工程师知道哪些内容可以用于设计。

4 现场与数据：日志、账单、工单比口述可靠

口述能提供线索，却容易受到记忆和职责位置影响。数据也有缺口：应用日志无法证明没有到达应用的请求，工单数不等于实际故障数，账单只记录付费项目。所谓交叉核对，是让不同来源围绕同个时间、同笔订单、同家门店互相解释。来源越多不代表结论越强；如果 3 份报表都复制自相同埋点，它们并非独立证据。

先建立证据登记表，记录来源系统、导出人、时间范围、时区、字段解释、缺失比例和可关联标识。本案例取支付 CSV 的 1000 行、最近 30 天客服工单、门店 Wi-Fi 与出口监测日志。支付记录用脱敏后的交易标识关联接单记录；客服工单保留分类和时间，删除顾客联系方式。采集之前确认 CSV 每行代表成功支付还是状态变化，退款与重复回调也不能混入订单总数。

对 1000 笔成功支付核对后，原来被称为“漏单”的 8 笔可能分成：5 笔晚到、2 笔因重复通知被误报、1 笔缺少接单证据。此时不能宣布漏单率已经确认是 0.8%，也不能宣称只有 0.1%。可以确认的是疑似事件比例为 8÷1000=0.8%，其中 1 笔仍待补证。分类会改变需求方向：晚到要研究及时性，重复通知要研究去重，证据缺失要研究状态追踪。

“经常连不上”也应转为带分母的描述。以某门店最近 30 天、每天营业 10 小时为例，共有 300 小时营业时间。每 5 分钟统计出口探测丢包率，得到 3600 个时间桶；其中 432 个桶的丢包率超过 2%，对应 36 小时，占营业时间 12%。因此可以写“该门店出口丢包率超过 2% 的时段占营业时间 12%”。这不等于 12% 的订单失败，更不能直接推广为全部 20 家门店的情况。

还要核对采样完整性。若 3600 个桶中另有 180 个没有观测，就应同时报告覆盖率为 95%，说明缺测是否集中于断电时段，并避免将缺测记成正常。上述 432 个异常桶占完整营业窗口 12%，在有观测的 3420 个桶中约占 12.63%；报告必须注明采用哪个分母。只有口径固定，后续修复前后才有可比性。

把异常时间与客服工单、网络费用明细放在时间线上。若工单集中在出口丢包时段，只能说明相关，还需要区分店内 Wi-Fi、门店出口和服务端故障。网络账单可以确认线路套餐和费用，却不能证明链路质量。调研结论可以是“优先验证网络相关性，试点增加断网提示与人工处理入口”，无需急于宣布必须更换平台。无法导出的数据也要登记替代取证方式、负责人和截止时间，不能让缺证据的断言获得更高优先级。

5 把愿望改写成可测需求

愿望描述方向，可测需求描述如何判断交付是否满足方向。改写时保留业务意图，补齐对象、动作、指标、证据来源、观察窗口和负责人。数字要由事实或决策支持，不能为了显得专业随手填上 99.99%。下面把访谈中的 5 句愿望改成待评审条目；其中目标值需要负责人确认，确认后才进入基线。

愿望 1：“别再漏单。” 改写为：“试点 5 家门店连续营业 7 天，每日闭店后 30 分钟内，将当天成功支付交易与接单、取消或退款状态关联；未关联交易必须进入异常清单，清单生成完整率为 100%，每条记录保留交易标识和处理人。”来源是支付 CSV 与订单状态导出，负责人为订单产品负责人林澈，运营复核。这里验收的是核对与暴露异常的能力，不把“没有投诉”当成数据完整性的充分证明。

愿望 2：“接单快点。” 改写为：“在 3 名店员的晚班配置下，抽取试点高峰期至少 100 次接单操作，从店员打开待接单项到提交成功，中位耗时不超过 20 秒，至少 95 次不超过 40 秒。”来源是现场计时与操作日志，窗口为连续 3 个晚班，负责人为门店经理陈妍。把页面操作时间与支付后送达门店的时间分开，避免网络延迟被算进店员动作，或被悄悄排除出整体体验。

愿望 3：“断网也能营业。” 改写为：“试点演练门店出口中断 10 分钟时，接单界面在检测到连接异常后 30 秒内提示人工处置入口，并显示最近成功同步时间；恢复连接后，店员能按交易标识核对中断期间订单，无需凭记忆补单。”来源是受控演练视频、连接事件日志与核对记录，每家试点门店演练 1 次，负责人为值班负责人许航。这个范围支持已约定的降级流程，不承诺断网期间仍能收到远端新订单。

愿望 4：“库存必须实时。” 改写为：“试点正常联网时，每次已确认库存变更到接单端展示相应版本，耗时不超过 5 分钟；连续 7 天检查全部已确认变更，以变更标识关联源端提交时间和展示版本确认时间。”来源是库存审计记录和接单端版本日志，负责人为库存负责人郭敏。断网期间明确显示旧数据时间，并暂停依赖新鲜库存的自动承诺；无法确认的订单进入人工核对。5 分钟能否接受，要由业务场景与冲突讨论决定，不能由工程师单方面替换原话。

愿望 5：“别太贵，也别难维护。” 改写为：“首季度每月支出不超过 8000 元，含托管资源、网络增量、短信和外部订阅；工程师运维投入另记工时，每月不超过 5 人日，每人日按 8 小时计。”来源是费用明细与工时记录，按月复核，预算负责人赵衡确认，值班负责人登记工时。若公司将人工折算进现金预算，应重新确认口径，不能将此处的独立工时约束理解为人工免费。

需求还要带适用条件和状态。“全部变更不超过 5 分钟”如果无法观测，就需要先补观测能力，不能仅靠验收时人工抽查便声称全量满足。需求变动时保留旧版本、修改原因与批准人，否则测试人员会用旧口径判失败，产品人员却以新口径解释成功。

这里也露出了非功能需求的入口，例如可用性草案“营业时段核心接单路径允许中断多长时间”、安全草案“退款操作由哪些角色授权、哪些行为需要审计”。它们应先记录业务后果、数据范围和确认人，再在 P3 展开指标、边界与验证结构。当前不必把所有细节写完，但不能把“安全可靠”留成无人负责的口号。

6 优先级：MoSCoW 与容量预算怎么一起用

MoSCoW 把需求分成 Must、Should、Could、Won't have this time。Must 是本轮缺失就无法达成已约定目标的内容；Should 很重要，但存在可接受的临时做法；Could 是资源允许时增加的收益；Won't 明确本轮不做。分类描述本轮交付承诺，不代表需求永久价值，也不表示说话者的级别。任何 Must 都应回答：删掉后，哪条已批准的验收会失败。

针对覆盖 20 家门店的整体目标，首轮 MVP 可以把支付关联、接单状态、异常清单、基本权限和故障提示列为 Must；跨门店经营报表列为 Should；主题外观列为 Could；复杂会员推荐列为本轮 Won't。之后仍要逐项估算成本和依赖。若没有预算检查，把 18 项全部写成 Must，只是给延期换了名称。需求条目数也不是可比工作量：历史数据迁移可能比多个页面改动更贵。

为了练习取舍，先使用教学估算模型。设本轮 Must 数量为 M，试点门店数为 S，月度现金成本 C=2000+350M+150S，单位为元；月度运维投入 T=0.8+0.25M+0.1S，单位为人日。模型把不同需求暂按相近复杂度处理，只用于暴露预算冲突，实际评审必须换成逐项估算。容量背景另记为现有 20 家门店合计峰值 200 单/小时，试点 5 家按历史数据暂估峰值 60 单/小时，不能直接按门店数量平均分摊。

在 M=8、S=20 时，C=7800 元，低于 8000 元上限；T=4.8 人日，也低于 5 人日上限。但增加到 M=14 时，C=9900 元，超出 1900 元，T=6.3 人日，同样越界。此时“全部都是 Must”不可能消除资源矛盾。把首批改为 S=5，则 C=7650 元、T=4.8 人日，可以进入评审；这仍需确认保留的需求是否适合试点，以及选定门店是否有代表性。

模型过线不等于真实容量足够。还应根据 5 分钟短时订单分布、异常处理量和断网场景验证方案。若试点门店包含最忙门店，其负载可能远高于门店数占比；若额外能力需要专属服务或夜间支持，线性模型会低估费用。因此预算表旁边要列出估算来源、敏感项与重新估算触发条件，不能拿滑块结果当采购报价。

当“实时到秒的库存联动”让整体费用超标时，有效决策是拆清业务后果，讨论缩小范围、放宽时效、追加预算或延期。假设负责人接受先保证 5 分钟同步，把秒级联动从本轮 Must 调整为后续候选，记录“现有营业流程可用人工核对承接，秒级方案增加月费与值班投入，待试点超卖数据证明收益后重评”。若某项能力确实是开业前提，就不能仅因超预算而偷偷降级，必须由范围负责人暂停上线或批准资源变化。

7 常见坑：诱导式提问、只听最高音量、把方案当需求

诱导式提问会把建议伪装成事实。 调研者问“上云后是不是就不会漏单”，店长为了尽快结束会议回答“是”。方案随后把迁移平台列为首要工作，却没有修复交班时无人确认订单的流程。试点后仍然发生漏单，团队才发现受访者从未比较过部署方式。修正方法是要求演示最近事件，询问“当时看到了什么、做了什么、在哪里留痕”，把技术选项留到问题与约束澄清以后。

即使没有明显暗示，也要防止带答案的数字。“20 秒够不够”会让人围绕提问者的数字讨价还价；先观察当前 100 次操作，再问等待多久会影响出餐，才能说明目标的依据。访谈记录中可以并列保存原话与改写，给受访者回看。若对方只能描述感受，就把它标为线索，安排现场计时，不要迫使对方当场编出精确数字。

只听最高音量会掩盖执行成本。 某负责人要求首版必须有跨门店经营大屏，会议立即把它列为 Must。店员直到试用才发现，退单需要回到收银机重新录入，晚班 3 人无法同时顾及出餐与核对。大屏虽然按时完成，未接单投诉却没有改善。补救不是否认管理者目标，而是把大屏对应的经营决策、使用频率与店员核心流程放在同张优先级表里，由范围负责人在预算内确认顺序。

沉默者也可能掌握最关键的证据。夜班工程师没有参加白天会议，团队默认可以增加新的值班组件；上线后每晚新增 12 次告警，值班人员只能临时关闭部分通知。调研应给不同班次留入口，允许受访者提交工单或异步批注。主持人可以按角色轮流核对“这条要求增加了什么工作”，让反对意见被记录，而不是把没有发言解释为同意。

把方案当需求会过早锁死选择。 “必须用某云托管数据库”可能来自已有运维经验，也可能只是销售演示。要继续问：真正需要的是减少备份工作、满足采购合同，还是复用现有技能？如果现行合同限定供应商，就把它作为采购约束，注明合同出处、适用期限和批准人；如果只是偏好，就保留为候选实现。这样做仍允许最后选择该服务，但选择有了能接受评审的理由。

还有种常见失败是把所有愿望都解释成“用户已经确认”。访谈者说“最好能自动退款”，不等于退款权限、误退责任和财务对账已经明确。应把它拆成目标、候选流程与待确认风险，再决定是否进入本轮。每条关键需求最好有反证问题：哪种情况会让这个指标失去意义，哪位角色会因此多做工作，现有证据还缺什么。能回答这些问题，需求才经得起方案评审。

8 案例：20 家门店线上订单的半日调研

某连锁商户计划把线上订单接入 20 家门店，团队只有 1 名调研协调人和 1 名工程师。本案例沿用“半日调研”的项目简称，实际指门店受访集中在上午；数据提取与归纳延续到 17:00，排期不能把它写成整个团队只投入半天。前个工作日先取得支付导出权限、工单访问权限和网络日志负责人联系方式，避免把现场时间花在等待账号上。

08:45 前，财务负责人赵衡异步确认预算口径：首季度每月现金支出不超过 8000 元，人工另受每月 5 人日约束。财务虽然不在上午的 3 场访谈中，仍然属于必须覆盖的角色；如果回复缺席，预算只列为待确认，下午的方案不能以“已批准”状态送审。协调人准备证据表与访谈提纲，工程师准备脱敏关联字段，不提前制作产品推荐页。

09:00—10:00 访问业务负责人，核对 20 家门店的整体目标、投诉基线与首批期限。10:00—11:00 由晚班店员演示最近的接单、交班和退款过程，重点核对 3 人配置下的动作分配。11:00—12:00 访问值班负责人，查看故障通知、人工补单和网络异常处理。每场预留末尾 5 分钟复述事实与疑点；没有看见操作或证据的结论，仍保留“待验证”标记。

13:00—15:00 提取并核对数据。工程师关联 1000 笔支付记录与接单状态，协调人整理最近 30 天工单及 Wi-Fi、出口日志。在共同时间轴上标记 8 笔疑似漏单，按晚到、重复通知和缺证据分类。字段时区不一致时先统一，交易标识缺失时建立待补清单；不要为赶在 15:00 前完成，就用金额和相近时间强行配对。可以保留未匹配项，但必须让它们出现在结论里。

15:00—17:00 把结果压缩成 1 页待办清单及证据附件。先讨论相互冲突的范围，再确认至少 5 条改写需求，随后做 MoSCoW 与预算估算。会议最后请没有负责写稿的工程师口头复述首批门店数、库存同步目标和未决事项。如果复述有偏差，优先修改记录，而不是要求读者记住会议背景。

交付物需要绑定负责人：协调人林澈维护角色与访谈纪要；工程师许航维护证据索引、关联方法和缺测说明；运营负责人周宁确认首批范围与需求基线；赵衡确认预算口径；门店经理陈妍确认现场验收安排。1 页清单保留需求编号、优先级、负责人、验收摘要及证据链接，详细数据放在附件，避免靠缩小字体制造“已经收敛”的假象。

当天应交付可用于选择方案的输入，而不是宣称所有事实已经查明。若那笔缺少接单证据的支付仍无法解释，就安排负责人在 2026-11-04 前补证，并说明补证可能影响哪条需求。若试点日志覆盖不了断网时段，就将采集改进列为前置工作。把未知事项关进有期限的队列，比用“后续优化”掩盖空白更能支持按期推进。

9 排查案例：需求文档三处互相打架怎么收敛

评审前发现需求文档存在 3 句相互牵制的话：A 写“全部门店上线”，B 写“先 5 家试点”，C 写“库存必须实时到秒”。它们可能分别出现在目标页、排期表和接口描述中，各自都有签字，却没有共同适用范围。若工程师分别照着实现，就会得到 20 家门店配置、5 家测试资源和秒级同步承诺，任何局部交付都无法证明整体完成。

主持人先暂停技术选型争论，建立证据板。每张记录卡包含原文、提出者、适用阶段、业务理由、支撑材料和待决定事项。A 的证据是年度经营计划，表达长期覆盖 20 家门店；B 的证据是首批培训与上线排期，只能支持 5 家；C 的提出者担心超卖，但尚未提供“超过 1 秒就造成损失”的交易证据。这里不能因为 C 没有证据就删除超卖问题，应保留风险并安排验证。

接着把讨论分成决策可以处理的内容。范围轴上区分整体目标与首批验收；时效轴上区分正常联网和断网降级；资源轴上展示费用及值班负担。工程师给出教学估算：M=14、S=20 时月费 9900 元、运维 6.3 人日，均超出限制；改为 S=5 后分别为 7650 元、4.8 人日。库存负责人说明，试点可以利用预留库存与人工核对承接同步延迟，但需要在真实营业中观察超卖事件。

主持人请各方回答“什么条件下可以接受 5 分钟”，而不是在 1 秒和 5 分钟之间凭职位投票。约定试点正常联网时库存变更到展示不超过 5 分钟，断网显示最后同步时间并进入人工核对；若出现因库存陈旧导致的错误承诺，就登记事件、影响与处置，触发重新评估。这个决定降低了当前实现压力，也明确保留了业务验证责任，并未证明所有门店长期都能接受相同目标。

正式决议写为：“首批试点 5 家门店，整体推广目标仍为 20 家；库存同步时限为正常联网下不超过 5 分钟，原 1 秒表述撤销。范围负责人周宁于 2026-11-03 17:00 前确认并发布需求基线。”基线附试点门店名单、验收窗口、降级流程、预算口径、变更原因和后续扩店的复核条件。实际签认未完成前，只能标记待确认，不能把拟定日期当成已经批准。

随后把原文中的 A、B、C 指向这份决议，更新目标页、排期表和接口说明的生效状态。只在聊天中说“以最新意见为准”，不能消除旧材料被继续引用的风险。对尚未解决的库存证据，指定郭敏负责，在试点第 7 个营业日结束后提交超卖与人工核对统计，作为是否收紧时效或增加投入的输入。

最后做脱离作者的验收：请另 1 名工程师只阅读基线，不听口头解释，复述上线门店、库存时限、异常处置、确认人和日期，并据此列出测试范围。若对方仍问“到底做 5 家还是 20 家”“1 秒是否还要测”，说明文档没有收敛。需求调研的交付质量，体现在接手者能作出一致判断，而不体现在会议已经开了多久。

放进方案里

在方案评审材料的开头放入调研准入清单，并给出可追查的记录入口。先检查角色：业务负责人、店员或顾客代理、值班人员、预算负责人是否覆盖；每类角色留下成功指标、实际约束与确认状态。缺席者写明补访人和日期，不能用管理者代替所有使用者。再检查提问：8 个问题是否得到具体回答，最近事件、现行流程、峰值、失败发现、补救、验收、资源与未决事项是否都有记录。

检查证据时，要求支付流水、日志、费用明细或工单具有来源、时间范围、分母和关联方式。口述数字必须标明未验证；缺测、未匹配交易与相反证据要可见。至少保留 5 条从愿望改写的需求，每条说明对象、指标、数据来源、观察窗口和负责人。可用性与安全草案允许继续细化，但必须指出业务后果和后续确认人。

检查范围时，列出本轮 MoSCoW、月度预算及运维投入的估算，把首批门店数与长期覆盖目标分开。超预算的 Must 必须附带缩范围、延期或追加资源的决定，以及批准状态。开放冲突集中记录原文、影响、负责人和截止日期；已经解决的冲突链接到生效基线，并注明旧表述如何退出使用。需求数量不等于完整性，预算合格也不等于容量已经验证。

让未参与调研的第 2 人使用这份清单独立审阅。如果材料只有数据库、缓存、云服务和产品价格，无法回答谁遇到什么失败、凭什么证据判定解决，就退回补充需求输入。退回时指出缺少的角色、证据或验收条目，避免只写“需求不清”。当审阅者能在没有作者解释的情况下复述首批范围、关键指标、约束及未决事项，调研包才具备进入方案设计的条件。

10 小结：从调研清单走向非功能需求

需求调研把角色经历变成证据，把愿望变成可复核条目，再把冲突变成有负责人和日期的决策。可以自查：200 单/小时指哪些门店，8 笔疑似漏单能否直接算漏单率，首批 5 家与整体 20 家在文档中是否各有明确阶段。

接下来进入 P3 非功能需求，把可用性、性能、安全与运维约束写成更完整的指标和验证结构。也可以按 Stage2 的并行安排继续云课程，用本课形成的需求与预算边界评估云服务能力；无需先学完云课程才能完成需求调研。

下一课转向 P3 非功能需求：把本章验收过的结论带进后续主题，写成可检查的方案约束。