用例驅動的需求過程實踐

                                  用例驅動的需求過程實踐 
--------------------------------------------------------------------------------
 
來自：電腦世界網 作者：徐鋒 [2004/01/05] 
一、需求矛盾
　　根據CHAO的權威統計，雖然自"軟體危機"提出以來，軟體工程方法得到了長足的發展與進步，但在去年的軟體項目成功率仍然不足30％，絕大多數的軟體項目仍然超進度、超成本。而在這些不成功的項目中，由於需求不清晰、需求不完整等方面的因素，佔到了60％左右。
　　下面的這幅漫畫雖然不乏誇張，但卻是能夠激起我們的深思：

 
　　根據筆者多年來從事軟體需求捕獲、分析工作的實踐經驗，認為造成這一現象的根本原因在於客戶與開發人員之間的溝通存在障礙，雙方都以自己的角度、自己的專業術語進行溝通，這使得大家並不能夠很好地就軟體需求達成共識。
　　由於協助客戶更好地利用資訊化工具提高工作效率，是我們軟體Team Dev的責任，因此我們沒有權利讓使用者理解我們所用的語言，而是反過來，我們有義務去理解使用者的語言，站在使用者的角度看問題。
　　而事實上，許多Team Dev經常抱怨"我們的客戶連需求都說不清楚"、"我們的客戶對電腦瞭解太少了"。多年以來，大家都習慣從自己的角度來定義、分析問題，這也就造成了軟體行業成為了一個最缺乏信任的行業，我們需要改一下習慣了。
二、現代需求實踐
　　針對這些現象，許多先賢們開始了實踐，並且總結出了一系列優秀的需求實踐：
1）Use case：用例分析技術
　　鼎鼎大名的RUP是這樣總結自己的：用例驅動，以體繫結構為中心，迭代、增量的開發過程。Use case也伴隨著RUP、UML一起名揚天下。
　　用例用來描繪一個系統外在可見的需求情況，是代表系統中各個項目相關人員（風險承擔人，Stakeholder）之間就系統的行為所達成的契約。
2）User Story：使用者故事、使用者素材
　　使用者故事是Kent Beck在極限編程（XP）方法論中推薦的最佳實務之一。它由客戶參與編寫，說明他們需要系統為他們做什麼，一般用客戶的術語寫就，三句話左右。
3）Feature：特徵
　　這是特徵驅動開發（FDD）方法論的核心實踐之一。一個特徵就是一個小的，具有客戶價值的功能，通常表示為<action><result><object>。
　　從上面的定義來看，這三種現代軟體工程需求實踐無一例外地遵從兩個原則：一是站在使用者的角度看待系統、定義系統；二是用使用者看得懂的語言表達。而在筆者的實踐中，鑒於以下兩點考慮還是先在團隊中應用了"用例分析技術"：
1）使用者故事略顯粗糙，掌握起來需要經驗，沒有詳細的規則用於按部就班，一開始採用容易迷失方向；而用例相對來說更加形式化，易於上手；
2）特徵看上去很有吸引力，但畢竟相關的理論還未完整，引入團隊實踐有些困難。
三、用例分析技術簡介
　　用例分析技術是Rational三友之一Ivar Jacobson先生於1967年在愛立信公司開發AXE交換器時開始研究，並於1986年總結、發布的一項源於實踐的需求分析技術。Ivar先生在加盟Rational之後，與三友合作提出了UML、完善了RUP，用例分析技術也因此被人廣泛瞭解和關注。
　　用例分析技術為軟體需求規格化提供了一個基本的元素，而且該元素是可驗證、可度量的。用例可以作為專案計劃、進度控制、測試等環節的基礎。而且用例還可以使Team Dev與客戶之間的交流更加順暢。
　　許多人是在學習UML的時候接觸到Use case，所以許多人都誤解其為一種圖表，把使用案例圖當作用例分析的全部，其實這是錯誤的，用例描述才是用例分析技術的核心。下面是一個簡單的例子：

3.1 參與者，Actor
　　參與者，定義了使用者在系統互動過程中扮演的角色，其可以是一個人，也可以是另一個相關的系統。
3.2 用例，Use case
　　用例執行個體（情境）是在系統中執行的一系列動作，這些動作將產生特定參與者可見的價值結果，一個用例定義一組用例執行個體（情境）。
　　一個用例應為參與者提供（實現）一個價值。

