需求验收记录围绕单项需求是否满足验收条件来保留信息，核心包括需求标识与版本、验收依据、验收环境与数据、验收方式与参与角色、逐条检查结果与证据、遗留问题与处理结论、验收结论与签署、变更与复验记录。本文提供一张可直接复制的空白表，并说明每个字段的填写口径、必填规则与归档方式，适用于单项需求的验收留痕；产品整体效果评估与项目整体验收不在本表范围。
要点总览（TL;DR）
- 需求验收记录围绕单项需求是否满足验收条件保留信息，核心字段分为表头、验收依据、验收执行、逐条检查结果、结论与签署五个区块。
- 必填字段以可追溯、可复验为标准：需求编号、名称、版本、验收标准及来源文档版本、逐条检查结果、验收结论与签署人不可空缺。
- 验收结论为不通过或部分通过时，遗留问题、处理方案与复验安排转为必填，每条不通过的标准都应对应一条遗留问题。
- 模板按需求类型增减字段并做版本管理，记录按需求编号归档，验收通过并签署后推进需求状态完成闭环。
可复制空白模板：需求验收记录表
下面这张表按“表头—依据—执行—结果—结论”五个区块组织，复制到文档或表格工具后即可填写。一条需求对应一份记录；同一需求多次验收时，每次验收单独复制一份，并在表头注明验收轮次。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 表头信息 | 需求编号 | |
| 需求名称 | ||
| 需求版本 | ||
| 所属迭代/批次 | ||
| 验收轮次 | ||
| 验收日期 | ||
| 验收依据 | 验收标准条目 | |
| 标准来源文档 | ||
| 来源文档版本号 | ||
| 验收执行 | 验收环境 | |
| 测试数据说明 | ||
| 验收方式 | ||
| 参与角色与人员 | ||
| 逐条检查结果 | 标准条目 | |
| 预期结果 | ||
| 实际结果 | ||
| 检查结论（通过/不通过） | ||
| 证据位置 | ||
| 结论与签署 | 验收结论 | |
| 遗留问题 | ||
| 复验安排 | ||
| 签署人及日期 | ||
| 变更说明 |
“逐条检查结果”区在实际使用时按验收标准条目逐行展开，一条标准一行，行数随标准数量增减。其余区块保持单份记录内唯一，避免同一字段出现多个互相矛盾的取值。
字段说明：每个字段记录什么、怎么填
字段说明的作用是让产品、研发、测试和业务方对同一份记录采用一致的填写口径。下表逐字段解释含义与填写要求，填写时以“后来者能否据此复验”为判断尺度。
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 需求编号 | 需求在需求池或需求管理系统中的唯一标识 | 填写系统编号，保持与需求条目一致，便于反向追溯 |
| 需求名称 | 需求的简短标题 | 与需求条目名称一致，不自行改写 |
| 需求版本 | 本次验收对应的需求版本 | 填写版本号或修订标识；需求在验收前发生变更时，更新版本并说明变更点 |
| 所属迭代/批次 | 需求交付所属的迭代、发布批次或交付批次 | 填写团队实际使用的迭代名称或批次编号 |
| 验收轮次 | 该需求第几次验收 | 首次填“第1轮”，复验依次递增，便于区分初验与复验结论 |
| 验收日期 | 实际执行验收的日期 | 填写执行当天日期；跨天验收可注明起止日期 |
| 验收标准条目 | 本次验收所依据的具体标准 | 逐条编号列出，标准应可判断通过与否，避免“体验良好”这类无法判定的表述 |
| 标准来源文档 | 验收标准出自哪份文档 | 填写需求文档、验收标准说明、合同附件等文档名称 |
| 来源文档版本号 | 所引用文档的版本 | 填写版本号或修订日期；文档更新后需确认标准是否同步调整 |
| 验收环境 | 验收所运行的环境 | 注明环境名称及关键配置差异，如测试环境、预发布环境、特定终端或浏览器 |
| 测试数据说明 | 验收使用的数据来源与范围 | 说明数据来源、数据量级或特殊构造条件；涉及敏感数据时只描述类型，不记录原始内容 |
| 验收方式 | 采用的验收手段 | 如功能演示、手工操作验证、自动化用例执行、接口联调验证、文档评审 |
| 参与角色与人员 | 参与验收的角色和具体人员 | 按角色填写，如产品负责人、测试、研发、业务方代表，并写明姓名 |
| 标准条目 | 逐条检查时对应的标准编号 | 与“验收标准条目”编号一一对应 |
| 预期结果 | 按标准应出现的结果 | 写可观察的结果描述，包含关键数值或状态 |
| 实际结果 | 验收时实际观察到的结果 | 如实记录，与预期不一致时写明差异表现 |
| 检查结论 | 该条标准的判定 | 填写“通过”或“不通过”；部分满足时判为不通过并说明缺口 |
| 证据位置 | 支撑判定的证据存放位置 | 填写截图、日志、测试报告、录屏的存放路径或附件编号，保证他人可查 |
| 验收结论 | 本次验收的整体判定 | 填写“通过”“部分通过”或“不通过”，并简述依据 |
| 遗留问题 | 未满足项与待处理事项 | 逐条列出问题描述、影响范围与建议处理方式 |
| 复验安排 | 复验的时间与范围 | 写明复验时间、复验条目和复验责任人；无需复验时注明“无” |
| 签署人及日期 | 对结论负责的人员确认 | 由验收结论确认人签署，注明日期；多方确认时逐一签署 |
| 变更说明 | 验收过程中发生的需求或标准变更 | 记录变更内容、变更原因与确认人，便于后续追溯 |
必填与选填：哪些字段不能空
必填字段的判断标准是“可追溯、可复验”：缺少该字段，后续人员无法确认这条需求验收的是什么、依据什么、结果如何。按此标准，需求编号、需求名称、需求版本、验收标准条目、标准来源文档及版本号、逐条检查结果、验收结论与签署人属于必填项。
必填字段的理由可以归为三类。需求编号、名称与版本保证记录能对应到唯一的需求条目及其状态；验收标准及来源文档版本保证判定有据可查，标准变更后也能分辨当时依据的是哪一版；逐条检查结果、证据位置与验收结论、签署则保证结论可被复核，出现争议时有据可依。
选填字段包括所属迭代/批次、验收轮次、测试数据说明、变更说明等。所属迭代在需求已关联迭代时可从系统中查到，记录中填写便于检索；验收轮次在首次验收时可省略，进入复验后建议补齐；测试数据说明在验收不依赖特定数据时可简写；变更说明仅在验收期间发生变更时填写。
字段暂缺时，统一标注“待补”，并写明补录责任人与补录时间，避免用空白或“无”掩盖未完成的信息。验收结论为“不通过”或“部分通过”时，遗留问题、处理方案与复验安排转为必填，且每条不通过的标准都应有对应的遗留问题记录，保证问题不丢失。
填写示例：一条需求的完整验收记录
以下为演示用示例，需求与数据均为虚构，用于说明各区块如何联动填写。
| 区块 | 字段 | 示例内容 |
|---|---|---|
| 表头信息 | 需求编号 | REQ-2024-0317 |
| 需求名称 | 订单列表支持按支付状态筛选 | |
| 需求版本 | V1.2 | |
| 所属迭代/批次 | 2024年第8迭代 | |
| 验收轮次 | 第1轮 | |
| 验收日期 | 2024-04-18 | |
| 验收依据 | 验收标准条目 | 1. 筛选条件包含“已支付、待支付、已退款”三个选项；2. 选择任一状态后列表仅显示对应订单；3. 筛选结果分页数量与筛选前一致；4. 清空筛选后恢复全部订单 |
| 标准来源文档 | 《订单列表筛选需求说明》 | |
| 来源文档版本号 | V1.2（2024-04-10 修订） | |
| 验收执行 | 验收环境 | 预发布环境，Web端 Chrome 最新版 |
| 测试数据说明 | 使用测试账号下 120 条订单数据，覆盖三种支付状态 | |
| 验收方式 | 手工操作验证 + 接口返回核对 | |
| 参与角色与人员 | 产品负责人：张某；测试：李某；研发：王某；业务方代表：赵某 | |
| 逐条检查结果 | 标准条目 1 | 预期：下拉框含三个选项；实际：三个选项齐全；结论：通过；证据：截图 01 |
| 标准条目 2 | 预期：列表仅显示对应状态订单；实际：三种状态筛选结果均正确；结论：通过；证据：截图 02–04 | |
| 标准条目 3 | 预期：分页数量与筛选前一致；实际：筛选后每页 20 条，与筛选前一致；结论：通过；证据：截图 05 | |
| 标准条目 4 | 预期：清空筛选恢复全部订单；实际：清空后仍保留上一次筛选条件，需手动刷新才恢复；结论：不通过；证据：录屏 01 | |
| 结论与签署 | 验收结论 | 部分通过：4 条标准中 3 条通过，1 条不通过 |
| 遗留问题 | 清空筛选后未重置列表，需刷新页面；影响范围：所有使用筛选的用户；建议处理：修复筛选状态重置逻辑 | |
| 复验安排 | 2024-04-22 复验标准条目 4，复验责任人：李某 | |
| 签署人及日期 | 产品负责人张某、业务方代表赵某，2024-04-18 | |
| 变更说明 | 无 |
示例中“不通过”的条目直接对应遗留问题与复验安排，形成从标准到问题再到复验的完整链条。复验时复制本表，验收轮次改为“第2轮”，只保留需复验的条目并补充新的实际结果与证据，历史轮次记录保留不覆盖。
调整与维护：模板怎么改、记录怎么留
模板调整应围绕需求类型展开，而非每次验收临时改表。涉及外部接口、数据迁移或权限变更的需求，宜在“验收执行”区补充环境配置与数据范围说明；纯文档、文案类需求可精简测试数据与验收方式字段，保留标准条目与检查结果即可。增减字段时同步更新字段说明，保证模板、说明与示例三处口径一致。
模板本身需要版本管理。每次调整记录变更内容、变更原因与生效时间，旧版本模板保留可查，避免历史记录因模板改版而失去解释依据。团队可将模板放入文档工具的模板库统一维护，新记录从最新版本创建。
验收记录的归档位置、保留期限与检索方式按团队制度确定。常见做法是按需求编号归档，与需求条目关联存放，检索时从需求编号或迭代批次进入。记录与需求状态流转衔接：验收通过并完成签署后，将需求状态推进到已完成或已发布，遗留问题转入问题跟踪；部分通过或不通过时，需求保持待验收状态，待复验通过后再闭环。
在 ONES 中，需求条目、任务、测试与缺陷可以在同一流程中关联，验收记录作为需求条目的附件或关联文档留存，验收结论与状态流转在同一处衔接，复验时从原需求条目进入即可找到历史记录。ONES Wiki 支持页面版本记录与回滚，模板可放入模板库统一创建，页面组关联项目后，需求与验收文档可以互相对应，便于按需求追溯历次验收材料。是否采用工具承载，取决于团队对追溯深度和协作范围的要求；记录字段与必填规则仍按本文模板执行。
常见问题
需求在验收前发生变更，验收记录应该怎么处理？
需求在验收前发生变更时，先更新需求版本字段，并在变更说明中记录变更内容、原因与确认人。验收标准若随需求调整，需同步更新验收标准条目和来源文档版本号，避免记录中的标准与实际判定依据不一致。已经按旧版本执行过的检查结果保留在原记录中，新版本另起一份记录或在新轮次中填写，历史内容不覆盖。
验收记录里的证据只写“见截图”可以吗？
建议写到可定位的程度。证据位置字段的作用是让他人无需询问就能找到支撑材料，填写截图编号、日志文件名、测试报告名称或附件存放路径都可以。只写“见截图”而不指明是哪一张，复验或争议复核时仍需二次沟通。证据本身涉及敏感数据时，记录类型和位置即可，原始内容按团队的数据管理要求存放。
复验时是新建一份记录，还是在原记录上修改？
建议新建一份记录，验收轮次递增，只保留需要复验的条目并填写新的实际结果与证据，原轮次记录保留不覆盖。这样初验与复验的结论可以分别追溯，出现争议时能看清每条标准是在哪一轮通过、依据是什么。若团队使用文档工具承载，可把各轮记录放在同一需求条目下关联存放。
验收记录需要保留多久，由谁负责归档？
保留期限没有统一标准，按团队所在行业的合规要求、合同约定和内部制度确定。归档责任通常落在验收组织方，例如产品负责人或测试负责人，在验收签署完成后将记录归入既定位置。检索方式建议与需求编号绑定，从需求条目即可进入历次验收材料。涉及外部交付或审计的项目，保留期限宜在项目启动时明确，避免事后补录。
用文档工具还是需求管理工具承载验收记录更合适？
取决于团队对追溯深度和协作范围的要求。记录以文档形式留存、验收频次不高的团队，用文档工具建模板库即可满足；需求状态流转、测试执行和缺陷处理已经在同一平台进行的团队，把验收记录关联到需求条目上，复验时从原需求进入就能找到历史记录，衔接更顺。在 ONES 中，需求、任务、测试与缺陷可在同一流程关联，验收记录可作为需求条目的附件或关联文档留存；ONES Wiki 支持页面版本记录与回滚，模板可放入模板库统一创建。无论用哪种载体，字段与必填规则仍按本文模板执行。
