作者：张克强 作者微博：张克强-敏捷307
来自于科伯恩《编写有效用例》对业务用例的说明
在《使用 UML 进行业务建模：理解业务用例与系统用例的相似和不同之处》中分析科伯恩编写有效用比例如以下：
Cockburn 的 Writing Effective Use Cases 给业务和系统用例使用了同样的用例说明模版。
业务用例与系统用例说明使用这个模版的差别是设计范围，而不是模版。
Cockburn 想通过目标层次对用例进行分类。如表格1所看到的。
|
图1： Alistair Cockburn 对业务和系统用例的分类 |
|
|
高层概要 |
|
|
概要 |
|
|
用户目标 |
|
|
子功能 |
|
|
最低层 |
|
Cockburn 编写 Writing Effective Use Cases 的最初目标是系统用例。但他在业务用例上也花了非常多精力。
他利用目标层次来区分业务与系统用例。而不是使用不同的模版类型。
那么这些图标和目标层次又意味着什么呢？
这些图标本身代表着一个简单的系统，它是依据用例与“海平面”（用户的实际层次）的相对高低来确定的。系统用例的最佳点是用户目标，通过海平面图标来表明。有时候须要将复杂的系统用例分解成其他有子功能目标、通过鱼图标表明的用例。可是您应该尽量避免将海平面系统用例分解成蛤或者最低层系统用例。
或许您会推測到。概要或者蛤用例应该是业务用例。云或者高层概要也可能是业务用例。
Cockburn 的方法是将这些用例看作是一个光谱。从一个组织的最高层次业务目标。到为实现这些业务目标而运行的软件解决方式的需求具体资料。
这样的方法将系统用例看作是一个业务用例的分解。这个用例分解方法能够用来帮助您从这个业务模型驱动系统用例模型。
业务用例在编写有效用例的位置
编写有效用例的章节安排是一開始就直接讲用例，第一部分的标题用例体部分，没有提到业务用例。是到第二部分的第15章才提到业务过程建模和业务用例，第15章总共的篇幅6页。第2部分的标题是常常讨论的主题，第12章是第二部分的第1章，标题是什么时候才算完毕。第13章标题是扩展到多个用例；第14章标题是CRUD和參数化用例。
关于业务用例的两个坏消息
他在第15章最后说到：
业务用例与系统用例具有同样的特征，因此编写和评审用例的方法对两者都适用。在业务用例中说明的东西，也会在系统用例中说明。
这形成了系统用例和用户用例之间的合作。但这样带来了两个坏消息。
第一：编写者和读者常常把二者弄混，可能把系统行为放入业务用例中。也可能把业务操作归于系统用例。假设可以商议着去做将会有所帮助。但通常编写者和读者不会认识到这样做的重要性。使用系统用例的读者批评业务用例所处层次太高，但却没有认识到提供系统具体的行为细节不是业务用例应该做的；业务用例编写者偶尔把系统行为细节写入当中，结果导致业务主管对这类有具体细节行为的文档失去了兴趣。
第二：全然且正确的连接系统和用户用例不太值得。
通常，业务用例编写者应对业务过程到系统使用（通常没有描写叙述）进行描写叙述。而在描写叙述日常生活中客户怎样使用新系统之前，用例编写者已经花光时间、財力、精力以及热情。
而系统用例编写者有时为了保持一致，会在业务过程中加一两句。可是他们通常不愿意重写一个包括新系统功能的业务用例。这样就在系统用例和业务用例之间形成了空隙，即系统用例和业务用例之间的不一致。
尽管科伯恩在后面附了来自于FirePond公司使用业务用例的正面样例，但能够看出那是少数派。