為什麼要用 UseCase 來捕獲需求?

    Q: 使用者說他希望系統能有”新增客戶訂單”的功能，這不就是需求了嗎?為什麼還要用 UseCase 去描述需求?(兼談為什麼不要將功能列表或系統特性清單當成系統需求)

A: 假如你要去高雄，你會經過那幾個城市? 

 

最常的走法	台北、桃園、新竹、苗栗、台中、彰化、嘉義、台南、高雄。
有時的走法	台北、桃園、新竹、苗栗、台中、彰化、南投、嘉義、台南、高雄。
另一種特別的走法	台北、基隆、宜蘭、花蓮、台東、屏東、高雄。
塞車的走法	………

 

究竟您會採取那一種路徑，有時是依您的意圖;有時是依當時的情況;更多的時候是限制於某些條件。但不管怎樣，雖然有那麼多不同的路徑，但目的是相同的，都是到達高雄(註:這裡沒有討論使用那一種交通工具，因為那是How to 的問題，Use Case 只描寫 What，做些什麼的事)。看似一句簡單的陳述，往往隱藏著多種可能，如果我們在還沒探究此目的下存在的多種不同路徑，就去估算達成此目的所須的資源，有可能與最後使用的資源有極大的差異。其原因在於，去高雄雖是一個明確的目的，但却缺乏足夠的資訊來說明此目的底下的各種可能路徑；不同的路徑自然隱含不同的成本(實際生活上我們也許只須一種路徑來支援你到達目的的，但系統不同，因為是要長久且大量的應付使用者的日常作業，所以每一種可能發生的路徑我們都須要實作。)。前一陣子有一則新聞說:有一位民眾透過 GPS 導航要去某一個地方，雖然 GPS 規劃出了一條不塞車的路徑，但却是一條人煙稀少的山路，結果那位民眾因汽車沒油(資源不足)，而困在山裡，最後還要勞駕人民保母送汽油給他，才能脫離困境，顯然 GPS 沒有評估這種情形下所須的資源使用量。

 

       同樣的，“新增客戶訂單”或者”管理客戶訂單”，都是傳統上的功能列表，也是客戶很直覺提出的需求，如果我們以這樣的訊息加上一些些的瞭解來評估專案，往往會因沒有察覺在此需求底下的意圖、情況及限制條件的不同(使用者雖有以不同的方式來使用系統的自主性，但有時因為條件的不同，表面上相同的行為却已是不同的情況了)，而錯估專案成本。誤解目標與意圖的意義是我們專案失敗的主因。目標有如海平上的冰山，明確清晰;意圖則是海平面底下的冰塊。據說讓鐵達尼號沉沒的不是海平面上的冰山而是海平面底下的冰塊，船長誤判了海平面下冰塊的威力，才是造成這場世紀大悲劇的主因。客戶需求就有如浮在海面上的冰山，在此需求底下的意圖、情況及限制條件則是海平面底下的冰塊，冰山底下的，才是我們要應付的危機，不容輕估。

UseCase 是描寫使用者使用系統某一項功能可能會採用那些方式的說明(注意:這裡所指的”功能”和”功能選單”上的功能是不一樣的含義) ，每一種使用方式稱為一種情境或是一個場景，也可以說是我們前面所說的意圖、情況及限制條件。透過它可以協助我們去發掘與記錄使用者會以什麼樣不同的方式來使用系統，而系統又該以怎樣的方式來回應使用者。就如前面的例子:我們可以透過 UseCase 來分析使用者會以那幾種方式去新增客戶訂單，而您的系統又將如何針對不同的用法與條件採取相對的行動與使用者互動來協同完成工作。換包話說:「要系統能新增客戶訂單」是客戶需求，但為了完成這個客戶需求，您的系統須以好幾種不同的方法來協助使用者完成工作，這幾種方法就是不同的系統需求，我們就是透過使用案例來發掘與記錄系統需求。

    回顧一下過去您負責的專案，是不是經常被客戶抱怨，實現的系統常常與他們真正所要的有點誤差或不足以應付某些特殊情況。其原因就是沒有以比較充份的時間來探索使用者使用系統的各種可能方式，所造成的後果。傳統採用 DFD分析系統時，往往因太早使用技術性的觀點來處理客戶需求，急於解決問題，而忽略了使用者不同的意圖及各種限制因素；通過Use Case觀察系統，我們能夠將系統實現與系統目標分開，有助於瞭解最重要的部分――滿足用戶要求和期望，而不會沉浸於實現細節。必竟SA 的工作應該是找出對的事，然後再把事情做對。

    最後要再次說明的是:把使用案例的名稱看成是使用者對系統的一個”要求”或”期待”，而系統在各種未知的意圖及條件因素底下，為了滿足使用者的這個”要求”或”期待”所做的種種行為，則是透過使用案例的描述來記錄，結果是您將得到一組使用者在此”要求”下使用系統的各種可能情況的說明。UseCase 是目前發掘與記錄系統需求的好工具，協助我們以一種比較有系統有結構的方式來完成這項工作。