用例（use case）已經(jīng)成為被廣泛使用的需求開發(fā)技術(shù)。圍繞著用戶和他們的目標，而不是產(chǎn)品的功能，這大大提高了開發(fā)出能真正滿足客戶需求的軟件產(chǎn)品的可能性。然而，由于對用例所知甚少，造成用例的神秘感與日俱增，很多開發(fā)團隊也在試圖成功地運用用例技術(shù)。本文將針對已經(jīng)開始應用用例技術(shù)的分析師，特別指出五處應避免的用例應用陷阱。

    陷阱1：連用戶都不理解的用例

    用例是一種表述用戶需求的方法，它描述了用戶需要產(chǎn)品所能完成的具體功能。用例應著重于那些用戶所需借助產(chǎn)品系統(tǒng)來完成的任務，所以用例和用戶的業(yè)務流程密切相關(guān)。用例應該能讓用戶方便閱讀和檢查，以尋找可能存在的問題，例如被遺漏的可替代流程，或者不正確的異常處理等。如果用戶不能參與用例，將帶來很多問題?；蛟S是因為這些用例太過注重技術(shù)，而不是業(yè)務性、前瞻性的。

    陷阱2：用例太多啦

    分析人員正忙于建立數(shù)十或數(shù)百個用例，他們沒有意識到這也許是錯誤的。用例數(shù)量過多通常意味著用例的抽象水平太低。每個用例都應當具備一定的抽象性，以涵蓋某個共同主題的多個相關(guān)場景。這些用例的部分將成功，而其他的在某些特例條件下則不會成功。如果你正處于這樣一種用例爆炸的情形，請試著提高抽象層次，將相似的用例合并成組，把它們作為一個單一的、更加抽象的用例的分支流程。

    陷阱3：過于復雜的用例

    用例應用的總體思路是，一個正常的用例流程所包含的步驟應該不超過12個。而事實上，曾經(jīng)有用例在一個正常流程中包括近50個步驟。問題就在于，所謂“正常流程”也包含了許多可能的分支，包括錯誤的異常流向，以及隨之而來的如何處理它們等問題。所以，事實上，正常的流程也包括了備選流程和異常情況。更好的方法是選擇一個簡單的、在默認情況下能夠順利走完整個用例流程的路徑，這才是真正的正常流程。然后再寫出其他的分支流程用例，以囊括該流程的其他分支和異常情況，特別是描述流程發(fā)生錯誤的那些用例情況。通過這種方法，提供一套包括多個小分支流程的用例包，相比提供給用戶一個試圖在單一流程描述中處理好每一種可能性的龐大用例，無疑將容易理解和管理得多。

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

    我們所需要的是撰寫“必要”的用例，在一個抽象的層面來描述用戶和系統(tǒng)的互動，而不要加入用戶界面的細節(jié)。用例描述不應包括界面設計，雖然簡單的用戶界面原型有利于方便地檢查用例。筆者甚至不喜歡聽到在用例中暗指特定用戶界面控制的那些術(shù)語。我們說“用戶點擊確定”，這意味著gui界面使用到鼠標和按鈕。但是，是不是還可以使用觸摸屏或語音識別界面呢？在用例中強加入不成熟的設計局限，可能導致產(chǎn)生一個糟糕的設計，除非你喜歡在已有界面的現(xiàn)有應用程序中不斷增添新功能。

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

    分析人員在采用用例方法后，似乎忘記了其它他們所知道的需求模型和獲取方法。對于交互式系統(tǒng)、網(wǎng)站等，用例對于捕獲用戶需求相當有幫助。然而，對于事件驅(qū)動的實時系統(tǒng)、數(shù)據(jù)倉庫或批處理過程，用例的方法卻并不適合。

    我們要避免受到用例方法好處的誘惑，將用例方法強加于所有的功能需求工作。我們完全可以用一份詳細的包括功能需求、非功能需求、圖形分析模型、原型、數(shù)據(jù)字典和其他相關(guān)需求信息的列表來補充用例說明。在很多情況下，用例是有用的，但請將它添加到您的需求分析工具箱，而不是用它取代您當前的所有工具。