业务用例和系统用例
业务用例与系统用例具有同样的特征，因此编写和评审用例的方法对两者都适用。在业务用例中说明的东西，也会在系统用例中说明。这形成了系统用例和用户用例之间的合作。但这样带来了两个坏消息。
第一个坏消息：编写者和读者经常把二者弄混，可能把系统行为放入业务用例中，也可能把业务操作归于系统用例。如果能够商量着去做将会有所帮助，但通常编写者和读者不会认识到这样做的重要性。使用系统用例的读者批评业务用例所处层次太高，但却没有认识到提供系统详细行为细节不是业务用例应该做的。业务用例编写者偶尔把系统行为细节写入其中，结果导致业务主管对这类有详细细节行为的文档失去了兴趣。
为了减少这种混乱，应该经常在用例模板中写明用例范围及层次，让用例编写者依此规则编写，同时让读者了解这些规则。如果可以的话，尽量对用例使用图标。对两者使用稍微不同的模型和用完全不同的数字进行编号（如一组从1000开始对用例编号，另一组从1开始编号）。同时，编写一些可以直接使用和可视化的构件。这样就可以既能充分利用这种合作关系，又不会让人混淆。
第二个坏消息：完全且正确地连接系统和用户用例不太值得。通常，业务用例编写者应对业务过程到系统使用（通常没有描述）进行描述。而在描述日常生活中客户如何使用新系统之前，用例编写者已经花光时间、财力、精力及热情。而系统用例编写者有时为了保持一致，会在业务过程中加一两句，但是他们通常不愿意重写一个包含新系统功能的业务用例。
这样就在系统用例和业务用例之间形成了空隙，即系统用例和业务用例之间不一致。FirePond的Rusty Walters对此评论如下。
在完整的业务用例展开为系统用例方面，我有一些成功的经验。根据我的经验，通常把业务用例分为3个层次：开始是少数几个黑盒、云朵级业务用例；然后很快转换为白盒、云朵级业务用例；最后展开为白盒、风筝级业务用例。
然而，在此过程中，看不到业务用例和系统用例之间清晰的连接。
在下面的论述中，FirePond的Rusty Walters阐述了他在业务过程用例方面的经验。
| ◆ Rusty Walters：业务建模和系统需求
| ||
| 受益于早先曾经阅读过你的书，我通过以前的尝试能够对问题合理规划，并且能利用新的知识。 阅读前的经历： 在阅读这本书之前，我从事过产品组中几个应用程序功能需求文档的编写工作。 在一个应用程序开发中，我们编写各个层次的系统用例，包括概要级、用户级和子功能级。我们主要集中在系统功能方面。对建模后的结果也非常满意，它非常易于理解。同时，我们也觉得没有开发业务用例来展示整个环境的必要，系统概要用例就包括了我们全部的需求。 在另一个应用程序开发中，虽然还是同样的开发组负责用例 | 建模，情况却完全不同。回顾起来，我明白问题的症结在于，不同组的成员从不同角度接近系统。我从业务过程到技术进行建模，有的人却从技术到业务过程进行建模。毫无疑问，在两组设计人员中，每个用例的设计范围不清晰。 在从业务过程到技术进行建模的组中，他们从不编写系统用例；而在从技术到业务过程进行建模的组中，他们也从不编写业务用例。相反，由于两组都希望直接利用对方编写的用例，因此难免正面冲突和相互指责。由于当时对界定用例范围层次没有远见并且缺少必要的理解，用例模型变得相当混乱。直到最后，整个小组对用例模型仍不满意。 | |
| 事实上，整个小组都知道这样有问题，但却不知道症结何在。 阅读后的经验： 正如我在一个试图理解和文档化开发过程的小组中发现的，从核心业务到技术进行建模似乎不会导致什么混乱。
我们从业务中很概要级（云朵级）的黑盒用例开始，大家对这些用例都很清楚，甚至包括那些从事底层建模的人。然后，如书本中所说的一样，很快写出很概要级（云朵级）的白盒用例。 | 当我们决定讨论下一低层次用例时，设计域（即我们是讨论整个业务，还是某个部门）引发的混乱出现了。这个问题也与如何创建后续用例有关。在一个特殊的例子中，当我们认识到那些应该在调用用例中实现，而不应该作为当前用例的一部分后，删除了上面两个步骤。同时开发组也不打算把业务用例展开为系统用例需求。 虽然在会议期间很难注意和修正整个过程，但会后，对问题域的理解相对容易一些。在文档化会议结果的过程中，我使用设计域语境图，用图标明每个用例的范围和层次。如果图足够简单，就会给读者留下深刻印象，并直接浮现在读者脑海中。 | |
本文节选自《编写有效用例》一书
[美]AlistairCockburn（阿利斯泰尔.科伯恩) 著
王雷，张莉译
图书详细信息:http://blog.csdn.net/broadview2006/article/details/7736848
4513
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
