試析rup以用例驅動的需求管理
rup是rational統一過程（rational unified process）的簡稱，它是rational公司（現歸屬ibm公司）推出的一種軟體過程產品。從軟體過程模式角度看，rup又是一種典型的軟體過程模式，它以迭代增量式、架構為中心、用例驅動的軟體開發方法為主要特徵，其中以用例驅動乃是貫穿軟體開發始終的方法，而將其應用於需求管理自然是首當其衝的課題。
軟體需求是乙個軟體系統必須完成或達到的目標總和，需求管理是指了解、記錄、追蹤不斷變化的需求的乙個系統化方法。至今許多軟體開發的實踐都表明，有無良好的需求管理是整個軟體專案成敗的至關重要的一步，是與專案得失關係最大的首要因素。rup把需求定義為「（正在構建的）系統必須符合的條件或具備的功能」，並描述了如何提取、組織需要的功能和限制；跟蹤和文件化適中方案和決策；捕獲和進行商業需求交流。在此過程中的用例和場景（用例的例項）的使用，已被證明是捕獲功能性需求的卓越方法，並確保由它們來驅動軟體的設計、實現和測試，使最終系統更能滿足終端使用者的需要。下面對此稍作具體的分析。
一、用例驅動較之功能分解的優勢
在不同行業中，都有很多機會足以去發明產品，或改善製造和管理的過程，而把握機會的乙個重要方法就是從問題中找機會。rational正是一家善於思考問題的企業。
長期以來，在軟體工程實踐中普遍存在這樣一種認識——使用者知道需求是什麼，開發人員要做的就是從他們那裡得到需求，並由此做出系統功能的說明。基於這樣的認識和思想指導，傳統的軟體需求規約採用的基本上都是以功能分解的方式來描述系統功能。在這種表述方式中，系統功能被分解到各個系統功能模組中，通過描述細分的系統模組功能來達到描述整個系統功能的目的。但採用這種方法來描述系統需求，非常容易混淆需求和設計的界限，其表述中實際上已經包含了部分的設計在內。由此常常導致這樣的迷惑：系統需求應該詳細到何種程度？極端的情況就是需求可以詳細到概要設計，因為這樣的需求表述既包含了外部需求也包含了內部設計。以往在有些公司的開發流程中，對於需求就有"內部需求"（實為內部設計）和"外部需求"之區分與稱謂。
功能分解方法的另乙個缺點是它分割了各項系統功能的應用環境，從各個功能項入手，你就很難了解到這些功能項是如何相互關聯來實現乙個完整的系統服務的。所以在傳統的srs文件中，我們往往需要另外一些章節來描述系統的整體結構及各部分之間的相互關聯，這些內容使得srs需求更像是乙個設計文件。
用例方法是完全站在使用者的角度上（即從系統的外部）來描述系統的功能，所要回答的問題是「系統應該為每個使用者做什麼」。它把被定義的系統看作是乙個黑箱，先不去關心系統內部是如何完成它所提供的功能，而僅描述被定義系統有哪些外部使用者（抽象成為actor）會與其發生互動；針對每一參與者，又描述系統為這些參與者提供了什麼樣的服務（抽象成為use case），或者說系統是如何被這些參與者使用的。在所有用例構成的用例模型中，判斷系統各項功能是否重要或有價值的標準，是考慮系統為每個使用者提供的價值，包括該功能輔助哪個使用者進行工作？需要提供什麼業務？能夠為業務增加多少價值？因此，用例能夠用於指導找出每個使用者所需要的功能，避免提出使用者根本就不需要的冗餘功能，從而有效界定系統的範圍和行為，使整個系統的業務為每個使用者提供最大的價值。
與傳統的功能分解方式相比，用例方法全都是從外部來定義系統功能，它把需求與設計完全分離開來。在物件導向的分析設計方法中，用例模型主要用於表述系統的功能性需求，系統的設計主要由物件模型來記錄表述。此外，用例定義了系統功能的使用環境與上下文，每乙個用例描述的是乙個完整的系統服務。
在rup中，以用例捕獲需求方法的優勢是顯而易見的。首先它描述了使用者是如何與系統互動的，這種描述更易於被使用者所理解，是開發人員和使用者之間針對系統需求進行溝通、迅速達成共識的有效手段。其次由於它是以時間順序描述互動過程，因此系統分析員和使用者都可以輕易地識別用例中存在的缺陷。再次是它能使團隊成員在設計、實現、測試和最後編寫使用者手冊的過程中都緊緊地以使用者需求為中心，促使開發人員始終站在使用者的角度考慮問題，容易驗證設計和實現滿足使用者的需求。此外，用例還簡化了記錄功能需求的工作，有效提高開發工作的效率。
二、用例驅動需求管理的技巧
注重需求管理，確保滿足客戶的需求，既是rup的基本原理之一，又是rup靜態結構中的乙個重要核心工作流程。針對軟體需求不顯見、多源頭、不同性、多變化等特點，rup提供了基於用例驅動的指導來提高需求管理技能和流程的專業技術，並開發了有效進行自動化管理需求的工具。其中下列的管理技巧在有效的需求管理流程中，是以不同的順序連續應用的。
三、管理需求中須注意的問題
rational公司的兩位rup的開發與管理者per kroll和philippe kruchten在《實踐者指南》一書中，曾提示了一些不能正確應用rup的問題，這在管理需求工作中也有所體現。由於以用例驅動需求管理所獲得的明顯益處，容易使團隊成員產生盲目樂觀情緒，從而減弱了把握正確應用的思維判斷能力，產生過猶不及或輕視麻痺的行為及不良效果，這是在管理需求實踐中必須加以注意和避免的。其主要問題有：
一是建立過多的用例。乙個常見的現象是根據功能把用例劃分得太細，沒能做到「有所為有所不為」，這樣將產生下列的後果：使用者對粒度太小的用例很難了解及難以判斷是否滿足他們的需求；設計人員對於過細的功能無法全部實現，難以通過設計滿足實際使用者需求；開發人員對關係太緊密的用例很可能開發重複功能並妨礙其他人工作；測試人員要花很多額外精力合成測試用例，才能建立有意義的測試。要避免發生這種情況，應注重以下列的幾條標誌來準確量度把握：無法衡量能否給使用者產生價值的用例，代表的是不完整的互動過程，應當重建；用例a總是與用例b或用例c相關，應當把它們集成為乙個用例；兩個或多個用例有著幾乎相同的描述，就可以把它們合併在一起；對於用例模型中用例之間的關係，不要進行多於一層的抽象。
二是忽視需求定義的準確與共識。系統的用例模型是由多個系統分析員協同完成的，模型本身也是由多個工件所組成。如果忽略了不同工件之間是否存在矛盾或衝突的地方，就會在模型內部產生不一致性，這種不一致性將會直接影響到需求定義的準確性。同時用例模型最大的優點就在於它應該易於被不同涉眾所理解且無二義性，因此用例的粒度、個數以及模型元素之間的關係複雜程度都應該依此原則所決定，從而使準確的需求定義成為團隊成員和所有涉眾達成共識的基礎。
三是在初始階段過於細化需求。根據rup對生命週期的階段、目的和里程碑的劃分，初始階段的目的是定義系統的邊界並理解最重要的使用者需求，這個階段最重要的任務是盡快建立可執行的架構，以化解重大風險，因此不必在初始階段花費太多時間細化需求。這一階段只要得到乙個合理並完整的參與者和用例的清單，廣泛而扼要地描述需求，細化基本的或關鍵的用例，就可結束任務，爾後盡早轉入到細化階段，從而為後續的細化需求工作留出充裕的時間。
四是不善於設定需求的優先順序。由於資源或技術條件的限制，不可能把所有需求都一次性完成，這樣就必須進行精心設定，按優先順序排序，分批予以實現。為需求設定優先順序時應當思考：某個用例是否必須在另乙個用例之前實現？是否必須實現整個用例？哪些用例或用例的哪些部分是最重要的？哪一些提供了最多的價值？應把每個需求按對效益的貢獻打分，然後將優先順序高的先實現，低的到下乙個版本，對不斷進來的新需求也應照此辦理。還要注意的一點是，最合理的需求不一定是要最先考慮的，「經濟為本」應始終是指導優先排序的最高原則。
試析RUP以用例驅動的需求管理
試析rup以用例驅動的需求管理 rup是rational統一過程 rational unified process 的簡稱，它是rational公司 現歸屬ibm公司 推出的一種軟體過程產品。從軟體過程模式角度看，rup又是一種典型的軟體過程模式，它以迭代增量式 架構為中心 用例驅動的軟體開發方法為...
用例驅動的需求過程實踐
根據筆者多年來從事軟體需求捕獲 分析工作的實踐經驗，認為造成這一現象的根本原因在於客戶與開發人員之間的溝通存在障礙，雙方都以自己的角度 自己的專業術語進行溝通，這使得大家並不能夠很好地就軟體需求達成共識。由於幫助客戶更好地利用資訊化工具提高工作效率，是我們軟體開發團隊的責任，因此我們沒有權利讓使用者...
需求的細化方法之用例驅動
在專案啟動階段，您是否遇到過這樣的問題呢？專案啟動的時候，只給你一本巨厚無比的標書，不知道從何下手。認真的看了一遍標書之後，只知道要做的是什麼，卻不知道如何推進。從標書上無法對任務進行細化。團隊的人不知道該如何分配任務。盡量將所有的資訊以紙質的形式列印出來，貼到白板或者牆上，以便大家隨時查閱。思考測...