需求评审与确认的依据由四类材料构成：需求本身的完整描述（来源、目标、范围、验收口径）、约束与依赖（业务规则、合规要求、技术限制、上下游接口）、可验证的支撑材料（数据、原型说明、历史同类需求记录），以及明确的评审规则（参与角色、判定标准、结论记录方式）。评审前把这些材料按需求逐条挂齐，评审中逐项核对并记录结论与待办，评审后由负责人确认关闭条件，才算完成一次可追溯的确认。下文按准备、核对、分工、示例与检查的顺序给出操作路径；在 ONES 中，需求条目、依据材料、评审结论与待办可以在同一工作项中挂接和流转。
要点总览（TL;DR）
- 需求评审与确认的依据分四类：需求描述（来源、目标、范围、验收口径）、约束与依赖（业务规则、合规要求、技术限制、上下游接口）、可验证支撑材料（数据、原型说明、历史同类需求记录）、评审规则（参与角色、判定标准、结论记录方式）。
- 评审前按需求逐条挂接依据，标注缺失项：关键缺失建议延期评审，部分缺失可上会但需在结论中写明补齐责任人与期限。
- 评审中逐条核对依据与需求描述的一致性，结论分通过、有条件通过、退回补充三档，并记录异议、待办、责任人与期限。
- 确认以记录落定为准，由需求负责人会同业务方代表完成；涉及合规或架构约束的需求需对应领域负责人确认相关依据。
- 完成判断看五项：依据完整性、缺失项处理、结论记录、确认有效性、跟踪闭环；依据关键缺失仍强行通过或结论无责任人，均不计为完成。
一次合格的需求评审要准备哪几类依据
只带一份需求文档进评审，评审往往只能停留在“听起来合理”的层面，无法判断需求是否该做、能否做、做完怎么算完成。把依据分成四类，可以让每个评审问题都有对应的材料支撑。
| 类别 | 包含材料 | 对应评审问题 |
|---|---|---|
| 需求描述 | 需求来源与提出人、业务目标、范围边界（含不做什么）、验收口径 | 这个需求解决什么问题？做到什么程度算完成？哪些不在本次范围内？ |
| 约束与依赖 | 业务规则、合规与安全要求、技术限制、上下游系统接口、关联需求 | 有哪些必须遵守的规则？依赖谁提供什么？哪一方先完成？ |
| 可验证支撑材料 | 业务数据或现状统计、原型与流程说明、历史同类需求记录、用户反馈 | 需求描述有数据支撑吗？方案是否经过推演？过去同类需求有什么经验？ |
| 评审规则 | 参与角色与职责、判定标准（通过/有条件通过/退回补充）、结论与待办记录方式 | 谁来评、按什么标准判、结论记在哪里、后续由谁跟踪？ |
依据齐备程度直接决定评审能走多深。四类材料齐全时，评审可以逐项做判断并当场形成结论；缺少约束与依赖，评审只能确认“方向可行”，具体实施仍需二次确认；缺少验收口径，评审无法判断需求是否可交付。依据不全时，可以选择先补充再评审，也可以明确以“有条件通过”的方式限定补齐责任人与期限，两种做法都需要在记录中写清楚。
评审前：按需求逐条挂齐依据的操作步骤
评审前的准备工作以“每条需求一份依据包”为目标，输入是本次待评审的需求清单，输出是挂接完成的材料与缺失项记录，完成标志是材料已分发、评审问题已列出。
- 确定评审范围与需求清单。由需求负责人汇总本次上会的需求条目，标注优先级与相互依赖关系。范围一旦确定，清单外的需求不临时插入，避免评审被稀释。
- 为每条需求挂接来源、目标、范围与验收口径。来源写清提出方与业务场景，目标写成可判断的表述，范围明确包含项与排除项，验收口径尽量落到可检查的条件。这一步的产物是需求描述字段的完整填写。
- 补充约束与依赖。逐条列出业务规则、合规要求、技术限制和上下游接口，标明依赖方与预计提供时间。跨团队依赖要写清对接人和交付物，避免会上才发现关键输入尚未确定。
- 附上可验证的支撑材料。数据统计、原型说明、历史同类需求记录按需求归入对应条目，材料要能回答“为什么这么判断”，而不是仅作背景展示。
- 标注缺失项并决定是否延期。对每条需求标记依据完整度：齐全、部分缺失、关键缺失。关键缺失（如验收口径或核心依赖未定）建议延期评审；部分缺失可上会但需在结论中写明补齐责任。
- 提前分发材料与评审问题清单。至少提前一个工作日把依据包和问题清单发给参会角色，问题清单按“需要谁回答什么”组织，让评审从宣读材料转为集中讨论分歧。
准备阶段的记录建议保留一张挂接表：需求编号、依据类别、材料位置、完整状态、缺失项责任人。这张表既是评审的输入，也是后续跟踪补齐情况的依据。
评审中：依据如何支撑逐项确认与结论记录
评审会上的核心动作是逐条核对：需求描述与支撑材料是否一致，约束与依赖是否已被相关方确认，验收口径是否可检查。核对以依据包为对象，逐项给出“一致、存在分歧、缺失”的判断，而不是对需求整体做印象式表态。
判定建议分为三档，每档对应明确的后续动作：
- 通过：四类依据齐全且核对一致，可进入后续方案或开发环节。
- 有条件通过：主体可行，但存在需补齐的依据或待确认的依赖，结论中写明补齐内容、责任人与期限，到期未补齐则回到评审。
- 退回补充：关键依据缺失或需求描述与材料存在实质冲突，退回提出方补充后重新排期评审。
结论记录需要包含固定字段，保证事后可追溯：需求编号与名称、参会角色、依据核对结果（按四类分别记录）、结论档位、异议内容及提出人、待办事项与责任人及期限、确认人签字或系统确认记录。异议即使未被采纳也应保留，它记录了当时的判断分歧，对后续复盘有价值。
最终确认权应归属明确角色，通常由需求负责人会同业务方代表共同确认；涉及合规或架构约束的需求，需要对应领域负责人确认相关依据。确认动作以记录落定为准，口头同意不计入完成。
角色分工与各环节交付物
依据无人负责是评审流于形式的主要原因。把准备、评审、确认、跟踪四件事分配到具体角色，并约定各环节交付物，可以让依据始终有主。
| 角色 | 评审前 | 评审中 | 评审后 |
|---|---|---|---|
| 需求提出方 | 提供业务背景、目标与来源说明，确认范围边界 | 解释需求意图，回应业务规则相关问题 | 按待办补充业务侧材料 |
| 需求负责人 | 汇总需求清单，组织依据挂接，标注缺失项，分发材料 | 主持逐条核对，记录结论与待办 | 跟踪待办关闭，发起确认 |
| 评审参与角色（业务、技术、测试、合规等） | 预读材料，提交评审问题 | 按职责核对对应依据，给出判断与异议 | 确认本人负责的待办完成情况 |
| 确认人 | 了解评审范围与判定标准 | 对结论档位做最终确认 | 核对关闭条件后签署确认记录 |
依据缺失时的升级路径需要事先约定：一般缺失由需求负责人在准备阶段推动补齐；关键缺失且影响排期的，由需求负责人提交给需求提出方的上级或项目决策人，决定延期评审还是带条件通过。升级的判断标准和受理人应写入评审规则，避免每次临时协商。
在 ONES 中，需求可以作为工作项承载描述字段与依据附件，评审结论与待办在同一工作项下记录和流转，需求负责人据此跟踪待办关闭；团队知识类材料可放在 ONES Wiki 页面中与需求关联，使依据和结论保持在同一上下文里。
示例：一条需求从依据准备到确认关闭
以下为演示情景，用于说明依据挂接与关闭流程，不代表真实项目记录。
需求：客户订单列表增加按交付状态筛选，支持运营人员快速定位延迟订单。
依据清单：
- 需求描述：来源为运营团队季度反馈；目标是将延迟订单的人工排查时间从逐页翻找改为条件筛选；范围为订单列表页筛选条件，不含报表导出；验收口径为按交付状态筛选结果准确，且与订单详情状态一致。
- 约束与依赖：交付状态字段由订单服务提供，需确认字段口径与更新频率；筛选需遵循现有数据权限规则；依赖订单服务接口在评审后两周内提供字段说明。
- 支撑材料：近三个月延迟订单人工排查的工时统计、运营提供的筛选场景清单、历史上类似筛选需求的实现记录。
- 评审规则：业务、技术、测试三方参与，判定分三档，结论记录在需求工作项中。
评审中的核对与结论：业务方确认筛选场景清单覆盖主要场景；技术方指出交付状态字段口径尚未与订单服务对齐，属于关键依赖未定；测试方提出验收口径需补充状态不一致时的处理方式。综合判定为有条件通过：由技术方在一周内确认字段口径，测试方补充验收条件，需求负责人跟踪。
待办关闭与确认：一周后字段口径说明与补充验收条件挂入同一需求条目，需求负责人核对后提交确认人，确认人检查两项待办均已关闭、结论记录完整，签署确认，需求进入后续方案环节。
可迁移的规律：关键依赖未定时，带条件通过比强行通过更可控，前提是补齐责任与期限写进记录；验收口径的分歧往往在评审中才暴露，提前准备支撑材料能让分歧更早被定位。
完成检查：评审与确认是否做到位
评审结束后，用以下清单逐项核对，全部满足才视为本次评审与确认完成。
| 检查项 | 通过标准 |
|---|---|
| 依据完整性 | 每条上会需求均有来源、目标、范围、验收口径；约束与依赖已列明责任方；支撑材料可查 |
| 缺失项处理 | 缺失项已标注，关键缺失已决定延期或写入带条件通过的补齐责任与期限 |
| 结论记录 | 每条需求有明确结论档位，异议已记录，待办有责任人与期限 |
| 确认有效性 | 确认人已核对关闭条件并留下确认记录，口头同意不计入 |
| 跟踪闭环 | 带条件通过的待办在期限内关闭，逾期未关闭的需求回到评审 |
两类情况应视为阻断项：依据关键缺失仍强行判定通过；结论或待办没有责任人。出现任一情况，本次评审不计为完成，需补充后重新确认。把这份清单固化为每次评审的收尾动作，依据准备、会上核对与确认关闭就能形成稳定、可追溯的闭环。
常见问题
需求评审时依据不全，应该延期还是先评审？
取决于缺失的是哪一类依据。验收口径或核心上下游依赖这类关键依据缺失时，评审无法判断需求能否交付，建议延期评审，先补齐再排期。业务数据、历史记录等支撑材料部分缺失时，可以上会，但要在结论中写明补齐内容、责任人与期限，按“有条件通过”处理，到期未补齐则回到评审。两种做法都需要在记录中体现，避免会上口头带过。
“有条件通过”的待办到期没关闭，怎么处理？
按事先约定的规则回到评审，而不是默认放行。需求负责人在期限到期时核对待办状态，未关闭的将需求重新列入评审清单，并在记录中注明逾期原因。如果待办反复逾期，说明补齐责任分配或期限设定不合理，需要在评审规则层面调整，例如把关键依赖的确认提前到评审前完成。
评审会上出现分歧，结论怎么定？
先判断分歧属于哪一类：对需求描述与支撑材料一致性的分歧，以可查的材料为准；对约束与依赖是否成立的分歧，由对应领域负责人给出判断；对验收口径的分歧，通常说明口径本身不够具体，应退回补充后再确认。分歧未被采纳也应记录提出人与理由，它保留了当时的判断依据，对后续复盘和需求变更追溯有价值。
需求评审和方案原型评审的依据有什么不同？
需求评审的依据围绕“这个需求该不该做、做到什么程度算完成”，核心是需求描述、约束与依赖、支撑材料和评审规则。方案原型评审关注“怎么做”，依据更多是设计方案、原型说明与技术可行性分析。两者可以在同一条需求上衔接：需求评审通过后进入方案环节，需求评审中确认的验收口径和约束条件应作为方案评审的输入，避免方案偏离已确认的范围。
小团队需求少，也需要按四类依据准备吗？
四类依据回答的是评审必须澄清的问题，团队规模小可以简化材料形式，但问题本身不宜跳过。例如来源与目标可以写在需求条目的一段说明里，约束与依赖用几行清单列明，支撑材料引用已有的数据或聊天记录，评审规则简化为“谁参与、怎么判、记在哪”。需求少时更容易做到逐条挂齐，反而适合先把这套习惯固定下来，等需求量上升再补充模板和工具支撑。
