用例 用例（），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个"场景"，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者"领域专家"的语言。用例一般是由软件开发者和最终用户共同创作的。 在1986年，Ivar Jacobson，UML和瑞理统一过程的重要贡献者，提出了用例的概念。Jacobson的思想很有影响力，也很有发展力。之后在这个科目上又有很多贡献，在定义用例是什么和怎么有效的书写用例方面最重要，最有影响力也最全面的，是Alistair Cockburn，他写的书籍是《编写有效用例》。 用例迅速成为获取功能需求最常用的手段。用例最初是和面向对象一同提出的。但是它不止局限于面向对象系统，因为用例实质上不是面向对象。 由于不少测试工程师将测试用例简称为用例，为便于区分两者，将原来的Use case （页面存档备份，存于-{zh-cn:互联网档案馆;zh-tw:网际网路档案馆;zh-hk:互联网档案馆;zh-sg:互联网档案馆;}-）用例称为需求用例。 测试用例（对应英文Test case （页面存档备份，存于-{zh-cn:互联网档案馆;zh-tw:网际网路档案馆;zh-hk:互联网档案馆;zh-sg:互联网档案馆;}-））已经广为人知，没有歧义，但就文字表面而言，测试用例类似是属于用例，就像红富士苹果属于苹果一样，所以为了更容易区分，需求用例是个更清晰的称呼。 用例范围和目标. 每个用例集中描述如何获得一个业务目标或任务。从传统的软件工程视角来看，用例只是描述了系统的一个特征。所以对大部分软件项目来说，这就意味着需要很多（有可能是数十个）用例来完整的描述新系统。一个特殊软件项目的正规度和项目的不同阶段将会影响每一用例需要的详细程度。 一个用例定义了外部执行者和被考虑的系统之间的交互来实现一个业务目标。执行者是在系统外部和系统交互的人；一个执行者可以是一类用户，用户可以扮演的角色或者其它系统。 用例把系统看作"黑盒"，同系统的交互，包括系统的响应都是可以在系统外部感知的。它是一个deliberate policy，因为它简化了需求的描 述，避免了对功能如何实现做出假设的陷阱。 用例应该： 用例图. 用例图并不是画成了图形的用例。用例图包含一组用例。每一用例用椭圆表示，放置在矩形框中；矩形框表示整个系统。矩形框外画如图所示的小人，表示参与者。参与者不一定是人，可以是其他软件、硬件等等。某一参与者与某一用例用线连起来，表示该参与者和该用例有交互。 许多人通过UML认识了用例，UML定义为展现用例的图形符号。UML并没有为描述用例定义书写格式的标准，因此许多人误认为这些图形符号就是用例本身；然而，图形符号只能给出最简单的一个或一组用例的概要。 UML是用例图形符号最流行的标准。但是，还有一些其它的可选择的标准。 书写用例. 细度. Alistair Cockburn在编写有效用例一书中确定了三种书写用例的细度。 摘要. 摘要用例有很少的句子组成来总结的用例。它十分适合在电子表格中计划软件开发。一个摘要用例能够简单插入电子表格的单元格中并且用表格中的其它列记述业务优先级，技术复杂度，版本号等。 非正式. 一个非正式的用例由文本段落组成，包括了上面提到的那些列，用总结或故事的形式详细的描述了用例。 完整正式. 一个完整正式或者复杂的用例是一个以包含了不同部分的长模板为基础的正规的文档。该用例在下面的用例模板部分进行讨论。 适当使用. 一些软件开发方法学只需要非正式的用例来定义需求。然而，开发方法学需要完整正式或详细的用例来定义需求。较大且较复杂的项目更需要使用完整正式的用例。 用例模板. 编写详细的或完整的用例，尚无通用的模板（）。现在存在很多相互竞争的模板。同时，程序员们也被鼓励用那些适合于他们的工作或者他们所做项目的模板，相对于某个指定模板的细节来说，项目的标准化要重要的多，但是这些模板的关键部分都是大体相同的，所以，虽然在某些术语上或者其他一些方面上存在不同，但是这些用例从本质上来说，是大同小异的。 典型部分包括： 不同的模板经常有其它部分，如，假设，异常流，建议，技术要求。也会有行业细节部分。 用例名称. 用例名称为用例提供了一个唯一标识。它要用动/宾格式书写，并且要充分，达到最终用户能够明白用例中描述的是什么。 迭代. 迭代部分通常需要告知读者用例完成的阶段。最初，为业务分析和确定范围的用例和用于软件开发的用例肯定会有许多不同。老版本的用例可能还在当前文档中，因为它们对不同的用户群可能会有价值。 描述. "描述"部分用于在主体完成之前捕获基本场景。它提供了快速的总结，避免了读者浏览全部内容，能够很快的理解该用例的用途。 前置条件. "前置条件"部分用来表达当用户开始用例时某些条件必须为真。但是它们不是启动用例的触发器。 基本流. 最低限度，每一个用例都需要描述一个"主场景"或者典型事件流。主事件流一般是一组有编号的步骤，如： ……其他 备选流. 用例可能包含第二条路径，或者和主题不同的备选场景。异常或当出错时会发生什么事情也需要描述出来，这种描述可以在备选路径中或者在它本身的部分。备选路径使用基本事件流中的序号来标示在哪一点上同基本场景不同，并且如果合适它从哪一点回到基本场景中。目的是避免不必要的重复信息。 备选流的例子： 异常路径的例子： 后置条件. "后置条件"部分总结了在场景结束后事务的状态。 业务规则. 业务规则是一些成文的或未成文的规则，对于用例来说它决定了一个组织是如何执行业务的。业务规则是一个特殊种类的假定。它可能适用于某一个用例或者整个用例，甚至整个业务。 特别要求. 说明对于本用例的非功能性要求，典型的是并发情况下的响应时间要求，还有易用性要求等等 用例的效益. 用例是一个较新的，比较敏捷的捕获软件需求的形式。用例经常和大的，统一的文档形成对比。这些大文档想要在新系统开始构成前，完整的表达出所有可能的需求，但这种做法通常都是失败的。 用例的几点优势： 用例的局限性. 用例不是没有局限性：