圖 1 錯誤的方式：用例是菜單項或者功能
這幅圖有什么錯誤？用最簡單的定義，我傾向于把用例看作是關于使用系統作某些有用的事情的方式的故事。利用這個定義，是不是所有的“用例”都是獨立的有用的呢？
答案當然是不是，在這個例子中，用例表示了系統需要做的所有的事情，但是他們也描述了用戶需要通過系統去做的一件單獨的事情：定購。所有保留的元素都是這一個用例的備選支流，它們是在定購時可能發生的步驟。在只做一件有用的事情的地方，只應該有一個用例。圖1就是一個功能分解的例子，或者“四輪馬車”格式的例子――一個參與者在中間，周圍是一圈用例。
這是一個常見的問題，為什么人們會陷入這個陷阱呢？我們有一個有對定購的內在需要，并且在不存在的地方如果我們需要那么就利用它。在功能分解的情況下，我們有一種自然傾向把問題分解為越來越小的塊。有一種天真的想法那就是把用例分解為越來越小的單位會簡化問題。這種理解是完全錯誤的。當我們分解用例時，實際上會把問題復雜化。
問題在這里
用例的目的是描述某人某物如何使用系統來完成對他們有價值的事情，它描述了系統在概念層次上做什么，使我們足夠理解系統以便決定系統是否要做恰當的事。用例是我們能夠形成一個系統的概念模型。
再看看圖1，現在問你自己，如果我從來沒有定購過，我想通過系統查詢定單的狀態嗎？這是不太可能的�；蛘呷绻覐膩頉]有定購過，我想變更訂單嗎？不，也許不。通常這些東西只有當我訂購過的時候才對我有用。然而，為了系統能夠允許我訂購，這些都是必要的。
把系統分解為越來越小的用例模糊了系統的真實目的，極端情況下，我們將以得到一堆隔絕的行為的細致末節而告終。結果我們不能說明系統做什么。這就像看到一輛被拆解為零件的汽車，或許你會說這是輛汽車，你也知道零件們是有用的，但是你確實不能說明他們如何組裝在一起。
當使用用例的時候，記住用例是考慮整個系統的一種方式，并且要組織成可管理的功能塊，這些功能塊完成一些有價值的事情。為了得到正確的用例集合，問你自己一個問題：“參與者實際上想使用系統做什么？”
如果你在想圖1的改進后的版本是什么樣的，圖2展示了改進后的版本。
圖 2一種更好，更加簡單的方法: 合并功能以反映對參與者的真正價值
這一個用例包含了以前的圖中所分解為用例的所有“功能”。你也許會問為什么這樣做比較好，答案很簡單：它關注于客戶想要系統提供的價值，而不是我們在系統內部如何細分和構造的。如果把所有的功能分解成單獨的用例，你將迫使客戶（為系統付錢的人）把分解過的用例裝配成一件對他們有意義的東西，以便理解系統所描述的是不是他們所想要的（即他們想為之付錢的）。
關注價值
很多小用例是常見的問題，尤其是在一個習慣于功能分解的團隊中，他們的用例名稱讀起來就象是一個系統所執行的功能的列表，如“輸入訂單”、“審查訂單”、“取消訂單”、“履行訂單”，這起先聽起來也不是很壞，但不僅僅這些。即使對于一個小規模的訂購系統，用例列表也很容易達到上百個，如果誰走到了這一步，他們不久就會淹死在用例的海洋中，尤其是當系統規模確實比較大時，在這種情況下，你最終也許會有幾百個，甚至上前個用例。
這么做有什么錯呢？
這些用例的價值將會被錯過。用例的唯一目的是為參與者產生價值。在一定層次上能夠輸入訂單也是某種有價值的事情，但是，如果這些訂單從來不被履行，那還有價值嗎？也許沒有吧。
怎樣輸入訂單、修改訂單以及取消訂單等等，所有這些事情都是與客戶真正想要做的事情有關的，那就是接受訂購的貨物。這些活動對公司想要的事情是必須的，那就是收到貨款。
這種看起來是支離破碎的沒有任何明顯關系的功能集合的另一個問題是導致難以使用的系統。很多系統跟這個很類似，它們只是一堆雜亂的特性。記住，用例幫助我們關注與什么是真正重要的，也就是具有真正價值的事物，并且使我們能夠圍繞那些元素來定義系統。用例不要是系統按照功能分解的藍圖。
舉例
考慮一個你在互聯網上用過的一個電子商務系統，當你登錄這個站點的時候，你的目標可能是查找產品相關的信息、選擇要購買的產品、安排支付及送貨約定。在做這些事的過程當中，你可能會改變主意、輸入錯誤的信息以至不得不修改它、改變郵遞或送貨地址，以及其他的一些東西。如果這個網站不允許你通過一種吸引人的方式來找到并訂購產品，你也許不會完成你的訂購，更不用說再次來到這個網站。
當建造一個系統時，始終要記住用例的核心定義：關于采用某種方式使用系統來做有價值的事情的故事。如果你能夠實施這個定義，展示用戶希望通過系統獲得的價值，然后創建反映這些價值的用例的時候，你的系統將會更好地滿足用戶的期望。
文章來源于領測軟件測試網 http://www.kjueaiud.com/