需求验收确认记录用于回答一个具体问题：这项需求是否按约定标准完成，并由谁在什么时间确认。模板以一张可复制的确认表为核心，覆盖需求标识、验收依据、环境与版本、逐条验收结果、结论与遗留问题、参与人签署、附件留痕七个字段组。它适用于单项需求的验收记录，产品整体效果评估与项目整体验收不在本文范围内。
要点总览（TL;DR）
- 模板以一张可复制的确认表为核心，覆盖需求标识、验收依据、环境与版本、逐条验收结果、结论与遗留问题、参与人签署、附件留痕七个字段组。
- 验收结论分通过、有条件通过、不通过三类；出现遗留问题时必须写明问题描述、后续动作、责任人与计划关闭时间。
- 记录编号、需求编号、验收依据、环境与版本、逐条判定、证据位置、结论与三方签署属于必填项，缺失即视为记录不完整。
- 留痕证据按记录编号建立子目录存放，截图、录屏、日志与测试用例至少保留一种可核对的证据，并与记录一同归档。
- 模板结构保持稳定，验收项按需求类型增减；模板设版本号与变更记录，已归档记录不随模板升级回溯修改。
可复制空白模板：需求验收确认记录表
下面这张表可以直接复制到文档或表格工具中使用。字段按填写顺序排列，先锁定需求与验收依据，再记录逐条验收结果，最后给出结论并完成签署。
| 字段组 | 字段 | 填写内容 |
|---|---|---|
| 表头信息 | 记录编号 | |
| 需求编号 | ||
| 需求名称 | ||
| 所属迭代/版本 | ||
| 验收日期 | ||
| 验收依据 | 验收标准来源 | |
| 关联需求文档 | ||
| 关联设计稿或接口说明 | ||
| 验收环境与版本 | 验收环境 | |
| 构建版本 | ||
| 数据条件 | ||
| 逐条验收明细 | 序号 | |
| 验收项 | ||
| 预期结果 | ||
| 实测结果 | ||
| 判定 | ||
| 证据位置 | ||
| 结论 | 验收结论 | □ 通过 □ 有条件通过 □ 不通过 |
| 遗留问题 | ||
| 后续动作 | ||
| 责任人 | ||
| 签署 | 提出方 | |
| 实现方 | ||
| 验收方 | ||
| 确认日期 | ||
| 附件与留痕 | 测试用例 | |
| 截图或录屏 | ||
| 日志或数据文件 | ||
| 其他附件 |
逐条验收明细在实际使用时按验收项数量展开为多行，每个验收项占一行，序号连续编号。验收项较多时，明细表可以单独成页，表头信息与验收依据保留在首页，结论与签署放在明细之后。
字段说明：每个字段记录什么、怎么填
模板能否起到追溯作用，取决于每个字段是否记录到可核对的位置。以下按字段组说明含义与填写口径。
标识类字段
记录编号用于区分每一次验收记录，建议采用“需求编号-验收轮次-日期”的组合，例如“REQ-0231-AC2-20250612”，保证同一需求多轮验收时记录不重复。需求编号沿用需求池中的原始编号，不另起一套编码；需求名称与编号对应，便于检索时快速识别。所属迭代/版本填写该需求计划交付的迭代或版本号，验收日期填写实际完成验收的日期，与签署区的确认日期区分开。
验收依据字段
验收标准来源写明标准出自哪里，例如需求文档中的验收标准章节、评审会议纪要或补充确认邮件。关联需求文档填写文档名称与版本号，关联设计稿或接口说明填写设计稿链接或接口文档编号。依据字段要引用到具体条款或章节位置，只写“见需求文档”会让后续复核无法定位判断依据。
环境与版本字段
验收环境记录验收发生在测试环境、预发布环境还是生产环境，构建版本记录被测代码或配置的具体版本号。数据条件记录验收时使用的账号、数据集或特殊配置，例如“使用测试账号A，订单数据为模拟数据”。这三项共同确定验收结果的适用范围，环境或版本变化后，原记录不能直接套用到新版本。
逐条验收明细字段
验收项是对验收标准的拆分，一条验收标准可以拆成多个可独立判断的验收项。预期结果照抄或转述验收标准中的期望行为，实测结果记录实际操作后观察到的现象，两者要能一一对照。判定字段只填“通过”或“不通过”，与实测结果保持一致：实测结果符合预期填通过，不符合填不通过，不写“基本通过”这类模糊判断。证据位置填写支撑该判定的截图、日志、测试用例编号或演示录屏的存放路径，路径要能让其他人直接打开查看。
结论字段
验收结论有三种取值。全部验收项通过时填“通过”；主要验收项通过、存在不影响核心使用的遗留问题时填“有条件通过”；存在验收项不通过且影响需求目标达成时填“不通过”。遗留问题逐条列出问题描述与影响范围，后续动作写明修复、补充验收或重新提测的安排，责任人填写具体承担该动作的人。结论为“通过”时，遗留问题栏填“无”，不留空。
签署字段
提出方通常是业务或需求提出角色，实现方是研发或交付角色，验收方是实际执行验收并给出结论的人。三方签署表示对验收结果和遗留问题处理方式的共同确认。确认日期填写签署完成的日期，与表头的验收日期可以相同，跨日完成签署时分别记录。
必填与选填：哪些字段不能空
必填字段缺失时，这份记录视为不完整，不能作为需求关闭的依据。选填字段按需求类型补充，不影响记录的基本完整性。
| 字段 | 填写要求 | 适用说明 |
|---|---|---|
| 记录编号、需求编号、需求名称 | 必填 | 缺失则记录无法与需求对应 |
| 所属迭代/版本、验收日期 | 必填 | 确定验收的时间与交付范围 |
| 验收标准来源、关联需求文档 | 必填 | 缺失则判定缺少依据 |
| 验收环境、构建版本 | 必填 | 缺失则结果无法复现 |
| 验收项、预期结果、实测结果、判定 | 必填 | 逐条填写，不得整表留空 |
| 证据位置 | 必填 | 判定为不通过时尤其需要 |
| 验收结论 | 必填 | 三选一，不留空 |
| 提出方、实现方、验收方、确认日期 | 必填 | 缺失则确认关系不成立 |
| 遗留问题、后续动作、责任人 | 有条件必填 | 结论为有条件通过或不通过时必须填写，含计划关闭时间 |
| 数据条件 | 选填 | 验收依赖特定数据或账号时填写 |
| 关联设计稿或接口说明 | 选填 | 涉及界面或接口的需求填写 |
| 性能压测数据、合规审批编号 | 选填 | 性能类、合规类需求按需补充 |
| 测试用例、截图录屏、日志文件 | 选填 | 按证据形式提供，至少保留一种可核对的证据 |
字段留空需要写明理由。例如某项验收不涉及接口，关联接口说明栏填“不涉及”，而不是留白；数据条件使用默认测试数据时填“默认测试数据”。用“不涉及”“默认配置”这类明确说明代替空白，可以让复核者区分“没有这项内容”和“漏填”。
填写示例：一条需求的完整验收记录
以下示例为演示情景，用于说明各字段如何联动填写。示例需求为“订单列表增加按支付状态筛选功能”，验收标准来自需求文档第4章。
| 字段 | 示例内容 |
|---|---|
| 记录编号 | REQ-0231-AC1-20250612 |
| 需求编号 | REQ-0231 |
| 需求名称 | 订单列表按支付状态筛选 |
| 所属迭代/版本 | 迭代 2025-06，版本 v2.4.0 |
| 验收日期 | 2025-06-12 |
| 验收标准来源 | 需求文档《订单列表筛选需求》v1.2 第4章验收标准 |
| 关联需求文档 | 《订单列表筛选需求》v1.2 |
| 关联设计稿或接口说明 | 设计稿“订单列表-筛选”第3版；接口文档 ORD-API-07 |
| 验收环境 | 预发布环境 |
| 构建版本 | v2.4.0-rc2 |
| 数据条件 | 测试账号 order_test01，含已支付、待支付、已退款订单各10条 |
逐条验收明细填写如下：
| 序号 | 验收项 | 预期结果 | 实测结果 | 判定 | 证据位置 |
|---|---|---|---|---|---|
| 1 | 按“已支付”筛选 | 列表仅显示已支付订单，数量与数据统计一致 | 显示10条已支付订单，与统计一致 | 通过 | 截图 /evidence/REQ-0231/01-paid.png |
| 2 | 筛选后翻页 | 翻页保持筛选条件，页码与总数正确 | 翻至第2页后筛选条件被清空，显示全部订单 | 不通过 | 录屏 /evidence/REQ-0231/02-paging.mp4；缺陷单 BUG-1187 |
| 3 | 组合筛选 | 支付状态与时间范围可同时生效 | 两个条件同时生效，结果正确 | 通过 | 截图 /evidence/REQ-0231/03-combined.png |
由于存在一条不通过项，且该问题影响筛选场景的连续使用，本次结论填“有条件通过”：核心筛选功能可用，翻页丢失筛选条件的问题列入遗留问题。遗留问题写“翻页后筛选条件丢失，影响多页数据的连续查看”，后续动作写“BUG-1187 修复后补充验收第2项”，责任人填实现方对应开发人员，计划关闭时间填 2025-06-18。签署区由提出方产品经理、实现方开发负责人、验收方测试人员分别签署，确认日期为 2025-06-12。附件留痕列出测试用例编号 TC-ORD-045 至 TC-ORD-047、上述截图与录屏、缺陷单 BUG-1187 链接。
调整与维护：模板怎么改、记录怎么留
模板需要在团队内长期使用，字段结构保持稳定的同时，允许按需求类型做有限调整。调整和维护围绕四件事展开：增减字段、管理版本、归档记录、衔接状态。
按需求类型增减验收项与选填字段
表头信息、验收依据、环境与版本、结论、签署这五组字段保持固定，不随需求类型变化。逐条验收明细的验收项按需求内容增减，界面类需求增加交互与文案检查项，接口类需求增加字段校验与异常返回项，性能类需求增加响应时间与并发数据项。选填字段按需启用，不为了统一格式强行填写与需求无关的内容。
模板版本与变更记录
模板本身设置版本号，例如 v1.0、v1.1，每次调整字段或填写口径时在模板末尾附变更记录，写明变更日期、变更内容和原因。已归档的验收记录保留其填写时对应的模板版本，不随模板升级回溯修改，保证历史记录可复核。
归档位置、命名规则与保存期限
确认记录统一存放在团队约定的文档空间或项目文档库中，按“需求编号-验收轮次-日期”命名，与记录编号保持一致。保存期限按团队的质量管理与审计要求确定，通常至少覆盖需求上线后的一个完整维护周期。记录归档时连同证据附件一起保存，证据文件按记录编号建立子目录，避免截图与记录分离。
与需求状态流转的衔接
验收结论确认后，需求状态随之更新：结论为通过时，需求流转到已完成或待发布状态；结论为有条件通过时，需求保持待验证状态，遗留问题修复并补充验收后再流转；结论为不通过时，需求退回开发或重新提测。状态更新以签署完成的记录为依据，记录编号回填到需求条目中，形成需求与验收记录的双向对应。
在 ONES 中，需求池、工单与任务看板可以同步需求状态与相关信息，便于追溯需求与问题；ONES Wiki 支持通过模板库创建文档、保存附件并记录页面版本，适合存放验收确认记录及其证据附件，页面组关联项目后，需求与文档可以互相对应。团队可以把确认记录作为需求条目的关联文档，在状态流转时一并核对。
定期抽查记录完整性
建议按迭代或按月抽查已关闭需求的验收记录，核对必填字段是否齐全、结论与明细判定是否一致、遗留问题是否有责任人和关闭时间、证据位置是否可打开。抽查发现的问题记录在检查清单中，作为下一轮模板调整的依据。抽查频率和样本量按团队交付节奏确定，需求量大时可按需求类型分层抽取。
常见问题
需求验收结论填了“有条件通过”，遗留问题修复后需要重新走一遍完整验收吗？
不需要重走全部验收项，但需要针对遗留问题补充验收并更新记录。常见做法是在原记录上追加一轮补充验收：保留原记录编号，新增验收轮次，只填写与遗留问题相关的验收项，判定通过后把结论更新为“通过”，并注明补充验收的日期与签署人。若遗留问题修复影响到其他验收项，则把受影响的验收项一并纳入补充验收范围。补充验收完成后，需求状态再流转到已完成或待发布。
验收时需求已经上线，验收环境该填生产环境还是原测试环境？
填写实际执行验收的环境。如果验收在生产环境完成，就填生产环境，并在数据条件中说明使用的真实数据范围与账号；如果验收在测试或预发布环境完成、上线属于发布动作，则填测试或预发布环境。环境字段的作用是确定验收结果的适用范围，环境变化后原记录不能直接套用到新版本，需要重新确认或补充验收。
同一需求多轮验收，记录编号怎么编才不会重复？
建议采用“需求编号-验收轮次-日期”的组合，例如“REQ-0231-AC2-20250612”，其中AC后面的数字表示第几轮验收。需求编号沿用需求池中的原始编号，不另起编码；日期填该轮验收实际完成的日期。这样同一需求的多轮记录既能按需求编号聚合检索，也能按轮次区分先后顺序。
团队用文档工具存放验收记录，怎么保证证据附件不丢失？
关键是让记录与证据保持同一归属。归档时按记录编号建立子目录，截图、录屏、日志和测试用例统一放入该目录，记录中的证据位置字段填写该目录下的具体路径，避免只写“见附件”。使用 ONES Wiki 时，可以通过模板库创建记录文档、以附件形式存档证据，页面版本会记录每次修改，便于回溯（F3、F4）。归档后定期抽查证据路径是否可打开，发现失效及时补传。
验收记录需要保存多久，保存期限由什么决定？
保存期限按团队的质量管理与审计要求确定，通常至少覆盖需求上线后的一个完整维护周期；涉及合规、合同或行业审计要求的需求，按对应要求延长。模板本身不规定统一期限，团队可以在维护规则中写明各类需求的保存年限，并在归档目录中标注到期时间，避免记录被提前清理。
