掌握系统用例设计的5个秘诀：从新手到专家的必经之路

系统用例设计最容易被误解的地方，是大家以为“把几个角色和椭圆画在图上”就完成了需求分析。我的经验是，真正让项目返工的，通常不是用例图画错，而是用例没有回答清楚三个问题：谁要通过系统完成什么目标、系统在什么条件下必须如何响应、出现异常时业务结果是什么。掌握系统用例设计的5个秘诀，关键不是从会画图变成会画复杂图，而是把模糊需求转化成开发、测试和验收都能使用的行为说明。

如果一份用例只能让产品经理看懂，却无法让开发人员确定实现范围，也无法让测试人员推导测试场景，那么它仍然只是沟通草稿。下面我会以在线请假审批系统为主案例，拆解参与者、系统边界、业务流程、用例粒度和需求追踪五个关键环节，并说明不同规模团队在详细程度、工具投入和流程控制上的取舍。

一、先讲核心结论：高质量用例必须同时满足四个条件

1. 用例不是功能清单，而是参与者的业务目标

“登录、查询、提交、导出”这些词可以出现在功能菜单里，但它们不一定天然构成好的用例。用例描述的是外部参与者通过系统完成的一个有价值目标，例如“提交请假申请”“审批请假申请”“撤回未审批申请”。这些目标能够产生明确业务结果，也能够被独立讨论、开发和测试。

判断一个候选用例是否成立，我通常会问一句话：这个参与者完成该行为后，是否获得了一个可以确认的业务结果？如果答案是否定的，它可能只是页面操作、内部步骤或技术实现，而不是用户目标。

2. 用例必须有边界，而不是把整个业务部门都画进去

系统边界决定了用例设计的有效范围。在线请假审批系统负责记录申请、校验规则、路由审批、保存结果和发送通知；人事制度的制定、主管的主观判断、员工是否真正休假，则不属于系统本身负责的行为。

边界模糊时，团队会出现两种相反问题。一种是把数据库、消息队列、审批服务等内部组件都画成参与者，导致业务视角被技术结构淹没。另一种是把考勤、薪资、组织架构、假期政策全部塞进一个“请假系统”，最终没有人知道本期究竟要交付什么。

3. 主成功场景只是起点，异常流程决定用例能否落地

很多初稿只有这样的流程：“员工填写信息，点击提交，系统保存，主管审批，通知员工。”这条路径能够说明理想情况，却没有说明真正影响开发和验收的条件：假期余额不足怎么办？主管不在职怎么办？重复提交如何处理？通知发送失败是否影响审批结果？申请时间跨越多个规则周期时如何校验？

我在需求评审中更关注异常路径，因为主流程通常人人都能补出来，异常路径才暴露业务规则是否真的被理解。一个可执行的用例，至少要覆盖高频替代流程、关键业务拒绝和会造成数据风险的系统异常。

4. 用例最终要连接需求、开发、测试和验收

用例不是分析师的私有文档。它应当成为一条可追踪链路的中间节点：上游连接业务需求，下游连接开发任务、测试场景和验收条件。需求变更时，团队能够知道哪些用例受影响；用例调整后，测试人员能够知道哪些场景需要重新验证。

我对用例质量的核心判断是：清不清楚、全不完整、能不能做、测不测试。这四个问题比“有没有使用某种建模软件”更能判断用例是否有工程价值。

二、真实场景：为什么一句“员工可以申请休假”会引发多轮返工

1. 从一句话需求开始拆解

假设业务部门提出的原始需求是：“员工可以在系统中申请休假，主管审批后通知员工。”这句话看起来足够明确，实际上至少隐藏了参与者、权限、规则、状态、通知和异常处理六组问题。

• 员工可以申请哪些假期类型？
• 申请日期是否允许早于当前日期？
• 半天假、跨月假和节假日如何计算？
• 直属主管由谁确定，主管离职或请假时由谁审批？
• 主管拒绝申请是否必须填写原因？
• 通知发送失败时，审批状态是否仍然生效？
• 员工提交后能否撤回，撤回的时间窗口是什么？
• 同一时间段重复申请由系统拦截，还是允许并行审批？

