RUP是Rational統(tǒng)一過程（Rational Unified Process）的簡稱，它是Rational公司（現(xiàn)歸屬IBM公司）推出的一種軟件過程產(chǎn)品。從軟件過程模式角度看，RUP又是一種典型的軟件過程模式，它以迭代增量式、架構為中心、用例驅(qū)動的軟件開發(fā)方法為主要特征，其中以用例驅(qū)動乃是貫穿軟件開發(fā)始終的方法，而將其應用于需求管理自然是首當其沖的課題。
　　軟件需求是一個軟件系統(tǒng)必須完成或達到的目標總和，需求管理是指了解、記錄、追蹤不斷變化的需求的一個系統(tǒng)化方法。至今許多軟件開發(fā)的實踐都表明，有無良好的需求管理是整個軟件項目成敗的至關重要的一步，是與項目得失關系最大的首要因素。RUP把需求定義為“（正在構建的）系統(tǒng)必須符合的條件或具備的功能”，并描述了如何提取、組織需要的功能和限制；跟蹤和文檔化適中方案和決策；捕獲和進行商業(yè)需求交流。在此過程中的用例和場景（用例的實例）的使用，已被證明是捕獲功能性需求的卓越方法，并確保由它們來驅(qū)動軟件的設計、實現(xiàn)和測試，使最終系統(tǒng)更能滿足最終用戶的需要。下面對此稍作具體的分析。
    一、用例驅(qū)動較之功能分解的優(yōu)勢
　　在不同行業(yè)中，都有很多機會足以去發(fā)明產(chǎn)品，或改善制造和管理的過程，而把握機會的一個重要方法就是從問題中找機會。Rational正是一家善于思考問題的企業(yè)。
　　長期以來，在軟件工程實踐中普遍存在這樣一種認識——用戶知道需求是什么，開發(fā)人員要做的就是從他們那里得到需求，并由此做出系統(tǒng)功能的說明?；谶@樣的認識和思想指導，傳統(tǒng)的軟件需求規(guī)約采用的基本上都是以功能分解的方式來描述系統(tǒng)功能。在這種表述方式中，系統(tǒng)功能被分解到各個系統(tǒng)功能模塊中，通過描述細分的系統(tǒng)模塊功能來達到描述整個系統(tǒng)功能的目的。但采用這種方法來描述系統(tǒng)需求，非常容易混淆需求和設計的界限，其表述中實際上已經(jīng)包含了部分的設計在內(nèi)。由此常常導致這樣的迷惑：系統(tǒng)需求應該詳細到何種程度？極端的情況就是需求可以詳細到概要設計，因為這樣的需求表述既包含了外部需求也包含了內(nèi)部設計。以往在有些公司的開發(fā)流程中，對于需求就有"內(nèi)部需求"（實為內(nèi)部設計）和"外部需求"之區(qū)分與稱謂。
　　功能分解方法的另一個缺點是它分割了各項系統(tǒng)功能的應用環(huán)境，從各個功能項入手，你就很難了解到這些功能項是如何相互關聯(lián)來實現(xiàn)一個完整的系統(tǒng)服務的。所以在傳統(tǒng)的SRS文檔中，我們往往需要另外一些章節(jié)來描述系統(tǒng)的整體結(jié)構及各部分之間的相互關聯(lián)，這些內(nèi)容使得SRS需求更像是一個設計文檔。
　　通過軟件開發(fā)的反復實踐后發(fā)現(xiàn)，任何系統(tǒng)都會有很多用戶（或不同類型的用戶），每個用戶只知道其個人如何使用系統(tǒng)，他們并不知道也不想了解系統(tǒng)的內(nèi)部結(jié)構、設計及整體運行情況，他們所關心的只是系統(tǒng)所能提供的服務，也就是被開發(fā)出來的系統(tǒng)將是如何被使用的，這就是Rational思考問題的角度，也是創(chuàng)制用例方法的基本指導思想。
　　用例方法是完全站在用戶的角度上（即從系統(tǒng)的外部）來描述系統(tǒng)的功能，所要回答的問題是“系統(tǒng)應該為每個用戶做什么”。它把被定義的系統(tǒng)看作是一個黑箱，先不去關心系統(tǒng)內(nèi)部是如何完成它所提供的功能，而僅描述被定義系統(tǒng)有哪些外部使用者（抽象成為Actor）會與其發(fā)生交互；針對每一參與者，又描述系統(tǒng)為這些參與者提供了什么樣的服務（抽象成為Use Case），或者說系統(tǒng)是如何被這些參與者使用的。在所有用例構成的用例模型中，判斷系統(tǒng)各項功能是否重要或有價值的標準，是考慮系統(tǒng)為每個用戶提供的價值，包括該功能輔助哪個用戶進行工作？需要提供什么業(yè)務？能夠為業(yè)務增加多少價值？因此，用例能夠用于指導找出

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html