用例（Use case）已经成为被广泛使用的需求开发技术。围绕着用户和他们的目标，而不是产品的功能，这大大提高了开发出能真正满足客户需求的软件产品的可能性。然而，由于对用例所知甚少，造成用例的神秘感与日俱增，很多开发团队也在试图成功地运用用例技术。本文将针对已经开始应用用例技术的分析师，特别指出五处应避免的用例应用陷阱。

　　陷阱1：连用户都不理解的用例

　　用例是一种表述用户需求的方法，它描述了用户需要产品所能完成的具体功能。用例应着重于那些用户所需借助产品系统来完成的任务，所以用例和用户的业务流程密切相关。用例应该能让用户方便阅读和检查，以寻找可能存在的问题，例如被遗漏的可替代流程，或者不正确的异常处理等。如果用户不能参与用例，将带来很多问题。或许是因为这些用例太过注重技术，而不是业务性、前瞻性的。

　　陷阱2：用例太多啦

　　分析人员正忙于建立数十或数百个用例，他们没有意识到这也许是错误的。用例数量过多通常意味着用例的抽象水平太低。每个用例都应当具备一定的抽象性，以涵盖某个共同主题的多个相关场景。这些用例的部分将成功，而其他的在某些特例条件下则不会成功。如果你正处于这样一种用例爆炸的情形，请试着提高抽象层次，将相似的用例合并成组，把它们作为一个单一的、更加抽象的用例的分支流程。

　　陷阱3：过于复杂的用例

　　用例应用的总体思路是，一个正常的用例流程所包含的步骤应该不超过12个。而事实上，曾经有用例在一个正常流程中包括近50个步骤。问题就在于，所谓 “正常流程”也包含了许多可能的分支，包括错误的异常流向，以及随之而来的如何处理它们等问题。所以，事实上，正常的流程也包括了备选流程和异常情况。更好的方法是选择一个简单的、在默认情况下能够顺利走完整个用例流程的路径，这才是真正的正常流程。然后再写出其他的分支流程用例，以囊括该流程的其他分支和异常情况，特别是描述流程发生错误的那些用例情况。通过这种方法，提供一套包括多个小分支流程的用例包，相比提供给用户一个试图在单一流程描述中处理好每一种可能性的庞大用例，无疑将容易理解和管理得多。

　　陷阱4：描述特定用户界面元素和行为的用例

　　我们所需要的是撰写“必要”的用例，在一个抽象的层面来描述用户和系统的互动，而不要加入用户界面的细节。用例描述不应包括界面设计，虽然简单的用户界面原型有利于方便地检查用例。笔者甚至不喜欢听到在用例中暗指特定用户界面控制的那些术语。我们说“用户点击确定”，这意味着GUI界面使用到鼠标和按钮。但是，是不是还可以使用触摸屏或语音识别界面呢？在用例中强加入不成熟的设计局限，可能导致产生一个糟糕的设计，除非你喜欢在已有界面的现有应用程序中不断增添新功能。

　　陷阱5：不再使用其他需求模型

　　分析人员在采用用例方法后，似乎忘记了其它他们所知道的需求模型和获取方法。对于交互式系统、网站等，用例对于捕获用户需求相当有帮助。然而，对于事件驱动的实时系统、数据仓库或批处理过程，用例的方法却并不适合。

　　我们要避免受到用例方法好处的诱惑，将用例方法强加于所有的功能需求工作。我们完全可以用一份详细的包括功能需求、非功能需求、图形分析模型、原型、数据字典和其他相关需求信息的列表来补充用例说明。在很多情况下，用例是有用的，但请将它添加到您的需求分析工具箱，而不是用它取代您当前的所有工具。