用例模型：从需求分析到系统设计的关键桥梁

《用例模型：从需求分析到系统设计的关键桥梁》真正要解决的，并不是“如何画一张漂亮的 UML 用例图”，而是如何把业务方口中的目标，转换成开发、测试和设计团队都能验证的系统行为。我的经验是，很多项目并不是需求没有写文档，而是缺少一份能够明确回答“谁在什么条件下，通过系统完成什么目标，失败时系统应该怎样处理”的中间模型。用例模型恰好承担了这项工作。

一、先讲核心结论：用例模型不是图，而是一份可验证的交接协议

1. 用例模型连接的是三种语言

业务人员通常从结果出发描述需求，例如“让请假审批更快”“减少人工对账”“支持供应商在线提交资料”。产品人员会把这些目标拆成功能、页面和流程，开发人员则需要继续追问数据、权限、状态、接口和异常处理。

这三种表达并不天然一致。业务方描述的是价值，产品描述的是方案，技术团队需要的是系统边界和可执行行为。用例模型的核心价值，是把“业务目标”翻译成“系统必须提供的能力”，再把这些能力落实为设计和测试输入。

因此，我不会把用例模型简单等同于用例图。严格来说，它至少包括以下几部分：

• 参与者：谁或什么外部对象与系统交互；
• 用例：参与者希望通过系统完成的业务目标；
• 系统边界：哪些行为属于当前系统职责；
• 关系：参与者与用例、用例与用例之间如何关联；
• 用例描述：正常流程、替代流程、异常流程、前置条件和结束状态；
• 约束和规则：权限、时限、数据校验、外部系统依赖等。

2. 用例的最小单位不是按钮，而是用户目标

“点击提交按钮”“打开审批页面”“输入手机号”都属于操作步骤，不适合作为独立用例。一个更合适的用例，应该能够表达一个有明确结果的用户目标，例如“提交请假申请”“审核退货申请”“同步考勤结果”“生成月度结算单”。

我在评审用例时经常使用一个简单判断：如果参与者完成这个用例后，业务上没有产生一个可以被确认的结果，那么它大概率只是步骤，不是用例。

例如，“填写请假表单”只是提交申请的一部分；“提交请假申请”才是完整目标，因为它包含填写、校验、保存、提交、生成申请编号和通知审批人等系统行为。

3. 用例模型的质量，要看下游能否接得住

一张用例图看起来完整，并不代表需求完整。真正有价值的模型应该能够向下游产生明确映射：

二、为什么很多需求写完了，系统仍然无法设计

1. 业务方给的是方向，不是系统行为

“提升审批效率”是一项有效的业务目标，但它不能直接变成接口，也不能直接画成页面。系统团队还需要知道：谁提交、谁审批、审批依据是什么、审批是否分级、超时如何处理、撤回后能否重新提交、审批人离职时由谁接管。

如果这些问题没有被显式建模，项目通常会在后期以变更单的形式补回来。表面上看，这是开发遗漏；实际上，很多遗漏发生在需求从业务语言转为系统语言的阶段。

2. 正常流程很容易写，异常流程才暴露需求成熟度

以在线请假为例，正常流程可以在几分钟内写完：员工填写申请，系统校验，主管审批，审批通过后同步考勤。真正影响系统复杂度的，往往是以下问题：

• 员工剩余假期不足，但申请天数超过余额时如何处理；
• 申请跨越两个考勤周期时，系统以哪个周期的规则计算；
• 主管在审批过程中离职或被调整岗位时，待办是否迁移；
• 员工提交后发现日期错误，能否撤回；
• 考勤系统暂时不可用时，审批结果是否先落库；
• 两名管理员同时修改同一条假期规则时，谁的版本生效。

我通常把异常路径当作需求质量的压力测试。如果一个用例只写了“提交成功”，却没有说明失败、撤回、重试和权限变化，那么它更像演示稿，而不是可交付的需求资产。

3. 页面数量会制造一种“需求已经很具体”的错觉

很多团队在需求评审中直接展示页面原型。页面确实直观，但页面不能替代用例模型。页面告诉我们用户看到了什么、可以点击什么，却未必说明后台什么时候校验、数据如何改变、外部系统何时被调用。