如果这些问题没有在用例阶段暴露，开发人员就会根据自己的理解实现。产品经理以为“通知失败不影响审批”，开发人员却把通知发送作为同步事务的一部分；测试人员以为“余额不足必须禁止提交”，业务方却允许先提交后由人事复核。表面看是实现偏差，本质上是用例没有把业务决策写出来。

2. 识别参与者：角色不是组织名称

在这个案例中，主要参与者包括员工和直属主管，次要参与者包括消息通知服务、组织架构服务和权限系统。需要注意的是，“人事部门”可能是业务利益相关者，也可能是实际参与者，取决于他们是否直接通过当前系统发起或接收交互。

例如，如果人事人员只负责维护假期规则，不直接参与“提交请假申请”，那么人事部门可以作为利益相关者，而不必强行画成该用例的参与者。如果组织架构服务向系统提供直属主管信息，它就是外部系统参与者；如果组织架构数据已经属于当前系统内部模块，就不应该在业务用例图中单独作为外部参与者。

3. 把需求转成可验证的用例集合

经过拆解后，原始需求至少可以形成四个用户目标层级的用例：提交请假申请、审批请假申请、查询申请状态、撤回未审批申请。把所有行为都压缩成“请假管理”会使测试范围过大；把“输入开始日期”“点击保存”分别列为用例，又会把业务目标切碎。

我建议先做用户目标层级的粗建模，再补充用例规约。用例图负责回答“有哪些目标和关系”，用例规约负责回答“每个目标如何完成”。不要试图把所有分支都塞进用例图，否则图形会变得难以阅读，且无法代替活动图、时序图和业务规则文档。

三、秘诀一：先识别参与者和目标，再开始画用例图

1. 用“角色，动作，结果”三步识别参与者

我通常不会在白板上直接问“系统有哪些用户”，因为这个问题容易得到部门名称或岗位名称。更有效的问法是：谁发起了行为？谁接收了系统结果？谁提供了系统依赖的信息？谁可以改变业务状态？按照这四个问题，可以快速发现普通用户、审批人、外部认证系统、第三方支付服务和定时任务等不同类型参与者。

参与者的本质是系统边界之外、能够与系统交换信息并获得价值的人或系统。它不一定是人，也不一定是登录用户。例如，定时任务可以触发“自动关闭超时订单”，外部支付服务可以返回支付结果，身份认证服务可以向当前系统提供认证结论。

2. 用业务目标命名，而不是用技术动作命名

好的用例名称通常使用“动词＋业务对象”的形式，例如“登记客户”“提交报销单”“审批采购申请”“确认收货”。这类名称天然包含动作和结果，便于产品、开发、测试和业务人员共同理解。

相反，“调用接口”“写入数据库”“刷新页面”“处理数据”都缺少外部价值。它们可以成为用例规约中的步骤，却不应在业务用例层面承担核心位置。一个实用的检查方法是：把名称放进句子“参与者希望通过系统……”中，如果读起来不自然，通常说明粒度或命名有问题。

3. 识别主要参与者与次要参与者

主要参与者是为了完成自身目标而发起用例的人或系统，次要参与者则是为用例提供服务、数据或外部结果的对象。请假案例中，员工是“提交请假申请”的主要参与者，直属主管是“审批请假申请”的主要参与者，消息服务则可能是通知环节的次要参与者。

这一区分有助于避免流程责任混乱。系统不是“主动审批”的主体，主管才是做出业务判断的人；通知服务也不是“决定申请是否通过”的主体，它只负责传递结果。用例设计如果把辅助服务和业务决策者放在同一层级，后续权限设计和验收边界都会变得模糊。

4. 适用不同项目规模的识别方法

