背景
许多人都知道也会使用到使用案例 (Use Cases)，但是却很少有人能够明确了解使用案例的定义以及合适的使用时机，我们也时常可以看到复杂而庞大使用案例让人变得难以真正理解系统概括的需求。
使用案例最早是在1986年由Ivar Jacobson所提倡的（在UML出现之前），他也是UML的主要贡献者之什么是使用案例
使用案例本身并不是指图形，而是一种文字型的文件，建立使用案例时主要的工作也是在撰写说明文字而非画图。之后UML定义了使用案例的图形，主要目的来展现使用案例中参与者与使用案例之间的名称与关系。
基本上使用案例代表了系统的功能性需求（或行为）。
使用案例中有参与者，参与者可以是人、计算机系统或组织等。例如在POS系统中，收银员是一个参与者。而使用案例主要便是描述参与者使用系统而达到目的的一组情节（包含成功情节与失败情节）。如果我们有一个POS的使用案例名称是处理退货，在这则使用案例中我们会详细描述收银员处理退货的步骤（情节）。
在对象导向分析中我们也可以使用互动图形来协助描述这些情节，例如循序图或者合作图，这也称为使用案例实例，但是并不是因此就代表我们可以省略文字来描述使用案例中的情节。
从另一个角度来看，使用案例是分析需求的工具，而我们做完需求分析之后，我们需要与客户确认需求的分析结果正确与否，只有严谨仔细的文字描述才有可能得到客户的签字认可，相信没有人会认为画几个UML中的使用案例图形就可以让客户签字吧（当然前提是客户需要懂得使用案例）。
用EBP（企业基本流程）作为找出使用案例的原则
许多人在定义使用案例时都会遭遇到没有一个可以依循的标准来作为使用案例的遵循依据。在这里介绍一个可以遵循的参考。
EBP：基本企业流程（BASIC BUSINESS PROCESS）
EBP的定义是，为了响应某个企业事件，一个人在某个地方、某个时间点所执行的工作。这个事件会增加可衡量的企业价值，并且让数据处于一致状态。也就是喔，当我们在寻找使用案例时，焦点应该放在能够增加企业看得见的价值的工作。例如，核准信用卡或者处理订单。换个角度来说，我们会说撰写企画书是一项有价值的工作，而非打开计算机或者使用WORD这样的工作。
关键在于：能够增加企业可衡量的价值
例如，登入系统显然并不能增加企业价值，特别是当老板询问你今天作了什么，而你回答『登入系统二十次』时。所以我们在找出使用案例时，应该避免用在描述过多低阶的需求上，而使得使用案例变得庞大而失焦，并且最后变得无法管理。
但某些低阶重要的使用案例则可以权衡的出现，例如『使用信用卡付款』这个使用案例并不能符合EBP指引，但是这样的子工作可能反复出现在基本使用案例中，因此我们可能会将他分离出来变成独立的使用案例。
使用案例应该符合参与者的目标（USER GOAL），这样的使用者案例称为使用者层级使用案例。

因此使用案例的重点在于：寻找使用者想要达成的目标，而非使用者想做什么。当我们询问使用者想做什么时，可能会得到笼统而且错误的答案，结果并不符合使用者真正的需求。
定义使用案例的四个基本流程
我们可以依循以下四个步骤来找出符合我们需要的使用案例来。
1. 选择系统边界：软件系统或者是软件体整合系统，使用者是个人或者组织。
2. 找出主要参与者：这些使用者会透过系统所提供的服务满足他们的目标。
3. 针对每个主要参与者，找出他的使用者目标。把这些使用者目标变成满足EBP指引的高阶使用者目标层级。并且在稍后列出参与者目标清单。
4. 定义满足使者目标的使用案例：根据这些目标替使用者案例命名。通常目标与案例是一对一的。
本篇文章主要的目的不在解释如何画出UML中的使用案例图形，而在于让读者了解使用案例的概念以及使用的时机，只要能够了解使用案例的精神，使用什么样的工具来辅助都是可以接受的。