需求验收针对单项需求，判断交付结果是否满足已确认的验收条件。具体做法是：需求进入开发前把验收条件写成可判定的条目，明确验收人、验收方式和证据形式；开发完成后由需求提出方与验收人逐项核对，记录通过、有条件通过或不通过及对应证据；不通过项转为缺陷或变更，回到处理流程，直到全部条目有结论并归档。本文聚焦单项需求的验收动作与闭环判定，不涉及产品整体效果评估或项目整体验收。
要点总览（TL;DR）
- 需求验收的起点在需求评审阶段：验收条件与需求描述分开写，每条包含判定对象、预期结果、判定方式和证据形式，随需求一起冻结。
- 验收执行按提交验收、逐项核对、给出结论、不通过项回流、复验归档五步推进，每步都有明确输入、输出和完成标志。
- 结论分通过、有条件通过、不通过三类，有条件通过同样要记录遗留项、处置责任人和期限。
- 不通过项转为缺陷或变更单回到处理流程，复验结论回填原验收记录，形成验收—回流—复验的完整链条。
- 闭环判定看三点：全部验收条件有结论、不通过项已关闭或有明确处置、验收记录与需求版本缺陷可相互追溯。
先定验收条件：把需求写成可判定的条目
需求验收的起点在需求评审阶段，而非开发完成之后。验收条件与需求描述同时评审、同时冻结，后续开发以冻结版本为准。把条件留到验收前才讨论，容易出现“做完了才发现标准不一致”的返工，验收人也会失去逐项核对的依据。
每条验收条件应包含四个字段：判定对象（看哪个页面、接口、报表或数据）、预期结果（应出现什么）、判定方式（人工观察、脚本比对、抽样统计等）、证据形式（截图、日志、测试报告、数据导出）。四个字段齐全，条件才具备可判定性。验收条件与需求描述分开写，需求描述说明“要解决什么问题”，验收条件说明“怎样算解决”。像“实现登录功能”这类表述无法判定，应改写为可观察的结果。
| 类型 | 判定对象 | 预期结果示例 | 判定方式 | 证据形式 |
|---|---|---|---|---|
| 功能结果 | 登录页提交按钮 | 输入正确账号密码后进入首页，错误密码提示“账号或密码错误” | 人工按用例操作 | 操作截图与测试记录 |
| 数据结果 | 登录日志表 | 每次登录尝试写入一条记录，含时间、账号、结果 | 查询数据库比对 | 数据导出文件 |
| 非功能约束 | 登录接口响应 | 在约定并发下，95%请求响应时间不超过约定阈值 | 压测工具统计 | 压测报告 |
写法对照可以帮助团队统一口径：“页面要好看”改为“首页在约定分辨率下无横向滚动条，主要按钮位置与设计稿一致”；“系统要稳定”改为“连续运行约定时长无异常退出，错误日志中无未处理异常”。条件数量按需求复杂度控制，每条都能被独立核对即可。
验收执行步骤：从提交验收到给出结论
验收执行按固定顺序推进，每个动作都有明确的输入、输出和完成标志。下表给出单项需求的验收步骤表，团队可直接套用。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交验收 | 可运行版本、冻结的验收条件、测试或自检记录 | 开发负责人确认版本可部署，整理自检记录，向验收人发起验收 | 验收申请与版本说明 | 验收人收到完整材料并确认可开始 |
| 2. 逐项核对 | 验收条件清单、可运行环境 | 验收人按条目逐项操作或查看数据，记录实际结果并留存证据 | 逐条核对记录 | 每条条件都有实际结果与证据 |
| 3. 给出结论 | 逐条核对记录 | 对照预期结果判定通过、有条件通过或不通过，写明理由 | 验收结论 | 结论覆盖全部条目并有签字确认 |
| 4. 不通过项回流 | 不通过条目及证据 | 转为缺陷或变更单，指定处理人，回到开发与测试流程 | 缺陷单或变更单 | 每项不通过都有对应单据和责任人 |
| 5. 复验与归档 | 修复后的版本、原验收记录 | 对回流项复验，更新结论，归档完整验收记录 | 归档的验收记录 | 全部条目有最终结论，记录可追溯 |
结论分三类，判定口径要事先约定。通过指全部条目符合预期；有条件通过指主体功能满足，遗留问题不影响核心使用且有明确处置计划与期限；不通过指存在影响验收条件的实质问题。有条件通过同样要记录遗留项，不能以“先上线再说”替代记录。
不通过项转为缺陷或变更单后，回到处理流程。缺陷修复后由原验收人对相关条目复验，复验结论回填到原验收记录，形成“验收—回流—复验”的完整链条。全部条目有结论后归档，归档内容包括验收条件、核对记录、证据、结论与签字。
角色与交付物：谁提、谁验、谁签字
验收责任分散在多个角色，单一角色既提需求又独自判定，容易失去制衡。需求提出方确认验收条件与最终结论，验收人负责逐项核对并留证，开发负责人保证提交的版本可验收，质量或测试角色提供验证证据。下表把职责与交付物对应起来。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求提出方 | 参与验收条件编写与冻结，确认最终结论 | 签字确认的验收条件与验收结论 |
| 验收人（业务或产品侧） | 按条目逐项核对，记录实际结果与证据，给出判定 | 逐条核对记录、验收结论及理由 |
| 开发负责人 | 提交可运行版本与自检记录，处理不通过项 | 版本说明、自检记录、缺陷修复记录 |
| 质量或测试角色 | 提供测试用例执行结果、缺陷记录与验证证据 | 测试报告、缺陷单、复验记录 |
角色可以由同一人兼任，但职责要分开记录。小团队里产品经理既提需求又验收时，至少让测试角色出具独立验证证据，避免自证自验。签字环节不必追求形式，关键是结论有明确的责任人，后续追溯时能找到判定依据。
验收条件、核对记录与不通过项需要在需求上留痕，并与缺陷单关联。ONES 通过统一的需求池、工单与任务看板同步状态与信息，支持追溯需求与问题，并配套用例库、测试计划、缺陷管理与报告生成等功能，构建需求—任务—测试—缺陷的全流程闭环。团队可以把验收条件挂在需求工作项上，把不通过项转为缺陷单，复验结论回填后归档，使验收记录与需求、版本、缺陷保持关联。
一个示例：登录需求如何走完验收
以下为演示情景，用于说明验收条件编写、逐项核对、结论记录与不通过项处理的全过程，数据为示例值。
需求为“账号密码登录”。验收条件在评审阶段冻结为四条：
- 功能结果：输入正确账号密码，点击登录后进入首页，页面显示当前账号名。判定方式为人工操作，证据为操作截图。
- 功能结果：输入错误密码，提示“账号或密码错误”，停留在登录页。判定方式为人工操作，证据为操作截图。
- 数据结果：每次登录尝试在登录日志表写入一条记录，含时间、账号、结果。判定方式为查询数据库，证据为数据导出文件。
- 非功能约束：登录接口在约定并发下，95%请求响应时间不超过约定阈值。判定方式为压测统计，证据为压测报告。
逐项核对记录如下：条目1通过，截图显示进入首页且账号名正确；条目2通过，截图显示错误提示；条目3有条件通过，日志记录完整，但失败尝试的结果字段为空，约定三个工作日内修复并复验；条目4不通过，压测报告显示响应时间超出约定阈值，转为缺陷单，指定开发负责人处理。
验收结论记录为“有条件通过”：条目1、2通过，条目3遗留字段问题，条目4转缺陷。缺陷修复后，验收人对条目3复验，确认结果字段已写入；对条目4复验，压测报告达到约定阈值。两条目结论更新为通过，验收记录归档，需求闭环。
闭环与完成检查：确认需求真的验收完了
闭环判定有三个条件：全部验收条件都有结论；不通过项已关闭或有明确处置，包括责任人、处置方式和期限；验收记录与需求、版本、缺陷可关联追溯。三者缺一，需求只能算“验过”，不能算“验完”。
验收记录与需求的关联方式，是在需求工作项上保留冻结的验收条件与最终结论；与版本的关联，是记录验收所针对的版本号或构建号；与缺陷的关联，是每个不通过项对应缺陷单编号，复验结论回填到原记录。关联完整，后续排查问题时才能从需求追到版本、从版本追到缺陷。
常见缺口有三类：条件缺失，验收时才发现部分需求没有可判定标准；证据不全，结论写了通过但找不到截图、日志或报告；结论无签字，记录存在但没有明确责任人确认。三类缺口都会让验收在追溯时失去效力。
完成检查清单如下，逐项核对后即可确认需求验收完毕：
- 验收条件已在需求评审阶段冻结，每条含判定对象、预期结果、判定方式、证据形式
- 验收条件与需求描述分开编写，无“实现某功能”类无法判定的表述
- 提交验收时附有可运行版本、验收条件与测试或自检记录
- 每条验收条件都有实际结果记录与对应证据
- 验收结论为通过、有条件通过或不通过，并写明理由
- 不通过项均有对应缺陷单或变更单，指定了责任人与处置期限
- 回流项已完成复验，复验结论回填到原验收记录
- 验收记录与需求、版本、缺陷编号可相互追溯
- 验收结论有需求提出方或验收人签字确认
- 验收记录已归档，归档内容完整可查
按这套动作执行，单项需求的验收从条件定义到记录归档形成完整链条，验收结论有据可查，不通过项有明确去向，需求闭环的判定也有统一口径。
常见问题
验收条件在开发中途发生变更，原来的验收记录怎么处理？
验收条件变更应走变更流程，而不是在验收时口头调整。做法是：变更单记录变更前后的条件条目、变更原因和影响范围，由需求提出方与验收人确认后，重新冻结验收条件版本；已经按旧条件核对过的条目，在验收记录中标注对应的条件版本，避免新旧口径混在一起。
如果变更发生在验收执行过程中，先暂停受影响条目的核对，等新条件冻结后再继续，其余不受影响的条目可以照常推进。归档时保留变更单与各版本验收条件，后续追溯才能看清每条结论依据的是哪一版标准。
有条件通过的需求，遗留项一直没处理完，还能算闭环吗？
不能算闭环。有条件通过的前提是遗留项有明确处置计划，包括责任人、处置方式和期限；期限到了仍未处理，需求应回到未闭环状态，由验收人跟踪推进。
实际操作中建议把遗留项逐条转为缺陷单或变更单，指定责任人和截止时间，并在需求上保留关联。这样遗留项不会停留在验收记录的备注里被遗忘，闭环判定时也能直接查看每项是否关闭。若遗留项确实需要延后，应重新确认处置计划并更新记录，而不是默认视为已完成。
小团队没有专职测试，验收证据由谁出？
角色可以兼任，职责要分开记录。没有专职测试时，可以由开发负责人提交自检记录和操作截图作为初步证据，再由需求提出方或业务侧验收人独立操作核对，形成第二份证据。关键是核对动作与开发动作由不同的人完成，避免同一人既提交又判定。
证据形式按验收条件确定：功能结果用操作截图或录屏，数据结果用查询导出文件，非功能约束用工具统计报告。证据不必复杂，能支撑结论、可被他人复核即可。
验收记录需要保存哪些内容，保存多久？
一份完整的验收记录至少包含：冻结的验收条件（含版本）、逐条核对的实际结果与证据、验收结论及理由、不通过项对应的缺陷或变更单编号、复验结论、签字确认人。这些内容与需求、版本、缺陷保持关联，后续排查问题时可从任一方向追溯。
保存期限按团队所在行业与内部制度确定，涉及合规或审计要求的场景通常需要覆盖产品生命周期。没有统一规定时，建议至少保留到该需求所属版本停止维护之后，避免追溯时记录已缺失。
需求验收和项目验收、产品效果评估的边界怎么划？
需求验收只判断单项需求是否满足已确认的验收条件，结论落在这一条需求上。项目验收关注项目整体目标、范围、进度与交付物是否达成，产品效果评估关注上线后的使用数据与业务价值，两者都不属于本文的验收动作。
边界清晰的好处是责任不混：需求验收由需求提出方与验收人负责，项目验收由项目负责人组织，效果评估通常在产品上线运行一段时间后开展。同一条需求可以同时出现在这三类活动中，但各自的判定标准和记录分开保存。