• 小型项目：可通过一小时角色访谈和业务流程走查，先列出主要参与者和核心目标。
• 中型项目：建议按岗位、系统和事件三类建立参与者清单，再进行重复角色合并。
• 大型组织：应区分业务角色、组织角色、外部系统角色和监管角色，并记录每个角色的权限来源。
• 平台型产品：不要只按当前客户组织建模，还要考虑租户管理员、配置管理员和集成系统等长期角色。

我不建议一开始就追求参与者清单“完整无遗漏”。更稳妥的做法是先覆盖能改变业务状态的核心角色，再在流程评审中补充读取数据、提供数据和触发事件的辅助角色。

四、秘诀二：先画清系统边界，再决定哪些行为属于用例

1. 用一张边界表替代无休止争论

当团队对“某功能到底属于哪个系统”争论不休时，我会先建立边界表，而不是继续修改图形。边界表至少列出业务行为、当前系统是否负责、外部依赖、交付阶段和责任人。它能把抽象争论转化为范围决策。

2. 用例图、活动图和模块图各自解决不同问题

用例图适合展示系统外部角色和业务目标之间的关系，帮助团队建立范围共识。活动图适合展示流程分支和条件判断，时序图适合说明对象或服务之间的调用顺序，模块图则适合讨论系统内部结构。

如果把“审批服务”“数据库”“订单表”直接作为业务用例，团队就把技术结构和用户目标混在了一起。技术结构当然重要，但它应该在系统设计阶段被推导出来，而不是反过来定义业务用例。先确定系统要为谁完成什么目标，再讨论由哪些模块、接口和数据结构实现。

3. 处理跨系统边界的用例

跨系统场景最容易产生责任空档。例如请假系统将批准结果发送到考勤系统，考勤系统负责扣减出勤记录。此时“同步请假结果”可以是当前系统的一个用例或内部行为，取决于外部交互是否需要独立验收。如果同步失败需要重试、告警和人工补偿，就不应只在一句“系统自动同步”中带过。

对于跨系统用例，我会额外记录数据所有权、失败后的最终一致性策略、重试次数、人工介入入口和对账方式。这些内容不一定全部放进业务用例图，但必须在用例规约、接口协议或运行约束中留下可追踪记录。

4. 什么时候应该冻结边界

• 业务目标尚未确认时，不宜冻结边界，否则容易把猜测变成范围承诺。
• 核心参与者和主流程确定后，应冻结第一版边界，避免所有讨论无限扩散。
• 发现外部系统职责变化时，应通过变更记录调整边界，而不是直接覆盖原图。
• 涉及私有化部署、国产化替代或多租户交付时，应重新确认哪些能力由平台承担、哪些能力由客户环境承担。

对于中大型企业，若团队需要统一管理需求、用例、研发任务和测试证据，可以考虑使用支持私有化部署、权限分层和需求追踪的项目管理平台。以 PingCode 为例，它更适合 100 人以上组织在多团队协作、历史需求迁移和国产化部署场景下维护追踪关系；但工具不能替代边界决策，边界仍然必须由业务和技术负责人共同确认。

五、秘诀三：用主成功场景、替代流程和异常流程写完整行为

1. 主成功场景必须围绕业务结果展开

主成功场景不是页面点击说明书，而是系统与参与者共同完成业务目标的正常路径。以“提交请假申请”为例，可以这样写：

1. 员工选择请假类型并填写起止时间、时长和申请原因。
2. 系统校验员工身份、申请时间范围和请假类型规则。
3. 系统查询员工可用假期余额，并判断是否满足申请条件。
4. 系统生成待审批申请记录和唯一申请编号。
5. 系统根据组织架构确定直属主管，并将申请放入审批队列。
6. 系统向员工反馈提交成功，并向主管发送待审批通知。

这条流程没有绑定具体页面、接口或数据库表，但已经足以让开发人员理解核心行为，也能够让测试人员识别出身份校验、规则校验、余额校验、记录生成和通知发送等验证点。

2. 替代流程表达“同一目标的不同合法路径”

