需求验收确认单用于记录单项需求是否达到验收标准，常见结构为“基本信息—验收依据—逐项验收结果—结论与签字—留痕与归档”五段。本文提供可直接复制填写的空白表格，并逐字段说明填写口径、必填与选填划分、完整填写示例，以及按团队情况裁剪字段和维护模板版本的方法。
要点总览（TL;DR）
- 需求验收确认单按“基本信息—验收依据—逐项验收结果—结论与签字—留痕与归档”五段组织，空白表格可直接复制到文档或表格工具。
- 必填项包括需求编号与名称、验收版本或范围、验收依据、逐条验收项与结果、验收结论、验收人与日期；环境信息、遗留问题、附件清单、复核记录按情形填写。
- 总体结论与逐项结果需对应：全部通过写“通过”，存在限期整改项写“有条件通过”，核心项无法整改写“不通过”。
- 必填项缺失时先退回补充，客观原因无法补齐的注明原因、责任人和补齐日期，结论标记为“有条件通过”。
- 模板应设版本号与变更记录，调整字段后同步核对空白模板、字段说明、必填清单和填写示例。
可复制空白模板：需求验收确认单
下表按五段结构组织，可直接复制到 Word、在线文档或表格工具中使用。填写时保留表头，按行补充内容；验收项数量按实际需求增减，其余段落保持顺序。
| 段落 | 字段 | 填写内容 |
|---|---|---|
| 一、基本信息 | 确认单编号 | |
| 需求编号 | ||
| 需求名称 | ||
| 需求提出方 / 负责人 | ||
| 开发负责人 / 验收人 | ||
| 验收日期 / 验收环境 | ||
| 二、验收依据 | 需求文档名称及版本 | |
| 验收标准来源 | ||
| 本次验收范围与版本 | ||
| 三、逐项验收结果 | 验收项编号 | |
| 验收项描述 | ||
| 预期结果 | ||
| 实际结果 | ||
| 单项结论（通过 / 不通过 / 部分通过）及说明 | ||
| 四、结论与签字 | 总体验收结论 | |
| 遗留问题与整改期限 | ||
| 验收人签字 / 日期 | ||
| 需求方确认签字 / 日期 | ||
| 五、留痕与归档 | 附件清单 | |
| 关联需求 / 任务链接 | ||
| 复核记录 | ||
| 归档位置与归档日期 |
逐项验收结果部分在实际使用时通常有多行，建议每个验收项占一行，编号与验收标准中的条目对应，便于回溯。若验收项较多，可将该段单独拆成一张子表，主表保留汇总结论。
字段说明：每个字段记录什么、怎么填
同一份确认单会被需求方、开发、测试和验收人共同使用，字段口径需要事先约定。以下按五段说明各字段的含义与常见写法。
基本信息类字段
- 确认单编号：团队内部唯一标识，常见写法为“YS-年份-序号”，用于归档检索和避免多份确认单混淆。
- 需求编号与名称：与需求池或需求文档中的编号保持一致，名称使用正式需求标题，便于与需求记录对应。
- 需求提出方 / 负责人：写明提出需求的角色或部门，以及对该需求内容负责的人，便于验收结论有异议时找到确认对象。
- 开发负责人 / 验收人：开发负责人说明交付由谁完成，验收人说明由谁判定结果，两者可以是同一角色也可以分开。
- 验收日期 / 验收环境：日期写到具体某一天；环境写明测试环境、预发布环境或生产环境，以及版本号，避免“在某个环境验过”这类无法复现的描述。
验收依据类字段
- 需求文档名称及版本：写明文档标题和版本号或更新时间。需求发生变更时，此处应指向变更后的版本，确认单随之更新。
- 验收标准来源：说明验收标准写在何处，例如需求文档中的验收标准章节、原型说明或单独的验收标准清单，便于验收人核对判定依据。
- 本次验收范围与版本：明确本次验收覆盖的功能范围和交付版本，把不在本次范围内的内容排除在外，减少“验了但没完全验”的争议。
逐项验收结果字段
- 验收项编号与描述：每条对应一个可判定的验收点，描述使用可观察的行为或结果，例如“提交后 3 秒内返回结果页”，避免“体验流畅”这类无法判定的表述。
- 预期结果：抄录或概括验收标准中的对应条目，保持与验收依据一致。
- 实际结果：记录验收时观察到的现象，包括数据、截图编号或日志位置，便于后续复核。
- 单项结论及说明：在通过、不通过、部分通过中选择一项，并写明原因。部分通过需说明已满足和未满足的部分。
结论、签字与留痕字段
- 总体验收结论：常见写法为“通过”“有条件通过”“不通过”。有条件通过需在遗留问题栏写明条件和期限。
- 遗留问题与整改期限：逐条列出问题描述、责任人和完成日期，与单项结论中“不通过”“部分通过”的条目对应。
- 签字与日期：验收人和需求方分别签字并注明日期，签字表示对结论的确认，日期用于判断确认单与交付版本的时间关系。
- 附件清单、关联链接、复核记录、归档位置：记录支撑材料、需求或任务链接、后续复核情况和最终存放位置，使确认单在需求关闭后仍可追溯。
必填与选填：哪些字段不能空
必填项的作用是保证确认单能独立说明“验了什么、依据是什么、结论是什么、谁确认的”。以下划分是建议口径，团队可结合自身流程调整，但调整后应在模板说明中同步写明。
| 类别 | 字段 | 理由或适用情形 |
|---|---|---|
| 必填 | 需求编号与名称 | 确认单与需求记录的对应关系，缺失后无法回溯 |
| 验收版本或范围 | 界定本次验收覆盖的内容，避免范围争议 | |
| 验收依据（验收标准 / 需求文档版本） | 判定结果的依据，缺失则结论无法复核 | |
| 逐条验收项与结果 | 确认单的主体内容，至少包含一条可判定的验收项 | |
| 验收结论 | 确认单的核心输出，决定需求能否进入下一状态 | |
| 验收人与日期 | 确认结论的责任人和时间点 | |
| 选填 | 环境信息 | 涉及多环境部署或问题复现时建议填写 |
| 遗留问题与整改期限 | 结论为有条件通过或不通过时转为必填 | |
| 附件清单 | 有截图、日志、测试报告等支撑材料时填写 | |
| 复核记录 | 需要二次验收或整改后复验时填写 |
必填项缺失时，不建议先签字后补填。常见处理规则是：验收人退回补充，确认单保持“待完善”状态；若因客观原因暂时无法取得某项依据，应在确认单中注明缺失原因、补齐责任人和补齐日期，并将结论标记为“有条件通过”，待补齐后再更新结论。这样处理可以让缺失项可见、可跟踪，避免确认单在信息不全的情况下被当作已完成验收。
填写示例：一条需求的完整确认单
以下示例为演示情景，展示一条需求从基本信息到归档的完整填写方式，重点看逐项结果与总体结论如何对应。
| 段落 | 字段 | 示例内容 |
|---|---|---|
| 一、基本信息 | 确认单编号 | YS-2025-018 |
| 需求编号 / 名称 | REQ-2025-112 / 订单列表增加按状态筛选 | |
| 需求提出方 / 负责人 | 运营部 / 张某 | |
| 开发负责人 / 验收人 | 李某 / 王某 | |
| 验收日期 | 2025-06-12 | |
| 验收环境 | 预发布环境，版本 v2.4.0-rc1 | |
| 二、验收依据 | 需求文档名称及版本 | 《订单列表筛选需求说明》v1.2（2025-06-05 更新） |
| 验收标准来源 | 需求文档第 4 节“验收标准” | |
| 本次验收范围与版本 | 订单列表按状态筛选功能，不含导出功能 | |
| 三、逐项验收结果 | 验收项 1 | 预期：列表页提供状态筛选下拉框，包含全部、待付款、已付款、已取消；实际：下拉框存在，选项齐全；结论：通过 |
| 验收项 2 | 预期：选择“待付款”后列表仅显示待付款订单，数量与筛选前统计一致；实际：筛选结果正确，数量一致；结论：通过 | |
| 验收项 3 | 预期：筛选条件在翻页后保持；实际：翻页后筛选条件重置为“全部”；结论：不通过，见遗留问题 1 | |
| 四、结论与签字 | 总体验收结论 | 有条件通过：核心筛选功能可用，翻页保持筛选条件的问题需在 6 月 20 日前修复并复验 |
| 遗留问题与整改期限 | 问题 1：翻页后筛选条件重置；责任人：李某；期限：2025-06-20；复验人：王某 | |
| 验收人签字 / 日期 | 王某 / 2025-06-12 | |
| 需求方确认签字 / 日期 | 张某 / 2025-06-12 | |
| 五、留痕与归档 | 附件清单 | 筛选结果截图 3 张、翻页问题录屏 1 段 |
| 关联需求 / 任务链接 | 需求 REQ-2025-112，开发任务 TASK-3341 | |
| 复核记录 | 待 6 月 20 日修复后复验，复验结论另行补充 | |
| 归档位置与日期 | 项目文档库 / 需求验收 / 2025-06，归档日期 2025-06-13 |
示例中总体结论与逐项结果直接对应：三项验收项中两项通过、一项不通过，因此总体结论写为“有条件通过”，并把不通过项转为遗留问题，写明责任人和期限。若三项全部通过，总体结论写“通过”，遗留问题栏可填“无”；若核心验收项不通过且无法限期整改，总体结论写“不通过”，并说明需求退回修改。
调整与维护：按团队情况裁剪字段
模板需要在长期使用中保持可用，裁剪字段和维护版本是两项常规工作。裁剪的依据是需求类型和流程要求，维护的重点是模板、字段说明和示例三者保持一致。
按需求类型裁剪字段
- 小型功能优化：可保留基本信息、验收依据、逐项结果和结论签字四段，环境信息和附件清单按需填写，减少填写负担。
- 涉及多系统或外部依赖的需求：建议保留环境信息、关联链接和复核记录，便于定位问题发生在哪一环。
- 合规或对外交付类需求：建议增加审批签字栏、附件清单和归档要求，确保确认单本身可作为交付证据。
- 团队规模较大、角色较多时：可在基本信息中区分提出方、开发负责人、验收人和复核人，避免责任集中在同一人身上。
模板版本与变更记录维护
模板本身应有版本号和变更记录，记录每次增删字段的原因、生效日期和适用范围。已归档的确认单保留原版本字段，不随新模板回溯修改；新发起的验收使用当前版本。这样既能保证历史记录可读，也能避免新旧字段混用造成口径不一致。
模板与示例一致性检查
每次调整字段后，按以下清单核对一遍：空白模板中的字段是否与字段说明一一对应；必填与选填清单是否同步更新；填写示例是否仍能覆盖新增或修改的字段；确认单编号规则和归档位置是否仍然适用。检查完成后更新模板版本号，并在变更记录中注明。
当团队在 ONES 中管理需求时，确认单的留痕可以与需求工作项配合使用：需求池和任务看板用于同步需求状态与验收进度，ONES Wiki 的页面模板库可用于存放制式化的确认单模板，页面组关联项目后，需求与验收文档可以互相对应，页面版本记录也便于查看和回滚模板的历史版本。具体字段配置和状态流转规则以团队实际使用的产品版本为准。
常见问题
需求验收确认单和项目验收报告有什么区别？
需求验收确认单针对单项需求，判断该需求是否满足验收标准，字段围绕需求编号、验收依据、逐项结果和验收结论展开。项目验收报告面向整个项目的交付范围、进度、成本和质量，覆盖多个需求与里程碑。两者可以并存：单项需求先完成验收确认，项目收尾时再汇总各需求的确认结论作为项目验收的输入。
验收结论为“有条件通过”时，确认单还需要补哪些内容？
“有条件通过”意味着需求可以进入下一状态，但仍有未满足项需要限期处理。确认单中应补充三项内容：遗留问题逐条描述，与单项结论中“不通过”或“部分通过”的条目对应；每条问题的责任人和完成日期；复验安排，包括复验人和预计复验时间。整改完成后，在复核记录中补充复验结论，并更新总体验收结论。
需求在验收后发生变更，原确认单怎么处理？
原确认单保留，作为该版本交付的验收记录，不回溯修改。变更后的需求重新发起验收时，新建一份确认单，验收依据指向变更后的需求文档版本，并在关联链接中引用原确认单编号。这样历史记录可追溯，也能看出需求经过几次验收、每次的结论差异。
确认单必须由需求方和验收人双方签字吗？
建议双方都签字。验收人签字表示对验收结果负责，需求方签字表示对需求是否满足业务预期作出确认。若团队流程中需求方已通过其他方式确认，例如在需求工作项中留下确认记录，可在确认单中注明确认方式和时间，替代手写签字。涉及对外交付或合规要求的需求，保留双方签字更为稳妥。
在 ONES 中管理需求时，验收确认单如何与需求记录对应？
可以把确认单作为需求工作项的关联文档存放。ONES Wiki 提供页面模板库，可用于存放制式化的确认单模板；页面组关联项目后，需求与验收文档可以互相对应，页面版本记录便于查看和回滚模板的历史版本。需求池和任务看板用于同步需求状态与验收进度。具体字段配置和状态流转规则以团队实际使用的产品版本为准。
