用用例整理用户需求
📅
开始之前 🔗
上一篇介绍了几种分析方法，用来发现用户没有明确说出的需求。
收集到需求后，还要清楚、有条理地整理它们，让各方对目标达成共识，帮助开发团队沿着正确方向前进。
今天来详细了解
用例（Use Case）
。它帮助我们从用户的角度
整理和表达需求，重点关注用户希望通过系统达成什么目标
。
本文介绍用例的基本概念、参与者与场景的作用，以及如何编写用例规约。绘制用例图的方法将在下一篇文章中介绍。什么是用例（Use Case）？ 🔗
用例的概念最早由瑞典计算机科学家 Ivar Jacobson 提出。它从用户视角描述系统为用户或其他系统提供的
有价值的功能
。
这里的“用户”除了与系统交互的人，也可以是外部系统或设备，统称为参与者（Actor）
。简单来说，用例以场景的形式回答：“哪个参与者使用系统，达成什么目标？”
以网上书店系统为例，可以列出以下用例。
- “会员搜索图书。”
- “会员订购图书。”
- “管理员登记新书。”
在用例图中，用例通常用椭圆表示，参与者用人形图标表示。用例图可以直观展示系统的整体功能范围。
用例的主要价值在于说明每个用例细节的
用例规约（Use Case Specification 或 Use Case Description）
。用例的核心组成 🔗
要理解和编写用例，需要明确以下三个核心概念。
1. 参与者（Actor） 🔗
参与者位于系统
外部
，可以是人、其他系统或设备，通过与系统交互达成目标。
参与者可能发起用例，也可能受到用例结果的影响。主要参与者（Primary Actor） 🔗
为达成某个用例的目标而使用系统的主要角色，通常由其发起用例。
例如，“订购图书”用例的主要参与者是会员。
次要参与者（Secondary Actor / Supporting Actor） 🔗
在主要参与者达成目标的过程中，为系统提供协助或与系统交换信息的角色。
例如，在“订购图书”用例中，与系统交互以处理付款的外部支付系统就是次要参与者。
特点 🔗
参与者在系统边界之外。
参与者表示一种角色（Role）。同一个人或系统可以扮演多个角色。
在用例图中，参与者通常用人形图标表示。
2. 用例（Use Case） 🔗
用例表示某个参与者希望通过系统达成的
目标
，对应系统向参与者提供的一项完整功能。
用例名称通常采用动词短语，例如“用户登录”“发布文章”或“搜索商品”。特点 🔗
用例应向参与者提供有意义的结果。
一个用例可以包含多个场景。
在用例图中，用例用椭圆表示。
3. 场景（Scenario） 🔗
场景具体描述某个用例从开始到结束时，参与者与系统之间发生的
一系列交互步骤
。
它就像戏剧中的一幕，按顺序展示在什么条件下、谁做了什么，以及产生了什么结果。基本流程（Basic Flow / Main Success Scenario） 🔗
这是用例最常见、顺利完成时的“理想路径（Happy Path）”。
它描述参与者在没有遇到异常或错误的情况下达成目标的过程。
备选流程（Alternative Flows） 🔗
描述偏离基本流程，但参与者仍能达成目标的其他路径。
例如，选择不同选项，或在满足特定条件时采用另一种处理方式。
异常流程（Exception Flows / Error Flows） 🔗
描述用例执行过程中出现错误，或参与者无法达成目标的情况。
例如，输入无效或系统故障。
每个用例都有一个基本流程，也可以有多个备选流程与异常流程。 详细描述这些场景，是编写用例规约的核心。
编写用例规约 🔗
用例规约是一份记录各个用例详细信息的文档。
它没有固定模板，但通常包含以下项目。
- 用例编号（Use Case ID）用于唯一标识用例的编号，例如 UC-001。
- 用例名称（Use Case Name）简要体现用例目的的名称，例如“注册会员”。
- 参与者（Actors）与用例有关的主要和次要参与者。
- 简述（Brief Description）用一两句话概括用例的目的和主要功能。
- 前置条件（Preconditions）用例开始前必须满足的条件，例如“用户必须已登录”。
- 后置条件（Postconditions）用例成功完成后的系统状态或应保证的条件。例如，“新会员信息保存到数据库”“向会员发送欢迎邮件”。
- 基本流程（Basic Flow / Main Success Scenario）按顺序记录用例成功执行的主要步骤。
- 备选流程（Alternative Flows）描述偏离基本流程的其他成功路径。
- 异常流程（Exception Flows）描述发生错误时的处理过程，或用例失败的场景。
- 特殊需求（Special Requirements）相关的非功能需求，例如性能、安全或业务规则。
- 其他信息（Notes and Issues）补充说明或尚未解决的问题。
用例规约示例：在网上书店订购图书 🔗
下面是“会员在网上书店系统中订购图书”的简要规约示例。
1. 用例编号
UC-ORD-001
2. 用例名称
订购图书
3. 参与者
- 主要参与者：会员
- 次要参与者：支付系统、库存管理系统
4. 简述
会员选择需要的图书，付款后完成订单。
5. 前置条件
- 会员必须已经登录系统。
- 购物车中至少有一本要订购的图书。
6. 后置条件
- 成功时，系统记录订单信息。
- 成功时，所订图书的库存减少。
- 成功时，系统向会员显示订单完成通知，并发送邮件。
- 失败时，不记录订单信息，并告知用户失败原因。
7. 基本流程（Main Success Scenario）
- 会员在购物车页面点击“下单”。
- 系统显示订购商品列表与应付总额，并提供填写收货信息的界面。
- 会员填写收货信息并点击“继续付款”。
- 系统显示支付方式选择界面。
- 会员选择支付方式、填写付款信息，然后点击“付款”。
- 系统向库存管理系统查询所订图书的库存。
- 库存管理系统返回库存充足的响应。
- 系统向支付系统发起付款请求。
- 支付系统返回付款成功的响应。
- 系统保存订单信息，并请求库存管理系统扣减库存。
- 系统向会员显示订单完成页面，并发送订单确认邮件。
8. 备选流程（Alternative Flows）
- 8.1. 更改收货地址在基本流程第 3 步，会员可以输入或选择新的收货地址。系统保存新的收货信息。
- 8.2. 使用优惠券在基本流程第 4 步，会员可以使用已有的优惠券。系统计算并显示折扣后的最终应付金额。
9. 异常流程（Exception Flows）
- 9.1. 库存不足在基本流程第 7 步，如果库存管理系统返回某本图书库存不足：
- 系统向会员显示该书库存不足的消息。
- 会员可以移除该书后继续下单，也可以取消订单。
- 9.2. 付款失败在基本流程第 9 步，如果支付系统返回付款失败：
- 系统向会员显示失败消息及原因，例如超出限额或银行卡信息无效。
- 会员可以更换支付方式，或修改付款信息后重试。
- 9.3. 系统故障处理订单时发生意外系统故障：
- 系统向用户显示提示，例如“暂时出现错误，请稍后重试。”
- 系统将错误信息写入日志。
10. 特殊需求
- 订单处理过程中的所有敏感信息，包括个人信息和支付信息，都必须加密。
- 从开始处理到订单完成，平均响应时间必须不超过 5 秒。
用例规约为各项功能提供详细场景，帮助开发团队准确理解用户需求，并作为实现系统的依据。
结语 🔗
今天介绍了用例，这是一种从用户视角定义和分析系统功能的工具。
我们了解了参与者、用例与场景的基本概念，也学习了用例规约的编写方法和要点。
下一篇将介绍如何描绘系统全貌、定义它与外部的关系，也就是系统建模：如何使用上下文图和活动图。
参考资料 🔗
- Use case - Wikipedia↗（英文，维基百科的用例条目）
- Use Case Tutorial - Visual Paradigm↗（英文，用例教程）
