用例建模是一种从外部使用者视角描述系统行为的建模方法：把系统当作一个整体，用参与者、用例以及二者之间的关系，说明谁为了什么目标与系统交互、系统应给出什么可观察的响应。本文围绕定义、范围边界、组成机制、与相邻概念的区别以及团队落地方式展开，帮助第一次接触这一方法的读者建立可复述、可判断的完整认识。
要点总览（TL;DR）
- 用例建模从外部使用者视角描述系统行为，用参与者、用例、系统边界三个要素说明谁为了什么目标与系统交互、系统应给出什么响应。
- 它关注系统对外提供的功能范围与行为目标，内部类结构设计、界面绘制和需求优先级判断属于相邻工作。
- 用例图给出全局结构与范围，用例说明文本承载主场景、备选流和前后置条件，二者配合才构成完整模型。
- 用例适合在需求早期界定完整行为范围，用户故事适合切成迭代内可交付的小块，二者可以配合使用。
- 把用例写成操作步骤、把界面当用例、追求用例数量，都会削弱模型在评审、变更和测试设计中的可用性。
用例建模的核心定义
用例建模（Use Case Modeling）是一种以外部视角组织系统功能需求的方法。它把待建系统视为一个边界清晰的整体，通过识别与系统交互的外部角色，以及这些角色希望达成的目标，来描述系统应当提供哪些行为。用例建模在面向对象分析与统一建模语言（UML，Unified Modeling Language，一种用于软件系统可视化描述的建模语言）的实践中被广泛采用，逐渐成为需求表达阶段的常用手段。
可以直接引用的定义表述是：用例建模是一种从外部使用者视角描述系统行为的建模方法，它用参与者、用例和系统边界三个基本要素，说明“谁为了什么目标与系统交互、系统应给出什么可观察的响应”，关注系统对外提供的功能范围与行为目标，不描述内部实现结构。
三个基本要素各有明确含义：
- 参与者（Actor）：与系统交互的外部角色，可以是人，也可以是另一个系统或定时触发的外部事件源。参与者代表一类使用者的立场，而非某个具体个人。
- 用例（Use Case）：系统为某个参与者提供的一个完整功能目标，从触发到结束构成一个有意义的服务过程，例如“借阅图书”“提交订单”。
- 系统边界（System Boundary）：划定哪些行为由本系统负责、哪些属于外部环境。边界之内是用例，边界之外是参与者。
需要强调的是，用例描述的是目标而非操作步骤。“借阅图书”是一个目标，而“点击借阅按钮、扫描条码、打印凭条”是达成目标的交互细节。把目标写成步骤，会让用例失去概括力，也难以在需求变化时保持稳定。
用例建模包括什么、不包括什么
用例建模有明确的工作范围。把它与相邻工作区分开，能避免在建模阶段混入设计或管理决策，也能避免遗漏真正需要产出的内容。
| 类别 | 内容 | 说明 |
|---|---|---|
| 属于用例建模 | 参与者识别 | 找出所有与系统交互的外部角色及其目标 |
| 属于用例建模 | 用例划分 | 按参与者目标切分系统功能，形成用例清单 |
| 属于用例建模 | 用例之间的关系 | 表达关联、包含、扩展、泛化等结构关系 |
| 属于用例建模 | 用例说明 | 用文本描述主场景、备选流、前置与后置条件 |
| 不属于用例建模 | 内部类结构设计 | 类、接口、数据库表等属于设计阶段的工作 |
| 不属于用例建模 | 界面绘制 | 页面布局与交互细节属于界面设计 |
| 不属于用例建模 | 需求优先级判断 | 价值排序、取舍决策属于需求分析与规划 |
系统边界的确定直接影响建模范围。边界划得过大，会把外部系统承担的职责纳入本系统用例，导致用例臃肿；边界划得过小，则可能遗漏本系统应提供的服务。实践中可以借助一个问题来判断：这项行为的结果是否由本系统负责并对外可见？如果是，它就在边界之内。边界一旦确定，应在用例说明中保持一致，避免同一功能在不同用例中归属混乱。
用例建模的组成与运作机制
一份可用的用例模型由图形与文本两部分配合构成。图形给出全局结构，文本给出行为细节，二者缺一不可。
参与者与用例之间的关系主要有四类：
- 关联（Association）：参与者与用例之间的基本连接，表示该参与者参与该用例的执行。
- 包含（Include）：一个用例必然调用另一个公共用例的行为，常用于抽取多个用例共用的片段，如“身份验证”。
- 扩展（Extend）：在特定条件下为基用例追加行为，基用例本身仍可独立完成，如“借阅图书”在逾期时扩展出“缴纳罚金”。
- 泛化（Generalization）：参与者或用例之间的继承关系，子类型具备父类型的行为并可增加特有行为，如“注册读者”泛化自“读者”。
用例说明文本通常包含以下结构：用例名称与简述、参与者、前置条件、主场景（顺利路径）、备选流（异常或分支路径）、后置条件。主场景按“参与者动作—系统响应”交替书写，保持一条可读的完整路径；备选流则标注触发条件与回归主场景的位置。这样写出的说明既能被业务方读懂，也能作为后续设计与测试的输入。
用例图与用例说明文本分工明确：用例图回答“系统对外提供哪些功能、谁在使用”，适合快速对齐范围；用例说明回答“每个功能具体如何表现”，适合承载细节与验收依据。只画图不写说明，模型会停留在清单层面；只写说明不画图，则难以检查范围是否完整、参与者是否遗漏。
用例建模与用户故事、业务流程的区别
这三类表达常被混用，但它们的粒度、格式与使用时机不同，混用会导致需求颗粒度失控或遗漏关键路径。
| 维度 | 用例 | 用户故事 | 业务流程 |
|---|---|---|---|
| 关注点 | 系统对外提供的行为目标 | 用户价值与交付切片 | 跨角色、跨系统的端到端活动流 |
| 粒度 | 一个完整功能目标，含多条路径 | 可在一个迭代内交付的小切片 | 覆盖多个系统与角色的长流程 |
| 格式 | 图形加结构化文本说明 | 简短叙述加验收条件 | 流程图或活动图加节点说明 |
| 使用时机 | 需求范围界定与行为细化 | 迭代计划与任务拆分 | 业务梳理与流程优化 |
用例与用户故事的核心差异在于粒度与用途：用例倾向于把一个功能目标的全部路径写清楚，适合在需求早期界定范围；用户故事倾向于切成可快速交付的小块，适合在迭代中驱动开发。二者可以配合使用，由用例提供完整行为视图，再由用户故事切分交付顺序。
用例建模与业务流程建模的关注点也不同：业务流程建模描述组织内多个角色与系统如何协作完成一项业务，跨越系统边界；用例建模聚焦单个系统对外提供什么行为。一个业务流程往往对应多个系统的多个用例。
用例与验收条件的关系是：用例说明中的主场景与备选流，天然构成验收条件的来源。每条路径的预期系统响应，都可以转化为一条可核验的验收条目。用例负责描述行为全貌，验收条件负责把关键路径转成可判定的检查点。
一个具体例子与常见误解
以下为演示情景，用于说明用例模型的产出形态，不代表任何真实项目。
以图书借阅系统为例。参与者包括“读者”和“图书馆员”。用例包括“借阅图书”“归还图书”“查询借阅记录”“缴纳罚金”。其中“缴纳罚金”作为“借阅图书”在逾期条件下的扩展用例出现。
“借阅图书”的用例说明可写成：
- 参与者：读者
- 前置条件：读者身份已验证，所借图书在馆且可借
- 主场景：读者提交借阅请求 → 系统校验借阅资格与图书状态 → 系统登记借阅记录并更新库存 → 系统返回借阅成功与应还日期
- 备选流 A：图书已借出，系统提示不可借并结束
- 备选流 B：读者存在逾期未还记录，系统触发“缴纳罚金”扩展用例，处理完成后回到主场景
- 后置条件：借阅记录已生成，库存数量已扣减
围绕这个例子，可以对照三类常见误解：
- 把用例写成操作步骤：如把“借阅图书”拆成“点击借阅、扫描条码、确认提交”。这样写出的内容随界面变化而失效，也丢失了目标层面的概括力。
- 把界面当用例：如“借阅页面”“罚金弹窗”。界面是目标的实现载体，同一目标可以有多种界面形态，界面不应成为用例的划分依据。
- 用例越多越好：把每个细碎动作都拆成独立用例，导致清单膨胀、关系复杂，读者难以看清系统的主要功能范围。
这些误解带来的实际后果是：需求评审时难以判断范围是否完整，变更时难以定位受影响的行为，测试设计时难以从用例推导覆盖路径。保持用例的目标粒度，是让模型持续可用的前提。
用例模型如何进入团队协作流程
用例模型要在团队中发挥作用，需要解决三个衔接问题：说明文本存在哪里、评审与变更如何保持对应、如何交接给开发与测试。
第一，用例说明应作为需求文档的一部分被承载，与用例清单放在同一处管理，避免图形与文本分散在不同工具中造成版本不一致。第二，评审时应以用例为单位逐条确认主场景与备选流，变更发生时同步更新对应的用例说明，并保留与需求条目的对应关系，使影响范围可追溯。第三，交接给开发时，以用例说明作为行为依据拆分任务；交接给测试时，以主场景与备选流作为设计测试路径的输入。
在工具承载层面，ONES 测试管理解决方案提供用例库，支持通过不同方式导入用例并以清晰的结构组织管理，同时支持丰富的自定义属性以适应不同场景的定制需求。当用例执行发现问题时，可一键创建并关联缺陷，让团队成员围绕缺陷协作；测试活动还可自动生成多维度测试报告并提供灵活的报告模板。这些能力承接的是用例清单的组织、执行与结果反馈环节。对于用例说明文本与需求条目的对应方式、用例图的图形化表达，建议在选型时结合团队实际流程进行核验。
如果团队希望减少在项目、文档与用例之间反复切换的成本，ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，基于相关数据和团队知识回答问题并执行后续操作。这有助于在评审与交接环节快速调取背景信息，但用例内容的判断与取舍仍由团队完成。
常见问题
用例建模适合在什么阶段做，做完之后还需要用户故事吗？
用例建模适合在需求早期做，此时团队需要先看清系统对外提供哪些功能、涉及哪些外部角色、每个功能有哪些主要路径。它给出的是完整行为视图，颗粒度偏大。
进入迭代计划后，通常还需要用户故事把用例中的路径切成可在一个迭代内交付的小块，并补充验收条件。两者配合的方式是：用例负责范围与行为全貌，用户故事负责交付顺序与任务拆分。如果项目规模很小、需求变化极快，也可以只用用户故事加验收条件，但需要额外确认参与者与异常路径是否被覆盖。
系统边界怎么划才算合适？边界变了用例要重做吗？
判断标准是这项行为的结果是否由本系统负责并对外可见。由本系统负责并对外可见的行为放在边界之内，由外部系统或人工完成的放在边界之外。
边界调整后，用例清单需要同步复核，但通常不需要全部重做：受影响的用例调整归属或拆分，未受影响的用例说明可以保留。建议在用例说明中记录边界假设，边界变化时按用例逐条检查参与者、前置条件和备选流是否仍然成立，避免同一功能在不同用例中归属不一致。
用例说明写到多细比较合适？
合适的细度是：业务方读得懂主场景，开发和测试能据此判断系统响应是否正确。主场景按“参与者动作—系统响应”交替书写，保持一条完整可读的路径；备选流标注触发条件和回归主场景的位置。
界面控件名称、字段校验规则、数据库操作这类内容不必写进用例说明，它们会随实现变化而失效。如果某条路径的预期响应无法用一句话说清，往往说明该用例的目标还不够聚焦，可以先考虑拆分用例，而不是在说明里堆细节。
用例和验收条件是什么关系，需要各写一份吗？
用例说明中的主场景与备选流是验收条件的来源。每条路径的预期系统响应，都可以转化为一条可核验的验收条目。
实践中通常不需要把两者写成两份互不相关的内容：用例负责描述行为全貌，验收条件从关键路径中提取可判定的检查点。这样在评审时可以先确认用例路径是否完整，再确认每条路径是否有对应的验收条目，减少遗漏。
团队用工具管理用例时，需要重点确认哪些能力？
可以围绕三个衔接点确认：用例说明文本与用例清单是否放在同一处管理，避免图形与文本版本不一致；用例与需求条目之间能否建立对应关系，变更时便于追溯影响范围；用例执行发现问题后能否直接关联缺陷并汇总结果。
以 ONES 为例，其测试管理解决方案提供用例库，支持通过不同方式导入用例并以清晰的结构组织管理，支持自定义属性；用例执行发现问题时可一键创建并关联缺陷，测试活动可自动生成多维度测试报告。用例说明文本与需求条目的对应方式、用例图的图形化表达，建议结合团队实际流程在选型时核验。
