单项需求验收确认需要四类依据：可判定的验收标准、可核验的交付证据、需求提出人的确认记录，以及遗留问题的处置约定。这四类材料分别回答“按什么判”“凭什么判”“谁认可”“没过的怎么办”。本文聚焦一条需求从提交验收到关闭的操作过程，给出可直接对照准备的清单、表格和记录示例。
要点总览（TL;DR）
- 单项需求验收确认需要四类依据：可判定的验收标准、可核验的交付证据、需求提出人的确认记录、遗留问题的处置约定，缺一项只能记为待确认。
- 验收标准从需求描述拆成正常、边界、异常三类场景，每条写明输入、操作、预期可观察结果与判定口径，并在开发前确认冻结。
- 验收确认按提交、核对、确认、记录、处置五步推进，开发或测试提交证据，质量角色核对完整性，需求提出人逐条确认，需求负责人登记结论。
- 结论分通过、有条件通过、不通过三种；有条件通过必须同时登记遗留项的责任人、期限与复验方式，否则等同于不通过。
- 闭环判断看六项：标准齐全、证据可核验、确认人有权、结论与证据一致、遗留项有处置、记录可追溯。
验收确认前先备齐哪四类依据
验收确认的依据由四类材料构成，缺任何一类，结论都应停留在“待确认”，不能记为通过。四类材料各有最低内容要求，准备时按清单逐项核对，比在评审会上临时找材料更可靠。
| 依据类别 | 作用 | 最低内容要求 |
|---|---|---|
| 验收标准 | 回答“按什么判” | 需求条目与验收条目的对应关系；每条标准的输入、操作与预期可观察结果；判定口径与不通过的具体表现 |
| 交付证据 | 回答“凭什么判” | 交付版本号与部署环境；测试记录或检查结果；演示材料、截图或操作录屏；证据与验收条目的对应关系 |
| 确认记录 | 回答“谁认可” | 确认人及其角色；确认时间；逐条确认结论；签字、邮件或系统留痕 |
| 遗留处置 | 回答“没过的怎么办” | 未通过项描述；整改责任人；整改期限；复验方式与复验人 |
验收标准是四类依据的基准。标准缺失时，证据再多也无法形成判定，确认记录也失去对照对象。交付证据要能定位到具体版本和环境，避免用开发本地环境的演示结果替代测试环境记录。确认记录的关键是确认人具备业务决策权，而不是任意参与者签字。遗留处置则把“有条件通过”变成可跟踪的承诺，防止问题在验收后失联。
从需求条目到验收标准：怎么写出可判定的依据
可判定的验收标准来自对需求描述的拆解。做法是把一条需求拆成正常路径、边界场景、异常场景三类，每类写成“输入—操作—预期可观察结果”的条目，并写明判定口径。标准应在开发开始前与需求提出人确认，验收时只做对照，不临时追加新条件。
| 场景类型 | 输入 | 操作 | 预期可观察结果 | 判定口径 |
|---|---|---|---|---|
| 正常路径 | 合法且完整的业务数据 | 按主流程提交 | 提交成功，生成对应记录，状态正确 | 结果与需求描述一致即通过 |
| 边界场景 | 数量、长度或金额处于允许范围的临界值 | 提交临界值数据 | 系统按约定接受或拒绝，提示明确 | 临界值处理与规则文档一致即通过 |
| 异常场景 | 缺失必填项、非法格式或超范围数据 | 提交异常数据 | 提交被阻止，提示指出具体问题项 | 能阻止并给出可理解提示即通过 |
写标准时，判定口径要落到可观察的结果上。例如“页面响应及时”难以判定，改为“提交后3秒内出现成功提示并生成记录编号”就可以对照。不通过的具体表现也要写明，例如“提交后无提示”“记录状态仍为草稿”，这样验收时双方对同一现象能得出一致结论。标准条目建议编号，与需求条目一一对应，后续证据和确认记录都引用同一编号，减少口径漂移。
标准在开发前确认这一点需要落到动作上：需求评审时同步评审验收标准，需求提出人对标准逐条确认，确认后的标准随需求一起冻结；开发过程中确需调整，走变更记录并注明影响范围。这样验收会上讨论的是“是否达到已确认的标准”，而不是“标准应该是什么”。
验收确认的操作步骤与角色分工
验收确认按“提交—核对—确认—记录—处置”五步推进，每步有明确输入、动作、输出、负责人和完成标志。角色上，开发或测试负责提交证据，测试或质量角色核对证据完整性，需求提出人做业务确认，需求负责人登记结论与遗留项。
| 步骤 | 输入 | 动作 | 输出 | 负责人 | 完成标志 |
|---|---|---|---|---|---|
| 提交验收申请 | 已确认的验收标准、交付版本 | 整理证据包，注明版本、环境、证据与标准条目的对应关系 | 验收申请与证据包 | 开发或测试 | 证据包提交至验收流程，状态为待核对 |
| 证据核对 | 验收申请与证据包 | 逐条核对证据是否覆盖全部标准条目，检查版本与环境是否一致 | 证据核对意见 | 测试或质量角色 | 证据完整，或列出缺失项退回补充 |
| 业务确认 | 验收标准、已核对证据 | 需求提出人按标准逐条对照证据，给出每条结论 | 逐条确认结论 | 需求提出人 | 全部条目有明确结论 |
| 结论记录 | 逐条确认结论 | 汇总为通过、有条件通过、不通过三种结论之一，记录确认人与时间 | 验收确认记录 | 需求负责人 | 记录完成留痕，状态更新 |
| 遗留项登记与复验 | 未通过项与有条件通过项 | 登记责任人、期限与复验方式，到期复验并更新结论 | 遗留项清单与复验结果 | 需求负责人与整改责任人 | 遗留项关闭或期限明确且在跟踪中 |
三种结论的适用条件要提前约定。全部标准条目达到判定口径，记为通过；主要条目通过、剩余问题不影响业务使用且有明确整改期限，记为有条件通过；存在影响核心使用的未达标条目，记为不通过并退回整改。有条件通过必须同时登记遗留项，否则等同于不通过。
确认记录需要在系统中留痕，便于后续追溯。ONES 的需求工作项可以承载验收标准条目与状态流转，评审记录和确认结论随工作项保存，遗留项可作为关联事项继续跟踪，使“标准—证据—确认—处置”在同一处可查。对于确认人分散在业务与研发两侧的团队，这种留痕方式能减少口头确认带来的争议。
示例：一条需求的验收确认记录怎么写
以下为演示情景，用于说明记录写法，不对应真实项目。需求为“报销单提交后支持按部门汇总查询”。
验收标准条目：
- AC-01 正常路径：选择有报销记录的部门与月份，查询结果列出该部门全部已提交报销单，合计金额与明细一致。
- AC-02 边界场景：查询无报销记录的部门，返回空结果并提示“暂无数据”。
- AC-03 异常场景：未选择部门直接查询，阻止提交并提示选择部门。
对应证据材料：交付版本 v1.4.2，测试环境；测试记录 TR-118 覆盖 AC-01 至 AC-03；操作截图三张，分别对应正常查询、空结果、未选部门提示；证据与条目编号一一对应。
业务确认结论：AC-01 通过，AC-02 通过，AC-03 通过；整体结论为通过。确认人为财务部需求提出人，确认时间记录在验收记录中，结论在系统中留痕。
遗留项与复验结果：确认过程中提出“汇总结果导出”为后续需求，不纳入本次验收范围，登记为独立需求；本次验收无未通过项，遗留项清单为空，验收状态关闭。
若 AC-02 当时返回报错而非空结果提示，则该条记为不通过，整体结论应为有条件通过或不通过，并登记整改责任人与复验时间，复验通过后再更新为通过。记录中保留原结论与复验结论，形成完整轨迹。
完成检查：验收确认是否闭环
判断一条需求的验收确认是否可以关闭，按以下清单逐项核对。任一项不满足，结论应保持待确认或待复验。
- 验收标准齐全：需求条目均有对应验收条目，正常、边界、异常场景均有覆盖，判定口径可观察。
- 证据可核验：证据对应明确版本与环境，覆盖全部标准条目，测试记录或演示材料可复查。
- 确认人有权确认：确认人为需求提出人或其明确授权的业务角色，确认时间与逐条结论完整。
- 结论与证据一致：通过、有条件通过、不通过的结论与逐条确认结果相符，无条件通过时遗留项清单为空。
- 遗留项有处置：未通过项与有条件通过项均有责任人、期限和复验方式，到期已复验或仍在期限内跟踪。
- 记录可追溯：验收确认记录、证据与遗留项在同一处可查，状态更新与结论一致，后续可回溯确认过程。
清单全部满足后，将需求状态更新为已验收并关闭确认流程；存在未复验遗留项的，保持跟踪状态，复验完成后再关闭。这样一条需求的验收确认就形成了从标准到处置的完整闭环。
常见问题
需求验收时，需求提出人无法到场确认怎么办？
可以提前书面授权一名具备业务决策权的代理人，并在确认记录中写明授权关系与授权范围。代理人按已确认的验收标准逐条对照证据给出结论，记录中同时保留授权说明。若授权来不及办理，本次验收应记为待确认，先完成证据核对，待有权确认人到位后再出结论，避免由无决策权的人签字造成后续返工。
验收标准在开发过程中发现写得不完整，还能补吗？
可以补，但要按变更处理：由需求提出人提出补充条目，说明补充原因与影响范围，经确认后随需求一起更新，并在验收记录中注明标准版本。补充的标准只对尚未验收的条目生效，已经确认通过的条目保持原结论。这样既解决标准遗漏，也避免验收会上临时追加条件导致双方对结论产生分歧。
有条件通过的需求，遗留项到期没整改完怎么处理？
到期未完成时，由整改责任人说明原因并申请延期，需求负责人评估影响后决定是否同意延期、调整期限或转为不通过。无论哪种处理，都要在遗留项清单中更新状态与新的期限，并保留原记录。遗留项长期挂起会削弱验收结论的可信度，建议在到期前设置提醒，把复验安排纳入日常跟踪。
验收证据用开发本地环境的演示结果可以吗？
不建议。证据要能定位到具体版本与部署环境，通常以测试环境或预发布环境的测试记录、截图、操作录屏为准。本地环境的结果难以复现，也无法证明与交付版本一致。若确实只能在本地演示，应在记录中注明环境差异，并由测试或质量角色补充对应版本的核验证据，再进入业务确认环节。
一条需求验收通过后，还需要保留哪些记录？
至少保留四类：已确认的验收标准条目、对应版本的证据材料、逐条确认结论与确认人时间、遗留项清单及复验结果。这些记录要能相互引用，标准条目编号与证据、结论一一对应。保留记录的作用是后续出现争议或需要回溯时，能还原当时的判定依据，也为同类需求的验收标准积累可复用的模板。
