需求评审清单的价值在于把“大家讨论一下”变成可逐项核对、可判定通过与否的检查过程。它按会前准备、会上核对、会后确认三个节点使用，每项检查都写明通过标准和证据来源；关键项缺失时评审不通过，需求不进入排期。评审记录和遗留项可以放在ONES等协作工具中跟踪，本文重点给出清单本身的结构与判定方法。
要点总览（TL;DR）
- 需求评审清单按会前准备、会上核对、会后确认三个节点使用，由产品负责人或评审组织者维护，需求提出人、研发、测试、设计及依赖方按分工参与。
- 会前五项准备（背景目标、范围界定、优先级与时间、验收口径初稿、依赖方通知）任一项未通过，会议不进入正式评审环节。
- 会上六类检查项逐行给出通过、不通过或待定结论，通过标准要写明对象、判定条件和确认人，口头同意不作为完成依据。
- 业务目标不清、范围未定、验收口径缺失、关键依赖未确认属于阻断项，出现时评审不通过，需求不进入排期。
- 评审完成需同时满足结论明确和遗留项可跟进；结论、遗留项与需求状态应放入同一可追踪载体，便于下一轮评审前核对。
谁在什么时点用这份清单
这份清单面向参与需求评审的各方：需求提出人、产品负责人、研发、测试、设计，以及受需求影响的依赖方代表。不同角色在三个时点承担不同职责，清单由产品负责人或评审组织者维护，其他角色按分工提供材料、参与核对、确认结论。
| 角色 | 使用时点 | 主要职责 |
|---|---|---|
| 需求提出人 | 评审前 | 提供需求背景、业务目标、期望上线时间，说明需求来源 |
| 产品负责人 | 评审前、评审会、结论确认 | 准备需求文档与验收口径初稿，主持逐项核对，汇总结论与遗留项 |
| 研发 | 评审会 | 核对功能边界、异常分支、技术依赖与风险，判断可实现性 |
| 测试 | 评审会 | 核对验收标准是否可判断，提出测试视角的边界与异常场景 |
| 设计 | 评审会 | 核对用户场景与交互边界，确认设计输入是否充分 |
| 依赖方代表 | 评审会、结论确认 | 确认跨系统或跨团队的依赖条件与配合时点 |
拿出清单的前置条件是：需求文档已有可读版本，背景说明写清需求从哪来、解决什么问题，初步验收口径已经形成文字。三项缺任何一项，评审会应改期或缩小范围，先补齐材料再开。
会前准备检查项
会前准备解决的是“材料是否齐、人是否到、问题是否提前暴露”。以下五项在评审会开始前逐项核对，任一项未通过，会议不进入正式评审环节。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 需求背景与业务目标 | 写明需求来源、要解决的业务问题、期望达成的可观察结果，目标可被后续验证 | 需求文档中的背景与目标章节 | 需求提出人 |
| 需求范围界定 | 明确本次做什么，同时列出明确不做的部分，边界无歧义 | 需求文档中的范围说明 | 产品负责人 |
| 优先级与期望上线时间 | 给出优先级判断及理由，期望上线时间有明确日期或时间窗 | 需求文档或需求条目中的优先级字段、时间字段 | 产品负责人 |
| 验收口径初稿 | 至少覆盖主要功能点的通过条件，每条可判断是否达成 | 验收标准初稿文档 | 产品负责人、测试 |
| 依赖方通知 | 受影响的系统、团队代表已收到评审通知并确认参会 | 会议邀请与参会确认记录 | 评审组织者 |
会前检查建议在评审前一天完成，留出补材料的时间。发现缺项时，由负责人补齐后重新核对，不把缺项带到会上临时讨论，否则评审时间会被材料澄清占满，关键问题反而来不及核对。
评审会上逐项核对表
会上核对的对象是需求内容本身。下表六类检查项按顺序过一遍，每项当场给出“通过 / 不通过 / 待定”结论，待定项必须指定跟进人和回复时点。
| 检查项 | 通过标准 | 证据 | 负责人 | 结论 |
|---|---|---|---|---|
| 业务目标与用户场景 | 目标可验证；主要用户场景写清角色、触发条件、操作路径和期望结果，场景可被测试复现 | 需求文档场景描述、流程图或原型说明 | 产品负责人 | 通过 / 不通过 / 待定 |
| 功能边界与异常分支 | 功能边界明确；输入异常、权限不足、数据为空、并发冲突等主要异常分支有处理说明 | 需求文档功能说明、异常分支列表 | 产品负责人、研发 | 通过 / 不通过 / 待定 |
| 非功能要求 | 性能指标、权限规则、兼容范围、数据保留与迁移要求已提出，指标有数值或明确范围 | 需求文档非功能章节 | 研发、测试 | 通过 / 不通过 / 待定 |
| 依赖识别 | 与现有系统、外部接口、其他团队的依赖已列出，每项依赖有对接人和确认状态 | 依赖清单、对接确认记录 | 研发、依赖方代表 | 通过 / 不通过 / 待定 |
| 风险与待定项 | 已识别的风险有描述、影响判断和应对方向；待定项记录在案并指定跟进人 | 风险与待定项记录 | 评审组织者 | 通过 / 不通过 / 待定 |
| 验收标准 | 每条验收标准对应具体功能点，写明判定条件和预期结果，测试可据此设计用例 | 验收标准文档 | 产品负责人、测试 | 通过 / 不通过 / 待定 |
核对时按表逐行推进，一行结论确定后再进入下一行，避免多个问题交织讨论。对“待定”项，当场记录待定原因、跟进人和最晚回复时间，会后由跟进人补充材料，再决定是否需要复评。
通过标准与证据要求
通过标准写得含糊，评审就会变成主观判断。可用的通过标准具备三个特征：对象明确（针对哪个功能点或哪条要求）、条件明确（在什么情况下算达成）、判定人明确（由谁确认）。例如“性能满足要求”不可判断，“列表页在1万条数据下首屏加载不超过2秒，由测试在预发环境验证”就可核对。
证据是结论的支撑，口头同意不算完成。常用的证据形式包括：
- 需求文档的版本记录，能看出评审时依据的是哪一版；
- 评审记录，包含参会人、逐项结论和待定项；
- 结论确认记录，如评审纪要的确认回复或系统中的状态变更；
- 依赖方、测试等角色的书面确认，如对接说明或用例设计输入。
未达标项按统一格式记录：检查项名称、未达标的具体原因、补齐要求、责任人和复评时点。复评条件写清楚，例如“验收标准补充至每条可判断后复评”，避免复评时再次陷入范围讨论。
阻断项与评审完成条件
阻断项是必须让评审停在原地的问题。出现以下任一情况，评审结论为不通过，需求不进入排期：
| 阻断项 | 判定依据 | 处理责任人 |
|---|---|---|
| 业务目标不清 | 无法说明需求解决什么问题、达成什么可观察结果 | 需求提出人、产品负责人 |
| 范围未定 | 做什么与不做什么存在争议，边界无法确认 | 产品负责人 |
| 验收口径缺失 | 主要功能点没有可判断的验收标准 | 产品负责人、测试 |
| 关键依赖未确认 | 核心依赖方未参会或未给出配合结论 | 评审组织者、依赖方代表 |
阻断项的处理流程是：会上记录阻断原因，指定责任人和补齐时点，评审结论标记为不通过；材料补齐后重新发起评审，复评只核对阻断项及受影响的内容，不重复已通过的检查项。
评审完成的判定条件有两条同时满足：结论明确，即每个检查项都有通过、不通过或待定的结论，且无未处理的阻断项；遗留项可跟进，即每个待定项和未达标项都有责任人和确认时点。只满足其中一条，评审视为未完成。
评审结论如何落到协作流程里
评审结论如果只停留在会议纪要里，遗留项容易在排期压力下被遗忘。落地的关键是把结论、遗留项和需求状态放进同一个可追踪的记录载体：评审记录关联需求文档版本，遗留项作为独立条目带责任人和时点，需求状态从“待评审”流转到“已确认”或“待补充”。
在ONES中，需求可以作为工作项管理，评审记录和补充材料可以沉淀在Wiki页面，遗留项以工作项形式指派给责任人并设置时点，需求状态随评审结论更新。ONES Assistant智能助手能够理解项目、工作项和Wiki页面等真实工作上下文，基于相关项目数据和团队知识回答问题，并可将自然语言指令转化为ONES中可追踪的工作、保存为工作项或Wiki页面，便于把评审会上口头形成的遗留项快速记录为待办。具体使用方式以团队实际配置为准。
这样处理后，下一次评审前可以直接查看上一轮遗留项的完成情况，需求从待评审到已确认的每一步都有记录可查，评审清单也就从一次性表格变成了持续运转的检查机制。
常见问题
需求评审会上出现争议、无法当场达成一致时怎么处理？
把争议项按“待定”记录，写明争议焦点、各方观点、待补充的材料和跟进人，并约定最晚回复时间。评审结论先按其余检查项汇总，争议项不占用整场会议时间。跟进人补齐材料后，由产品负责人判断是否需要复评；复评只核对争议项及受影响的内容，已通过的检查项不重复讨论。
小需求或紧急需求也要走完整清单吗？
可以按风险裁剪，但裁剪要有明确规则，不能由提出人单方面跳过。建议保留业务目标、范围界定、验收标准和关键依赖四项，其余检查项可合并或简化。紧急需求同样需要留下书面结论和遗留项记录，否则后续排期和验收阶段容易反复澄清。裁剪范围由团队在评审规则中事先约定，避免每次临时判断。
评审通过后需求又发生变更，清单需要重新走一遍吗？
取决于变更影响的范围。若变更涉及业务目标、功能边界、验收标准或关键依赖，应重新核对对应检查项并更新评审记录；仅涉及文案、样式等不影响验收判断的调整，可由产品负责人确认后直接更新文档版本。无论哪种情况，需求文档版本记录都要能看出变更前后的差异，便于测试和研发对照。
评审记录和遗留项用什么方式承载比较合适？
关键是让结论、遗留项和需求状态互相关联、可查询。常见做法是把评审记录关联到需求文档的具体版本，遗留项作为独立条目指派责任人和时点，需求状态随结论更新。ONES 中需求可作为工作项管理，评审材料可沉淀在 Wiki 页面，ONES Assistant 智能助手能够理解项目、工作项和 Wiki 页面等工作上下文，并可将自然语言指令转化为可追踪的工作、保存为工作项或 Wiki 页面。具体配置以团队实际使用为准。
评审参与人经常缺席或派代表参会，会影响评审有效性吗？
会影响。关键角色缺席时，相关检查项无法当场确认，尤其是研发对功能边界与依赖的判断、测试对验收标准的判断。建议在会前通知环节确认参会人，核心角色无法到场时改期或缩小评审范围。派代表参会时，代表需具备对该领域结论的确认权限，否则相关项只能记为待定，不能算通过。