替代流程并不等于错误流程，它通常仍然能够完成原来的业务目标。例如，普通员工的请假申请由直属主管审批，部门负责人也可能拥有代理审批权限；员工可以从首页发起申请，也可以从个人考勤页面进入申请入口。这些路径不同，但目标仍是提交或审批请假申请。

在用例规约中，替代流程应当明确从主成功场景的哪一步分叉、触发条件是什么、最终是否回到主流程。这样做可以避免把每一个分支都新建成一个独立用例，也能让开发和测试知道不同路径之间的关系。

3. 异常流程要优先覆盖三类风险

第一类是业务规则拒绝，例如假期余额不足、申请时间不合法、审批人无权限。第二类是并发和重复操作，例如员工重复提交、主管同时处理同一申请、申请已经被撤回。第三类是外部依赖故障，例如组织架构查询超时、消息发送失败、考勤同步中断。

我不会要求初期用例把所有理论异常写完。更实用的优先级是：先覆盖高频异常，再覆盖会造成错误数据或合规风险的异常，最后补充低概率但高损失的灾难场景。异常流程的价值不是让文档变长，而是让系统行为在失败时仍然可预测。

4. 用例规约示例

下面是一份“提交请假申请”的简化规约。它没有追求把所有技术细节塞进来，而是保留了开发、测试和验收都需要的行为信息。

用例名称：提交请假申请
用例目标：员工提交符合规则的请假申请，进入审批流程

主要参与者：员工

次要参与者：组织架构服务、假期余额服务、消息通知服务

触发条件：员工选择“新建请假申请”

前置条件：

员工已完成身份认证；
员工处于有效在职状态；
请假规则和审批关系已配置。
主成功场景：

员工填写请假类型、时间范围和原因；
系统校验字段格式和时间范围；
系统查询员工可用余额；
系统创建待审批申请；
系统确定直属主管；
系统返回申请编号并发送待审批通知。
替代流程：

A1. 员工选择半天假，系统按半天规则计算时长；

A2. 直属主管不可用时，系统按照代理审批规则路由至代理人。

异常流程：

E1. 假期余额不足，系统拒绝提交并提示可用余额；

E2. 组织架构服务超时，系统不创建申请，提示稍后重试；

E3. 通知发送失败，申请保持待审批状态，并记录待补发任务。

后置条件：

成功时生成唯一申请记录；
失败时不得生成重复申请；
所有状态变化均保留操作人和时间。
验收条件：

合法申请能够生成唯一编号；
余额不足时不能进入待审批状态；
通知失败不改变申请的业务状态；
重复提交不会生成两条有效申请。

5. 如何判断异常流程写得够不够

我会把每个主流程步骤都问一遍：“这一步失败后，业务结果是什么？”如果回答只能是“系统提示错误”，说明规约还不完整。系统提示什么只是界面表现，更重要的是数据是否落库、状态是否改变、用户是否可以重试、是否需要人工补偿。

例如“通知发送失败”不能只写成“提示发送失败”。如果申请已经创建，系统是否允许主管在待审批列表中看到它？如果用户再次点击提交，是否会产生重复申请？如果消息服务恢复，是否会自动补发？这些问题决定了系统是否可靠，也决定了测试是否能够设计完整。

六、秘诀四：控制用例粒度，避免“管理一切”或“点击一切”

1. 粒度过粗会让开发和测试无从下手

“管理员管理用户”“财务处理报销”“系统管理订单”看似覆盖面很广，实际上没有明确触发条件、业务结果和结束边界。开发人员无法判断本期需要支持哪些动作，测试人员也无法知道应该验证创建、修改、禁用还是查询。

过粗用例适合在早期业务地图中作为能力域，但不适合直接作为需求交付单元。我的做法是保留它作为上层主题，再拆出能够独立完成和验收的用户目标，例如“创建用户”“调整用户角色”“禁用用户”“重置登录凭证”。

2. 粒度过细会把业务模型变成操作录屏

