单项需求验收标准判断的是“这一条需求交付后是否满足它自己的业务条件”，通常由该需求的验收条件、场景和预期结果构成；完成定义DoD判断的是“一项工作是否达到团队约定的完成状态”，是跨需求复用的通用门槛。两者是交集关系：一条需求要算真正完成，既要满足DoD，也要满足它自己的验收标准。项目整体验收则针对项目交付物和项目目标，不属于单项需求层面。
要点总览（TL;DR）
- 单项需求验收标准由触发条件、操作或输入、可观察的预期结果、边界与异常情况四类要素构成，逐条对应具体需求。
- 完成定义DoD是团队对工作项达到完成状态的通用条件集合，可按团队级、迭代级、工作项类型级分层，对同类工作项重复适用。
- 两者的边界在判定对象、来源和复用方式：验收标准判定一条需求的业务满足，DoD判定一类工作的完成状态；需求真正完成需同时通过两层判定。
- 项目整体验收针对交付物、项目目标与合同或立项约定，产品效果评估关注上线后的价值实现，二者都不替代单项需求验收。
- 把测试通过、代码合并当作验收标准，或把特殊业务条件塞进DoD，都会让两层判定失效；在需求评审阶段分开定义、分开核对是可行做法。
单项需求验收标准包含哪些要素
单项需求验收标准是对“这条需求算不算被满足”的判定条件。它从需求描述或用户故事出发，把业务方期望的结果转成可观察、可核对的条目。需求描述说明“要做什么”，验收标准说明“做到什么程度算满足”，两者配合使用，缺一不可。
一条完整的验收标准通常包含以下要素，每项要素回答一个具体问题：
| 要素 | 回答的问题 | 示例表述 |
|---|---|---|
| 触发条件或前置状态 | 在什么条件下这条需求才会被使用或验证？ | 用户已登录且账户处于正常状态时 |
| 操作或输入 | 用户或系统执行了什么动作、提供了什么数据？ | 在订单页提交一笔金额超过500元的订单 |
| 可观察的预期结果 | 动作完成后，业务上应看到什么结果？ | 系统生成待审核记录，并提示预计审核时长 |
| 边界与异常情况 | 在临界值、异常输入或失败路径下应如何处理？ | 金额恰好500元时不触发审核；提交失败时保留已填信息 |
这四个要素合在一起，构成对一条需求是否满足的完整判定。缺少触发条件，验收时无法复现场景；缺少预期结果，判定只能靠主观感觉；缺少边界与异常，需求在上线后容易在临界情况下暴露问题。验收标准逐条对应具体需求，不同需求的验收标准通常不能互换。
完成定义DoD是什么，覆盖到哪一层
完成定义DoD（Definition of Done）是团队对“一项工作达到完成状态”所约定的通用条件集合。它回答的问题与具体业务无关：这项工作在工程和管理上是否已经收尾到可以标记完成的程度。典型条目包括代码已通过评审、自动化测试通过、相关文档或变更记录已更新、变更已合并或部署到约定环境等。
DoD具有层级差异，不同层级可以有不同的条件集合：
- 团队级DoD：整个团队共同遵守的完成底线，适用于团队承接的所有工作项。
- 迭代级DoD：针对某个迭代的额外约定，例如本迭代要求所有变更完成回归测试。
- 工作项类型级DoD：按工作项类型区分，缺陷修复与需求开发的完成条件可能不同。
无论哪个层级，DoD都服务于“完成状态”判定，并且对同类工作项重复适用。它的价值在于把工程与管理上的收尾动作固化为统一门槛，避免同一类工作在不同人手里完成标准不一。DoD条目应当保持通用和精简，条目越多、越具体，越容易失去跨需求复用的意义。
两者的边界：判定对象、来源与复用方式
区分单项需求验收标准与DoD，最有效的方式是用同一组口径对照。两者的核心差异在于判定对象：验收标准判定一条具体需求的业务满足，DoD判定一类工作项的完成状态。由此派生出来源和复用方式的不同。
| 对照口径 | 单项需求验收标准 | 完成定义DoD |
|---|---|---|
| 判定对象 | 这一条需求交付后是否满足它自己的业务条件 | 一项工作是否达到团队约定的完成状态 |
| 来源 | 该需求的业务方、使用场景与预期结果 | 团队的工程实践与管理约定 |
| 复用方式 | 逐条需求单独定义，通常不跨需求复用 | 跨需求、跨工作项复用，同类工作共用一套 |
| 回答的问题 | 业务上做对了吗？ | 工程和管理上收尾了吗？ |
| 缺失后的后果 | 无法判断需求是否真正满足业务期望 | 同类工作的完成质量参差不齐 |
两者是交集关系，而非替代关系。一条需求要算真正完成，需要同时通过两层判定：先满足DoD，确认代码评审、测试、文档等通用门槛已过；再对照该需求的验收标准，确认业务条件已满足。只过DoD，需求可能“工程上完成了但业务上没做对”；只过验收标准，需求可能“业务上验证了但工程收尾不完整”。在需求评审时把两层判定分开写、分开核对，可以避免验收时反复拉扯。
在工具承载上，这两层判定可以落在同一条需求工作项的不同位置：验收条件作为需求内容的一部分随需求流转，DoD检查则体现在完成状态的流转与评审动作中。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，并以任务和工单串联需求—任务—测试—缺陷的闭环，使需求从提出到验证的过程可追踪；团队还可以通过模板、权限和流程配置约定工作项的流转方式，让通用完成门槛与单条需求的验收条件各归其位。
与项目整体验收标准的区别
单项需求验收标准之上还有项目整体验收标准，两者回答的问题不同，归属范围也不同。项目整体验收针对项目交付物、项目目标以及合同或立项约定，回答“这个项目是否可交付”；单项需求验收标准只回答“这一条需求是否满足”，不承担项目目标是否达成的判定。
可以把验收对象分为三层来理解：
- 单项需求层：这条需求是否满足其业务条件，依据是该需求的验收标准。
- 项目整体层：项目交付物是否齐全、项目目标是否达成、是否符合合同或立项约定，依据是项目验收标准。
- 产品效果层：产品上线后的使用效果与业务价值是否达到预期，属于另一层判断，通常在上线后通过数据与反馈评估。
三层之间是逐层支撑的关系：单项需求验收通过是项目整体验收的基础之一，但项目整体验收还涉及交付物完整性、目标达成度等更广的条件；产品效果评估则发生在交付之后，关注的是价值实现。把三层混在一起，常见的结果是需求验收时被要求证明项目价值，或者项目验收时才发现单条需求的业务条件从未被核对。
一个具体例子与常见误解
假设一条需求是“订单金额超过500元时进入人工审核”。它的验收标准可以写成：用户已登录且账户正常时，提交金额超过500元的订单，系统生成待审核记录并提示预计审核时长；金额恰好500元时不触发审核；提交失败时保留已填信息。团队DoD则可能是：代码通过评审、自动化测试通过、变更记录已更新、已合并到约定分支。验收时，先核对DoD条目是否全部满足，再按验收标准逐条验证业务行为，两层都通过，这条需求才算完成。
围绕这个例子，有三类常见误解需要纠正：
- 把“测试通过、代码合并”当作该需求的验收标准。这些是DoD条目，说明工程收尾到位，并不能证明“超过500元进入审核、恰好500元不触发”这些业务条件成立。用DoD替代验收标准，会让需求在业务上是否做对失去判定依据。
- 把某条需求的特殊业务条件写进DoD。例如把“订单审核提示文案正确”加入团队DoD，看似严谨，实则让DoD随需求不断膨胀，最终每条需求都要对照一长串与本需求无关的条目，DoD失去通用门槛的作用。特殊业务条件应留在该需求的验收标准里。
- 用项目整体验收替代单项需求验收。项目验收通过只说明交付物整体可交付，不能反推每条需求的业务条件都已被逐条核对。单项需求的验收应在需求层面完成，项目验收在此基础上进行。
把两层判定分开定义、分开核对，并在需求评审阶段就明确哪些条件属于本条需求、哪些属于团队通用门槛，是避免混用的直接做法。需求数量较多时，可以借助 ONES 的需求池与需求—任务—测试—缺陷闭环，让每条需求的验收条件随工作项流转、验证结果有据可查，减少验收阶段的反复确认。
常见问题
一条需求的验收标准写几条比较合适？
条数没有统一规定，判断依据是覆盖是否完整。一条需求通常围绕一个业务目标，验收标准以能完整判定“这条需求是否满足”为准：触发条件、操作或输入、预期结果、边界与异常各至少有一条对应。如果一条需求包含多个相互独立的业务结果，可以考虑拆成多条需求，让每条需求的验收标准保持聚焦，验收时也更容易逐条核对。
团队DoD条目越来越多，怎么控制？
先检查新增条目是否对同类工作项普遍适用。只对某条需求成立的业务条件，应留在该需求的验收标准里；只有所有同类工作项都必须满足的工程与管理门槛，才进入DoD。可以定期回看DoD条目，把长期无人核对或已被自动化覆盖的条目合并或移除。DoD保持精简，才能在每次完成状态流转时被真正执行。
需求先过验收标准还是先过DoD？
通常先过DoD，再对照验收标准做业务验证。DoD确认代码评审、测试、文档、合并部署等工程收尾动作已完成，此时交付物具备被验证的条件；随后按验收标准逐条核对业务行为。顺序反过来也能做，但可能出现在工程尚未收尾时反复验证业务行为的情况。团队可以在流程中约定核对顺序，关键是两层都要过，缺一层都不算真正完成。
缺陷修复需要单独写验收标准吗？
需要，但形式可以简化。缺陷的验收标准通常包括复现条件、修复后的预期表现以及相关场景是否受影响，本质仍是判定“这个问题是否被真正解决”。缺陷类工作项的DoD可能与需求开发不同，例如要求补充回归用例。把缺陷的验收条件写清楚，可以避免出现“状态已关闭但问题仍能复现”的情况。
项目整体验收通过，能否说明每条需求都已验收？
不能直接等同。项目整体验收关注交付物完整性、项目目标达成和合同或立项约定，单项需求的业务条件是否逐条核对，需要在需求层面留下记录。实际操作中，可以在项目验收前先完成各需求的验收核对，把需求验收结果作为项目验收的支撑材料之一，减少项目收尾阶段才发现个别需求条件未验证的情况。