例如请假页面上有一个“提交”按钮，但这个按钮背后可能包含身份校验、假期余额计算、日期冲突检查、审批链生成、申请状态变更、消息通知和审计记录。只看页面，团队很容易低估系统行为的数量。

4. 需求文档越长，不代表模型越完整

我见过一些几十页的需求文档，充满了页面说明和字段定义，却无法回答“系统边界在哪里”。文档长度解决的是信息承载问题，用例模型解决的是关系和责任问题。

一份有效的用例描述不一定很长，但必须让读者知道触发条件、参与者目标、系统响应、业务规则和最终状态。用例模型追求的不是文字数量，而是关键决策是否被显式记录。

三、用例模型与其他流程图，究竟有什么区别

1. 业务流程图回答“组织如何完成一件事”

业务流程图关注岗位、部门、审批环节和业务制度。例如采购流程可能包括需求部门提交申请、采购部门询价、财务部门审核预算、负责人审批、供应商签约和仓库收货。

其中有些动作可能在线下完成，有些动作可能由多个系统共同承担。业务流程图的边界是业务过程，而不是某个具体软件。

2. 用例图回答“系统为谁提供什么能力”

用例图会把系统放在一个明确边界内，描述外部参与者与系统能力之间的关系。它不追求展示每个判断节点，而是帮助团队快速确认系统范围和角色目标。

在采购场景中，“提交采购申请”“审批采购申请”“维护供应商资料”“接收采购订单”可以成为用例；“部门负责人线下沟通预算”则未必属于系统用例，除非系统需要记录或支持这项活动。

3. 功能流程图回答“系统内部如何处理一项功能”

功能流程图适合展开一项用例的逻辑。例如提交请假申请时，系统先检查用户身份，再检查日期合法性，然后计算余额、匹配审批人、保存申请并发送通知。这个层次比用例图更接近功能实现。

4. 页面流程图回答“用户如何在界面之间移动”

页面流程图关注页面跳转和交互路径，例如员工从工作台进入请假页面，填写表单后进入确认页，再回到申请详情页查看状态。它可以帮助产品和设计团队优化操作路径，但无法覆盖后台接口、权限和数据状态。

我建议团队不要争论“哪张图最重要”，而要先问每张图在当前阶段回答什么问题。一个成熟项目往往不是只画一种图，而是让不同模型在不同抽象层次上互相校验。

四、从需求访谈到用例模型：我使用的五步拆解法

1. 先把业务目标改写成用户目标

第一步不是打开建模软件，而是把“提升效率、降低成本、加强管控”这类宏观表达，改写成可以被某个角色完成并产生结果的目标。

例如，“加强请假管控”可以拆成员工提交请假申请、主管审核申请、人力资源管理员维护假期规则、考勤系统接收已批准结果。每个目标都需要有明确参与者和完成状态。

2. 识别参与者，包括外部系统和自动任务

参与者不只包括人。第三方支付服务、身份认证系统、消息服务、定时任务和设备都可能是参与者。判断标准是：它是否在系统边界之外，主动触发系统行为或接收系统结果。

以请假审批为例，员工和主管是人类参与者，考勤系统是外部系统，通知服务是外部服务，夜间自动同步任务则可以作为时间触发的参与者。

3. 画出系统边界，再讨论功能

系统边界是最容易被忽略、但对项目范围影响最大的部分。假设本项目只负责请假申请和审批，不负责计算薪资，那么薪资发放不应被写成本系统内部用例。系统可以向薪资系统提供结果，但不能把薪资处理过程全部纳入本系统。

在企业项目中，我通常会把以下问题写在边界评审表中：

• 这一步是否由本系统执行；
• 这一步是否需要本系统保存业务状态；
• 这一步是否由外部系统提供结果；
• 本期是否需要支持这项能力；
• 如果不纳入系统，谁对结果负责。

4. 围绕业务结果定义用例粒度

用例过大，会变成一张业务流程图；用例过小，会退化为按钮清单。一个实用的粒度判断方法是检查用例是否满足三个条件：

1. 有明确的参与者；
2. 有可识别的业务目标；
3. 完成后能产生可确认的结果。