3.3 事件流 
　　就像類對應於對象一樣，一個用例的執行個體就是使用情境，用例就是對使用情境進行抽象的總結：
　　1）前置條件：指在用例啟動時，參與者（Actor）與系統應置於什麼狀態，這個狀態應該是系統能夠檢測到的、可觀測的；
　　2）後置條件：用例結束時，系統應置於什麼狀態，這個狀態也應該是系統能夠檢測得到的、可觀測的；
　　3）基本事件流：基本事件流是對用例中常規、預期路徑的描述，也被稱為Happy day情境，這時大部分時間所遇到的情境；它將體現系統的核心價值；
　　4）擴充事件流：主要是對一些異常情況、選擇分支進行描述。
　　建議大家在編寫事件流時，注意以下幾點：
　　1）使用簡單的文法：主語明確，語義易於理解；
　　2）明確寫出"誰控制球"：也就是在事件流描述中，讓讀者直觀地瞭解是參與者在控制還是系統在控制；
　　3）從俯視的角度來編寫：指出參與者的動作，以及系統的響應，也就是第三者的角度；
　　4）顯示過程向前推移：也就是第一步都有前進的感（例如，使用者按下tab鍵做為一個事件就是不合適的）；
　　5）顯示參與者的意圖而非動作（光有動作，讓人不容易直接從事件流中理解用例）；
　　6）包括"合理的活動集"（帶資料的請求、系統確認、更改內部、返回結果）；
　　7）用"確認"而非"檢查是否"：（如系統確認使用者密碼正確，而非系統檢查使用者密碼是否正確）；
　　8）可選擇地提及時間限制；
　　9）採用"使用者讓系統A與系統B互動"的習慣用語；
　　10）採用"迴圈執行步驟x到y，直到條件滿足"的習慣用語。
四、Alistair Cockburn眼中的用例分析技術
　　在使用用例分析技術時，很多人都覺得如何確定用例的粒度是一個痛點，而且感覺到用例沒有什麼規則遵從，甚至有無所適從的感覺。正如Cockburn先生提出的學慣用例分析技術的"守、破、離"的三個階段：
　　1）守：練習基本功夫，遵循規則，照章行事；
　　2）破：能突破傳統，因地制宜地靈活應用； 3）離：超脫任何招式與規則，達到無招勝有招的境界。
　　但用例分析技術卻讓第一階段的初學者感到無法很快地掌握。而其所著"編寫有效用例"則想為用例分析技術補充規則，讓大家能夠更好地掌握。
　　Cockburn先生在Ivar Jacobson的基礎上，做了一些補充：
　　1）用例是契約，是系統與涉眾之間達成的契約。也就是將用例朝著形式化的方向發展；
　　2） 將用例分成三級：
　　◆ 概要級：包括多個使用者目標（顯示使用者目標啟動並執行語境，顯示相關目標的生命週期、為低層用例提供一個目錄表）；
　　◆ 使用者目標級
　　◆ 子功能級
　　不過，對於Cockburn先生的貢獻，用例始祖Ivar大師並未做出任何反應。本人在實踐中認為，Cockburn先生的思路與理念對於初學用例分析技術的人來說，十分有價值，使得用例分析技術更具操作性，當其同時也有點畫地為牢的感覺，也許Cockburn先生也意識到這點，因此第三階段就是"離"，沒有規則，按需靈活使用。
五、如何在開發過程中應用用例分析技術 
　　用例分析技術在需求過程中的地位如所示：
 

　　對於用例分析技術理解上的兩個最大的誤區是：
　　1）用例分析技術包括了整個需求過程：它只是一個需求分析技術，是在傳統的需求捕獲技術的基礎上使用的，並無法替代這些技術；
　　2）用例分析技術是分解技術：其實用例分析技術是一種合成技術，將在需求捕獲中收集而來的零散的特性合成為用例：
 

5.1 用例分析前的工作
　　在用例分析之前，應該完成以下工作：
　　1）確定涉眾（Stakeholder）和使用者類型（命名、簡要描述、涉眾代表、特徵、能力）；
　　2）確定涉眾代表（命名、簡要描述、責任、參與）；
　　3）在項目中加入涉眾代表（訪談、問卷、顧問、評審、角色扮演）；
　　4）建立共同的構想（問題定義、系統範圍、使用者目標、非功能需求à前景文檔）；
　　5）採用傳統的需求捕獲技術捕獲需求；
　　6）組建用例分析隊伍（少量、有問題域知識）。
5.2 用例分析過程中的注意事項
　　用例分析的過程如所示：
 

　　在使用中要注意：
　　1）用例源於涉眾，請不要自己杜撰出用例；
　　2）用例的事件流的編寫過程中，應充分加入團隊的參與；
　　3）雖然用例源於涉眾，但不要企圖向他們直接問"你還有什麼用例?這樣的問題。