RUP是Rational統一過程（Rational Unified Process）的簡稱，它是Rational公司（現歸屬IBM公司）推出的一種軟件過程產品。從軟件過程模式角度看，RUP又是一種典型的軟件過程模式，它以迭代增量式、架構為中心、用例驅動的軟件開發方法為主要特征，其中以用例驅動乃是貫穿軟件開發始終的方法，而將其應用于需求管理自然是首當其沖的課題。
軟件需求是一個軟件系統必須完成或達到的目標總和，需求管理是指了解、記錄、追蹤不斷變化的需求的一個系統化方法。至今許多軟件開發的實踐都表明，有無良好的需求管理是整個軟件項目成敗的至關重要的一步，是與項目得失關系最大的首要因素。RUP把需求定義為“（正在構建的）系統必須符合的條件或具備的功能”，并描述了如何提取、組織需要的功能和限制；跟蹤和文檔化適中方案和決策；捕獲和進行商業需求交流。在此過程中的用例和場景（用例的實例）的使用，已被證明是捕獲功能性需求的卓越方法，并確保由它們來驅動軟件的設計、實現和測試，使最終系統更能滿足最終用戶的需要。下面對此稍作具體的分析。
一、用例驅動較之功能分解的優勢
在不同行業中，都有很多機會足以去發明產品，或改善制造和管理的過程，而把握機會的一個重要方法就是從問題中找機會。Rational正是一家善于思考問題的企業。
長期以來，在軟件工程實踐中普遍存在這樣一種認識——用戶知道需求是什么，開發人員要做的就是從他們那里得到需求，并由此做出系統功能的說明�；谶@樣的認識和思想指導，傳統的軟件需求規約采用的基本上都是以功能分解的方式來描述系統功能。在這種表述方式中，系統功能被分解到各個系統功能模塊中，通過描述細分的系統模塊功能來達到描述整個系統功能的目的。但采用這種方法來描述系統需求，非常容易混淆需求和設計的界限，其表述中實際上已經包含了部分的設計在內。由此常常導致這樣的迷惑：系統需求應該詳細到何種程度？極端的情況就是需求可以詳細到概要設計，因為這樣的需求表述既包含了外部需求也包含了內部設計。以往在有些公司的開發流程中，對于需求就有"內部需求"（實為內部設計）和"外部需求"之區分與稱謂。
功能分解方法的另一個缺點是它分割了各項系統功能的應用環境，從各個功能項入手，你就很難了解到這些功能項是如何相互關聯來實現一個完整的系統服務的。所以在傳統的SRS文檔中，我們往往需要另外一些章節來描述系統的整體結構及各部分之間的相互關聯，這些內容使得SRS需求更像是一個設計文檔。
通過軟件開發的反復實踐后發現，任何系統都會有很多用戶（或不同類型的用戶），每個用戶只知道其個人如何使用系統，他們并不知道也不想了解系統的內部結構、設計及整體運行情況，他們所關心的只是系統所能提供的服務，也就是被開發出來的系統將是如何被使用的，這就是Rational思考問題的角度，也是創制用例方法的基本指導思想。
用例方法是完全站在用戶的角度上（即從系統的外部）來描述系統的功能，所要回答的問題是“系統應該為每個用戶做什么”。它把被定義的系統看作是一個黑箱，先不去關心系統內部是如何完成它所提供的功能，而僅描述被定義系統有哪些外部使用者（抽象成為Actor）會與其發生交互；針對每一參與者，又描述系統為這些參與者提供了什么樣的服務（抽象成為Use Case），或者說系統是如何被這些參與者使用的。在所有用例構成的用例模型中，判斷系統各項功能是否重要或有價值的標準，是考慮系統為每個用戶提供的價值，包括該功能輔助哪個用戶進行工作？需要提供什么業務？能夠為業務增加多少價值？因此，用例能夠用于指導找出每個用戶所需要的功能，避免提出用戶根本就不需要的冗余功能，從而有效界定系統的范圍和行為，使整個系統的業務為每個用戶提供最大的價值。
與傳統的功能分解方式相比，用例方法全都是從外部來定義系統功能，它把需求與設計完全分離開來。在面向對象的分析設計方法中，用例模型主要用于表述系統的功能性需求，系統的設計主要由對象模型來記錄表述。此外，用例定義了系統功能的使用環境與上下文，每一個用例描述的是一個完整的系統服務。
在RUP中，以用例捕獲需求方法的優勢是顯而易見的。首先它描述了用戶是如何與系統交互的，這種描述更易于被用戶所理解，是開發人員和用戶之間針對系統需求進行溝通、迅速達成共識的有效手段。其次由于它是以時間順序描述交互過程，因此系統分析員和用戶都可以輕易地識別用例中存在的缺陷。再次是它能使團隊成員在設計、實現、測試和最后編寫用戶手冊的過程中都緊緊地以用戶需求為中心，促使開發人員始終站在用戶的角度考慮問題，容易驗證設計和實現滿足用戶的需求。此外，用例還簡化了記錄功能需求的工作，有效提高開發工作的效率。
二、用例驅動需求管理的技巧
注重需求管理，確保滿足客戶的需求，既是RUP的基本原理之一，又是RUP靜態結構中的一個重要核心工作流程。針對軟件需求不顯見、多源頭、不同性、多變化等特點，RUP提供了基于用例驅動的指導來提高需求管理技能和流程的專業技術，并開發了有效進行自動化管理需求的工具。其中下列的管理技巧在有效的需求管理流程中，是以不同的順序連續應用的。
分析業務問題。進行業務分析是為了加深了解與熟悉用戶的需要和實際業務運作流程，盡力找出“隱藏在問題背后的問題”，并提出高層解決方案。在問題分析過程中，將對實際問題的說明取得一致，并確定有關的涉眾。初始解決方案的界限和約束從技術和業務兩個方面來定義。在適當的時候，從項目的商業理由分析中還能得到期望從系統獲得的投資回報。
理解涉眾需要。需求將有許多來源，客戶、合作伙伴、最終用戶以及領域專家都是某些需求的來源，而管理人員、項目團隊成員、業務策略和管理機構是另外一些需求源。不同的用戶和相關人員會關心不同的問題，其間的要求甚至是互相矛盾的；同時這些需求之間又有著千絲萬縷的聯系，必須在深刻理解的基礎上，既綜合整理歸納，又分門別類對待。
明確定義系統。定義系統是指正確解釋涉眾需求，并整理成對要構建的系統意義明確的說明。說明可以是書面文檔、電子文件、圖像或用于表達除系統本身以外的系統需求的任何表示方式。在系統定義初期，需要決定需求的構成、文檔格式、語言規范、需求等級、請求優先級、預計工作量、技術和管理風險以及系統規模等。系統定義活動還可包括與最關鍵的涉眾請求直接聯系的初期原型和設計模型。
管理系統規模。項目規模由分配給它的需求集定義。管理項目規模，使之適合可用資源（時間、人力和資金），是成功管理項目的關鍵。使用需求屬性（如優先級、工作量和風險）作為協商項目應包含需求的基礎，對管理系統規模而言是相當有用的技巧。側重于屬性，而不是需求自身，將減少通常對敏感問題的爭論。同時這也有助于培養團隊負責人的談判技巧，有助于在項目中為組織培養推介人。項目推介人應既有能力代表組織拒絕那些超出可用資源的規模變更，也有相應能力擴展資源以適應擴大的規模。
改進系統定義。對高層系統定義達成一致并充分理解了系統初始規模后，投入資源改進系統定義不僅有可能，而且也是經濟的。改進系統定義包括兩個重要的考慮事項：制定更詳細的高層系統說明和驗證系統是否符合涉眾需要并按說明運行。說明通常是項目團隊的重要參考材料，在制定說明時一定要考慮受眾，需要為不同的受眾編制不同類型的說明。確定說明格式后，改進將持續貫穿整個項目生命周期。
管理變更需求。軟件需求的變更總是在不斷的產生之中，實際上有些變更是非常值得的，我們應當樹立“變更不是敵人，而沒有管理的變更才是真正敵人”的觀念。對于一個團隊來說，能否適應變更需求是評測團隊涉眾敏感度和運作靈活性的一個尺度，而敏感度和靈活性正是對項目成功有貢獻的團隊的特征。當然需求變更表明多少需要耗費一些時間來實施某個特定的功能，而且一個需求的變更對其他需求可能帶來影響。管理需求變更包括這樣一些活動：設立基線，追蹤每個需求的歷史，確定哪些依賴關系值得追蹤，在相關項之間建立可追蹤關系以及維護版本控制等。此外，建立變更控制或批準流程也很重要，它要求由指定相關負責的團隊成員來復審所有提議的變更，以在全局的高度上對變更需求的好處和可能引起的后果之間有個客觀的權衡和把握。
文章來源于領測軟件測試網 http://www.k11sc111.com/