另一种极端是把“点击申请按钮”“选择下拉选项”“输入开始日期”“调用余额接口”分别写成用例。这样做的结果是文档看起来很详细，业务目标却被淹没了。页面改版、接口重构或技术方案替换后，大量用例都需要重写。

用例应尽量保持在业务目标层，而不是界面或代码层。界面字段、接口参数和数据库结构当然需要记录，但它们应放在交互设计、接口文档和技术设计中，并通过需求编号与用例关联。

3. 用四个问题确定合适粒度

• 参与者是否能用一句话说明这个用例要完成的目标？
• 用例是否能够产生一个明确的业务结果或状态变化？
• 开发人员是否可以据此拆分任务，而不必猜测范围？
• 测试人员是否可以据此设计正常、拒绝和异常场景？

如果四个问题中有两个以上无法回答，通常需要重新调整粒度。尤其要注意“是否能独立验收”，这是区分业务目标与页面步骤的有效标准。

4. include 与 extend 应该如何使用

在 UML 语义中，<<include>> 表示基础用例在完成过程中必然需要调用的公共行为；<<extend>> 表示在特定条件下对基础用例增加的可选或条件行为。两者不是简单的“复用”和“异常”按钮。

例如，“提交请假申请”每次都必须进行身份和权限校验，可以把一个稳定、独立且被多个用例重复调用的行为抽取为包含关系。但“撤回申请”并不是提交申请的可选内部步骤，它是员工在特定状态下发起的另一个用户目标，更适合作为独立用例。

我建议只有在行为具有稳定语义、确实被多个用例共享，并且单独抽取后能提高模型可读性时，才使用 include 或 extend。为了让图看起来“专业”而大量添加关系，往往会增加理解成本。

七、秘诀五：让用例连接需求、开发、测试和验收

1. 用例规约至少要有十二个字段

对于简单功能，可以使用简版模板；对于多人协作和跨系统项目，我建议至少保留以下字段：用例编号、名称、业务目标、主要参与者、次要参与者、触发条件、前置条件、后置条件、主成功场景、替代流程、异常流程、业务规则、非功能要求、验收条件、关联需求和关联测试用例。

字段多并不意味着每个字段都要写成长篇说明。一个好规约的标准是信息足够、语义稳定、方便评审，而不是字数越多越专业。对于尚未确定的内容，应明确标记待决策事项，不要用模糊句子掩盖不确定性。

2. 把业务规则写成可判断的条件

“系统要支持灵活审批”“用户只能申请合理日期”“操作要安全”都不是合格的业务规则，因为它们无法直接判断系统是否实现。更好的写法是把条件、行为和结果写完整。

• 当申请时长超过员工可用余额时，系统不得创建待审批申请。
• 当申请时间早于当前日期时，系统应拒绝提交，并提示允许的申请范围。
• 当审批人拒绝申请时，拒绝原因必须填写，且员工可在申请详情中查看。
• 当通知服务不可用时，申请状态保持原业务状态，系统记录补发任务。

业务规则应尽量避免把展示方式写死，除非展示方式本身就是验收重点。规则的核心是“在什么条件下允许或禁止什么行为”，而不是“页面必须弹出某种颜色的提示框”。

3. 将用例直接转成测试场景

一个成熟的用例规约，通常可以按照主流程、替代流程和异常流程生成测试场景。以“提交请假申请”为例，至少应有合法申请、余额不足、时间不合法、主管不存在、重复提交、外部服务超时和通知失败七类测试。

4. 用需求追踪降低变更遗漏

在小项目中，需求编号、用例编号和测试编号可以通过表格维护；在中大型组织中，需求经常跨多个团队、多个版本和多个部署环境，单纯依赖文档链接很快会失效。此时可以通过某项目管理平台建立需求、用例、开发任务、缺陷和测试用例之间的关联。

如果组织有私有化部署、国产化替代或历史项目迁移要求，选型时应重点确认权限模型、审计能力、数据迁移能力、接口开放性和部署方式。PingCode 支持私有化部署，也支持从 Jira 平滑迁移，更适合 100 人以上组织在多团队协作和合规环境下维护需求追踪。但我不会把工具选型当成用例设计的替代品，工具只能保存关系，不能替团队做出业务判断。

