业务用例和系统用例

业务用例和系统用例
业务用例与系统用例具有同样的特征，因此编写和评审用例的方法对两者都适用。在业务用例中说明的东西，也会在系统用例中说明。这形成了系统用例和用户用例之间的合作。但这样带来了两个坏消息。

第一个坏消息:编写者和读者经常把二者弄混，可能把系统行为放入业务用例中,也可能把业务操作归于系统用例。如果能够商量着去做将会有所帮助，但通常编写者和读者不会认识到这样做的重要性。使用系统用例的读者批评业务用例所处层次太高，但却没有认识到提供系统详细行为细节不是业务用例应该做的。业务用例编写者偶尔把系统行为细节写入其中，结果导致业务主管对这类有详细细节行为的文档失去了兴趣。
为了减少这种混乱，应该经常在用例模板中写明用例范围及层次，让用例编写者依此规则编写，同时让读者了解这些规则。如果可以的话，尽量对用例使用图标。对两者使用稍微不同的模型和用完全不同的数字进行编号(如一组从1000开始对用例编号，另一组从1开始编号)。同时，编写一些可以直接使用和可视化的构件。这样就可以既能充分利用这种合作关系，又不会让人混淆
第二个坏消息:完全且正确地连接系统和用户用例不太值得。通常，业务用例编写者应对业务过程到系统使用(通常没有描述)进行描述。而在描述日常生活中客户如何使用新系统之前，用例编写者已经花光时间、财力、精力及热情。而系统用例编写者有时为了保持一致，会在业务过程中加一两句，但是他们通常不愿意重写一个包含新系统功能的业务用例。
这样就在系统用例和业务用例之间形成了空隙，即系统用例和业务用例之间不一致。FirePond 的Rusty Walters 对此评论如下。

在完整的业务用例展开为系统用例方面，我有一些成功的经验。根据我的经验，通常把业务用例分为3个层次:开始是少数几个黑盒、云朵级业务用例;然后很快转换为白盒、云朵级业务用例;最后展开为白盒、风筝级业务用例。
然而，在此过程中，看不到业务用例和系统用例之间清晰的连接，企图寻找从业务过程到系统需求的自动映射方法是不明智的。我认为自动派生系统需求是不可能的。