用例类型
用例类型有的翻译为版型；英文为stereotype。用例类型一般分为：普通用例(usecase)和业务用例(business usecase).
需求分析阶段的用例类型
1.业务建模
业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生。这个阶段通常使用业务用例类型；
2.用例分析
用例分析是系统分析员采用 OO 方法来分析业务用例的过程，这个阶段又称为概念模型阶段。这个阶段通常使用无类型的用例。 用例分析是一个过渡过程，但笔者认为其非常重要， 业务架构通常在这个阶段产生。
3.系统建模
系统建模是将用户的业务需求转化为计算机实现的过程。这个阶段通常使用无类型的用例和用例实现两种类型。系统范围， 项目计划，系统架构通常在
这个阶段形成雏形（在系统分析阶段确定）。
所谓 business usecase，是用来描述用户原始需求的， 它的含义是站在用户的角度， 使用用户的业务术语来描述用户在其业务领域所做的事情。
业务用例命名、描述都不必须采用纯业务语言。而不能使用计算机术语。因为业务模型是系统分析员与用户讨论需求， 达到一致理解的基础， 必须使用用户熟悉的，不会有歧义的专业术语以避免系统分析员与用户对同一事件的理解误差。
笔者自己在用例分析和系统建模阶段不区分用例类型， 都使用无类型的 use case， 但在这两个阶段， 用例的含义还是有所差别的。 用例分析阶段， 用例主要是从业务模拟的概念上， 从 OO 的视角来分解、 组合业务用例， 粗略的建立一个业务架构。 而在系统建模阶段， 用例主要是从计算机视角描述需求， 规定开发范围，作为项目计划的依据， 为系统设计做准备。
用例粒度
粒度是令人迷惑的。 比如在 ATM 取钱的场景中， 取钱， 读卡，验证账号， 打印回执单等都是可能的用例， 显然， 取钱包含了后续的其它用例， 取钱粒度更大一些， 其它用例的粒度则要小一些。 到底是一个大的用例合适还是分解成多个小用例合适呢？ 这个问题并没有一个标准的规则， 笔者可以给大家分享的经验是根据阶段不同， 使用不同的粒度。在业务建模阶段， 用例的粒度以每个用例能够说明一件完整的事情为宜。 即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。 例如取钱， 报装电话， 借书等表达完整业务的用例， 而不要细到验证密码， 填写申请单， 查找书目等业务中的一个步骤。在用例分析阶段， 用例的的粒度以每个用例能描述一个完整的事件流为宜。 可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用 OO 方法， 归纳， 抽象业务用例中的概念模型。 例如， 宽带业务需求中有申请报装， 申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料， 受理业务，现场安装等多个业务流程中都会使用的概念用例。在系统建模阶段， 用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。 例如， 填写申请单， 审核申请单， 派发任务单等。 可理解为一个操作界面， 或一个页面流。在 RUP 中， 项目计划要依据系统模型编写， 因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。
实际上，用例粒度的划分依据（尤其是业务用例） 最标准的方法是一个用例的粒度是否合适， 是以该用例是否完成了参与者的某个目的为依据的。举个例子， 某人去图书馆， 查询了书目， 出示了借书证， 图书管理员查询了该人以前借阅记录以确保没有未归还的书， 最后借到了书。 从这段话中能得出多少用例呢？ 请记住一点， 用例分析是以参与者为中心的， 因此用例的粒度以能完成参与者目的为依据。 这样， 实际上适合用例是： 借书。 只有一个，其它都只是完成这个目的过程——这里讨论的用例指的是业务用例——这个例子是比较明显的能够区分出参与者完整目的的， 在很多情况下可能并没有那么明显， 甚至会有冲突。
不论粒度如何选择， 必须把握的原则是在同一个需求阶段， 所有用例的粒度应该是同一个量级的。
参考：
OO_Raod coffeewoo