需求验收清单用来判断单项需求是否达到可交付、可验收的状态。它按准备、评审、验收、闭环四个时点组织，每项给出可核验的通过标准、所需证据和负责人，并标出未满足即阻断验收的条目。使用前先确认需求范围与验收口径一致，再逐项核对证据，最后记录结论与遗留项。本文只讨论单项需求的验收判断，产品整体效果验证与项目整体验收不在范围内。
要点总览（TL;DR）
- 需求验收清单按准备、提测评审、验收、闭环四个时点组织，每个时点由不同角色核对不同重点。
- 准备阶段确认需求目标、范围、验收口径、依赖与责任人，任一项缺失即阻断进入开发。
- 提测与评审阶段核对需求条目与实现逐条对应、测试用例覆盖验收口径、变更与评审意见有记录。
- 验收环节以证据判断功能行为、异常边界与遗留问题处理，文档说明可限期补齐。
- 验收口径缺失、关键功能不符、遗留问题无责任人或条目存在无法解释的遗漏，均阻断验收通过。
谁在什么时点使用这份验收清单
这份清单由需求提出方、产品负责人、开发负责人和测试负责人共同使用，但各角色介入的深度不同。需求提出方关注目标与验收口径是否被准确表达，产品负责人对需求范围和优先级负责，开发负责人确认实现与依赖条件，测试负责人核对验收口径是否可测、证据是否完整。清单在四个时点被调用，每个时点的核对重点不同。
| 使用时点 | 主要使用角色 | 核对重点 | 产出 |
|---|---|---|---|
| 需求进入开发前 | 需求提出方、产品负责人 | 需求描述、验收口径、依赖与责任人是否齐备 | 准备阶段核对结论 |
| 提测前 | 开发负责人、测试负责人 | 实现内容与需求条目是否逐条对应，测试用例是否覆盖验收口径 | 提测核对记录 |
| 验收评审时 | 需求提出方、产品负责人、测试负责人 | 功能行为、异常处理、文档与遗留问题是否满足通过标准 | 验收结论 |
| 闭环归档时 | 产品负责人 | 证据是否齐全、遗留项是否有人跟进、结论是否归档 | 归档记录 |
开始逐项核对的前置条件是：需求范围已确认，验收口径已写明且各方理解一致，各环节责任人已指定。这三项中任何一项缺失，清单核对就失去判断基础，应先补齐再进入检查。
需求进入开发前的准备检查项
准备阶段的目标是确认需求本身可验收。需求描述含糊、验收口径无法判断的需求，进入开发后往往在验收环节反复返工，因此这一阶段的检查要从严。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 需求目标 | 用一段话说明该需求解决什么问题、服务哪类用户或场景，读者无需额外解释即可理解 | 需求文档中的目标描述 | 需求提出方 | 是 |
| 需求范围 | 逐条列出本次要做的事项，并单独列出明确不做的部分 | 需求文档的范围清单 | 产品负责人 | 是 |
| 验收口径 | 每条验收口径都能用可观察的行为或结果判断，避免“体验良好”“响应较快”这类无法判定的表述 | 验收标准条目 | 产品负责人、测试负责人 | 是 |
| 依赖与前置条件 | 列出依赖的系统、接口、数据或其他需求，并注明当前是否已具备 | 依赖清单及状态说明 | 开发负责人 | 是 |
| 责任人与参与方 | 需求提出方、产品、开发、测试各有一名明确负责人，验收参与方名单已确定 | 需求文档中的责任人字段 | 产品负责人 | 是 |
准备阶段全部阻断项通过后，需求才进入开发。若某项暂时无法满足，应记录原因和补齐时间，并明确该需求在补齐前不进入开发排期。
提测与评审阶段的检查项
提测与评审阶段核对的是实现与需求的一致性。这一阶段形成的记录是验收时判断“做的是不是要的东西”的主要依据，因此检查要落到条目级别，而不是整体印象。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 需求条目对应 | 需求范围中的每条事项都能在实现说明或提测单中找到对应条目，无遗漏、无超出范围的额外改动 | 需求条目与实现内容的对照表 | 开发负责人 | 是 |
| 测试用例覆盖 | 每条验收口径至少对应一个测试用例，异常与边界情况有用例覆盖 | 测试用例清单及与验收口径的映射 | 测试负责人 | 是 |
| 变更记录 | 开发期间的范围、口径或方案变更均有记录，注明变更原因、影响范围和同步对象 | 变更记录及通知记录 | 产品负责人 | 是 |
| 评审意见处理 | 评审中提出的每条意见都有处理结论：已修改、已说明不修改理由或转为遗留项并指定责任人 | 评审记录及意见处理状态 | 产品负责人 | 是 |
变更记录这一项容易被忽略。开发过程中调整了交互细节或接口字段却没有同步给测试和需求提出方，验收时就会出现“按旧口径判断新实现”的争议。把变更记录列为阻断项，是为了保证验收时各方依据的是同一版口径。
验收环节的逐项通过标准
验收环节的每项标准都要能直接判断通过或不通过。判断依据是证据，不是参会者的主观评价。以下四项构成单项需求的验收通过标准。
| 验收项 | 通过标准 | 所需证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 功能行为 | 按验收口径逐条演示或核验，每条结果与口径描述一致；口径中未覆盖的行为不作为本次验收判断依据 | 验收演示记录或核验结果 | 测试负责人、需求提出方 | 是 |
| 异常与边界 | 验收口径中列明的异常与边界情况均有明确处理结果，处理方式与需求描述一致 | 异常场景测试记录 | 测试负责人 | 是 |
| 文档与操作说明 | 面向使用者的操作说明或变更说明已提供，内容与当前实现一致 | 文档链接或附件 | 产品负责人 | 否 |
| 遗留问题 | 每个遗留问题都有描述、影响判断、责任人和计划处理时间 | 遗留问题清单 | 产品负责人 | 是 |
文档与操作说明列为非阻断项，是因为它通常可以在验收结论给出后短期内补齐，但必须设定补齐期限并纳入闭环跟踪。功能行为、异常处理与遗留问题三项直接关系需求是否可用，未满足即不能通过验收。
证据留存与负责人分工
验收结论能否被追溯，取决于每类检查项是否有对应证据、证据由谁提供和确认。建议在需求启动时就确定证据清单，而不是验收时才临时收集。
| 证据类型 | 提供人 | 核对人 | 确认人 | 存放位置与命名 |
|---|---|---|---|---|
| 需求文档（含范围与验收口径） | 产品负责人 | 需求提出方 | 产品负责人 | 需求工作项附件，命名“需求编号-需求文档-版本号” |
| 测试记录与用例映射 | 测试负责人 | 开发负责人 | 测试负责人 | 测试计划或测试报告，命名“需求编号-测试记录-日期” |
| 评审记录与意见处理 | 产品负责人 | 评审参与方 | 产品负责人 | 评审工作项或文档页，命名“需求编号-评审记录-日期” |
| 验收结论与遗留项清单 | 产品负责人 | 需求提出方 | 需求提出方与产品负责人 | 需求工作项下的验收记录，命名“需求编号-验收结论-日期” |
证据命名统一带需求编号，是为了在多个需求并行时能快速定位和比对。提供人与核对人分开设置，可以避免同一人既产出又判定。验收结论由需求提出方与产品负责人共同确认，体现“需求方认可交付结果”这一层含义。
在工具层面，ONES 通过统一的需求池、工单与任务看板同步状态与信息，并构建需求—任务—测试—缺陷的全流程闭环，配套用例库、测试计划、缺陷管理与报告生成等功能。对于需要把验收结论、评审记录与测试证据挂在同一需求下的团队，这类结构可以让证据随需求工作项一起留存，减少在多个系统间来回查找的成本。具体字段与流程配置需结合团队实际使用方式确定。
阻断项与验收完成条件
阻断项指未满足即不能通过验收的条目。把它们单独列出，是为了在验收会上快速判断需求处于“通过”“有条件通过”还是“不通过”哪种状态，避免用笼统的“基本可以”代替结论。
以下情形构成阻断，任一项存在即不能判定验收通过：
- 验收口径缺失，或口径中存在无法判断的表述，导致功能行为无法逐条核验；
- 关键功能行为与验收口径不一致，且未通过变更记录正式调整口径；
- 验收口径列明的异常或边界情况没有明确处理结果；
- 遗留问题没有责任人或没有计划处理时间；
- 需求条目与实现内容存在无法解释的遗漏或超出范围的改动。
非阻断项按以下方式处理：文档与操作说明缺失的，设定补齐期限并指定责任人，在期限内补齐后由产品负责人确认；表述层面的小问题记录为遗留项，不影响本次验收结论，但纳入闭环跟踪。非阻断项不能累积成“先通过再说”的惯例，同一需求出现多项非阻断项时，应在验收结论中逐条列明。
验收完成的判定条件是：全部阻断项通过，非阻断项已有明确处理安排，验收结论已由需求提出方与产品负责人确认，证据已按命名规则归档到对应需求下，遗留项已进入跟踪列表并指定责任人。四项同时满足，该单项需求才算完成验收闭环。归档后如需变更结论，应新增记录说明原因，保留原有结论以便追溯。
常见问题
需求验收清单和项目验收清单有什么区别？
需求验收清单判断的是单项需求是否达到可交付、可验收的状态，核对对象是这条需求的目标、范围、验收口径、实现对应关系和遗留问题。项目验收清单面对的是项目整体目标、里程碑和交付物，涉及多个需求的汇总判断。两者可以共用同一套证据，但结论分开记录：单项需求先完成验收闭环，项目层面再依据各需求的验收结论做整体判断。
需求开发过程中验收口径变了，清单怎么处理？
口径变更本身不阻断验收，缺少变更记录才阻断。变更发生时，应在变更记录中写明变更原因、影响范围和已同步的对象，并同步更新需求文档中的验收口径与对应测试用例。验收时以最新一版口径为准，旧口径下的实现结果不再作为判断依据。如果变更影响到已完成的部分，需要重新核验受影响的条目，而不是只在验收会上口头说明。
遗留问题较多时，这项需求还能通过验收吗？
可以，前提是每个遗留问题都有描述、影响判断、责任人和计划处理时间。遗留问题清单齐全时，验收结论可以记为有条件通过，遗留项进入跟踪列表按计划处理。如果遗留问题涉及验收口径中的关键功能或异常处理，则属于阻断项，应先处理再判定通过。把遗留问题数量当作唯一判断标准容易失真，关键看问题是否影响需求可用性和是否有人跟进。
验收证据应该保存在哪里，需要保存多久？
证据应挂在对应需求下，与需求工作项一起留存，命名统一带需求编号和日期，便于多个需求并行时定位比对。常见做法是把需求文档、测试记录、评审记录和验收结论分别归档，由提供人与核对人分开确认。保存期限取决于团队的合规要求和项目周期，涉及对外交付或行业审计的场景通常需要按审计周期保留。具体规则建议在需求启动时随证据清单一起确定。
小需求也要走完整的四阶段清单吗？
四阶段的结构可以保留，核对深度按需求复杂度调整。小需求可以合并准备与提测的核对记录，验收时只核验与口径直接相关的条目，但验收口径、责任人、遗留问题处理这三类阻断项不宜省略。省略这些内容省下的时间，往往会在验收争议和返工时补回来。团队可以在清单模板中为不同规模的需求预设不同的必填项，同时保持阻断项的判定标准一致。