八、常见误区：看起来专业的做法，为什么反而降低了用例质量

1. 误区一：用例图越复杂，分析就越深入

复杂图形不等于复杂业务，更不等于深入分析。大量交叉箭头、几十个 include 和 extend 关系会增加阅读成本，让评审人员把注意力放在图形结构上，而不是业务规则和系统边界上。

我的判断标准很简单：把图打印出来或投影到会议室后，业务人员能否在一分钟内说出系统包含哪些核心目标？如果不能，应当拆分图、降低关系数量，或把行为细节移到用例规约和流程图中。

2. 误区二：只写成功路径，认为异常可以交给开发补充

异常不是开发阶段自然会出现的技术问题，其中很多是业务决策。例如审批人无权限时是否自动转交、余额不足时是否允许提交待人工复核、通知失败时是否回滚申请，都需要业务负责人决定。开发人员可以实现规则，但不应替业务做出规则。

将异常留到开发阶段，通常会导致两个结果：要么开发按最简单方式处理，造成上线后的业务争议；要么测试临时提出大量场景，迫使团队在迭代末尾重新修改流程。把高风险异常前置到用例评审，成本通常低于上线后修复数据和权限问题。

3. 误区三：把非功能需求平均塞进每一个用例

性能、安全、可用性和审计要求当然重要，但不应把所有系统级约束重复写进每一个用例。这样会让规约越来越臃肿，也容易造成指标冲突。

更合理的做法是区分三类要求：对某个用例直接有影响的要求，写在该用例中；多个用例共同遵守的约束，写在模块或系统级非功能需求中；需要统一监控和验收的指标，写入质量属性或验收方案。例如，审批操作必须记录操作人和时间，可以写入审批用例；全系统平均响应时间，则更适合作为系统级性能指标。

4. 误区四：过早绑定微服务、接口和数据库

用例阶段过早讨论微服务数量、数据库类型和消息队列，并不能证明需求已经清晰。技术选型应由业务规模、数据一致性、延迟目标、团队能力和运维成本共同决定，而不是由“看起来先进”的架构名词决定。

如果一个团队只有几十名成员、业务边界尚未稳定，却先拆分出大量服务，往往会增加部署、监控和联调成本。相反，中大型企业存在多团队并行开发、独立发布和组织边界时，服务拆分可能有合理价值。关键是用例先说明业务协作边界，再由架构设计决定技术边界。

5. 误区五：把工具模板当成分析能力

模板能够帮助团队不漏字段，工具能够帮助团队保存关系，但它们不能自动识别参与者冲突、判断业务规则是否合理，也不能替代真实用户访谈。一个内容空泛的用例，即使放进最复杂的平台，也仍然是内容空泛的用例。

九、不同情况下的行动建议：不要用同一套深度处理所有项目

1. 需求仍然模糊时：先做目标地图，不要急着写完整规约

如果业务方只能说出“做一个审批系统”“支持移动端报销”，说明需求还处于问题探索阶段。此时应先访谈参与者、梳理业务事件、确认核心目标和范围，不要立即要求每个用例都填满前置条件和异常流程。

• 先列出主要参与者和业务目标。
• 标记当前明确、待确认和明确不在范围内的内容。
• 选择一条高价值流程做深度走查。
• 把待决策问题形成清单，指定负责人和截止时间。

2. 需求已经明确但团队较小时：使用轻量用例规约

小型项目不需要为了形式建立几十页模型。可以采用“用例名称、目标、参与者、前置条件、主流程、关键异常、验收条件”七字段模板，再配一张简单流程图。重点是让每项需求都能被开发和测试理解。

轻量化不等于省略关键决策。即使只有三个人，也应该写清楚权限不足、重复提交、外部依赖失败和业务拒绝等高风险场景。小团队减少的是文档形式，不是业务思考。

