用例粒度是令人困惑的。比如ATM场景取钱场景中，取钱、读卡、验证账号、打印回执单等都是可能的用例，显然，取钱包含了其他用例，取钱的粒度更大一些，其他用例的粒度要小一些。到底是一个大的用例适合还是分解成多个小用例合适呢？
这个没有一个标准的规则，但可以根据以下经验来做，在不同的阶段使用的粒度不同：
在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于需求范围。例如取钱、报装电话、借书等表达完整业务的用例，而不要细节到验证密码、填写申请单、查找数目等业务中的一个步骤。
在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整事件流为宜。可以理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用一些面向对象的方法，归纳和抽象出业务用例中的关键概念模型并为之建模。例如，宽带业务需求中有申请报装和申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料、受理业务、现场安装等多个业务流程中都会使用的概念用例。
在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完成交互为宜。例如，填写申请单、审核申请单、派发任务单等。可以理解为一个操作界面或一个页面流。
另一个参考的粒度是一个用例的开发工作量在一周左右为宜。
实际上，用例粒度的划分依据最标准的方法是以该用例是否完成了参与者的某个完整的目的为依据的！
一般一个用例在大于10个小于50个之间，否则应该考虑一下粒度的选择是否合适了。不管粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。
如果读现则的粒度感到困惑，或者出现同一个阶段粒度大小不一的情况，你应该首先确认你是否选择了一个正确的边界并时时检查自己是否越过了这个边界。