“管理请假”通常过大，因为它可能包含提交、审核、撤回、查询和规则维护。把它拆成多个用户目标后，权限、页面和测试边界会清晰很多。

5. 补齐主流程、替代流程和异常流程

主流程描述系统顺利完成目标的路径；替代流程描述在合法条件变化时的另一条路径；异常流程描述系统无法完成目标时的处理方式。

例如请假申请可以这样区分：

• 主流程：员工填写合法日期，余额充足，系统找到审批人并成功提交；
• 替代流程：员工申请半天假，系统按小时计算余额；
• 异常流程：假期余额不足，系统拒绝提交并提示可用余额；
• 异常流程：审批链为空，系统保存草稿并通知管理员处理；
• 异常流程：通知服务超时，申请仍保存，但通知进入重试队列。

五、案例拆解：在线请假审批系统如何从用例进入设计

1. 先建立业务背景和范围

假设一家拥有多个事业部的企业，希望上线统一请假审批系统。员工需要在线提交申请，直属主管负责审批，人力资源部门维护假期规则，审批通过后结果同步到考勤系统。第一期不负责薪资计算，也不替代现有的组织架构系统。

这个范围说明了两个重要边界：本系统负责申请、审批、状态管理和结果同步；组织身份和薪资计算分别由外部系统负责。边界一旦明确，后续用例就不会无限膨胀。

2. 识别参与者和核心用例

这里有一个容易犯的错误：把“发送通知”一定做成用户可见的主用例。实际上，通知服务更多是外部参与者或被包含的系统行为，是否独立成用例，要看它是否被多个核心用例稳定复用，以及团队是否需要单独管理它的失败和重试。

3. 编写“提交请假申请”的用例描述

用例图只能表达参与者和能力关系，真正支撑开发和测试的，是用例描述。下面是一份简化但可执行的版本。

4. 主成功场景与异常场景

1. 员工进入请假申请页面。
2. 系统读取员工身份、部门和剩余假期信息。
3. 员工选择假期类型、开始时间、结束时间并填写原因。
4. 系统检查时间范围、假期余额和已有申请是否冲突。
5. 系统根据组织关系匹配直属主管。
6. 系统保存申请，生成申请编号。
7. 系统将状态设置为“待审批”。
8. 系统向主管发送待办通知。

异常场景必须单独写清楚。例如余额不足时，系统不能只返回“提交失败”，还应说明可用余额、申请天数和下一步选择。审批人缺失时，也不能让申请静默停留在数据库中，否则业务人员会误以为申请已经进入流程。

5. 从用例推导页面、接口、权限和状态

当用例描述完成后，系统设计就有了稳定的输入。员工提交申请这一用例，可以推导出申请页面、余额查询接口、申请创建接口、审批链查询服务和通知消息服务。

从参与者可以推导权限：员工只能查看自己的申请，主管只能处理授权范围内的申请，人力资源管理员可以修改规则和处理异常。权限不是页面上的一个隐藏按钮，而是用例中参与者目标的系统约束。

从流程中的状态变化，可以推导状态机：草稿、待审批、审批中、已通过、已驳回、已撤回、同步中、同步失败。状态名称一旦明确，数据库字段、接口返回值、页面展示和测试条件就能使用同一套语言。

六、用例关系怎么用：少画一点，反而更清楚

1. 关联关系表达参与者与用例的交互

关联关系表示参与者会使用或触发某个用例。它不需要表达先后顺序，也不需要把每个页面动作都画出来。用例图的第一任务是说明系统为哪些外部角色提供哪些能力。

2. 包含关系适合稳定复用的必经行为

如果多个用例都必然执行一段独立且稳定的行为，可以考虑使用包含关系。例如多个业务操作都必须完成身份校验，或者多个提交类用例都必须记录审计日志。

但我不建议为了让图显得“专业”而大量使用包含关系。任何行为都被拆出去，主用例会失去业务语义，阅读者反而看不懂完整目标。

3. 扩展关系适合可选或条件触发的行为

扩展关系用于表示某个附加行为只在特定条件下发生。例如请假申请在跨部门审批时增加额外会签，或金额超过阈值时增加财务审核。

