用例范围和目标

　　每个用例集中描述如何获得一个业务目标或任务。从传统的软件工程视角来看，用例只是描述了系统的一个特征。所以对大部分软件项目来说，这意味着需要很多（有可能是数十个）用例来完整的描述新系统。一个特殊软件项目的正规度和项目的不同阶段将会影响每一用例需要的详细程度。

　　一个用例定义了外部执行者和被考虑的系统之间的交互来实现一个业务目标。执行者是在系统外部和系统交互的人；一个执行者可以是一类用户，用户可以扮演的角色或者其它系统。

　　用例把系统看作"黑盒"，同系统的交互，包括系统的响应都是可以在系统外部感知的。它是一个deliberate policy，因为它简化了需求的描述，避免了对功能如何实现做出假设的陷阱。

　　用例应该:

　　描述了满足业务目标的业务活动

　　没有涉及特定的实现语言

　　要求合适的细节级别

　　足够短，使得在一次发布中能够被一个软件开发人员实现

　　Image:UMLUSE.PNG展现用例的图形符号。 UML并没有为描述用例定义书写格式的标准，因此许多人误认为这些图形符号是用例本身；然而，图形符号只能给出简单的一个或一组用例的概要。

　　用例图

　　许多人通过UML认识了用例，UML定义为

　　UML是用例图形符号流行的标准。但是，还有一些其它的可选择的标准。

　　书写用例

　　细度

　　Alistair Cockburn 在编写有效用例一书中确定了三种书写用例的细度。

　　摘要

　　摘要用例有很少的句子组成来总结的用例。它十分适合在电子表格中计划软件开发。一个摘要用例能够简单插入电子表格的单元格中并且用表格中的其它列记述业务优先级，技术复杂度，版本号等。

　　非正式

　　一个非正式的用例由文本段落组成，包括了上面提到的那些列，用总结或故事的形式详细的描述了用例。

　　完整正式

　　一个完整正式或者复杂的用例是一个以包含了不同部分的长模版为基础的正规的文档。该用例在下面的用例模版部分进行讨论。

　　适当使用

　　一些软件开发方法学只需要非正式的用例来定义需求。然而，开发方法学需要完整正式或详细的用例来定义需求。较大且较复杂的项目更需要使用完整正式的用例。

　　用例模版

　　没有一个意见一致的模版来编写详细的或fully dressed 用例。 There is no agreed template for documenting detailed or fully dressed use cases. There are a number of competing schemes and individuals are encouraged to use templates that work for them or the project they are on. Standardisation for each project is more important than the detail of a specific template. However， there is considerable agreement about the core sections; and so beneath different terminology and order there is an underlying similiarity between most use cases. (现在存在很多相互竞争的模板。同时，程序员们也被鼓励用那些适合于他们的工作或者他们所做项目的模板，相对于某个指定模板的细节来说，项目的标准化要重要的多，但是这些模板的关键部分都是大体相同的，所以，虽然在某些术语上或者其他一些方面上存在不同，但是这些用例从本质上来说，是大同小异的。)

　　典型部分包括:

　　用例名

　　迭代

　　综述

　　前置条件

　　触发器

　　基本事件流

　　备选路径

　　后置条件

　　业务规则

　　说明

　　作者和日期

　　不同的模版经常有其它部分，如，假设，异常，建议，技术要求。也会有行业细节部分。

　　用例名

　　用例名为用例提供了一个标示。它要用动/宾格式书写，并且要充分，达到终用户能够明白用例中描述的是什么。

　　迭代

　　迭代部分通常需要告知读者用例完成的阶段。初，为业务分析和确定范围的用例和用于软件开发的用例肯定会有许多不同。老版本的用例可能还在当前文档中，因为它们对不同的用户群可能会有价值。

　　综述

　　综述 部分用于在主体完成之前捕获基本场景。它提供了快速的总结，避免了读者浏览全部内容，能够很快的理解该用例的用途。

　　前置条件

　　前置条件 部分用来表达当用户开始用例时某些条件必须为真。但是它们不是启动用例的触发器。

　　触发器

　　触发器 部分描述了启动用例的起始条件。