1. 基本概念
一个用例就是与参与者（actor）交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。
所谓的用例就是一件事情，要完成这件事情需要做一系列的活动；而做一件事情可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中称之为用例场景，一个场景就是一个用例的实例。
要启动用例是有条件的，这是启动用例的前提（前置条件）；用例执行完了会有一个结果，成为后置条件。
综上所述，一个完整的用例由参与者、前置条件、场景、后置条件构成。
2. 用例的特征
- 用例之间是相互独立的
- 用例的执行结果对参与者来说是可观测且有意义的
- 不存在没有参与者的用例，参与者启动用例（用例不应该自动启动，也不应该主动启动另一个用例）
- 用例必然是以动宾短语形式出现的（构成一个完整的事件，例如喝水而不是喝）
- 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元
3. 用例的粒度（如何细分/尺度的确定）
- 业务建模阶段：一个用例可以描述一项完整的业务流程（这有助于明确需求范围）
- 概念建模阶段：一个用例能描述一个完整的事件流（一项完整业务中的一个步骤）
- 系统建模阶段：一个用例能描述操作者与计算机的一次交互
总结：粒度选择问题本质上由边界的认定不同而产生，原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。
4. 用例的获得
用例的定义就是：由参与者（actor）驱动的，并给其提供可观测的有意义的结果的一系列活动的集合。
所以用例的来源就是：参与者（actor）对系统的期望。
所以发现用例的前提条件就是：发现参与者；而确定参与者的同时就确定了系统边界。
接下来通过以下问题引导业务代表，并从访谈结果中找出用例：
- 您对系统有什么期望？（一件可以做的事，而不仅仅是一个主观愿望）
- 您打算在这个系统里做些什么事情？
- 您做这件事的目的是什么？
- 您做完这件事希望有一个什么样的结果？
应当确保： - 一个明确的有效目标才是一个用例的来源
- 一个真实的目标应当完备地表达主角的期望
- 一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果
如果发现有些业务总是说不清，应当考虑重新进行访谈，并考虑以下策略： - 调整系统边界和主角
- 扩大或缩小系统边界
- 变更主角
- 然后重新开始
5. 用例的实现
完整叫法是系统用例的实现，不过系统二字可以省略。用例实现是连接用例模型和系统实现之间的桥梁，也是实现对象追溯到需求的一个重要环节。