1. 用例图中参与者、用例、系统边界的概念。
2. 掌握用例的粒度。
3. 撰写简单用例文本。
用例图中参与者、用例、系统边界的概念
参与者：与系统交互的人或外部系统
关注角色：与系统交互的人
与系统交互的硬件组件
或者其他的外部系统
关注的重点是所承担的“角色”
参与者的名要明确定义其角色
用例：系统为参与者提供的有价值的服务功能。用例定义系统的一系列行为，通过此可为参与者提供有价值且可观测的结果。
用例包含软件系统需求：定义一个参与者要用到的系统功能
描述系统为实现参与者价值所开展的行为序列
对参与者与系统之间的交互活动进行建模
从特定的用户角度出发，是完整的，实现特定用户价值的事件流
关联：用例图中用例与参与者之间的交互关系
参与者与用例之间的交互通道
用一条直线表示交互——关联
有箭头的关联指出谁发起的交互
没有箭头则表明双方都可以发起交互
系统边界：一个系统所包含的所有系统成分与系统之外各种食物的分界线，系统边界会对用例以及参与者的定义有所影响。
用例建模过程中的检查项
用例建模是为了表示系统的行为。通过模型可以很容易理解系统进行的操作
应该识别出所有的用例，用来表达所有的需求。·系统的任何一个特性都可以找到对应的用例
用例模型并不包含多余的行为;所有的用例可以追溯到系统的功能性需求作为验证。
去掉所有的CRUD类的用例
创建(Create)、查找(Retrieve)，更新(Update),删除(Delete)
撰写简单用例文本
(1)找出系统外部的参与者和外部系统，确定系统的边界和范围;
(2)确定每一个参与者所期望的系统行为﹔
(3)把这些系统行为命名为Use Case;
(4)使用泛化、包含、扩展等关系处理系统行为的公共或变更部分;(⒂)编制每一个Use Case的脚本;
(6)绘制Use Case图;
(7)区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单独的Use Case处理;
(8)细化Use Case图，解决Use Case间的重复与冲突问题。
用例的粒度
颗粒度的大小取决与以下三点
1、“重要功能”、“特殊功能”颗粒密集度高，“通用功能”可以试用通用测试粒度，密集度应该可以大致界定。个人认为，假如你非要为了一个字体的样式而写了一大长串的测试用例 ，那么这个颗粒度就毫无意义了。
2、颗粒度的大小还取决与客户对“产品”的要求。测试有一个难题是测试的精度，或者说颗粒度的定义，不要说一个程序，就算是一个简单的登录都可以写出几乎无穷尽的测试用例，所以你需要指明功能、性能需求，使用环境等，并说明对缺陷容忍的限度。才好依据最终的需求来定义测试的颗粒度，也才好写测试用例，总之，客户的要求越详细所得到的测试用例越准确。如果客户跟你说这个地方你必须仔仔细细的测试。那么我们在写测试用例的时候。这个颗粒度一定要小了。
3、一般功能颗粒密集度可能会根据项目或是时间来确定。如果时间充裕颗粒度可以适当小。
4、粒度取决于测试的种类，一般用验收测试,是项目测试中颗粒度比较大。系统测试颗粒度相对较小。