需求：系统必须满足的条件或具备的能力，以用例为中心组织需求
1.角色（谁来做）：
（1）角色是群体概念，即角色代表一类能使用某个功能的人或外部系统、外因素、外时间，不是指某个个体
（2）每个角色可以参与一个或多个用例
（3）在系统的实际运作中，一个实际用户可能对应系统的多个角色
如何识别角色：
&谁使用系统的主要功能
&谁改变系统的数据
&谁从系统获取信息
&谁需要系统的支持以完成日常工作任务
&谁负责日常维护、管理并保证系统正常运行
&谁使用或删除系统中的信息
&谁（或什么）对系统运行产生的结果（值）感兴趣
&系统需要应付（处理）那些硬设备
&系统需要和那些外部系统交互
&在预定时间，是否有事件自动发生
&时间、气温等内部外部条件
2.用例（做什么）：
为完成一个相对完整的一种功能，系统执行的一系列动作的集合
用例的动态执行过程可以用U M L的交互作用来说明，可以用状态图、顺序图、协作图或非正式的文字描述来表 示
区别：
- 活动图：适合描述多个对象跨越多个用例时的总面貌
- 交互图（顺序图、协作图）：适合描述单个用例中多个对象之间的协作行为
- 状态图：适合描述跨越多个用例的单个对象的行为，不适合描述多个对象之间的协作行为
简洁识别用例：参与者使用系统达到目标
3.识别用例要点：
可观测→用例止于系统边界
结果值→用例是有意义的目标
系统执行→结果值由系统生成
3.4 由参与者观测→业务语言、用户观点
一组用例实例→用例的粒度：
3.5.1过细的粒度，一般都会导致技术语言的描述，而不再是业务语言
3.5.2 创建用例容易导致关心数据的存储和维护，反而忽略了用户的目的，如下图：
3.5.3 不管是C、R、U、D，都是为了完成“管理”目标；
甚至很多种的基本数据管理都可以用一个用例表示
用例命名
4.0 用例关系
4.1 关联关系：
关联关系描述参与者与用例之间的关系，描述它们之间的通信
4.2 包含关系：
用例与用例间的关系
肯定有的，非可选，不写不完整，可以简单认为源代码中的函数调用或操作调用
4.3 扩展关系
用例与用例间的关系
4.3.1 在前一个事例的多种选择中选择，将导致不同的结果
4.3.2 存在评定点（特定条件是超期，如果满足特定条件，将执行“交纳罚金”这个扩展用例）
4.4 泛化关系
在前一个事例的多种选择中选择，将导致相同的结果（ 父用例能够被使用的时候，任何子用例也能够被使用， 子用例之间是一种平行关系）：
还有就是参与者之间的泛化关系，它们之间通常不需要特殊条件触发，所以很明显用泛化而不是拓展
