RUP里有两个重要的概念，用例和业务用例。初识RUP人常常会问，到底什么是用例，用例和业务用例的区别是什么。以下简要说明一下用例以及用例与业务用例之间的区别。

　　用例又叫系统用例，是一种软件需求定义的方法或形式。基于用例的需求定义方法与其他需求定义方法相比，有如下一些特点：

　　一、用例更加从用户（actor）的角度定义需求、强调用户目标，因此很容易为用户所理解。

　　传统以特性或功能的方式定义需求常常表现为系统必须这样或系统应该那样。如在描述一个在线书店的系统时，基于特性的方法会描述为：

　　1、系统应该提供搜索功能；

　　2、系统必须具备分类浏览的功能；

　　3、系统必须具有按折扣计算最终价格的能力等。

　　系统需求以一条条孤立的特性的方式表现出来，如果系统相对复杂，用户可能就会发出如下的疑问：“系统到底能帮我做什么，怎么帮我做的？”。用例正好回答了这个问题。以用例的方式定义需求处处关心用户到底想用系统做什么，如何做。例如，上例中网上书店系统，用户到底用它做什么呢？购书！嗯，购书就是其中的一个用例。接着，在购书这个用例中就会具体描述用户怎样和系统交互并最终完成购书过程。基本事件流示意如下：

　　1、用户准备在网上书店购书，用例开始。

　　2、用户浏览图书分类，查找图书。系统显示分类、子分类以及子分类下的图书。

　　3、用户选择准备购买的图书，并加入购物车。系统记录已加入购物车的图书并计算价格。

　　4、用户准备结账，系统提示确认购物清单，并提示输入银行账号、送货地址等关键信息。

　　5、用户输入以上信息，并确认。系统完成交易，并显示交易信息。用例结束。

　　二、用例不是功能也不是特性，用例不能被逐层分解为更小的用例。

　　用例的价值在于展现系统最终能帮用户做什么以及如何做到的。如果我们试图分解用例，那么谁去承担这个责任呢？最终结果与以特性方式定义需求相比又能有什么优越性呢。

　　在FDD方法中，提倡将基于特性的需求描述方式改进为以特性集的方式来描述需求，即将任务相关性强的特性组织在一起。在XP中，需求以用户故事的方式来描述，即以相对随意的方式描述用户怎么使用系统完成任务。可见关注用户任务的整体性并不是用例特有的。只是用例方法更为形式化一些。