业务用例模型的目的在于：

1． 描述企业的内部组织结构

2． 描述企业各部门的业务

3． 关注于角色和系统的交互界面

业务用例是用来捕获功能性需求的，功能性需求是由actor的业务目标来体现的。也就是对于actor来说，他所负责的业务需要由一系列的业务目标组成。比如一个档案管理员，他的业务目标就是维护档案。比如论坛管理员，他的业务目标有维护用户，维护帖子等..这些业务目标构成actor职责的全部。业务用例体现了需求。

业务用例的不同类型

当考查业务中的活动时，您至少可以确定三类工作，它们对应着三种业务用例类型。

• 第一类是在商业上比较重要的活动，常称为业务流程。
• 第二类是在商业上不太重要的活动，但必须进行这些活动来保证业务正常运转。系统管理、清洁和安全等工作就是这类活动的示例。该业务用例具有支持的性质。
• 第三类是管理工作。具有管理性质的业务用例所显示的工作影响如何管理其他业务用例以及该业务和其所有者的关系。

好的业务用例的特征

其名称和简要说明清晰易懂，甚至对业务建模团队之外的人来说也是如此。
从外部（即主角的）角度看，每个业务用例都是完整的。例如，保险公司的“索赔处理”业务用例以一个客户提交索赔请求开始。如果不包含保险公司向客户发出有关索赔请求处理决定的通知或（在同意赔偿的情况下）保险赔偿的支付，则“索赔处理”业务用例是不完整的。
每个业务用例一般至少涉及一个主角。业务用例由主角启动，通过与主角进行交互来完成活动并交付结果。
支持用例可能不与主角进行交互，不过这种情况不太常见。如果业务用例由某个内部事件启动，并且不必和主角进行交互即可完成活动，则可能出现上述情况。

建立业务用例模型

1.识别业务参与者

2.识别业务用例

3.详述业务用例

每个核心业务用例都应该和某个业务主角之间存在通信关系。该规则强调了构建业务的目的，即构建业务是为了提供用户要求的服务。如果业务用例模型中存在无人要求的业务用例，这就说明模型存在问题。

业务用例可以周期性地触发，也可以长时间工作；监督功能就是后者的一个示例。这些业务用例中甚至还存在最初启动这些业务用例并期望得到不同服务的业务主 角。否则，它们将不能成为业务的一部分。其他业务用例将产生业务主角需要的结果，尽管业务主角并没有明确地启动它们。例如，某个广泛发布产品的开发很少是 由某个可以确定的客户启动的。而对新产品的需求通常是通过市场研究和积累大量的用户请求了解到的。

尽管管理和支撑业务用例一般都有某种外部联系，但它们不一定需要与业务主角进行联系。例如，管理业务用例可以将业务的所有者或董事会作为其业务主角。

抽象业务用例不需要业务主角，因为它们从不独立进行实例化（“启动”）。