如果一个流程分支是每次都会发生的必经步骤，就不适合使用扩展关系。判断重点不是“这一步是否单独存在”，而是“它是否在特定条件下才发生”。

4. 泛化关系不要替代普通角色权限

角色之间存在继承关系时，可以使用泛化。例如部门主管继承普通审批人的基础能力，同时增加批量审批权限。但如果只是两个角色拥有不同按钮，就不一定需要画泛化，直接在权限矩阵中表达通常更清晰。

七、工具和团队协作：什么时候值得引入需求管理平台

1. 小型项目不必为了画图而引入复杂工具

如果项目只有三四名成员，业务边界稳定，需求数量不多，使用在线白板、文档或轻量建模工具就可以完成初步用例梳理。此时最重要的不是工具功能，而是团队是否愿意共同评审异常场景。

工具不能替代分析。如果参与者没有识别清楚、系统边界没有确认、用例描述没有写完整，再强的工具也只会让错误更容易被复制。

2. 中大型组织更需要追踪关系，而不仅是画图

当团队规模超过百人，项目同时存在多个产品线、多个研发团队和多个交付批次时，需求管理的难点会从“怎么表达”转向“如何追踪”。一个用例可能关联多个需求、页面、接口、测试用例和发布版本，如果这些关系依靠人工维护，评审和变更很容易失控。

以 PingCode 这类面向中大型企业、尤其是 100 人以上组织的研发管理平台为例，它更适合承载需求条目、用例描述、任务、缺陷和测试之间的关联。对于有合规要求或数据不能出域的企业，私有化部署也是需要纳入评估的条件；如果团队原本使用 Jira，也应重点检查迁移过程中的字段、工作流、权限和历史数据是否能够平滑承接。

这里的关键并不是“是否使用某一个具体平台”，而是平台能否实现以下闭环：

• 用例可以关联业务需求和版本范围；
• 用例中的异常场景可以转化为开发任务或测试场景；
• 需求变更后，团队能够知道哪些设计和测试受到影响；
• 不同角色可以在同一条需求上留下评审意见和决策记录；
• 私有化部署、权限隔离、审计和国产化适配满足组织治理要求。

3. 选择工具时，先看追踪能力，再看图形数量

很多团队会比较模板数量、图标数量和看板样式，却忽略需求追踪。对用例模型而言，我更关注“一个异常场景能否追踪到测试结果”和“一个规则变更能否定位受影响的功能”。

八、不同项目阶段的行动建议与取舍

1. 需求探索阶段：先粗后细，不要一开始追求完整 UML

在需求探索阶段，业务目标和系统范围仍在变化。此时建议先完成参与者识别、核心用户目标和初步系统边界，不要急于把所有包含、扩展关系画得很细。

取舍是：接受模型暂时不完整，换取更快暴露范围争议。过早细化会让团队沉迷格式和符号，反而不愿意推翻已经画好的结构。

• 适合产出：上下文图、参与者清单、核心用例清单；
• 重点评审：谁使用系统、系统不负责什么、一期范围是什么；
• 暂不追求：所有字段、所有接口、所有异常分支。

2. 方案设计阶段：优先补齐状态、规则和外部依赖

进入方案设计后，重点从“有哪些用例”转为“每个关键用例如何执行”。这时需要补充前置条件、状态变化、规则、接口依赖和失败处理。

取舍是：用例描述会变长，但它能显著降低开发阶段的猜测空间。尤其是涉及审批、支付、库存、消息和第三方接口的场景，异常分支越晚明确，改造成本越高。

• 适合产出：详细用例描述、状态模型、业务规则清单；
• 重点评审：状态是否闭环、异常是否可恢复、接口失败如何处理；
• 需要避免：把数据库字段设计直接冒充需求分析。

3. 开发迭代阶段：让用例成为验收和拆任务依据

开发阶段不应把用例文档束之高阁。产品可以根据用例主流程拆分功能任务，开发根据异常路径识别服务和数据处理，测试根据每条路径设计验收场景。

取舍是：不一定要求所有用例一次性达到最终状态，但每个进入开发的用例必须达到“可实现、可验证”的最低标准。否则迭代速度只是把不确定性提前转移给开发和测试。

