需求评审的依据由四类材料构成：需求本身的完整描述与验收口径、上游来源与业务目标、约束与依赖条件、评审规则与历史记录。评审前按清单备齐并标注版本，评审中逐条对照判断需求能否进入开发，评审后把结论与待办回写到需求条目。本文聚焦需求评审这一环节，方案原型评审与研发阶段决策不在讨论范围内。
要点总览（TL;DR）
- 需求评审的依据分四类：需求描述与验收口径、来源与业务目标、约束与依赖、评审规则与历史记录，每类材料都要标注版本与责任人。
- 评审前两个工作日冻结需求描述与验收口径，会前一天冻结约束与依赖；关键材料缺失时顺延评审，次要材料缺失可降级为有条件通过。
- 会上按目标、描述、约束、规则四类逐条核对，结论分为通过、有条件通过、退回补充三类，判定标准需提前写明。
- 评审结论、待办与依据版本要回写到需求条目，待办指定责任人和复核人，依据变更保留旧版本以便追溯。
- 评审完成后按依据齐全、结论明确、待办有责任人、记录可追溯四项做完成检查，依据链可在后续需求变更中复用。
需求评审要备齐哪几类依据
评审桌上缺材料，讨论就容易滑向主观判断：有人凭印象说”这个做不了”，有人凭经验说”用户肯定要”。把依据分成四类并逐项备齐，评审才有可对照的基准。四类依据各自回答一个不同的问题，缺任何一类都会让判断出现盲区。
| 类别 | 具体材料 | 回答的问题 | 责任人 | 版本要求 |
|---|---|---|---|---|
| 需求描述与验收口径 | 需求说明、业务规则、界面或流程说明、验收标准、优先级 | 要做成什么样，怎样算做完 | 产品负责人 | 评审冻结版，标注日期与修订号 |
| 来源与业务目标 | 需求提出人、来源渠道（客户反馈、运营诉求、数据洞察）、关联目标与衡量指标 | 为什么做，做完影响什么 | 需求提出人 | 与需求条目关联，注明提出时间 |
| 约束与依赖 | 技术约束、合规要求、上线时间窗、上下游系统依赖、关联需求与排期 | 在什么条件下做，受谁影响 | 研发负责人、测试负责人 | 评审前确认，依赖方需给出可用时间 |
| 评审规则与历史记录 | 评审准入标准、结论判定规则、同类需求的历史评审结论与遗留问题 | 按什么标准判，以前踩过什么坑 | 评审组织者 | 规则用当前生效版，历史记录取最近同类项 |
每类依据缺失的后果不同。缺验收口径，评审只能确认”方向对”，无法确认”做完的标准”，开发中容易反复返工；缺来源与目标，需求优先级失去支撑，资源紧张时最先被砍；缺约束与依赖，排期承诺建立在假设上，联调阶段才发现外部接口未就绪；缺评审规则与历史记录，同类问题重复讨论，上次的遗留风险无人跟进。
版本标注是依据可用的前提。每份材料注明版本号或修订日期、责任人和适用范围，评审通知里附带的材料清单与会上展示的材料保持一致。口头补充的内容当场记入会议记录，会后并入需求条目，避免出现”会上说过但文档里没有”的分歧。
评审前如何准备依据并确定参与角色
依据准备的关键是设定冻结时点。建议在评审会前两个工作日冻结需求描述与验收口径，会前一天冻结约束与依赖的确认结果。冻结后如需修改，由产品负责人判断是否影响评审范围：影响范围则顺延评审，不影响则在会上说明变更点。冻结时点写进评审通知，参与者据此安排阅读时间。
| 角色 | 提供的材料 | 确认动作 | 完成时点 |
|---|---|---|---|
| 需求提出人 | 来源说明、业务目标、期望收益与衡量指标 | 确认目标可衡量、优先级理由成立 | 评审前三天 |
| 产品负责人 | 需求说明、业务规则、验收标准、原型或流程说明 | 确认描述完整、验收口径可判定 | 评审前两天冻结 |
| 研发负责人 | 技术约束、实现方案要点、工作量区间、外部依赖 | 确认约束已识别、依赖方已沟通 | 评审前一天 |
| 测试负责人 | 验收标准的可测性意见、测试范围与数据准备需求 | 确认每条验收标准可验证 | 评审前一天 |
| 业务方 | 使用场景、操作角色、上线时间要求 | 确认场景覆盖主要使用路径 | 评审前一天 |
依据不全时有两种处理方式。缺的是关键材料，例如验收标准缺失或依赖方未确认，采用补件：评审顺延，组织者列出缺件清单并指定补齐责任人与时限。缺的是次要材料，例如历史记录未整理完整，采用降级评审：会议照常进行，结论限定为”有条件通过”，补齐材料后由指定角色复核确认，不再重复开会。
评审通知应附带材料清单，逐项列出材料名称、版本、责任人和存放位置，并写明本次评审的判定规则与预计时长。参与者收到通知后先阅读材料，会上直接进入判断环节，把会议时间用在分歧点上。
评审会上如何逐条对照依据做判断
会议按依据类别逐条核对，每一类给出明确的问题，避免讨论发散。核对顺序建议从目标到约束：先确认来源与目标成立，再确认需求描述与验收口径完整，然后确认约束与依赖可控，最后对照评审规则与历史记录检查是否触碰已知风险。
- 来源与目标：提出人是否明确，目标是否有衡量指标，与当前阶段重点是否一致。
- 需求描述与验收口径：业务规则是否有遗漏分支，异常场景是否覆盖，每条验收标准能否用测试用例验证。
- 约束与依赖：技术约束是否影响方案可行性，依赖方是否给出可用时间，上线时间窗是否与排期冲突。
- 评审规则与历史记录：是否满足准入标准，同类需求的历史遗留问题是否已规避。
结论分三类，判定标准需在会上明确。通过：四类依据齐全，无未决分歧，验收标准可测，依赖已确认。有条件通过：主体依据齐全，存在个别待补项，但待补项不影响开发启动，需指定责任人与补齐时限，补齐后由指定角色复核。退回补充：关键依据缺失，例如验收标准无法判定或核心依赖未确认，需求退回补充材料后重新排期评审。
争议项当场记录，写明分歧点、各方观点和所需补充的信息。争议涉及资源优先级时，升级到产品负责人与研发负责人共同决策；涉及业务目标是否成立时，升级到需求提出人的上级或业务决策人。升级路径和时限在评审规则中预先约定，避免争议悬置。
| 记录字段 | 填写内容 |
|---|---|
| 需求标识 | 需求编号与名称 |
| 评审日期与参与人 | 日期、各角色到场人员 |
| 依据核对结果 | 四类依据逐项标注齐全、缺失或待确认 |
| 结论 | 通过、有条件通过或退回补充 |
| 待办事项 | 事项描述、责任人、截止时间、复核人 |
| 争议与升级 | 分歧点、升级对象、决策结果 |
一个需求评审依据的填写示例
以下为演示情景，用于说明依据如何组织并支撑结论，不代表真实项目数据。
背景：某内部管理系统收到运营团队提出的需求，希望在订单列表增加批量导出功能，目标是减少运营人员每周手工整理数据的时间。需求提出人给出目标：导出耗时从每周约四小时降至一小时内，衡量方式为运营人员记录的实际操作时长。
| 依据类别 | 填写内容 |
|---|---|
| 需求描述与验收口径 | 支持按筛选条件导出订单明细，字段包含订单号、下单时间、金额、状态；单次导出上限五万条；验收标准：按指定条件导出后字段完整、金额与列表一致、超限时有明确提示 |
| 来源与业务目标 | 来源为运营团队周会反馈；目标为每周手工整理时间降至一小时内；优先级为中，因当前有合规改造任务并行 |
| 约束与依赖 | 导出文件需符合数据脱敏要求，手机号中间四位掩码；依赖报表服务提供导出接口，该接口预计两周后可用；上线时间窗为下个迭代末 |
| 评审规则与历史记录 | 准入标准要求验收标准可测、依赖已确认；历史记录显示上一版导出功能因未做脱敏被安全评审退回 |
评审中发现两个问题：一是验收标准未写明导出失败时的处理方式，测试无法设计异常用例；二是报表服务接口的可用时间晚于计划上线时间窗。对应结论为有条件通过：产品负责人三个工作日内补充异常场景的验收标准，研发负责人与报表服务方确认接口时间并调整排期，两项待办均指定复核人。历史记录中的脱敏问题已在依据中明确，评审时确认方案包含掩码规则，不再重复讨论。
这个示例可迁移的规律是：依据填写要落到可验证的粒度，验收标准写到测试能直接设计用例的程度；依赖项必须带时间，不能只写”依赖某系统”；历史记录的作用是提前排除已知风险，把讨论集中在本次新增的不确定点上。
评审后如何回写依据并做完成检查
评审结论只有回写到需求条目才算落地。回写字段包括：评审结论、评审日期与参与人、依据材料的版本号、待办事项及责任人、争议项的决策结果。待办事项进入任务跟踪，与需求条目关联，完成一项关闭一项，复核人确认后标记完成。
依据版本在评审后如有变更，例如验收标准补充或依赖时间调整，需在需求条目中记录变更内容、变更原因和变更人，保留旧版本可查。这样后续开发、测试和验收都以最新版本为准，出现分歧时能追溯到是哪次变更引入的差异。
评审完成后逐项核对以下检查项：
- 四类依据齐全，每类材料标注版本与责任人。
- 评审结论明确为通过、有条件通过或退回补充，无模糊表述。
- 每条待办有责任人和截止时间，有条件通过的待办指定了复核人。
- 争议项已记录并给出升级结果或后续决策时点。
- 结论与待办已回写到需求条目，与需求状态一致。
- 依据变更留有记录，旧版本可追溯。
依据链在后续变更中可复用。需求进入开发后发生变更时，先对照评审时冻结的依据判断变更影响范围：只影响实现细节的，由研发负责人确认；影响验收口径或依赖的，回到评审规则判断是否需要重新评审。历史评审记录也成为下一次同类需求的参考依据，减少重复讨论。在需求条目上集中管理依据材料、评审结论与待办状态，可以让这条依据链在需求生命周期内保持可查。ONES 的需求管理工作项支持记录需求描述、验收标准与关联材料，评审结论和待办可作为字段或关联任务留存，便于后续变更时对照原始依据。
常见问题
需求评审前材料没备齐，是照常开会还是推迟？
按缺失材料的重要性区分处理。缺的是关键材料，例如验收标准无法判定或核心依赖方未确认，建议顺延评审，组织者列出缺件清单并指定补齐责任人与时限。缺的是次要材料，例如历史评审记录未整理完整，可以照常开会，但结论限定为“有条件通过”，补齐后由指定角色复核确认，不再重复开会。判断关键与否的标准是：缺了它，会上能否对需求是否可进入开发给出明确结论。
验收标准写到什么程度，评审才算有依据？
写到测试人员能直接据此设计用例的程度。具体包括：正常路径的预期结果、异常与边界场景的处理方式、数据口径（例如金额是否含税、时间按哪个时区）、以及导出或批量操作的上限。示例中的教训是验收标准只写了导出字段完整，未写导出失败时的提示方式，测试无法设计异常用例，评审只能给有条件通过。验收标准越接近可验证的断言，评审中的争议越少。
有条件通过的需求，后续由谁确认待办补齐？
评审会上就要指定复核人，通常由提出待办的角色或其直接负责人担任，例如验收标准补充由测试负责人复核，依赖时间确认由研发负责人复核。待办进入任务跟踪并与需求条目关联，完成一项关闭一项，复核人确认后才标记完成。复核结果回写到需求条目，需求状态随之更新。若补齐过程中发现影响范围超出原评审结论，例如依赖时间推迟导致上线窗口变化，应回到评审规则判断是否需要重新评审。
需求评审的依据和方案原型评审的依据有什么区别？
需求评审判断的是“这个需求该不该做、做成什么样算完成”，依据集中在需求描述与验收口径、来源与目标、约束与依赖、评审规则与历史记录。方案原型评审判断的是“这个方案能不能实现需求、交互是否合理”，依据更多是原型稿、交互说明、技术方案与设计规范。两者可以衔接：需求评审通过后进入方案设计，方案原型评审时把需求评审冻结的验收口径作为对照基准。本文只覆盖需求评审环节，方案原型评审的组织方式不在讨论范围内。
需求进入开发后发生变更，原来的评审依据还有用吗？
有用，它是判断变更影响范围的基准。变更发生时先对照评审时冻结的依据：只影响实现细节的，由研发负责人确认即可；影响验收口径、依赖或上线时间窗的，按评审规则判断是否需要重新评审。原评审记录中的历史遗留问题也可作为参考，避免同类风险再次出现。因此依据材料、评审结论与待办状态集中保存在需求条目上，变更时能快速调出原始依据做对照。
