用例

用例（英语：use case），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
在1986年，Ivar Jacobson，UML和瑞理统一过程的重要贡献者，提出了用例的概念。Jacobson的思想很有影响力，也很有发展力。之后在这个科目上又有很多贡献，在定义用例是什么和怎么有效的书写用例方面最重要，最有影响力也最全面的，是Alistair Cockburn，他写的书籍是《编写有效用例》。
用例迅速成为获取功能需求最常用的手段。用例最初是和面向对象一同提出的。但是它不止局限于面向对象系统，因为用例实质上不是面向对象。
由于不少测试工程师将测试用例简称为用例，为便于区分两者，将原来的Use case用例称为需求用例。
测试用例（对应英文Test case）已经广为人知，没有歧义，但就文字表面而言，测试用例类似是属于用例，就像红富士苹果属于苹果一样，所以为了更容易区分，需求用例是个更清晰的称呼。

用例图

用例图并不是画成了图形的用例。用例图包含一组用例。每一用例用椭圆表示，放置在矩形框中；矩形框表示整个系统。矩形框外画如图所示的小人，表示参与者。参与者不一定是人，可以是其他软件、硬件等等。某一参与者与某一用例用线连起来，表示该参与者和该用例有交互。
许多人通过UML认识了用例，UML定义为展现用例的图形符号。UML并没有为描述用例定义书写格式的标准，因此许多人误认为这些图形符号就是用例本身；然而，图形符号只能给出最简单的一个或一组用例的概要。
UML是用例图形符号最流行的标准。但是，还有一些其它的可选择的标准。

细度

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

摘要

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

非正式

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

完整正式

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

适当使用

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

用例名称

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

迭代

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

描述

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

前置条件

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

后置条件

后置条件部分总结了在场景结束后事务的状态。

业务规则

业务规则是一些成文的或未成文的规则，对于用例来说它决定了一个组织是如何执行业务的。业务规则是一个特殊种类的假定。它可能适用于某一个用例或者整个用例，甚至整个业务。

特别要求

说明对于本用例的非功能性要求，典型的是并发情况下的响应时间要求，还有易用性要求等等