為什么用例不是“功能”?[2]

　　為什么用例不是“功能”?[2]   軟件測試

　　如果你在想圖1的改進后的版本是什么樣的，圖2展示了改進后的版本。

　　圖 2一種更好，更加簡單的方法: 合并功能以反映對參與者的真正價值

　　這一個用例包含了以前的圖中所分解為用例的所有“功能”。你也許會問為什么這樣做比較好，答案很簡單：它關注于客戶想要系統提供的價值，而不是我們在系統內部如何細分和構造的。如果把所有的功能分解成單獨的用例，你將迫使客戶(為系統付錢的人)把分解過的用例裝配成一件對他們有意義的東西，以便理解系統所描述的是不是他們所想要的(即他們想為之付錢的)。

　　關注價值

　　很多小用例是常見的問題，尤其是在一個習慣于功能分解的團隊中，他們的用例名稱讀起來就象是一個系統所執行的功能的列表，如“輸入訂單”、“審查訂單”、“取消訂單”、“履行訂單”，這起先聽起來也不是很壞，但不僅僅這些。即使對于一個小規模的訂購系統，用例列表也很容易達到上百個，如果誰走到了這一步，他們不久就會淹死在用例的海洋中，尤其是當系統規模確實比較大時，在這種情況下，你最終也許會有幾百個，甚至上前個用例。

　　這么做有什么錯呢?

　　這些用例的價值將會被錯過。用例的唯一目的是為參與者產生價值。在一定層次上能夠輸入訂單也是某種有價值的事情，但是，如果這些訂單從來不被履行，那還有價值嗎?也許沒有吧。

　　怎樣輸入訂單、修改訂單以及取消訂單等等，所有這些事情都是與客戶真正想要做的事情有關的，那就是接受訂購的貨物。這些活動對公司想要的事情是必須的，那就是收到貨款。

　　這種看起來是支離破碎的沒有任何明顯關系的功能集合的另一個問題是導致難以使用的系統。很多系統跟這個很類似，它們只是一堆雜亂的特性。記住，用例幫助我們關注與什么是真正重要的，也就是具有真正價值的事物，并且使我們能夠圍繞那些元素來定義系統。用例不要是系統按照功能分解的藍圖。

　　舉例

　　考慮一個你在互聯網上用過的一個電子商務系統，當你登錄這個站點的時候，你的目標可能是查找產品相關的信息、選擇要購買的產品、安排支付及送貨約定。在做這些事的過程當中，你可能會改變主意、輸入錯誤的信息以至不得不修改它、改變郵遞或送貨地址，以及其他的一些東西。如果這個網站不允許你通過一種吸引人的方式來找到并訂購產品，你也許不會完成你的訂購，更不用說再次來到這個網站。

　　當建造一個系統時，始終要記住用例的核心定義：關于采用某種方式使用系統來做有價值的事情的故事。如果你能夠實施這個定義，展示用戶希望通過系統獲得的價值，然后創建反映這些價值的用例的時候，你的系統將會更好地滿足用戶的期望。

原文轉自：http://www.anti-gravitydesign.com