試析RUP以用例驅動的需求管理[2]

　　與傳統的功能分解方式相比，用例方法全都是從外部來定義系統功能，它把需求與設計完全分離開來。在面向對象的分析設計方法中，用例模型主要用于表述系統的功能性需求，系統的設計主要由對象模型來記錄表述。此外，用例定義了系統功能的使用環境與上下文，每一個用例描述的是一個完整的系統服務。

　　在RUP中，以用例捕獲需求方法的優勢是顯而易見的。首先它描述了用戶是如何與系統交互的，這種描述更易于被用戶所理解，是開發人員和用戶之間針對系統需求進行 溝通、迅速達成共識的有效手段。其次由于它是以時間順序描述交互過程，因此系統分析員和用戶都可以輕易地識別用例中存在的缺陷。再次是它能使 團隊成員在設計、實現、測試和最后編寫用戶手冊的過程中都緊緊地以用戶需求為中心，促使開發人員始終站在用戶的角度考慮問題，容易驗證設計和實現滿足用戶的需求。此外，用例還簡化了記錄功能需求的工作，有效提高開發工作的效率。

　　二、用例驅動需求管理的技巧

　　注重需求管理，確保滿足客戶的需求，既是RUP的基本原理之一，又是RUP靜態結構中的一個重要核心工作流程。針對軟件需求不顯見、多源頭、不同性、多變化等特點，RUP提供了基于用例驅動的指導來提高需求管理技能和流程的專業技術，并開發了有效進行自動化管理需求的工具。其中下列的管理技巧在有效的需求管理流程中，是以不同的順序連續應用的。

　　分析業務問題。進行業務分析是為了加深了解與熟悉用戶的需要和實際業務運作流程，盡力找出“隱藏在問題背后的問題”，并提出高層解決方案。在問題分析過程中，將對實際問題的說明取得一致，并確定有關的涉眾。初始解決方案的界限和約束從技術和業務兩個方面來定義。在適當的時候，從項目的商業理由分析中還能得到期望從系統獲得的投資回報。

　　理解涉眾需要。需求將有許多來源，客戶、合作伙伴、最終用戶以及領域專家都是某些需求的來源，而管理人員、項目團隊成員、業務策略和管理機構是另外一些需求源。不同的用戶和相關人員會關心不同的問題，其間的要求甚至是互相矛盾的；同時這些需求之間又有著千絲萬縷的聯系，必須在深刻理解的基礎上，既綜合整理歸納，又分門別類對待。

　　明確定義系統。定義系統是指正確解釋涉眾需求，并整理成對要構建的系統意義明確的說明。說明可以是書面文檔、電子文件、圖像或用于表達除系統本身以外的系統需求的任何表示方式。在系統定義初期，需要決定需求的構成、文檔格式、語言規范、需求等級、請求優先級、預計工作量、技術和管理 風險以及系統規模等。系統定義活動還可包括與最關鍵的涉眾請求直接聯系的初期原型和設計模型。

　　管理系統規模。項目規模由分配給它的需求集定義。管理項目規模，使之適合可用 資源（時間、人力和資金），是成功管理項目的關鍵。使用需求屬性（如優先級、工作量和風險）作為協商項目應包含需求的基礎，對管理系統規模而言是相當有用的技巧。側重于屬性，而不是需求自身，將減少通常對敏感問題的爭論。同時這也有助于培養團隊負責人的談判技巧，有助于在項目中為組織培養推介人。項目推介人應既有能力代表組織拒絕那些超出可用資源的規模變更，也有相應能力擴展資源以適應擴大的規模。

　　改進系統定義。對高層系統定義達成一致并充分理解了系統初始規模后，投入資源改進系統定義不僅有可能，而且也是經濟的。改進系統定義包括兩個重要的考慮事項：制定更詳細的高層系統說明和驗證系統是否符合涉眾需要并按說明運行。說明通常是項目團隊的重要參考材料，在制定說明時一定要考慮受眾，需要為不同的受眾編制不同類型的說明。確定說明格式后，改進將持續貫穿整個項目生命周期。

　　管理變更需求。軟件需求的變更總是在不斷的產生之中，實際上有些變更是非常值得的，我們應當樹立“變更不是敵人，而沒有管理的變更才是真正敵人”的觀念。對于一個團隊來說，能否適應變更需求是評測團隊涉眾敏感度和運作靈活性的一個尺度，而敏感度和靈活性正是對項目成功有貢獻的團隊的特征。當然需求變更表明多少需要耗費一些時間來實施某個特定的功能，而且一個需求的變更對其他需求可能帶來影響。管理需求變更包括這樣一些活動：設立基線，追蹤每個需求的歷史，確定哪些依賴關系值得追蹤，在相關項之間建立可追蹤關系以及維護版本控制等。此外，建立 變更控制或批準流程也很重要，它要求由指定相關負責的團隊成員來復審所有提議的變更，以在全局的高度上對變更需求的好處和可能引起的后果之間有個客觀的權衡和把握。


　　三、管理需求中須注意的問題

　　Rational公司的兩位RUP的開發與管理者Per Kroll和Philippe Kruchten在《實踐者指南》一書中，曾提示了一些不能正確應用RUP的問題，這在管理需求工作中也有所體現。由于以用例驅動需求管理所獲得的明顯益處，容易使團隊成員產生盲目樂觀情緒，從而減弱了把握正確應用的思維判斷能力，產生過猶不及或輕視麻痹的行為及不良效果，這是在管理需求實踐中必須加以注意和避免的。其主要問題有：

　　一是創建過多的用例。一個常見的現象是根據功能把用例劃分得太細，沒能做到“有所為有所不為”，這樣將產生下列的后果：用戶對粒度太小的用例很難了解及難以判斷是否滿足他們的需求；設計人員對于過細的功能無法全部實現，難以通過設計滿足實際用戶需求；開發人員對關系太緊密的用例很可能開發重復功能并妨礙其他人工作；測試人員要花很多額外精力合成測試用例，才能創建有意義的測試。要避免發生這種情況，應注重以下列的幾條標志來準確量度把握：無法衡量能否給用戶產生價值的用例，代表的是不完整的交互過程，應當重建；用例A總是與用例B或用例C相關，應當把它們整合為一個用例；兩個或多個用例有著幾乎相同的描述，就可以把它們合并在一起；對于用例模型中用例之間的關系，不要進行多于一層的抽象。

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