需求验收要回答的是一个具体问题：这一项需求交付后，是否满足开发前已经确认的验收条件。本文按“先定条件与分工、再执行核对、留下验收记录、处理偏差并关闭需求、最后用清单自查”的顺序展开，给出可直接套用的条件表、步骤清单和记录字段。产品整体效果验证与项目整体验收不在本文范围内。
要点总览（TL;DR）
- 需求验收的判断依据是开发前确认的验收条件，每条条件要写清可观察结果、边界与例外、判定方式，避免验收时临时补标准。
- 验收执行按发起与材料准备、逐条核对、偏差回流、复验关闭四步推进，每条条件单独给结论，不凭整体印象判断。
- 验收记录要与条件编号逐条对应，结论区分通过、有条件通过、不通过，并写明确认人与日期，便于未参与验收的人追溯。
- 不通过项先判断转缺陷还是走需求变更，约定责任人与复验时点；全部条件通过并留齐证据后，需求才可关闭。
- 验收完成检查清单重点核对条件前置、逐条对应、偏差责任与复验时点、关闭证据，以及与产品整体验证、项目验收的边界。
需求验收先定什么：验收条件与责任分工
验收能否顺利，主要取决于开发前是否把“凭什么判断通过”写清楚。验收条件在需求评审通过、进入开发之前确认，由需求提出方与交付方共同认可，之后作为唯一判定依据。验收时临时补充标准，容易把确认动作变成协商动作。
验收条件怎么写
一条合格的验收条件应当让不同的人读完后得出相同结论。建议每条条件包含三个要素：
- 可观察结果：描述用户或系统可以看到、可以操作到的状态，例如“提交订单后，订单列表在3秒内出现该订单，状态为待支付”。避免“体验流畅”“响应及时”这类无法判定的表述。
- 边界与例外：写明适用范围和不适用情形，例如“仅覆盖已登录用户；未登录访问跳转登录页，不在此条验收范围”。边界写清楚，验收时就不会为范围争执。
- 判定方式：说明用什么手段确认，例如演示操作、界面走查、核对测试用例执行结果、检查接口返回或文档内容。
验收方式怎么选
验收方式与条件类型匹配即可，不必所有需求都走同一套流程。
| 验收方式 | 适用条件 | 需要准备的材料 |
|---|---|---|
| 演示 | 结果可通过操作界面直接观察 | 可运行环境、演示脚本、测试数据 |
| 走查 | 涉及页面布局、文案、交互流程 | 设计稿、走查清单、对照页面 |
| 测试结果核对 | 结果体现在功能正确性、性能或异常处理上 | 测试用例、执行记录、缺陷列表 |
| 文档确认 | 交付物为说明文档、规则配置或接口约定 | 文档版本、变更说明 |
角色分工
三个角色各司其职，避免验收变成“谁有空谁看”。
- 需求提出方：说明业务场景，参与编写验收条件，负责判断结果是否满足使用需要。
- 交付方：在开发前确认条件可实现，交付时准备验收材料，对不通过项给出处理方案。
- 验收确认人：通常由提出方指定，对每条条件给出通过或不通过的结论并签字确认；条件较多时可指定一名主确认人汇总。
验收时点与状态约定
需求状态建议至少区分：待开发、开发中、待验收、验收中、已关闭。约定“交付方提交验收材料后状态转为待验收”“确认人给出结论后转为已关闭或退回处理”，状态变化与验收动作一一对应，后续追溯时能看清需求在哪个环节停留过。
下面这张表可以直接填写，作为单个需求的验收前置输入。
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 需求标识 | 需求编号与名称 | REQ-1023 订单列表增加状态筛选 |
| 验收条件 | 逐条编号，含结果、边界、判定方式 | AC-1 按待支付筛选后仅显示待支付订单 |
| 验收方式 | 演示/走查/测试结果核对/文档确认 | 演示 + 测试结果核对 |
| 提出方 | 姓名与角色 | 运营 张×× |
| 交付方 | 姓名与角色 | 后端 李××、前端 王×× |
| 验收确认人 | 姓名与角色 | 产品 赵×× |
| 计划验收时点 | 日期或迭代节点 | 迭代结束前2个工作日 |
单项需求验收的操作步骤
验收执行按“发起—核对—处理偏差—复验关闭”四步推进，每一步都有明确的输入、动作、输出和完成标志。
第一步：验收发起与材料准备
- 输入：已确认的验收条件表、交付说明。
- 动作：交付方提交验收申请，附上可运行环境、演示脚本、测试执行记录或文档版本；确认人确认材料齐全后约定验收时间。
- 输出：验收申请记录与材料清单。
- 完成标志：确认人确认材料足以支撑逐条核对，需求状态转为验收中。
第二步：逐条核对验收条件
- 输入：验收条件表、验收材料。
- 动作：按条件编号逐条核对，每条记录“通过/不通过”及简要依据；不凭整体印象给结论，也不合并多条条件一次性判断。
- 输出：逐条核对记录。
- 完成标志：所有条件均有结论，没有空白项。
第三步：不通过项的偏差描述与回流
- 输入：不通过的条件条目。
- 动作：写清偏差现象、复现步骤、与条件的差距，判断属于实现缺陷还是条件本身需要调整。实现缺陷转入缺陷流程修复；条件需要调整的走需求变更，变更后的条件重新确认。
- 输出：偏差记录及对应的缺陷单或变更单。
- 完成标志：每个不通过项都有责任人和处理路径，没有悬空条目。
第四步：复验安排与关闭
- 输入：偏差处理结果。
- 动作：按约定时点对不通过项复验，复验只针对原不通过条目及其影响范围；全部条件通过后，确认人给出结论并关闭需求。
- 输出：复验记录、最终验收结论。
- 完成标志：需求状态转为已关闭，验收记录归档。
在实际协作中，验收条件、核对记录与需求状态往往分散在文档、表格和沟通记录里，追溯时需要来回翻找。ONES 通过统一的需求池、工单与任务看板同步状态与信息，需求—任务—测试—缺陷形成连贯链路，验收条件与核对结论可以随需求一起留存；配套的用例库、测试计划与缺陷管理也能承接“测试结果核对”和“不通过项转缺陷”这两类动作。具体字段与状态配置以团队实际搭建为准。
验收记录怎么写：字段与示例
验收记录的作用是让没参与验收的人也能判断这次验收是否可信。字段不必多，但要能支撑追溯。
| 字段 | 含义 | 填写要求 |
|---|---|---|
| 需求标识 | 对应需求编号与名称 | 与需求池中的编号一致 |
| 验收条件 | 逐条列出的条件编号与内容 | 与开发前确认版本一致，变更需注明 |
| 核对结果 | 每条条件的通过或不通过 | 逐条对应，不合并 |
| 偏差 | 不通过项的现象与差距 | 写清复现方式与影响范围 |
| 结论 | 通过、有条件通过或不通过 | 与核对结果一致 |
| 确认人 | 给出结论的人 | 姓名与角色 |
| 日期 | 结论形成日期 | 复验时另记复验日期 |
一条需求的填写示例
以下为演示情景，用于说明填写方式。
| 字段 | 内容 |
|---|---|
| 需求标识 | REQ-1023 订单列表增加状态筛选 |
| 验收条件 | AC-1 选择“待支付”后列表仅显示待支付订单；AC-2 筛选条件切换后列表在2秒内刷新；AC-3 无匹配结果时显示空状态提示 |
| 核对结果 | AC-1 通过；AC-2 通过；AC-3 不通过，无匹配结果时页面空白，无提示 |
| 偏差 | AC-3 未实现空状态提示，已转缺陷 BUG-2087，责任人前端王×× |
| 结论 | 有条件通过：AC-3 修复并复验通过后关闭 |
| 确认人 | 产品 赵×× |
| 日期 | 2025-03-12（复验日期 2025-03-14） |
三种结论的写法差异
- 通过：全部条件核对通过，记录中不出现未处理偏差，可直接关闭需求。
- 有条件通过：主体功能满足使用需要，存在少量不影响主流程的偏差，需写明偏差条目、责任人和复验时点，复验通过后关闭。
- 不通过：存在影响主流程或核心条件的偏差，需求退回处理，记录中列明全部不通过条目及回流路径，不设关闭日期。
结论用词要与核对结果严格对应，避免出现“基本通过”“大致没问题”这类无法追溯的表述。
验收之后如何闭环：偏差处理与需求关闭
验收记录写完并不等于流程结束，结论要驱动后续动作，需求才算真正闭环。
不通过项转缺陷还是走变更
判断依据是“原条件是否仍然成立”。交付结果与已确认条件不一致、条件本身无需调整的，转缺陷修复；验收中发现原条件遗漏了必要场景、或业务规则发生变化导致条件不再适用的，走需求变更，变更后的条件重新确认后再验收。两类处理不要混在同一张单里，否则复验时无法判断依据哪版条件。
复验触发条件与责任归属
复验由偏差处理完成触发，责任人为原验收确认人。复验范围限定在原不通过条目及其直接影响的功能，不重复全量验收；若修复改动波及相邻功能，将受影响条目一并纳入复验并在记录中注明。复验时点应在偏差记录中约定，逾期未复验的条目在例行评审中提出。
需求关闭所需证据
- 开发前确认的验收条件版本；
- 逐条核对记录，全部条目有结论；
- 不通过项的缺陷单或变更单及其处理结果；
- 复验记录（如有）；
- 确认人签署的最终结论与日期。
归档与追溯
验收记录随需求归档，保留条件版本与结论的对应关系。后续出现线上问题或需求复盘时，可以据此判断是条件未覆盖、实现偏差还是使用场景变化。归档位置与需求本身放在一起，比单独存放在个人目录更利于追溯。
当需求、缺陷与验收记录分处不同系统时，追溯成本会明显上升。ONES 将业务需求池、产品需求池与工单系统联动，需求、任务、测试、缺陷在同一链路中流转，验收结论与关闭状态可以随需求记录保留，业务团队也能跟踪处理进度。这类承载方式适合需求来源多、跨角色协作频繁的团队；需求量小、角色集中的团队用文档加表格同样可以执行。
验收完成检查清单
以下清单用于验收自查或评审，逐项判断“是/否”，出现“否”的项需在关闭需求前补齐。
| 序号 | 检查项 | 判定标准 |
|---|---|---|
| 1 | 验收条件是否在开发前确认 | 条件表有提出方与交付方确认记录，时间早于开发启动 |
| 2 | 条件是否可判定 | 每条含可观察结果、边界与例外、判定方式，无模糊表述 |
| 3 | 核对记录是否逐条对应 | 条件编号与核对结果一一对应，无空白、无合并 |
| 4 | 偏差是否有人负责并有复验时点 | 每个不通过项有责任人、处理路径和约定日期 |
| 5 | 结论是否与核对结果一致 | 通过、有条件通过、不通过的用词与条目状态匹配 |
| 6 | 关闭证据是否齐全 | 条件版本、核对记录、偏差处理结果、复验记录、确认人签署齐备 |
| 7 | 状态是否已更新 | 需求状态与实际验收进度一致，关闭有据可查 |
| 8 | 边界是否清晰 | 本次验收只针对单项需求条件，产品整体效果与项目整体验收已另行安排 |
清单全部为“是”时，这次需求验收可以视为完成；其中第1、3、6项是评审中最常被追问的环节，建议在验收发起阶段就对照检查，减少关闭前的返工。
常见问题
需求验收和产品整体验证、项目整体验收怎么区分？
需求验收只回答单项需求是否满足已确认的验收条件，判断对象是这一项需求的交付结果。产品整体效果验证关注上线后的使用效果与价值，项目整体验收关注项目范围、进度与交付物是否完成。三者可以共用同一批记录，但结论各自独立：一项需求验收通过，不代表产品整体效果达标；项目整体验收通过，也不替代单项需求的逐条核对。
验收条件在开发过程中发生变化，验收时按哪一版判断？
按变更后重新确认的版本判断，并在验收记录中注明条件变更的时间与原因。原条件遗漏必要场景或业务规则调整的，走需求变更流程，变更后的条件由提出方与交付方重新确认后再进入验收；条件本身无需调整、只是实现与条件不一致的，按原条件转缺陷修复。两版条件混用会让复验失去判断依据，因此记录里要保留条件版本与结论的对应关系。
有条件通过的需求，什么时候算真正关闭？
有条件通过表示主体功能满足使用需要，但仍有少量不影响主流程的偏差。这类需求在记录中写明偏差条目、责任人和复验时点，待偏差处理完成、复验通过后由原验收确认人给出最终结论，再关闭需求。复验范围限定在原不通过条目及其直接影响的功能；若修复波及相邻功能，把受影响条目一并纳入复验并注明。复验时点逾期未处理的条目，可在例行评审中提出。
需求量不大、角色集中的团队，也需要建完整的验收流程吗？
流程深度可以按协作复杂度调整，但几个关键动作建议保留：开发前确认验收条件、逐条核对并留结论、不通过项有责任人和复验时点、关闭前证据齐全。角色集中的团队用文档加表格即可执行，把条件表、核对记录和结论放在需求同一处，追溯成本并不高。需求来源多、跨角色协作频繁时，再考虑用工作项与状态流转承载，减少在文档、表格和沟通记录之间来回翻找。
验收记录归档后，后续还能用来做什么？
归档的验收记录可用于线上问题定位和需求复盘：出现问题时对照当时的条件版本与核对结论，判断是条件未覆盖、实现偏差还是使用场景变化。记录随需求一起存放，比单独放在个人目录更利于追溯。复盘时也可以回看偏差集中的条件类型，作为下一轮需求编写验收条件的参考。
