需求验收标准、验收清单和DoD（完成定义）记录的对象不同：验收标准记录单项需求“做到什么程度算满足”，是判断依据；验收清单记录“按什么逐项核对、由谁核对、结果如何”，是执行与留痕工具；DoD记录团队对“完成”的统一约定，是适用于一类工作项的通用完成门槛。本文围绕单项需求是否满足展开，产品整体效果验证和项目整体验收不在讨论范围内。
要点总览（TL;DR）
- 需求验收标准记录单项需求的合格条件，回答“这条需求合不合格”，随需求变化而重写。
- 需求验收清单记录核对项、核对人、核对时间、结果与证据，回答“这次验收怎么查、查完记什么”。
- DoD（完成定义）记录团队对一类工作项的通用完成门槛，回答“什么状态才允许叫完成”，相对稳定。
- 三者按顺序配合：需求提出时写验收标准，开发前确认DoD适用，验收时按标准逐项核对并留痕，结果作为关闭依据。
- 常见误区是用DoD代替验收标准、用清单代替标准、验收后不留证据，都会让需求关闭失去可查依据。
三者的记录对象与一句话定义
三个概念容易混用，原因在于它们都出现在“需求做完没有”这个场景里。但落到记录上，各自回答的问题并不相同。
| 概念 | 记录对象 | 一句话定义 | 回答的问题 |
|---|---|---|---|
| 需求验收标准 | 单项需求的合格条件 | 针对一条具体需求，写明满足什么条件才算合格 | 这条需求合不合格 |
| 需求验收清单 | 核对项、核对人、核对结果与证据 | 把验收标准拆成可逐项核对的条目，并记录每次核对的过程和结论 | 这次验收怎么查、查完记什么 |
| DoD（完成定义） | 团队对完成状态的通用约定 | 团队约定一类工作项在什么状态下才允许标记为完成 | 什么状态才允许叫完成 |
三者的分工可以概括为：验收标准是判断依据，验收清单是执行留痕，DoD是完成门槛。验收标准随需求变化，一条需求一套条件；验收清单随验收次数变化，一次验收一份记录；DoD相对稳定，在一段时间内对同类工作项统一生效。
边界：各自管到哪里、不管什么
划清边界比记住定义更有用，因为实际工作中出问题，往往是把一个概念该管的事交给了另一个概念。
- 验收标准与验收清单针对单项需求。它们服务于“这一条需求是否满足”的判断，换一条需求就要重新写标准、重新生成或选用清单。
- DoD针对一类工作项的通用完成条件。它不针对某条需求的具体业务效果，而是约定需求、任务、缺陷等同类工作项在流转到“完成”之前必须满足的共性条件。
- 产品整体效果验证不属本文范围。需求上线后是否带来预期的业务指标变化，属于产品效果评估，需要另行设计验证方式。
- 项目整体验收与收尾不属本文范围。项目层面的交付确认、合同验收、结项归档，涉及范围、进度、成本的综合判断，与单条需求的验收不是同一层事务。
- 三者不能互相替代。用DoD代替验收标准，会漏掉每条需求特有的业务条件；用验收清单代替验收标准，会让核对失去判定依据；用验收标准代替清单，则验收过程没有逐项留痕，无法追溯是谁在什么时间核对了什么。
各自应记录的字段
字段设计的目标是让记录可执行、可核对、可追溯。以下字段属于通用管理方法，可按团队实际情况增减。
需求验收标准应记录的字段
- 条件描述：用可观察的行为或结果描述满足状态，例如“提交订单后，库存数量在3秒内扣减”。
- 判定方式：说明如何确认，例如人工操作验证、数据比对、接口返回检查。
- 阈值或样例：涉及数量、时间、比例时给出具体数值；涉及界面或文案时附样例或截图说明。
- 来源依据：标注条件来自哪次需求评审、哪份业务规则或哪个干系人确认，便于后续追溯变更。
需求验收清单应记录的字段
- 核对项：从验收标准拆出的可逐项勾选的条目，一条标准可对应多个核对项。
- 对应标准条款：标明该核对项对应哪条验收标准，避免清单与标准脱节。
- 核对人：实际执行核对的人，便于责任追溯。
- 核对时间：记录核对发生的日期，必要时精确到时段。
- 核对结果：通过、不通过、部分通过等明确结论。
- 证据链接：指向截图、日志、测试记录或演示录屏的位置，让结论有据可查。
DoD应记录的字段
- 适用工作项类型：明确这份DoD适用于需求、任务、缺陷中的哪一类，避免跨类型套用。
- 完成条件条目：逐条列出共性条件，例如代码已合并、自动化测试通过、文档已更新、验收标准已逐项核对。
- 生效范围与例外：说明在哪些团队、哪些项目或哪些阶段生效；确有例外时写明例外情形和审批方式。
三类记录之间存在引用关系：验收清单的每个核对项引用验收标准的条款，DoD中的“验收标准已核对”条目又引用验收清单的完成状态。这种引用让判断依据、执行记录和完成门槛串成一条可追溯的链。
三者如何配合：从需求提出到验收关闭
三者的配合体现在顺序上：先有标准，再有门槛，最后有核对记录。
- 需求提出时写验收标准。在需求评审阶段就把合格条件写清楚，与业务方确认来源依据。标准缺失的需求不进入开发排期，避免做完再补判定条件。
- 进入开发前确认DoD适用。团队确认这条需求作为工作项适用哪份DoD，明确完成前必须满足的共性条件。DoD不通过，需求不进入验收环节，例如测试未通过或文档未更新时，应先回到开发处理。
- 验收时按标准生成或选用清单逐项核对。依据验收标准拆出核对项，指定核对人，逐项执行并记录结果。核对项与标准条款一一对应，避免漏检。
- 核对结果回写并作为关闭依据。全部核对项通过且证据齐全，需求才可关闭；存在不通过项时，记录问题并退回处理，处理完成后重新核对。
在这个流程里，DoD是进入验收的前置门槛，验收标准是验收中的判定依据，验收清单是验收后的留痕载体。三者各管一段，缺一段就会出现“做完了但说不清是否合格”或“验收了但查不到依据”的情况。
当需求、任务、测试与缺陷需要在同一套流程中流转时，工具承载方式会影响记录能否连贯。ONES通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，构建需求—任务—测试—缺陷的全流程闭环，并配套用例库、测试计划、缺陷管理与报告生成等功能。对本文讨论的管理动作而言，这意味着验收标准可以随需求工作项一起维护，验收核对结果与测试、缺陷记录在同一闭环中衔接，关闭状态有据可依。具体字段名称与流程节点配置以实际部署为准。
相邻概念区别：验收标准、验收清单、DoD与测试用例、项目验收
除了三者之间，还有几个概念常被混用。区分的关键仍是看记录对象和服务目的。
| 对比 | 区别要点 |
|---|---|
| 验收标准与测试用例 | 验收标准记录“满足什么条件算合格”，面向业务判定；测试用例记录“用什么步骤和输入验证某个行为”，面向技术验证。测试用例可以覆盖验收标准，但验收标准中的业务条件未必都能写成自动化用例。 |
| 验收清单与测试报告 | 验收清单是逐项核对的执行记录，强调核对人、时间和证据；测试报告是对一轮测试结果的汇总分析，强调通过率、缺陷分布和结论。清单服务于单条需求的验收关闭，报告服务于质量评估。 |
| DoD与验收标准 | DoD是一类工作项的通用完成门槛，对所有同类工作项生效；验收标准是单条需求的合格条件，随需求不同而变化。DoD回答“能不能叫完成”，验收标准回答“这条需求合不合格”。 |
| 单项需求验收与项目验收 | 单项需求验收判断一条需求是否满足其验收标准；项目验收判断项目整体交付是否达到约定范围和要求，涉及范围、进度、成本的综合确认。前者是后者的输入之一，但不能互相替代。 |
具体例子与常见误解
以下示例为演示情景，用于说明三类记录各自写什么，不作为真实案例引用。
一个需求的验收标准
需求：会员用户在结算页可以使用积分抵扣订单金额。验收标准可写为：
- 积分抵扣入口仅对会员等级达到V2及以上的用户展示，非会员不展示（判定方式：分别用两类账号登录核对，附截图）。
- 抵扣金额按100积分抵1元计算，单笔订单抵扣上限为订单金额的20%（判定方式：构造边界订单数据比对计算结果）。
- 抵扣后应付金额实时刷新，刷新时间不超过2秒（判定方式：多次操作记录响应时间）。
- 条件来源：2024年第三季度会员权益评审会议纪要。
同一需求的验收清单
- 核对项1：非会员账号结算页无积分抵扣入口；对应标准第1条；核对人：测试A；时间：验收当日；结果：通过；证据：截图链接。
- 核对项2：V2会员账号可见入口且可正常抵扣；对应标准第1条；核对人：测试A；结果：通过；证据：操作录屏。
- 核对项3：抵扣上限20%在边界订单上生效；对应标准第2条；核对人：产品B；结果：通过；证据：数据比对表。
- 核对项4：应付金额刷新时间在2秒内；对应标准第3条；核对人：测试A；结果：部分通过，弱网环境下超过2秒；证据：响应时间日志；处理：记录问题并退回。
团队DoD条目示例
- 适用工作项类型：需求。
- 完成条件：代码已合并至主干；相关自动化测试通过；需求文档与验收标准已更新；验收清单全部核对项通过且证据齐全；无未关闭的阻断级缺陷。
- 生效范围：研发一组当前迭代起生效；例外情形需经技术负责人确认并记录原因。
常见误解
- 把DoD当验收标准。DoD只说明“测试通过、文档更新”这类共性条件，无法说明这条需求的业务效果是否达标。只满足DoD的需求，仍可能不满足验收标准。
- 把清单当标准。清单是核对动作的记录，本身不定义合格条件。若清单条目没有引用标准条款，核对就失去判定依据，容易出现“勾完了但不知道算不算合格”。
- 验收后不记录证据。只写“通过”而不留截图、日志或数据比对结果，后续出现争议时无法追溯，也无法支撑需求关闭的合理性。
把这三类记录分开维护并建立引用关系，需求验收就从口头确认变成可查证的闭环：标准说明依据，清单说明过程，DoD守住完成门槛。
常见问题
验收标准写得很细，是否还需要单独维护验收清单？
需要。验收标准记录的是“满足什么条件算合格”，属于判定依据；验收清单记录的是“这次由谁、在什么时间、核对了哪一项、结果如何、证据在哪”，属于执行留痕。一条标准可能对应多个核对项，同一标准在不同轮次验收中也会产生不同记录。把两者合并，后续追溯时只能看到条件，看不到核对过程。
DoD已经要求“验收标准已核对”，是否意味着每条需求不用再写验收标准？
不能这样理解。DoD中的“验收标准已核对”是一条通用完成条件，它要求存在并执行了验收标准，本身并不提供任何一条具体需求的合格条件。如果需求没有写验收标准，这条DoD条目就无从核对。实际操作中，DoD守住完成门槛，验收标准提供判定内容，两者配合使用。
需求验收不通过时，清单记录应该怎么处理？
建议保留本轮清单记录，把不通过的核对项标注结果、证据和问题描述，然后退回处理。处理完成后重新核对时，可以新增一轮记录或更新原条目，并保留历史版本。直接覆盖原记录会让“曾经不通过、后来如何修复”的过程消失，后续出现争议时缺少依据。
团队规模较小、需求数量不多时，三类记录能否简化？
可以按实际情况简化字段，但三类记录的分工不宜合并。小团队可以把验收标准直接写在需求描述里，把清单做成简单表格，DoD用一页文档约定共性条件。简化的是字段数量和工具形式，保留的是“判定依据、执行留痕、完成门槛”三种不同记录对象。是否简化取决于团队对追溯精度的要求，没有统一标准。
验收标准在开发过程中发生变更，清单和DoD需要同步调整吗？
验收标准变更后，清单中引用该标准的核对项需要同步更新，否则核对会依据旧条件执行。DoD通常不需要因单条需求的业务条件变化而调整，除非变更涉及共性完成条件，例如新增了必须通过的评审环节。变更时建议在标准中记录来源依据和变更时间，便于核对人确认使用的是最新版本。
