需求可评审通过，指需求在进入方案设计和开发之前，已经逐项满足一组可核对的判定口径。判定口径不是评审会上临时形成的印象，而是一组能给出“通过”或“不通过”的检查项，覆盖目标与价值、范围边界、验收标准、依赖约束、优先级与决策人、分歧收敛六个方面。本文给出这套口径清单、适用边界和执行方式，帮助评审参与者在会前自检、会中逐项判断、会后留下可追溯的结论。
要点总览（TL;DR）
- 需求可评审通过，指需求在进入方案设计与开发前，逐项满足目标与价值、范围边界、验收标准、依赖约束、优先级与决策人、分歧收敛六条可核对口径。
- 每条口径都要写明通过表现与不通过表现，评审结论逐项对应口径并留存记录，避免用整体印象代替逐项判断。
- 评审通过只针对需求本身的质量与可决策性，不覆盖方案与原型评审、阶段决策，也不等于承诺排期开发。
- 评审结论常见三种形态：通过、有条件通过、退回补充；有条件通过的条件应转为可跟踪事项，关闭后确认。
- 验收标准是需求内容的一部分，判定口径检查的是验收标准是否存在且可验证；需求变更后应重新对照口径判定。
需求可评审通过的直接判定口径
判定口径的作用，是把“这个需求能不能往下走”拆成若干条可以单独回答“是”或“否”的问题。每条口径都要有明确的通过表现和不通过表现，评审结论逐条对应，避免用整体感觉代替逐项判断。
| 判定口径 | 通过表现 | 不通过表现 |
|---|---|---|
| 目标与价值 | 能说明需求要解决的具体问题、影响的对象，以及不做的后果；价值判断有依据，如用户反馈、数据、业务规则 | 只写“优化体验”“提升效率”等笼统目标；说不清受益对象；无法回答为什么现在要做 |
| 范围与边界 | 明确本次做什么、不做什么；列出涉及的模块、角色和场景；对容易混淆的相邻需求有排除说明 | 范围随讨论不断扩张；关键场景缺失；与相邻需求的界限不清，评审中反复确认“这个算不算” |
| 验收标准 | 每条主要功能都有可验证的验收条件，包含输入、操作和预期结果；异常与边界情况有对应说明 | 只有功能描述没有验收条件；标准写成“正常使用”“符合预期”等无法判定的表述 |
| 依赖与约束 | 已识别上下游系统、数据、外部接口和合规要求；对未落实的依赖标注责任人和确认时间 | 依赖只在口头提及；关键外部条件未确认；约束条件在评审时才被发现 |
| 优先级与决策人 | 需求优先级有明确结论和判断依据；需求负责人、业务决策人、评审结论确认人清晰 | 优先级待定且无判断规则；出现分歧时不知道由谁拍板 |
| 分歧收敛 | 评审前收集的主要异议已有处理结论，或明确转为待办并指定负责人；剩余分歧不影响是否进入下一环节的判断 | 关键分歧仍停留在讨论阶段；以“会后再说”结束但没有记录责任人和时间 |
记录方式建议与口径一一对应：每条口径标注结论（通过／不通过／有条件通过）、判断依据和遗留事项。这样评审记录既是一份结论，也是一份可复核的检查底稿。需求类型不同，口径的侧重点可以调整，例如合规类需求对约束条件的核对更细，平台类需求对依赖与边界的描述要求更高，但“逐项可核对”这一形式应保持一致。
判定口径的边界：评审通过不等于什么
需求评审通过，针对的是需求本身的质量和可决策性：它回答“这个需求是否描述清楚、条件是否具备、可以进入下一环节”。它不回答“用什么方案实现”，也不回答“什么时候排期开发”。把这几件事分开，评审才不会在一个会上同时处理需求、方案和资源三类问题。
方案与原型评审属于另一环节。需求评审阶段可以提出实现上的疑问，但交互稿、技术方案、数据结构的评审有各自的参与角色和判定标准，不纳入本文的口径清单。研发阶段评审与组织阶段决策机制同样独立：立项审批、资源投入决策、里程碑评审关注的是项目层面的取舍，需求评审通过只是这些决策的输入之一。
评审通过也不等于需求一定排期开发。通过意味着需求具备了进入待排期池的条件，实际排期取决于优先级排序、资源情况和版本规划。把“评审通过”和“承诺开发”混为一谈，容易让业务方产生错误预期，也会让评审会在资源讨论上消耗过多时间。明确这一边界，评审参与者才能把注意力放在需求质量本身。
判定口径如何组成一次评审：从材料到结论
判定口径要在评审流程中真正起作用，需要经过会前自检、会中逐项核对、结论形成和记录留存四个动作。每个动作都有明确的产出物，评审不是一次讨论会，而是一次按清单核对并形成结论的过程。
评审前：材料准备与自检
需求负责人按判定口径逐条准备材料，并在提交评审前完成自检：目标与价值是否有依据、范围是否写明不做什么、验收标准是否可验证、依赖是否已确认、优先级和决策人是否明确、此前收集的异议是否已有处理意见。自检不通过的需求先补充材料，再进入评审议程，避免在会上才发现基础信息缺失。
评审中：逐项核对与分歧记录
评审主持人按口径顺序逐条核对，每条给出明确结论。出现分歧时，记录分歧内容、各方观点和待确认事项，指定跟进人。对于不影响是否进入下一环节的细节分歧，可以转为待办；对于影响需求成立与否的分歧，应当场判定为不通过或退回补充，不用“基本同意”模糊处理。
评审结论的三种形态
- 通过：六条口径均满足，需求进入待排期或方案设计环节。
- 有条件通过：主体内容成立，但存在少量必须补齐的条件，如某项依赖待确认、某条验收标准待细化。条件应逐条转为可跟踪事项，写明责任人和完成时间，条件关闭后由指定人员确认，无需重新召开完整评审。
- 退回补充：存在影响需求成立的关键缺口，如目标不清、范围无法界定、验收标准缺失。退回时注明需补充的具体内容，补充完成后重新提交评审。
记录留存与变更后的重新判定
评审记录应包含每条口径的结论、依据和遗留事项，并与需求条目关联保存。需求发生实质性变更时，例如范围扩大、验收标准调整、关键依赖变化，应重新对照判定口径判定，避免沿用旧结论。变更后的重新判定可以简化流程，只核对受影响的口径，但结论仍需记录。
在需求条目集中管理的工具中，评审结论、有条件通过事项和变更记录可以随需求一起流转。以 ONES 为例，需求可以作为工作项承载评审状态和遗留事项，评审记录与需求文档关联保存，后续变更时便于回溯此前的判定依据。具体字段和流程配置需结合团队实际的管理方式设置。
与验收标准、需求质量检查的区别
验收标准、需求质量检查和评审通过判定经常被混用，三者检查的对象和目的不同。验收标准是需求内容的一部分，描述功能完成后如何验证；需求质量检查关注需求文档的描述是否规范、完整；评审通过判定关注需求是否具备进入下一环节的条件。三者可以同时使用，但不能互相替代。
| 概念 | 检查对象 | 回答的问题 | 典型产出 |
|---|---|---|---|
| 验收标准 | 需求内容中的功能预期 | 功能完成后，用什么条件判断它做对了 | 可执行的验收条件清单 |
| 需求质量检查 | 需求文档的表述与结构 | 描述是否清楚、完整、无歧义 | 文档规范检查结果 |
| 评审通过判定 | 需求整体是否可决策、可进入下一环节 | 这个需求现在能不能往下走 | 逐项结论与评审记录 |
判定口径与验收标准的关系是：判定口径检查“验收标准是否存在且可验证”，验收标准本身则规定“怎么验证”。一份需求可能验收标准写得很细，但目标价值不清，仍然无法通过评审；也可能描述规范、格式完整，但关键依赖未确认，同样不满足通过条件。评审通过判定与优先级排序也有区别：前者判断需求是否合格，后者在合格需求之间决定先后顺序。先判定是否通过，再讨论排序，两个动作分开进行，结论才清晰。
一个判定示例与常见误解
以下示例为演示情景，用于说明逐项判定的过程。某业务方提出“在订单列表增加批量导出功能”。对照判定口径逐项核对：目标与价值方面，业务方说明客服每月需手工整理订单数据约二十小时，有工时记录支撑，通过；范围与边界方面，明确只导出当前筛选结果、不含历史归档订单，通过；验收标准方面，初稿只写“导出正常”，不通过，需补充导出字段、数据量上限和异常提示；依赖与约束方面，导出涉及的数据权限规则尚未与安全团队确认，不通过；优先级与决策人方面，优先级为高，业务决策人已明确，通过；分歧收敛方面，对导出格式的异议已转为待办并指定负责人，通过。综合结论为“有条件通过”，条件为补充验收标准和确认数据权限规则，两项条件转为跟踪事项，关闭后确认通过。
常见误解有三类。第一类是把评审会开完当作通过：会议结束但没有逐项结论，需求实际上处于未判定状态，后续出现问题时无法追溯依据。纠正做法是会议结束前形成逐项结论并记录。第二类是把口头同意当作结论：会上有人表示“没问题”，但没有对应到具体口径，也没有记录，变更时容易产生争议。纠正做法是每条结论都落到记录上，注明判断依据。第三类是把方案讨论混入需求评审：会上大量时间用于讨论实现方式，需求本身的口径反而没有核对完。纠正做法是需求评审聚焦需求质量，方案问题另行安排评审。这三类误解的共同后果是评审结论不可复核，需求在开发和验收阶段反复返工；把口径清单和记录方式固定下来，是成本较低的纠正手段。
常见问题
需求评审时，六条口径必须全部满足才能通过吗？
通常按全部满足来判定“通过”。如果主体内容成立、只有少量必须补齐的条件，可以判为“有条件通过”，把条件逐条转为可跟踪事项，写明责任人和完成时间，条件关闭后由指定人员确认。若存在影响需求成立的关键缺口，例如目标不清、范围无法界定、验收标准缺失，则应退回补充。需求类型不同，口径的侧重点可以调整，但逐项核对的形式应保持一致。
评审会上对某条口径意见不一致，应该怎么处理？
先判断分歧是否影响需求成立。不影响进入下一环节的细节分歧，可以转为待办并指定跟进人；影响需求成立与否的分歧，当场判定为不通过或退回补充，不用“基本同意”模糊处理。分歧内容、各方观点和待确认事项都应写入评审记录，便于后续复核。
需求通过评审后发生变更，原来的结论还能沿用吗？
需求发生实质性变更时，例如范围扩大、验收标准调整、关键依赖变化，应重新对照判定口径判定，避免沿用旧结论。重新判定可以简化流程，只核对受影响的口径，但结论仍需记录，并与需求条目关联保存。
需求评审通过，是否意味着这个需求一定会排期开发？
不等于。评审通过说明需求具备了进入待排期池的条件，实际排期取决于优先级排序、资源情况和版本规划。把评审通过和承诺开发分开，可以减少评审会上围绕资源的讨论，也让业务方对后续节奏有合理预期。
需求质量检查和评审通过判定可以合并成一次吗？
两者检查对象不同，可以先后衔接，但不宜互相替代。需求质量检查关注文档表述是否清楚、完整、无歧义；评审通过判定关注需求整体是否可决策、可进入下一环节。实践中可以先做质量检查，把描述问题在会前修掉，评审会上集中核对判定口径，减少会上处理格式和表述问题的时间。