3. 多团队并行开发时：优先管理边界和追踪关系

当一个用例涉及前端、后端、数据、消息和外部系统多个团队时，最容易出现“每个人都完成了自己的部分，但业务流程仍然无法闭环”。此时需要将用例拆分为可分配任务，同时保留端到端验收条件。

建议在评审时明确：谁负责状态创建、谁负责状态变更、谁拥有数据、谁处理失败补偿、谁提供测试环境。对于跨团队场景，最好使用支持需求追踪、权限管理、测试关联和变更审计的某项目管理工具，避免关系散落在聊天记录和个人表格中。

4. 频繁变更的产品：保持用户目标稳定，单独管理规则变化

如果产品页面和技术方案经常调整，用例名称不应跟着页面按钮变化。可以保持“提交请假申请”这一稳定目标不变，把不同版本的审批规则、通知方式和入口变化记录在业务规则、替代流程或版本约束中。

这样做可以降低模型维护成本。只有当参与者目标、业务结果或系统责任发生变化时，才需要重新评估用例边界；单纯的页面改版或接口替换，不应导致业务用例全部重写。

5. 合规、金融或人事场景：把审计和不可抵赖性前置

在审批、财务、人事和权限管理场景中，系统不仅要说明“操作是否成功”，还要说明谁在什么时候以什么身份做了什么决定。用例规约应明确操作日志、状态历史、撤回限制、代理审批和数据访问范围。

这类系统不能只测试正常页面流程，还要验证越权访问、重复提交、并发审批、历史数据篡改和接口重放等风险。必要时应将审计日志和权限校验作为独立的质量要求，并在验收阶段提供可查证的证据。

十、不同情况下的取舍：用例设计没有唯一最优解

1. 详细程度与维护成本之间的取舍

用例写得越详细，早期沟通和测试越充分，但后续变更维护成本也越高。写得过于简略，维护轻松，却会把理解成本转移给开发和测试。我的建议是：对稳定、关键、跨团队的核心用例写深；对探索性强、低风险、短生命周期的功能先写轻。

2. 用例图与文字规约之间的取舍

用例图适合帮助管理者和业务人员快速理解全局，文字规约适合开发和测试落地。不能用图替代文字，也不能用长篇文字完全取代全局模型。对于核心模块，我通常保留一张简洁用例图，再为关键用例补充规约和流程图。

如果参与者和用例数量已经超过一张图的可读范围，可以按业务域拆图，例如请假申请、审批处理、规则维护和报表查询分别建模。拆图的目标是降低认知负担，而不是隐藏系统复杂度。

3. 自建表格与项目管理平台之间的取舍

表格适合早期探索和小团队快速协作，成本低、修改快，但在需求频繁变更、多人并行和多版本维护时，容易出现编号重复、链接失效和状态不一致。某项目管理平台则更适合建立持续追踪关系，但需要投入权限配置、字段设计、流程培训和治理成本。

我的判断顺序是先看协作复杂度，再看工具预算。若只有一个团队、需求数量少且生命周期短，表格完全可以满足需要；若涉及多个产品线、多个研发团队、私有化部署或从既有系统迁移，则应重点评估平台的迁移能力、审计能力、开放接口和长期维护成本。

4. 性能指标写进用例还是单独管理

如果性能直接影响某个业务目标，例如支付确认必须在规定时间内返回，或者审批提交不能出现重复扣款，就应该把相关约束写进该用例的非功能要求和验收条件。若是整个系统的吞吐量、可用性和容量指标，则应放在系统级质量要求中。

不要为了显得专业而随意写“响应时间小于一秒”“支持十万并发”。指标必须有业务依据、测量条件和测试方法。没有真实压测结果时，可以先写目标区间和验证口径，等技术方案和环境确定后再冻结具体数值。

十一、从新手到专家的训练路径：不要从画图工具开始

1. 第一阶段：练习识别用户目标

