确定需求验收条件，是把“做完”这类模糊表述转成可观察、可判定、可追溯的检查项。做法是先锁定需求对象与范围，再按业务规则、边界异常、数据与权限、非功能约束拆出场景，为每个场景写清前置条件、操作、预期结果和判定依据，最后由需求方、开发、测试三方评审并挂到需求条目上，作为开发完成与验收共用的判定口径。
要点总览（TL;DR）
- 验收条件要判定四类内容：业务结果、规则约束、异常处理和非功能要求；需求是否值得做、架构与界面设计不在其中展开。
- 拆场景以需求条目、业务规则、角色与数据约束为输入，按正常路径、边界值、异常失败、权限与数据状态四个维度展开，每条场景写清前置条件、操作、预期结果和判定依据。
- 书写采用给定—当—则结构，预期结果落到界面状态、数据值、消息、日志或接口返回；把“友好”“快速”“合理”改写成带阈值、单位和取数时点的表述。
- 需求方提出初稿并负责业务规则，开发补充技术边界，测试检查可验证性，评审输出确认版条件、遗留问题清单和责任人。
- 需求变更时同步更新验收条件并保持与需求条目、测试用例的追溯；无法判定或缺少判定依据的条件不得进入开发完成状态。
先明确验收条件要判定什么
验收条件是需求条目上的一组判定语句，用来回答“这条需求做到什么程度算完成”。它介于需求描述与测试用例之间：需求描述说明要解决什么问题、服务谁；验收条件把需求收敛为可判定的结果口径；测试用例则在此基础上补充具体数据、步骤组合和执行细节。三者分工不同，验收条件不替代需求背景说明，也不承担测试脚本的职责。
一条需求的验收条件通常需要覆盖四类判定对象：
- 业务结果：用户完成某个动作后，业务上应产生的结果，例如订单状态变为“已提交”、审批流转到下一节点。
- 规则约束：业务规则对输入和结果的限制，例如金额上限、可用范围、状态流转顺序。
- 异常处理：输入不合法、依赖服务失败、重复提交等情况下系统应给出的反馈与状态。
- 非功能要求：与需求直接相关的响应时间、并发量、数据保留期限、权限隔离等可测量约束。
以下内容属于需求分析阶段的澄清工作，不在验收条件中展开：需求是否值得做、业务规则本身是否合理、系统架构如何设计、界面如何布局。验收条件只对已经确认的需求内容做判定口径的转化。若在写验收条件时发现业务规则缺失，应回到需求澄清，而不是用模糊措辞先填上。
本节的可交付物是一份判定范围清单：列出该需求涉及的业务结果、规则约束、异常处理和非功能要求各有哪些，作为后续拆解场景的输入。
从需求中拆出可判定的验收场景
拆解验收场景的输入包括四项：需求条目原文、相关业务规则、涉及的角色、以及数据与状态约束。缺少任何一项，拆出的场景都容易漏掉关键分支。操作上，先确认需求的主流程，再沿四个维度展开。
| 拆解维度 | 关注点 | 典型场景来源 |
|---|---|---|
| 正常路径 | 主流程走通后的业务结果 | 需求描述中的核心动作 |
| 边界值 | 数量、金额、时间、长度的临界点 | 业务规则中的阈值与限制 |
| 异常与失败路径 | 非法输入、依赖失败、重复操作 | 规则约束的反面情况 |
| 权限与数据状态 | 不同角色可见可做的范围、数据所处状态 | 角色清单与状态流转规则 |
每个场景按四要素填写：前置条件说明场景开始前的数据与角色状态；操作描述执行了什么动作；预期结果写清可观察到的结果；判定依据说明依据哪条业务规则或哪份需求内容判定通过。四要素齐全，场景才具备被不同角色一致理解的基础。
完成标志是：每条需求至少有一个可判定的正常路径场景，且边界、异常、权限维度中凡需求明确涉及的部分都有对应场景。若某维度经确认不适用，在拆解表中注明原因，避免评审时反复追问。
把验收条件写成可执行的判定语句
推荐采用“给定—当—则”结构，或等价的条件—动作—预期格式。这种结构把场景背景、触发动作和判定结果分开，开发和测试读到的口径一致。示例模板如下：
- 给定：前置条件，包括角色、数据状态、已有记录。
- 当：执行的操作或触发的事件。
- 则：可观察的预期结果，以及判定依据。
预期结果要落在可观察的对象上：界面状态变化、数据字段的具体值、系统消息文案、日志记录、接口返回码与返回内容。写“提示成功”不如写“页面顶部出现成功提示，订单状态字段变为‘已提交’，列表中该订单不再显示编辑按钮”。
不可判定措辞的改写方法：把形容词换成可测量的条件。“友好”改写为具体的提示位置、文案和可操作项；“快速”改写为带阈值和取数时点的表述，例如“在常规网络条件下，提交后 2 秒内返回结果”；“合理”改写为引用具体业务规则条款。数值型条件要写清阈值、单位、取数时点和统计口径，例如“单笔金额不超过 5000 元，以提交时订单金额为准”，避免评审时对口径产生分歧。
改写前后对照示例：
| 原始表述 | 改写后的判定语句 |
|---|---|
| 提交后系统快速给出反馈 | 给定用户已填写完整表单，当点击提交，则 2 秒内页面显示提交结果，成功时订单状态为“已提交” |
| 金额填写要合理 | 给定单笔订单，当输入金额超过 5000 元，则提交按钮不可用并提示“单笔金额不得超过 5000 元” |
| 权限控制要友好 | 给定只读角色，当访问编辑入口，则编辑按钮不显示，直接访问编辑地址返回无权限提示 |
角色分工与评审确认
验收条件由需求方提出初稿，开发与测试在评审中补充，三方共同确认。分工按各自掌握的信息划分，避免一方包办。
- 需求方：负责业务规则与预期结果，说明每条条件背后的业务意图，确认判定口径符合业务预期。
- 开发：负责技术可行性与边界补充，指出实现上可能出现的中间状态、依赖失败和性能约束，补充对应场景。
- 测试：负责可验证性与覆盖缺口，检查每条条件是否可观察、是否缺少异常路径和权限场景，提出补充项。
评审的输出应包含三部分：确认版验收条件，逐条记录确认结论；遗留问题清单，写明尚未达成一致的条件和原因；责任人与处理时限，确保遗留项在开发开始前闭环。评审记录与需求条目放在一起，后续变更时可直接对照。
完整示例：一条需求如何形成验收条件
原始需求描述：“支持员工提交报销单，审批人审批后财务打款。”其中的模糊点包括：报销单包含哪些必填信息、金额有无上限、审批人如何确定、审批被驳回后如何处理、打款失败如何反馈。
拆出的场景与四要素填写如下：
| 场景 | 前置条件 | 操作 | 预期结果 | 判定依据 |
|---|---|---|---|---|
| 正常提交 | 员工已登录，报销单信息完整 | 点击提交 | 单据状态变为“待审批”，审批人收到待办 | 需求主流程 |
| 金额边界 | 单笔金额上限 5000 元 | 输入 5001 元并提交 | 提交被拦截，提示金额超限 | 财务报销规则 |
| 审批驳回 | 单据处于“待审批” | 审批人点击驳回并填写原因 | 单据状态变为“已驳回”，员工可查看驳回原因并修改重提 | 审批流程规则 |
| 权限隔离 | 非审批人角色 | 访问审批入口 | 入口不可见，直接访问返回无权限提示 | 角色权限规则 |
改写后的判定语句示例：“给定员工已登录且报销单信息完整，当点击提交，则单据状态变为‘待审批’，对应审批人待办列表中出现该单据，列表显示提交时间。”
评审中补充的边界与遗留项：打款失败时的重试与通知方式尚未确认，列为遗留问题，由财务方在开发开始前给出规则；审批人休假时的转交规则同样待定。这两项在确认前不进入开发完成判定。
验收条件的维护与完成检查
需求变更时，验收条件同步更新，更新规则是：需求内容变化则对应场景重写；仅表述调整则核对判定依据是否仍成立；新增业务规则则补充边界与异常场景。每次变更在需求条目上留下版本记录，说明改了哪条条件、依据什么变更。
验收条件、需求条目与测试用例之间保持追溯关系：每条验收条件能对应到需求条目，测试用例能追溯到所覆盖的验收条件。这样在需求变更时，可以快速定位受影响的用例，避免出现需求已改、测试仍按旧口径执行的情况。
在工具承载上，ONES 通过统一的业务需求池、产品需求池与工单系统构建需求—任务—测试—缺陷的全流程闭环，并配套用例库、测试计划、缺陷管理与报告生成等功能。验收条件作为需求条目的一部分挂在需求上，测试用例在用例库中与需求关联，评审确认与变更记录随需求状态流转保留，便于开发完成判定和验收时对照同一份口径。
交付前的完成检查表：
| 检查项 | 通过标准 |
|---|---|
| 可判定 | 每条条件都有明确的预期结果，不含“友好”“快速”“合理”等措辞 |
| 有判定依据 | 每条条件能指向具体业务规则或需求内容 |
| 经三方确认 | 需求方、开发、测试均已在评审记录中确认 |
| 覆盖异常路径 | 需求涉及的边界、异常、权限场景均有对应条件 |
| 可追溯 | 验收条件与需求条目、测试用例的关联关系完整 |
阻断项：无法判定或缺少判定依据的条件不得进入开发完成状态。这类条件应退回需求澄清或评审环节处理，待补齐后再纳入完成判定。
常见问题
一条需求要写多少条验收条件才算够？
数量由需求涉及的分支决定，没有固定条数。判断标准是覆盖度：至少有一条正常路径场景，需求明确涉及的边界值、异常失败、权限与数据状态都要有对应条件。若某个维度经确认不适用，在拆解表中注明原因即可。反过来，条件写得过多、把测试用例的步骤组合也搬进来，会让验收口径变得难以维护，执行细节留给测试用例补充更合适。
业务规则本身还没定清楚，能先写验收条件吗？
可以先写出已知部分，但涉及未定规则的条件要标记为待确认，不能先用模糊措辞占位。例如报销金额上限尚未确定时，不要写“金额需合理”，而应记录“金额上限规则待财务确认”，并明确责任人和确认时限。这类条件在规则确认前不纳入开发完成判定，否则开发和测试会各自按理解实现，返工成本更高。
验收条件和测试用例的边界在哪里，会不会重复维护？
验收条件回答“做到什么程度算完成”，用业务语言描述可判定的结果；测试用例回答“怎么验证”，包含具体测试数据、步骤组合和执行顺序。一条验收条件通常对应多条测试用例。维护上让用例追溯到所覆盖的验收条件，需求变更时先改验收条件，再据此定位受影响的用例，避免两边各改一套口径。
需求上线后才发现验收条件漏了异常场景，怎么处理？
先评估遗漏场景的影响范围：是否已有用户遇到、是否造成数据错误、是否涉及资金或权限。影响明确的，作为缺陷或补充需求进入排期，同时把该场景补进验收条件并关联对应测试用例。复盘时检查拆解环节漏在哪一维度，是输入信息缺失还是评审时未追问，把结论写进下次评审的检查项，减少同类遗漏。
验收条件放在需求文档里还是工具的需求条目上？
两种方式都能用，差别在于变更时能否同步。放在工具的需求条目上，验收条件随需求状态流转，评审记录和变更历史与需求放在一起，测试用例也能直接关联到同一处。ONES 通过业务需求池、产品需求池与工单系统构建需求—任务—测试—缺陷的闭环，并配套用例库、测试计划与缺陷管理，验收条件可作为需求条目的一部分保留，测试用例在用例库中与需求关联，便于开发完成判定和验收时对照同一份口径。具体字段与关联方式需按团队实际配置确认。
