如何写好最外围用例
2003 年，我曾经在网上看到一篇技术文章《 没头没尾—项目开发笔记：如何编写最外层用例 ?! 》，这篇文章写得很好，真实记述、反映了用例写作中的一些常见现象和误区。 然而，该文的前后两个用例实际上都不是针对客户的真正的“最外层用例”，尽管作者作了些改进，但这些用例在具体的内容和写法上还存在一些问题。
1．引言
“本系统的目标是制作出一个跨企业的信息平台，为目标公司的客户进行服务。这些服务分成很多的方面，比如提供给银行的公司财务情况查询，提供给生产厂商销售情况的报告。提供给销售的商场以及店铺货源的情况，提供给物流，安装服务公司送货以及安排信息。从中赚取提高销售效率，减少运输损耗的费用。设定目标公司为 A公司，信息平台名称B系统。”
从上面介绍的内容来看，我猜 B 系统是 一个 类似于供应链 应用 的 企业 门户 系统，这里所说的 A 公司好像是一家从事商品分销的企业。通过该门户， A 公司可以有效地联系上家—生产商（供货商），下家—商场、店铺以及银行、物流公司、安装服务公司等客户或合作伙伴。
在讨论这个案例前，首先让我们重温一下什么是最外围用例（ the outermost use cases ，根据 Cockburn 的定义改写） ：
对于每一个用例找到它仍能适用的最外圈的设计范围，针对该范围为它编写一个概要用例； 对于一个将要设计的系统， 我们 通常可以找到一个更广的设计范围，而使主用角（ PA ， Primary Actor ）仍然处于该范围之外，如果不断扩大该范围，可以找到一个临界点，主用角就会被包含在当前的范围之内，这个临界点就是最外圈的范围； 最外围用例是通过把同一个范围内具有相似目标的主用角合并到一起而创建出来的，它们把与这些用角有关的所有低层用例都汇聚到了一起。
如何获取最外围用例呢？ Cockburn 给了一些步骤建议 ：
（1） 从一个用户目标开始。
（2） 问“这个目标对主用角 AA （最好在组织外部）提供什么服务？”，用角 AA 是我们想要收集用例的最终主用角。
（3） 找出最外圈的设计范围 S ，使得 AA 仍然在 S 之外，给 S 命名。
（4） 找出最终主用角 AA 在设计范围 S 中的所有用户目标。
（5） 找出 AA 对系统 S 的概要目标 GG 。
（6） 为 GG 编写出概要用例。这个用例就是我们要找的最外围用例，它将一些海平面（用户目标层）的用例维系在一起。
值得注意的是，这里 Cockburn 所说的“系统” S 不一定都是指软件，它可能是软件系统（如 B 系统），也可能是业务系统（如 A 公司、企业、部门等）。 在下面第 2 、第 3 小节中我将按照 Cockburn 的最外围用例 定义 来考察 原文中的两个最外围用例 ，逐个分析存在的错误。用第 1 个例子说明以“操作人员”为 主用角 、最外圈范围为软件系统（ B 系统）的正确写法，用第 2 个例子说明以“客户”为主用角 、最外圈范围为业务系统（ A 公司）的正确写法。
2．软件用例 - 业务管理
用例名称： 最外围用例
错误分析： 显然这不是一个正确的用例名称。建议改为“业务管理”，解释如下文。
简要说明：
A 公司决定让其业务合作伙伴以及最终的用户通过互联网访问 B 系统以达到减少 A 公司本地人员的工作量以及提升工作效率的目的。 B 系统负责完成进销存业务、其它业务处理以及报表管理。一些系统维护人员还负责管理基础信息的认定与实现。包括四个用例：基础设置子系统，进销存子系统，其它业务处理子系统，报表子系统。
错误分析： 首先，用例的名称、内容中不应该出现“子系统”这个术语， subsystem 属于系统设计范畴。
从业务介绍来看，操作人员主要进行“进销存、报表和其他业务”的处理，系统维护人员主要进行基础信息管理，所以这 4 个概要用例（风筝层）分属不同的 PA 。这两种角色在概要白云层似乎没有必要严格区分，所以我们把系统维护人员和操作人员合并成“操作维护人员”，并且把这 4 个用例合并成 1 个最外围用例“业务管理”，并在此处描述。
用例范围： 跨企业信息平台
主执行者（ PA ）： 客户
错误分析： 从用例范围和基本流的内容看， 这里的 PA 应该是“操作维护人员”（客户作为 PA 的最外围用例见第 3 小节）。
用例层次： 白云（最高层次）
触发事件： 客户有购货的需求
错误分析： 这里应该描述可以检测到的事件（动作、状态的改变等），我们怎么知道客户有购货的需求呢？正确的说法可能是：客户以各种方式请求服务。
主成功场景（基本流）
· 系统维护人员操作基础设置子系统维护基础设置的数据。
· 操作人员操作进销存子系统完成进销存业务。
· 操作人员通过报表系统分析查询业务结果。
· 操作人员通过其它的业务子系统完成对系统中的其它业务处理。（注，其它业务子系统包括财务资金等等子系统，将会子用例描述中强调）
小结：
从以上分析看，原用例存在着基本的概念错误，用例的主用角（ PA） 、范围和基本流的内容相互之间存在不一致的现象。这 个最外围用例可以改写如下：
|
用例名称： |
业务管理 |
|
范围： |
B 系统 |
|
层次： |
概要 / 白云 |
|
主用角： |
系统操作维护人员 |
|
触发事件： |
客户通过电话、邮件等方式向操作维护人员提出服务请求（如购货）。 |
|
基本流： |
操作维护人员通过 B 系统可完成以下任务： |
3．业务用例 - 客户服务
用例名称： 最外围用例
错误分析： 显然这不是一个正确的用例名称，建议改为“客户服务”。
简要说明：
A 公司决定让其业务合作伙伴以及最终的用户通过互联网访问 B 系统以达到减少 A 公司本地人员的工作量以及提升工作效率。 B 系统负责完成销售业务以及报告销售情况。一些系统维护人员还必须为客户和职员设置安全存取级别。包括四个用例：增加服务（ A 公司本地），增加服务（客户），报告业务情况，管理安全存取权限。
错误分析： 这段话其实不太像用例简述。最外围用例应该从 A 公司向客户提供服务的角度来叙述，比方说，可以请求服务，查询业务销售报表等。在本例中我们进行黑盒业务建模，涉及到 B 系统和系统维护人员的内容，比如安全级别设置，不应在此处反映。
用例范围： 跨企业平台
错误分析： 我们选定了 A 公司的客户作为 PA ，那么按照最外围用例的定义，最大范围边界应为 A 公司而不是 B 系统。实际上这是一个业务用例（ Business Use Case ）。虽然客户也可以直接访问 B 系统，但是对于客户而言，B 系统 不是最大的范围 。
用例层次： 白云（最高层次）
主执行者（ PA ）： 客户
主成功场景（基本流）：
·客户通过电话，邮件联系 A 公司操作人员，请求一个新的服务。 A 公司的操作人员通过 B 系统处理服务请求。
·客户直接通过 B 系统的客户端，请求与处理新的服务。
·客户通过 B 的系统可以查询出销售情况以及其它相关情况的报表。
·B 的系统维护人员将要对客户以及操作人员进行安全存取权限的设置。
错误分析： 在最外围业务用例的基本流中，主要包含一些用户目标层或概要层的用例，所以此处不应该出现与 B 系统、操作人员、系统维护人员相关的内容，它们在我们定义的范围边界（ A 公司）之内。 根据以上分析，我将该 最外围用例改写如下：
|
用例名称： |
客户服务 |
|
范围： |
A 公司 / 业务 |
|
层次： |
概要 / 白云 |
|
主用角 ： |
客户 |
|
触发事件： |
客户提出服务请求 |
|
基本流： |
客户可以下列 2 种方式获得服务： |
4．总结
有人认为：“ 也许针对一个项目可以有很多‘正确的'最外层用例的设计方法。上面两种划分方式应该说只从最外层用例的角度来说都是正确的 ” 。我不同意这种开脱的说法，针对 1 个项目抽取最外围用例实际上只有 1 种“最优解”。为什么？道理很简单，因为最外围用例是 Cockburn 提出的，他给出了找到最外围用例的步骤和方法，而这种方法是明确的、无二义性的。人们找错了最外围用例，多半是因为没有理解和掌握这套方法。
概括一下，原文主要存在以下错误：
1 ）由于用例的主用角 、范围与基本流的内容不一致，导致那两个用例都不是真正的最外围用例。实际上，针对“客户”的最外圈范围是 A 公司，而针对“操作维护人员”的最外圈范围是 B 系统。
2 ）在用例的功能描述中出现了软件内部设计的内容，不符合需求提取、分析的要求。
最终，由于原作者对于为什么要编写用例，用例与传统结构化方法的功能总体描述究竟有何实质上的不同，用例有哪些特点，缺乏准确而深入的理解，导致编写用例的时候思路凌乱，把几种内容混杂在一起，做成了一碗“杂烩面”。 这个案例给我们的重要启迪是，抽取用例最关键的一步是首先明确 SuD （ System Under Discussion or Design ）范围的定义 以 及针对这个范围的主用角 。 如果用 传统 “结构化”的老思路来套用例的格式，换汤不换药，那对 IT/软件项目开发将起不到真正的效果，甚至可能产生负作用，如果那样还不如不写用例。 最外围用例便于我们将关注的焦点转向用户真正需要什么，从而真正地从用户的角度出发来考虑问题
