0 概述
对于信息系统开发团队来说，最主要挑战就是能够从关联如人员（PD、甲方、业务等）提取出争取的确实需要的系统需求，并以关联人员可以理解的方式进行说明，以便需求可以得到证实和验证。用例建模是一种以用户为中心的开发方法，通过用例工具确定和描述系统功能，在从用户和关联人员那里确定系统需要做什么很有用。
当我们进行业务系统架构设计时，我们需要进行业务域划分、功能模块拆分等；做好这件事情前提是我们要做好需求用例分析，识别出全业务全景的用例集合。本文主要从2W1H思路谈谈对用例的理解。
1 什么是用例
维基百科的定义：用例（use case ）用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。
UML文档中定义：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。可以简单理解为就是对系统功能描述。
通俗的讲，用例是文本形式的情节描述，是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现目标。参与者是某些具有行为的事物，可以是人或者某个系统或者组织等，例如：收银员，商品系统。场景是参与者和系统之间的一系列特定的活动或者交互，这也称为用例实例，场景是使用系统的一个特定情节或者用例的一条执行路径。用例是文本文档，而非图形，用例建模主要是编写文本的活动而非制图，这也常见的初学者常见的错误。
案例：消费者使用京东购买手机，这里参与者是消费者（买家）其目标是使用京东系统购买手机，成功的场景：用户下单成功，失败的场景：用户下单扣减库存失败，下单失败。
2 为什么要使用用例
用例强调以用户为中心，可以从用户和关联人员那里确定系统需要做什么，这也是确保项目成功的主要关键因素之一，另外用例还有以下优点。
● 用例是一种优秀的方法，使领域专家或者需求提供者自己编写用例成为可能，并使这项工作难度降低。
● 用例的价值是强调的用户的目标和观点，强调以用户为中心，谁使用系统?他们使用典型场景是什么？他们目的是什么？
● 软件开发核心难点是处理隐藏在业务知识中复杂度，用例使用格式化语言去描述需求，能够根据需要对复杂程度的形式化的程度进行增减调节。
3 怎么定义用例
3.1 用例的3种表现形式
用例能购以不同形式化程度或者格式进行编写：
● 摘要，简洁的一段概要，通常用于主成功场景。何时使用：早期需求分析过程，为了快速了解主题和范围。
● 非正式，非正式的段落格式，用几个段落覆盖不同场景。何时使用：同上
● 详述，详细编写所有步骤以及各种变化，同时具有补充部分，如前置条件等。何时使用：确定并以摘要形式编写大量用例后，在第一次需求讨论会中，详情编写其中少量的具有重要架构意义和高价值的用例。
| 用例的不同部分 | 功能说明 | 注释&补充 |
|---|---|---|
| 用例名称 | 以动词开始 | 如处理销售 |
| 范围 | 要设计的系统 | 系统用例：用例描述的是对一个软件系统的使用 业务用例：用例描述顾客如何使用业务 |
| 级别 | 用户目标或者子功能 | 用户目标级别：该级别大致相当于基本业务流程 子功能级别：用例描述支持用户目标所需要的子步骤，当若干常规用例共享重复子步骤时候，则将其分离出来创建为子功能级别的用例 |
| 主要参与者 | 调用系统，使之交付服务 | 调用系统服务来完成目标 |
| 涉众及其关注点 | 关注改用例的人，及其需要 | 界定了系统必须要做的工作，用例应该包含满足所有涉众关注点的事物 |
| 前置条件 | 值得告知读者的，开始前必须为真的条件 | 传达的是应该引起警惕的条件，不是所有为真的条件都需要编写 |
| 成功保证（后置条件） | 值得告知读者的，成功完成必须满足的条件 | 用例成功结束后必须为真的事务，包括主成功场景以及替代路径。 |
| 主成功保障 | 典型的，无条件的、理想方式的成功场景 | 满足涉众关注点的典型成功路径，通常不包含任何条件和分支，保持一定的连贯性，将条件和分支放置到扩展部分。也就是我们常说的先抓主流程 |
| 扩展 | 成功或者失败的替代场景 | 描述了其他所有的场景或分支，包括成功的和失败的路径 |
| 特殊需求 | 相关的非功能性需求 | 相关的非功能性需求、质量属性或约束 |
| 技术和数据变元表 | 不同的I/O方法和数据格式 | |
| 发生频率 | 影响对实现的调查、测试和时间的安排 | |
| 杂项 | 例如未决问题 |
3.2 编写用例几个准则
● 以本质风格编写用例，摈弃用户界面并且关注参与者的意图。案例：收银员可能会说其目标之一表述为登录；此时收银员大概会想象有图形界面、对话框、用户名和密码框等。这只是实现目标一种机制，但是不是目标本身，与实现机制无关目标：身份认证、安全防盗等。这种对根源目标发现过程能够拓展视野，以促成新的改进解决方案。
● 编写简洁的用例，删除噪音词汇。案例：“系统认证”而不是“这个系统认证”
● 编写黑盒测试用例，他不对系统内部工作、构件或者设计进行描述。案例：黑盒写法：系统记录销售，非黑盒写法：系统讲信息写入mysql数据库…
● 采用参与者和参与者目标的视角。关注系统的用户或者参与者编写需求，询问其目标典型情况以及其所考虑的价值结果。
3.3 定义用例基本步骤
为满足主要参与者的目标而定义用例。因此，基本过程如下：
3.3.1 选择系统边界。
系统仅仅是软件应用，还是将硬件应用作为整体？是一个在用还是整个组织在使用？如果对被设计系统的边界定义不清晰，那么可以通过对此后对系统外部事物的定义加以明确。一旦定义外部参与者，系统的边界将变得清晰。
3.3.确定主要参与者和目标
方法一：问题式分析
在识别用户目标之前首先要识别出主要参与者，可以集中讨论，可以通过提问题的方式寻找参与者和目标，如下相关类似问题有助于寻找参与者和目标。值得注意是：提问总是围绕参与者与目标，用例建模的观点就是寻找这些参与者与目标，创建产生有价值结果的解决方案。如：首先询问“谁来使用系统？他的目标是什么？”而不是“系统的任务是什么？”。
a.谁来定和停止系统
b.谁来完成用户管理和安全管理
c.谁来完成系统管理
d.“时间”是参与者吗？因为系统要响应时间事件来完成某些活动。
e.当系统失败时，是否存在监控进程将系统重新启动。
f.软件升级是如何处理的？“推”模式还是“拉”模式？
g.除了人作为主要参与者之外，还有其他外部系统的软件调用该系统的服务么？
h.谁来考察系统活动和性能？
i.谁来考察日志？是否可以远程检索？
j.系统发生故障和错误时通知谁？
当识别到参与者和其目标时，我们可以通过以下的方式将其记录下来，以便后续进行用例的完善。
方法二：事件分析
有哪些外部事件，源于何处，为什么？通常一组事件属于同一个用例。
3.3.3定义满足用户目标的用例，根据其目标对用例命名
一般来说，为每个用户目标定义用例，用例的名称与用户目标类似。常见的例外是，江分散的CRUD合并成一个用例，并习惯性称为管理XXX。例如，管理用户用例可以同时满足编辑用户、删除用户等目标。
4 UML用例图
UML提供了用例表示法，用以描述用例名词和参与者以及其之前的关系。用例图是一种优秀的系统语境图，能够展示出系统的边界、位于系统边界之外的事务以及系统如何被使用。值得说明是：用例图和用例关系在编写用例的工作中是次要的，用例核心工作编写文本文档。如下图所示一个简单uml用例图，其中系统边界是充值系统，主要参与者是用户其发起用例充值话费，微信支付和支付宝支付是支付金额具体的实现。
参考文献
[1]uml和模式应用（第三版），机械工业出版社。
[2]系统分析与设计方法，机械工业出版社。