新手最适合从真实业务句子开始练习，而不是先背 UML 符号。拿“客户可以申请退款”“员工可以出差报销”“管理员可以配置权限”这类需求，分别找出参与者、业务目标、触发条件和结果。

每天选择一个场景，将其中的页面动作改写为业务目标。例如把“点击确认收货”改成“确认收货”，把“上传发票”改成“提交报销申请材料”。经过一段时间后，能够明显减少把界面控件当成用例的情况。

2. 第二阶段：练习补全异常和业务规则

当能够稳定识别目标后，再逐步补充前置条件、后置条件、替代流程和异常流程。建议每个用例至少提出五个问题：谁可以操作？什么情况下不能操作？重复操作会怎样？外部依赖失败会怎样？最终状态如何确认？

这一阶段不要追求一次写全，而要通过评审和测试反馈不断修正。用例设计能力很大一部分来自对失败场景的积累，而不是来自记忆更多术语。

3. 第三阶段：练习把用例转为验收条件

专家级用例的差异，不在于写出更多步骤，而在于能够把每个关键行为转化为可观察的验收条件。验收条件应包含前提、动作和结果，避免“系统正常”“体验良好”这类无法执行的描述。

例如，“当审批人拒绝一条待审批申请时，系统必须保存拒绝原因、记录审批人和时间，并将申请状态更新为已拒绝；员工重新打开申请详情时可以查看结果。”这条条件同时覆盖业务结果、审计信息和用户可见性，测试人员可以据此设计验证步骤。

4. 第四阶段：练习跨团队追踪和变更影响分析

当项目规模扩大后，单个用例写得好还不够，还要知道它影响哪些接口、任务、测试和发布范围。可以选择一个变更需求，反向追踪受影响的用例、开发任务、测试用例和上线说明，训练自己识别隐性影响。

如果团队使用某项目管理平台，应建立统一编号、关联规则和状态定义；如果暂时使用文档和表格，也要保持同样的追踪逻辑。工具形式可以变化，但“需求变更必须能找到受影响交付物”的原则不能变化。

十二、系统用例设计检查清单

1. 评审前的十个问题

• 主要参与者是否是真正发起目标或接收结果的角色？
• 用例名称是否表达业务目标，而不是按钮、接口或数据库操作？
• 系统边界是否清楚，哪些行为明确不在本期范围内？
• 是否写明触发条件、前置条件和后置条件？
• 主成功场景是否围绕业务结果，而不是页面点击顺序？
• 是否覆盖关键替代流程和业务拒绝场景？
• 外部服务超时、重复提交和并发冲突如何处理？
• 重要业务规则是否写成了可判断、可测试的条件？
• 非功能要求是否放在正确层级，避免重复和冲突？
• 用例是否能够关联到需求、开发任务、测试场景和验收结果？

2. 用例质量的快速分级

这套分级的价值在于避免团队争论“文档是否写完”。不同阶段需要不同深度，关键是明确当前版本能支持什么决策。草稿可以用于探索，评审级可以用于确认范围，可开发级用于任务拆解，可验收级用于交付判断。

十三、结语：好的用例不是让团队写更多，而是让团队少猜一点

系统用例设计的五个秘诀，可以归纳为一条完整路径：先识别参与者和目标，再划清系统边界；围绕主成功场景描述行为，同时补充替代和异常流程；控制在用户目标层级的合适粒度；最后将用例连接到开发、测试和验收。

我最想强调的独特判断是：用例设计的产出，不是图，而是团队对系统行为形成的共同承诺。图形只是建立全局视角的工具，真正决定项目质量的是那些被明确写下、能够被实现、能够被测试、能够被追责的业务规则。

下一步不要先打开建模软件。选择一个正在开发或最近返工过的真实功能，先写出参与者、目标、系统边界、主流程、三类异常和五条验收条件。然后邀请产品、开发、测试和业务负责人各自指出一处不确定点。只要这次评审能够提前暴露一个权限冲突、一个状态遗漏或一个外部依赖失败，用例设计就已经为项目节省了真正的成本。