需求验收清单要能回答一个具体问题：这一条需求是否按约定完成、可以验收。清单至少应包含需求标识与版本、验收对象与范围、验收依据、逐项检查项与通过标准、证据材料、责任人与检查时点、结论与遗留问题、阻断项及解除条件。它服务于单项需求的判定，不承担产品整体效果评估或项目整体收尾的职责。
要点总览（TL;DR）
- 需求验收清单围绕单项需求是否满足来组织，至少包含需求标识与版本、验收依据、逐项检查项与通过标准、证据材料、责任人与检查时点、结论与遗留问题、阻断项及解除条件。
- 清单由需求提出方、开发、测试和产品负责人在提测前自检、验收评审、上线前确认三个时点分别填写或签署，每个字段都要有明确的填写者和确认者。
- 通过标准要写到换人复核也能得出相同结论，例如把“界面显示正常”改成可观察的具体现象，把“性能达标”改成约定数据量与响应时间下的结果。
- 证据与检查项逐条对应，检查人和复核人分开担任；证据缺失的检查项按不通过处理，补充材料后重新确认。
- 验收标准缺失、关键检查项不通过、遗留问题未登记、变更未回归、证据缺失且无法补充属于典型阻断项；全部必填项有结论、证据齐全、双方签署后清单才算完成。
谁在什么时点使用这份清单
这份清单贯穿需求交付的后半段，由不同角色在三个时点分别填写或确认。需求提出方负责确认验收依据和最终结论，开发负责准备阶段的自检和证据提交，测试负责功能与异常场景的核对记录，产品负责人负责验收评审的组织和阻断项的裁定。角色分工不必固定为某个人，但每个字段都要有明确的填写者和确认者。
使用时点可以按以下方式划分：
| 角色 | 提测前自检 | 验收评审 | 上线前确认 |
|---|---|---|---|
| 需求提出方 | 确认验收标准已写入清单 | 逐项核对检查结果，给出通过或不通过结论 | 确认遗留问题已登记并接受处理方式 |
| 开发 | 填写需求标识、版本、变更记录，提交自检证据 | 对不通过项说明原因和修复计划 | 确认变更已回归 |
| 测试 | 确认检查项可测、预期结果明确 | 填写实际结果与测试记录 | 补充回归测试证据 |
| 产品负责人 | 确认验收范围与需求条目一致 | 主持评审，签署结论 | 确认阻断项已解除或明确放行条件 |
需要划清的边界是：清单只判断单项需求是否满足其验收标准。产品上线后的用户反馈、业务指标变化属于产品效果评估；项目范围、进度、成本的收口属于项目整体验收与收尾管理。这两类工作可以引用本清单的结论，但不以本清单作为判定依据。
清单必备信息：字段与填写要求
清单的表头设计决定了它能否被逐项核对。建议按下表设置字段，必填项缺失时清单不能进入评审环节。
| 字段 | 填写要求 | 是否必填 |
|---|---|---|
| 需求编号 | 与需求管理系统中的编号一致，便于回溯 | 必填 |
| 需求标题 | 使用需求原始标题，不改写、不概括 | 必填 |
| 需求版本 | 标明本次验收对应的需求版本号或修订次数 | 必填 |
| 关联需求条目 | 列出本清单覆盖的具体需求条目或子项，避免一条清单对应多条无关需求 | 必填 |
| 验收标准 | 逐条列出可观察、可判定的完成条件，与需求条目一一对应 | 必填 |
| 原始需求描述 | 摘录或引用需求原文，作为验收标准的来源依据 | 必填 |
| 变更记录 | 记录验收期间发生的需求变更、范围调整及其确认人 | 有变更时必填 |
| 检查项 | 每条检查项对应一个可独立判断的验证点 | 必填 |
| 预期结果 | 写清通过时应观察到什么，避免“功能正常”这类无法判定的表述 | 必填 |
| 实际结果 | 记录实际观察到的结果，与预期结果逐条对应 | 必填 |
| 证据材料 | 注明证据类型和存放位置，如测试记录编号、截图文件名、评审记录链接 | 必填 |
| 检查人 | 填写实际执行检查的人员 | 必填 |
| 检查日期 | 填写检查完成日期 | 必填 |
| 通过/不通过 | 每条检查项给出明确结论，不使用“基本通过”等模糊表述 | 必填 |
| 遗留问题 | 记录不通过项或暂缓项的问题描述、影响范围和计划处理时间 | 有遗留时必填 |
| 阻断标记 | 标记该检查项是否构成验收阻断，并注明解除条件 | 必填 |
字段设计上有两个容易出问题的地方。一是验收标准与检查项混在一起写，导致评审时无法区分“依据”和“验证动作”；建议验收标准单独成列，检查项从标准中拆解而来。二是实际结果只写“已确认”，缺少可复核的内容；实际结果应描述观察到的现象或数据，让复核人不必重新执行也能判断。
分阶段检查项与逐项通过标准
检查项按准备、评审、上线前三个阶段组织，每个阶段有各自的核对重点。通过标准的写法遵循一个原则：换一个人来看，能得出相同结论。
准备阶段
| 检查项 | 通过标准 | 检查时点 |
|---|---|---|
| 需求条目完整 | 清单覆盖的条目与需求文档中的条目数量、编号一致，无遗漏 | 提测前 |
| 验收标准可测 | 每条验收标准都能对应至少一个检查项，且预期结果可观察 | 提测前 |
| 版本与变更已记录 | 需求版本号与当前开发版本一致，变更记录有确认人 | 提测前 |
| 检查项已分配责任人 | 每条检查项都有检查人和复核人 | 提测前 |
评审阶段
| 检查项 | 通过标准 | 检查时点 |
|---|---|---|
| 功能主流程核对 | 每条验收标准对应的主流程操作均执行，实际结果与预期一致 | 验收评审 |
| 边界与异常场景核对 | 需求中列明的边界条件、异常输入、权限差异等场景逐项执行并记录结果 | 验收评审 |
| 不通过项有说明 | 每个不通过项写明实际现象、影响范围和修复计划 | 验收评审 |
| 证据与检查项对应 | 每条检查项都能指向至少一份证据材料 | 验收评审 |
上线前阶段
| 检查项 | 通过标准 | 检查时点 |
|---|---|---|
| 变更已回归 | 评审后发生的所有变更均有对应的回归检查记录，且结论为通过 | 上线前 |
| 遗留问题已登记 | 每个遗留问题都有描述、责任人、计划处理时间和提出方确认 | 上线前 |
| 阻断项已处理 | 所有阻断标记的检查项均已解除，或已获得明确的放行确认 | 上线前 |
| 结论已签署 | 需求提出方和产品负责人对最终结论完成确认 | 上线前 |
通过标准的写法可以直接对照检查：把“界面显示正常”改成“列表页在无数据时显示空状态提示文案，文案与需求描述一致”；把“性能达标”改成“在约定数据量下，查询操作在需求规定的响应时间内返回结果”。前者无法判定，后者换人复核也能得到相同结论。
证据留存与责任人分工
证据的作用是让结论可追溯，而不是增加文档负担。每类检查项对应一种主要证据形式，证据与检查项在清单中逐条关联，避免评审结束后再去补材料。
| 检查项类型 | 证据形式 | 提供人 | 复核人 |
|---|---|---|---|
| 功能主流程 | 测试记录或操作截图 | 测试 | 产品负责人 |
| 边界与异常场景 | 测试用例执行记录 | 测试 | 开发 |
| 验收标准与需求一致性 | 需求文档对应条目引用 | 需求提出方 | 产品负责人 |
| 变更与回归 | 变更单及回归测试记录 | 开发 | 测试 |
| 评审结论 | 评审记录，含参与人和结论 | 产品负责人 | 需求提出方 |
责任分工上，检查人负责执行并填写实际结果，复核人负责确认证据与结论一致。两者不宜由同一人担任，尤其是阻断项相关的检查。证据缺失时的处理方式应在清单中预先写明：缺少证据的检查项按不通过处理，由检查人补充材料后重新确认，不能以口头说明替代。若因客观原因无法补充，需由产品负责人记录例外原因和替代确认方式，并在遗留问题中登记。
在需求条目较多、评审参与方分散的情况下，清单的版本和证据容易散落在不同文档中。ONES 可以将需求条目、验收状态和评审记录放在同一工作项下管理，检查项的实际结果与证据随需求状态流转，评审时按条目逐项核对，减少清单与需求脱节的情况。这一衔接适用于需求条目需要与验收记录保持对应关系的团队，具体使用方式可按团队现有的需求管理流程调整。
阻断项与完成条件
阻断项是那些一旦出现就必须暂停验收、不能带条件放行的情况。清单中应预先列明典型阻断项，评审时逐条比对，而不是等到结论阶段再讨论。
| 阻断项 | 判定条件 | 解除条件 | 确认人 |
|---|---|---|---|
| 验收标准缺失 | 存在需求条目没有对应的验收标准或检查项 | 补齐验收标准并拆解出检查项，经需求提出方确认 | 需求提出方 |
| 关键检查项不通过 | 主流程或需求明确要求的场景检查结果为不通过 | 修复后重新执行该检查项并记录通过结果 | 产品负责人 |
| 遗留问题未登记 | 存在已知问题但没有描述、责任人和处理计划 | 完成登记并获得提出方对处理方式的确认 | 需求提出方 |
| 变更未回归 | 评审后发生变更但无回归记录 | 完成回归检查并附证据 | 测试 |
| 证据缺失且无法补充 | 关键检查项无证据支撑，也无替代确认 | 补充证据，或由产品负责人记录例外并登记遗留问题 | 产品负责人 |
清单完成的判定条件可以归纳为三条同时满足：全部必填字段有明确结论，每条检查项都有对应证据，需求提出方和产品负责人完成签署。三条中任意一条不满足，清单保持未完成状态，不能进入上线确认。
不通过项的后续流转需要写清楚去向：属于本次需求范围内的缺陷，回到开发修复并重新检查；属于需求理解偏差的，回到需求条目修订并同步更新验收标准；属于可以延后处理的，登记为遗留问题并明确处理时间与责任人。每条流转都要在清单上留下记录，避免不通过项在评审结束后失去跟踪。
常见问题
需求验收清单和项目整体验收清单可以共用一份吗？
不建议共用。需求验收清单的判断对象是单条需求是否满足其验收标准，字段和检查项都围绕需求条目展开；项目整体验收关注范围、进度、成本的收口，判定依据不同。两者可以引用同一批证据，但清单结构和签署人应分开设置。需求验收的结论可以作为项目验收的输入，项目验收的结论不能反过来替代单项需求的判定。
验收标准在评审前发生变更，清单应该怎么处理？
变更发生后，先在变更记录字段写明变更内容、影响范围和确认人，再同步修订对应的验收标准和检查项，并重新确认预期结果。已经执行过的检查项如果受变更影响，需要重新执行并更新实际结果与证据；不受影响的检查项保留原记录。变更未完成回归前，清单不能进入上线前确认环节。
检查项很多时，是否每一项都要留存证据？
原则上每条检查项都应有可指向的证据，但证据形式可以按检查项类型区分：主流程用测试记录或截图，边界与异常场景用用例执行记录，需求一致性用需求条目引用，变更与回归用变更单和回归记录。重复性高、结论一致的检查项可以合并为一份证据，但清单上要写明该证据覆盖了哪些检查项，便于复核时对应。
遗留问题登记后，需求还能验收通过吗？
可以，前提是遗留问题不属于阻断项，且已完成登记：有描述、责任人、计划处理时间，并取得需求提出方的确认。阻断项清单中的情况必须先解除才能放行，例如关键检查项不通过、变更未回归。遗留问题的处理结果需要回到清单更新状态，避免评审结束后失去跟踪。
需求条目分散在多个文档里，清单如何保持与需求一致？
在清单中设置关联需求条目字段，逐条列出本清单覆盖的条目编号，并与需求文档的条目数量和编号核对一致。需求条目较多时，可以在需求管理工具中把需求条目、验收状态和评审记录放在同一工作项下，检查项结果随需求状态流转，评审时按条目逐项核对。ONES 支持将需求条目与验收记录关联管理，具体使用方式可按团队现有流程调整。
