1. 用例图概述
用例图（Use Case Diagram）：描述“用户、需求、系统功能单元”之间的关系，是参与者所能观察和使用到的系统功能模型图。
用例用于软件开发过程中的需求分析阶段。
确立系统边界分内外：
（1）外，找参与者，不需要开发，但需考虑建立接口，让系统内外可以通过接口传递信息。
（2）内，找用例，需要考虑开发的部分。
先找出参与者，再从参与者角度去寻找用例。
用例图 = 参与者（Actor） + 用例（Use Case）+ 关系（Relationship）
2. 参与者（Actor）
3.1 参与者定义
参与者是系统外部的实体，它以某种方式参与用例的执行过程。参与者位于系统边界之外，不是系统的组成部分。
参与者通过向系统中输入某些事件来触发系统的执行，每个参与者可以参与一个或多个用例。
在UML中，参与者使用人形表示，每个参与者都必须有一个名称且不能重复。参与者名称推荐使用对象名词。
参与者一般分为三类：系统用户、其他系统、可运行的进程。
（1）系统用户。最直接的参与者，需要使用系统的用户。
（2）其他系统。在当前系统范围之外，需要建立与其他系统的接口。
（3）一些可运行的进程。如时间，当经过一定时间段后，发生系统中的某个事件时，时间成为参与者。
3.2 识别参与者
获取用例之前，首先要确定系统的参与者。
参与者的识别方法：
（1）系统主要功能的使用者；
（2）系统的维护/管理人员；
（3）需要接入的其它设备（如：打印机、扫码枪等）；
（4）需要接入的其它系统；
（5）时间是否会触发某些事件。
3. 用例（Use Case）
3.1 用例定义
用例是外部可见的系统功能部分，是系统的行为，是参与者在系统中做某件事从开始到结束的一系列活动的集合，以及结束时应该返回的结果，其中可能包含各种分支情况。
每个用例的执行都独立于其它用例，每个用例都表示一个功能模块。
在UML中，用例用一个椭圆表示，每个用例都必须有一个名称且不能重复，用例名称推荐使用动宾短语（动词+对象名词）。
2.2 识别用例
确定用例的方法是从参与者开始，考虑每个参与者是如何使用系统的。
用例的识别方法：
（1）参与者希望系统提供什么功能？
（2）当系统改变状态时，是否通知参与者？
（3）是否存在什么外部事件发生时需要系统知道的，哪个参与者通知系统这些事件？
（4）是否存在什么外部事件发生时，需要系统自动执行什么操作？
（5）系统是否需要定期执行什么操作？
（6）这个用例是否有多种不同结果？
3. 关系（Relationship）
在UML用例图中，关系共包括6种：关联（Association）、直接关联（DirectedAssociation）、泛化（Generalization）、依赖（Dependency）、包含（Include）和扩展（Extend）。
3.1 参与者之间关系
参与者之间存在的关系：泛化（Generalization）。
参与者之间的泛化关系用来描述多个参与者之间的公共行为。
示例：
3.2 参与者与用例之间关系
参与者与用例之间关系包括：关联（Association）、直接关联（DirectedAssociation）。
参与者与用例之间关联或直接关联的关系可以为多对多，即一个参与者可以参与多个用例，一个用例可以隶属多个参与者。
当参与者与用例之间直接关联时，箭头由参与者指向用例。
主参与者与次参与者：主参与者是用例的重要服务对象，而次参与者则为协助。
3.3 用例之间关系
用例之间的关系包括：包含（Include）、泛化（Generalization）和扩展（Extend）。
3.3.1 包含关系
包含关系：要完成包含用例，就一定要先执行被包含用例。
在UML中，包含关系用虚线箭头加<<include>>来表示，箭头指向被包含的用例。
示例：
3.3.2 泛化关系
用例泛化：一个用例可以被特别列举为一个或多个子用例。当父用例能够被使用时，任何子用例也可以被使用。子用例可以从父用例继承属性与行为，还可以添加、改变继承的行为。
在UML中，泛化关系用一个三角箭头从子用例指向父用例。
示例：
3.3.3 扩展关系
扩展关系是一个用例被定义为基础用例的增量扩展，通过扩展关系把新的行为插入到已有用例中。扩展关系中，扩展用例是基础用例的一个相对独立并且可选的用例。
在UML中，扩展关系用虚线箭头加<<extend>>表示，箭头指向基础用例，即被扩展的用例。
示例：读者在归还图书馆借书时，若超过应归还日期，则需要超期罚款；若未超过归还日期，则不需要超期罚款。
4. 用例描述
| 用例名称 | |
| 用例编号 | |
| 用例描述 | 描述用例的作用，包括执行用例的不同类型用户和通过用例所达到的效果。 |
| 参与者 | |
| 用例图 | |
| 前置条件 | 用例的必须满足的条件。置条件是另一个用例已经执行或用户具体有运行当前用例的权限。并不是每个用例都有前置条件。 |
| 触发器 | |
| 基本事件流 |
从用户角度描述执行用例的具体步骤 用例的开始、交互、正常流程、结束。 |
| 扩展事件流 | 用例的分支事件流、错误事件流 |
| 业务规则 | |
| 后置条件 | 用例执行完后必须为真的条件。并不是每个用例都有后置条件。 |
| 特殊需求 |
5. 用例建模
用例建模方法如下：
（1）识别参与者
（2）识别用例
（3）整理用例关系
（4）编写用例需求描述，确定用例优先级。