4. 变更频繁的项目：优先维护追踪关系

如果项目处于快速试错期，需求会持续变化，团队应重点维护用例与版本、任务、缺陷之间的关系。此时不必追求文档文字极度精美，但必须能回答：这次变更影响哪些角色、哪些页面、哪些接口和哪些测试。

取舍是：接受一定程度的模型迭代，换取变更影响可见。最危险的不是模型修改，而是模型不改、实际行为已经悄悄变化。

5. 强合规项目：优先保证审计和权限完整

金融、制造、医疗、政企等场景通常更关注谁审批、谁修改、谁发布以及变更是否留痕。此时用例模型除了描述用户目标，还应该关联审批记录、版本记录、权限矩阵和测试证据。

取舍是：流程会比普通互联网项目更重，但这部分成本换来的是可追溯性和责任边界。对于数据不能出域的组织，私有化部署、访问审计和权限隔离也应在工具选型阶段一起评估，而不是上线后再补。

九、最容易踩的七个坑，以及我的判断方法

1. 把业务流程原样复制成用例图

业务流程中的人工沟通、线下签字和组织制度，不一定属于系统行为。直接复制会让系统边界膨胀，导致项目范围失控。

改进方法是逐步追问：这一步是否由系统执行？系统是否保存结果？谁通过系统触发它？如果答案都是否，就把它保留在业务流程图，而不是用例模型中。

2. 把页面和按钮当成用例

按钮是界面元素，用例是业务目标。一个用户目标通常包含多个按钮、接口和状态变化。如果把按钮全部独立建模，图会非常细，却没有办法支持业务验收。

判断标准很简单：删掉页面名称后，业务方是否仍能理解这个用例的结果？如果不能，说明名称可能过于界面化。

3. 只写主成功场景

只写正常流程会造成一种危险的假象：系统好像只需要处理“顺利提交”。但生产环境真正消耗时间的，往往是重复提交、权限不足、数据冲突、第三方超时和状态不一致。

对于高风险用例，我建议至少覆盖三类异常：输入或规则异常、权限异常、外部依赖异常。涉及资金、库存或审批的场景，还要增加并发和补偿路径。

4. 滥用包含和扩展关系

用例图不是为了展示建模者掌握了多少 UML 符号。关系越多，未必越专业。大量关系会让业务人员难以阅读，也会掩盖真正重要的用户目标。

我的建议是先用自然语言写清楚完整用例，再判断是否存在稳定复用或条件扩展。不能因为两个流程都有“校验”二字，就立刻抽象成包含关系。

5. 忽略状态变化

审批、订单、支付、工单和库存类系统，都不是简单的“成功或失败”。状态变化决定了用户下一步能做什么，也决定了接口幂等、权限和数据一致性。

如果一个用例涉及提交、审核、撤回、驳回或重新提交，就应该单独列出状态表，并明确每个状态允许哪些动作。

6. 忽略外部系统失败

“调用考勤系统”“发送消息”“同步支付结果”都不是一句话可以结束的需求。必须明确超时、重试、重复回调、结果延迟和人工补偿。

系统设计最怕的是边界条件没有归属。外部系统失败时，是本系统重试、人工处理，还是允许业务先继续？这个决策必须在用例阶段确定。

7. 用例没有回溯到业务价值

有些用例会在迭代中不断增加字段和流程，却没有人再确认它解决什么问题。最终系统功能越来越多，用户目标却没有变得更清晰。

每次重大变更都应该问一句：这个变化服务哪个参与者目标？如果找不到对应目标，就要警惕范围蔓延或技术实现被误当成业务需求。

十、如何判断一份用例模型是否真的可用

1. 用三个问题检查范围

• 系统服务哪些参与者？
• 每个参与者通过系统想完成什么目标？
• 哪些行为明确不属于本系统？

如果这三个问题无法在十分钟内回答，说明系统边界还没有稳定。此时继续画详细流程，通常只会加深误解。

2. 用四个条件检查单条用例

• 是否有明确触发条件；
• 是否有前置条件和成功结果；
• 是否写出系统响应，而不仅是用户操作；
• 是否覆盖关键异常、权限和外部依赖。

特别要注意“用户点击提交后，系统做什么”这一类句子。用例描述应交替写出参与者动作和系统响应，不能只写用户步骤。

3. 用五条追踪关系检查落地能力

4. 用一次联合评审验证模型

业务人员负责确认目标和规则，产品人员负责确认用户路径，开发人员负责确认边界和实现约束，测试人员负责确认场景是否可验证。四类角色共同参加，才能发现单一角色视角下的盲区。

我建议评审不要从“这条线应该用实线还是虚线”开始，而是从一个具体场景开始演练：参与者如何触发、系统如何响应、数据如何变化、失败时谁处理。图形规范应服务于讨论，而不是取代讨论。

十一、我的实践建议：把用例模型做成项目中的“单一事实源”

1. 先建立用例目录，再建立详细描述

不要一开始就为每条用例写十几页。先建立用例目录，包含编号、名称、参与者、业务目标、优先级、版本和负责人。目录用于控制范围，详细描述用于支撑设计。

当目录稳定后，再优先细化高风险用例。通常应该优先处理涉及审批、支付、库存、权限、数据同步和跨系统协作的场景，而不是先处理简单查询页面。

2. 用例编号要贯穿需求、任务和测试

建议为用例设置稳定编号，例如 UC-LEAVE-001。编号不应随页面名称变化而变化，因为页面可能重构，但用户目标和业务追踪关系需要保持稳定。

开发任务、接口设计、测试用例和缺陷记录都可以引用这个编号。这样在需求变更时，团队能够快速找到影响对象，而不是依靠关键词搜索几十份文档。

3. 把异常流程当作一等公民

很多团队把异常流程放在文档末尾，甚至写成“异常情况另行处理”。我的建议是：凡是会改变状态、影响资金或阻断业务的异常，都应该与主流程一样进入评审、开发和测试范围。

如果异常处理规则尚未确定，就把它标记为待决策项，而不是假装需求已经完成。显式暴露不确定性，比把问题藏到开发阶段更专业。

4. 工具只是载体，追踪关系才是核心资产

无论使用文档、白板、建模软件，还是面向研发团队的项目管理平台，都应确保模型能够被持续维护。一个没人更新的漂亮用例图，很快就会失去参考价值。

对于中大型企业，我更建议选择支持需求、任务、测试、缺陷、版本和权限关联的管理方式。特别是已经有大量历史项目数据的团队，迁移前要检查字段、工作流、附件、评论和权限是否能够保留；如果现有流程依赖 Jira，也应先做小范围迁移验证，再决定是否全面切换。

十二、写在最后：真正的桥梁不是图，而是可验证的行为

用例模型最容易被误解的地方，是大家把注意力放在“怎么画”。实际上，图只是压缩信息的方式，模型真正承载的是参与者目标、系统边界、业务规则、状态变化和异常处理。

如果一份用例模型能够让业务方确认目标，让产品知道功能范围，让开发明确系统行为，让测试找到验收场景，它就已经发挥了桥梁作用。反过来，如果图画得很规范，却无法指导接口、权限和测试，那么它只是文档装饰。

我对用例模型的最终判断是：它不是需求分析的终点，也不是系统设计的替代品，而是两者之间最适合被反复验证的中间层。它的价值不在于减少所有变化，而在于让变化发生时，团队知道变化影响了什么。

如果你准备在实际项目中使用用例模型，可以从一个高风险业务开始，而不是试图一次覆盖整个系统。选择一个“提交，审核，状态变化，外部同步”完整闭环的场景，按参与者、目标、边界、主流程、异常流程和设计映射六个步骤拆解，再邀请业务、开发和测试共同评审。

下一步可以直接建立一张用例评审表，至少包含以下字段：

• 用例名称与稳定编号；
• 主要参与者和次要参与者；
• 前置条件和触发条件；
• 主成功场景；
• 替代流程和异常流程；
• 业务规则与权限约束；
• 状态变化与外部系统依赖；
• 对应页面、接口、任务和测试场景；
• 当前负责人、版本和待决策问题。

当这张表不再只是分析师的个人文档，而是成为团队共同维护的交接协议时，用例模型才真正从一张图，变成了连接需求、设计、开发和质量验证的工程基础设施。