1、基于軟件需求管理的風險研究學生姓名： 學 號：學 院：專 業： 指導教師： 論文成績： 內 容 摘 要隨著互聯網的發展，各行各業對軟件系統的需求愈來愈復雜，規模愈來愈大，從最初的紙質化轉為電子化的發展，到現在的大數據分析的信息化的發展。并且隨著企業的發展，工作過程重組，需求管理也越來越成為必然。需求管理是軟件項目管理的基礎，也是決定軟件項目成功的關鍵。而軟件需求的不確定性產生軟件項目的高風險，對于軟件需求造成的系統風險，需要進行風險管理。而風險管理是項目管理中的重要部分，通過對軟件項目需求的風險管理，減少風險的損失，從而實現軟件項目的科學管理方法。本論文從風險管理的風險識別、風險分析、風險應對

2、和風險監控幾個方面入手，分析研究了訓練系統中需求風險管理和控制的方法。關鍵字：需求管理 風險管理 風險識別 風險分析 風險應對 風險監控 訓練系統ABSTRACTWith the development of the Internet, all walks of life demand of the software system becomes more and more complicated, the scale is getting bigger, from the original paper turn to electronic development to today's

3、 big data analysis of informatization development. And with the development of enterprises, the restructuring of the work process, demand management has become increasingly inevitable. Demand management is the foundation of software project management, and it is also the key to the success of softwa

4、re project. The uncertainty of the software needs to produce the high risk of the software project, the system risk caused by the software requirements, the need for risk management. And risk management is an important part of project management, through the risk management of software project requi

5、rements, to reduce the risk of loss, so as to realize the scientific management of software project. This article from the risk management of risk identification, risk analysis, risk response and risk control aspects of the analysis of the need for risk management and control of the training system.

6、KEY WORDS：Demand management risk management risk identification risk analysis risk response risk monitoring training system23目 錄第一章 緒論1（一）研究背景和意義1（二）國內外研究現狀2（三）研究內容和方法2第二章 相關理論概述4（一）風險相關理論4（二）項目風險管理相關理論5（三）軟件需求管理相關概念6（四）軟件需求和風險管理的關系7（五）國內外軟件項目需求風險研究綜述8第三章 XX系統及其需求風險控制9（一）XX系統概述及特點9（二）項目需求的風險識別10（三）項

7、目需求的風險分析14（四）項目需求的風險控制14（五）項目需求的風險監控17第四章 項目需求管理中風險管理的心得體會19（一）項目需求管理中風險管理中的實踐及感悟19（二）項目需求管理中對項目風險管理的啟示19第五章 總結19（一）論文總結19（二）論文的局限于不足19參考文獻20基于軟件需求管理的風險研究基于軟件需求管理的風險研究第一章 緒論（一）研究背景和意義自20世紀80年代以來，我國軟件產業呈現出迅猛、廣泛、深化的發展趨勢，而全球范圍內經濟和社會的信息化發展，更催化了市場對軟件產品的巨大需求。軟件產品作為一種邏輯產品，是人類思維的創造物，其更替速度比傳統領域要迅速的多。隨著軟件產品規模

8、的不斷增長，軟件的復雜性也不斷提高。復雜軟件系統在國防、通信、航空航天、大型計算機等領域，以及證券、醫療、金融等國民經濟領域上的應用，更使得軟件產品成為人們生活中必不可少的重要組成部分。對軟件產品依賴程度的加大一方面方便了人們的生活，另一方面也使得軟件產品的質量直接關系到人們的生活、財產甚至是生命安全。因此，在軟件開發過程中影響軟件產品質量的問題也引起了普遍關注。國際化標準組織ISO中定義軟件質量為“反映軟件產品滿足規定需求和潛在需求能力的特征和特性的組合”。由此可知，衡量軟件質量標準的根本在于軟件是否能滿足用戶的需求，在多大程度上滿足用戶的需求。軟件需求與軟件質量息息相關，對軟件需求管理的好

9、壞也將直接影響到軟件項目開發的進度、預算、質量，甚至是軟件項目開發的成敗。軟件需求是軟件工程中的重要環節，是軟件設計的基礎，也是用戶于軟件工程人員之間的橋梁。作為軟件開發的源頭，需求定義和限制了軟件產品最終實現的要求。但是，軟件產品的抽象性、高度復雜性使得軟件產品的需求同傳統產品相比具有更多的不確定性、變化性、主觀性和模糊性。軟件開發過程中存在大量與軟件需求相關的問題。對軟件項目實踐的統計數據表明：大多數導致軟件項目失敗的原因并不是軟件開發的技術問題，而是管理問題，其中尤以需求管理的問題最為突出。軟件需求管理的難度是由需求本身的特點造成的。軟件需求的一個重要特征就是“不確定性”，這些不確定性可

10、能導致項目失敗、費用超標、開發周期延長、產品功能不完整等后果。對不確定要素造成的損失進行預測，并根據預測的結果選擇合適的管理方法和技術方法降低不確定帶來的損失，成為風險管理。而風險管理是項目管理中最重要的任務，是因為項目的確定性和常規性的工作及其管理都是程序化和結構化的管理問題，它們所需的管理力度十分有限；項目風險是一種帶來損失的可能性，如果不管理或管理不當就會造成損失；反之，項目風險還包含機會成分，如果能夠很好地開發和管理將會有效地提升項目的成功度。而對軟件項目需求管理的風險研究，就是找出這些導致不良后果的風險，并使其對產品的不良影響最小化。（二）國內外研究現狀1.國外研究現狀根據美國專門從

11、事IT項目實施效果跟蹤的權威機構Standish Group的；CHAOS報告：2003年，在所調查的IT項目中，徹底失敗的項目占調查總數的15%，還有超過50%的項目因為質量原因受到不同程度的質疑；2004年的調查顯示，絕對成功的IT項目占調查總數的29%，徹底失敗的占到了18%。CHAOS的報告分析還指出：導致這些項目失敗和質量問題的最主要原因都與需求相關；僅有20%的軟件項目能夠在預定工期內完成，其主要原因也是非預期的需求變更，尤其是需求形態的變化和新需求的增加。2.國內研究現狀目前國內很多的軟件企業，在提供IT整體解決方案的項目中不太關心對項目進行需求風險管理，結果導致項目延期、超支、

12、甚至失敗的情況比比皆是。隨著信息時代的發展，計算機軟件的需求愈來愈復雜，規模愈來愈大，而且隨著企業的發展，工作過程重組，需求管理已愈來愈成為必然。軟件危機持續了30年之久，至今仍無法得以很好地解決。究其原因，與軟件本身的特點固然有關，但長期以來，缺乏對軟件開發和維護的正確方法以及忽視軟件開發過程的質量控制仍是最為關鍵的原因。其中軟件開發和維護的方法的不正確性主要體現在：1) 忽視軟件開發前期的需求調研及分析；2) 開發過程缺乏統一的、規范化的方法指導；3) 文檔資料不齊全或不準確；4) 忽視與用戶之間、開發組成員之間的交流；5) 忽視測試的重要性；6) 不重視維護或由于上述原因造成維護工作的困

13、難。這樣，就經常出現用戶對“已完成”系統不滿意，軟件產品的質量經常出現漏洞，補丁一大堆。（三）研究內容和方法最近幾年，不論是軟件開發的技術和工具，還是對軟件項目進行項目管理的水平都取得了較大的進步，但是由于軟件項目管理和一般項目管理不同，往往存在著很大的不確定性，直接影響著項目的順利完成。控制軟件項目的風險是軟件項目管理的重要組成部分。目前的軟件風險管理方法存在著一些不足，在軟件項目管理實踐中不能取得最佳效果。本文通過對軟件產品開發中資源、用戶需求和產品之間的內在關系的分析，提出了基于用戶需求的軟件項目風險管理。在收集相關材料之后，依據科學的研究原則，通過對資料的深入細致研究，最后形成本論文的

14、內容框架。圖1 本文內容框架第二章 相關理論概述（一）風險相關理論1.風險風險，是某些不確定性以及由其可能引起的偏離預定目標的不良后果的綜合。風險包含三個主要特點：（1）不確定性。風險的本質是不確定性，這種特性表現于多個未來的不良后果及其發生的可能性。（2）后果的客觀性。當一種后果已經成為現實，或一項活動已結束，風險也就不存在了。（3）風險的可控制性。在我們周圍存在大量的風險，人們試圖評估它或者控制它，有些控制是成功，但有些控制是失敗的。人們可以通過風險發生的一些規律制定一些對應方案從而達到對風險進行控制。2.項目風險項目風險是指在項目生命周期內，由于某些不確定性可能導致項目偏離目標，造成項目

15、損失的風險。美國項目管理大師馬克思·懷德曼將其定義為某一時間發生給項目目標帶來不利影響的可能性。項目風險具有以下特征：（1）客觀性。在項目的全壽命周期內，項目風險是無處不在，無時沒有的，風險的存在決定于風險的各種因素的存在，只要決定風險的各種因素都達到發生風險的要求，風險就會發生。雖然人類一直希望能認識和控制風險，但直到現在也只能在一定的條件下適當改變項目風險存在和發生的條件，降低其發生的概率，減少損失程度，要完全消除所有風險是不可能的。（2）偶然性和規律性。風險具有不確定性，任何一種風險的發生，都是由許多條件和不確定性因素相互作用的結果，是一種隨機現象。個別風險事件的發生是偶然的、

16、無規律的，但是通過對大量風險事件資料的統計分析，我們可以從中找到其發生的規律，也就是說我們可以利用概率統計的方法來描述具有隨機不確定性的風險的發生規律，并在此基礎上進行風險管理。（3）多樣性。一般情況下，比較大型的項目實施周期長、規模大、涉及范圍廣，風險因素數量和種類多，導致大型項目在項目全壽命周期內面臨的風險種類多種多樣，如質量、技術、時間、成本等各種風險。（二）項目風險管理相關理論項目風險管理是指項目承擔單位對項目全壽命周期內可能遇到的風險進行預測、識別、分析、評估，并在此基礎上采取措施，提出對策，減少風險的損失，從而實現項目目標的科學管理方法。項目管理知識體系（Project Manag

17、ement Body of Knowledge，PMBOK）中告訴我們：項目的風險管理是對項目風險從識別到分析乃至采取應對措施等一系列過程，它包括將積極因素所產生的影響最大化和使消極因素產生影響最小化兩方面內容，風險管理包括四方面內容：1. 風險識別風險識別是是指在風險事故發生之前，人們運用各種方法系統的、連續的認識所面臨的各種風險以及分析風險事故發生的潛在原因。風險識別風險管理的第一步，也是風險管理的基礎。只有在正確識別出自身所面臨的風險的基礎上，人們才能夠主動選擇適當有效的方法進行風險處理。風險識別的主要任務是確定項目風險來源、風險產生的條件、描述風險特征和確定哪些風險條件有可能影響到本項

18、目。2. 風險分析風險分析有狹義和廣義兩種，狹義的風險分析是指通過定量分析的方法給出完成任務所需的費用、進度、性能三個隨機變量的可實現值的概率分布。而廣義的風險分析則是一種識別和測算風險，開發、選擇和管理方案來解決這些風險的有組織的手段。風險分析是對風險影響后后果進行風險評估和風險之間的相互作用，以便評定可能結果范圍。3. 風險應對風險應對是指在確定了決策的主體經營活動中存在的風險，并分析出風險概率機器風險影響程度的基礎上，根據風險性質和決策主體對風險的承受能力而制定的回避、承受、降低或者分擔風險等相應防范計劃。風險應對過程的活動是以求將風險降至可接受程度。4. 風險監控風險監控是指在決策主體

19、的運行過程中，對風險的發展與變化情況進行全程監督，并根據需要進行應對策略的調整。因為風險是隨著內部外部環境的變化而變化的，它們在決策主體經營活動的推進過程中可能會增大或者衰退乃至消失，也可能由于環境的變化又生成新的風險。風險監控是跟蹤已經識別的風險，完成風險管理計劃，可根據項目執行情況、已出現的風險和可能風險，對風險進行計劃調整，保證風險管理計劃的實施，并評估削減風險的效果。（三）軟件需求管理相關概念 1.軟件需求的概念。軟件需求，是（1）用戶解決問題或達到目標所需條件或權能。（2）系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或權能。（3）反應以上兩點所描述的條件或權能

20、的文檔說明。它包括功能性需求及非功能性需求。軟件需求包括三個不同的層次，即業務需求、用戶需求和功能需求，也包括非功能需求。業務需求反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明；用戶需求文檔描述了用戶使用茶品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明；功能需求定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。2.軟件需求管理的重要性。在軟件項目的開發中，要想讓項目取得成功，就應該充分的理解和滿足用戶的開發要求，如果不進行需求管理，就很難達到客戶的項目要求，設計出來的軟件不是用戶想要的那種，自然就會降低項目獲得成

21、功的機率。需求管理是軟件開發的第一步，也是最難走的一步，需求管理的好壞關系著軟件的好壞，甚至影響到軟件項目的成敗。從某種意義上來說，軟件行業和一般的生產行業有異曲同工之處，它們的性質都是為了更好的滿足消費者的需求掌握市場的最新動向。但軟件和傳統的生產企業還是有所區別，生產企業的需求管理是具體地、可直接描述的，而軟件是一種看不見摸不著的商品，它是無形的，因此它是需求管理具有模糊性、難以確定性。軟件行業的需求管理比傳統生產企業的需求管理更加重要，因為需求管理是軟件行業的命脈，決定著軟件項目的成功與否，需求管理不當會直接導致企業利益受損。因此，通過需求管理，建立和維護軟件項目和用戶需求之間的共識，要

22、求用戶的需求要合理，充分的理解和滿足用戶的開發要求，確保軟件項目滿足用戶需求，實現軟件項目的成功。（四）軟件需求和風險管理的關系軟件項目是一項要求協同完成的任務，它關注一個系統的軟件成分及其相連文檔的分析、詳細說明、設計、開發、測試和維護等工作。它根據用戶需求分配資源來完成軟件產品，用戶需求作為項目的初始條件，引發資源的分配和使用，在軟件過程結束后，資源轉化為軟件產品，項目中的資源包括：時間、技術、費用、軟硬件、人力資源和軟件過程，軟件過程作為一種特殊的資源，分配和安排其他資源的使用。軟件項目的不確定性導致項目高風險性，而軟件需求不確定性更是造成這些不確定性最主要因素。軟件需求對于軟件是否能按

23、時交付和成功應用有著舉足輕重影響。提高軟件產品質量，必須對軟件需求進行嚴格風險管理。即風險管理應該以用戶需求為根據：1.有統計數據和研究報告證明，軟件項目中的關鍵風險和需求有關；2.在軟件項目實施過程，用戶需求主導著項目中資源的分配和產品的生成，所以用戶需求決定著軟件項目的風險；3.從用戶需求在軟件項目中的地位來看，由于一切軟件產品、軟件項目都是為了滿足用戶需求而存在的，用戶需求能夠為軟件風險管理指明方向；4.一般性經驗證明，風險管理實施的越早，為風險付出的額外代價就越小，需求管理從軟件項目的最早階段開始貫穿于整個項目中，從用戶需求出發進行風險管理可以實現最佳效果。因此，風險管理方法應該直接反

24、映對用戶需求的管理。用戶需求在軟件項目風險管理中占據著很重要位置，關系著軟件項目的成功與否。如下表所示：表1 判斷軟件項目是否成功的統計表成功的標準（風險度）權重成功的標準（風險度）權重用戶的參與19高層管理的支持16明確的需求說明書123適當的計劃編制11切合實際的預期10更小的項目里程碑9勝任的工作人員8所有權6清晰的前景和目標3努力工作、專注的工作人員3對于軟件項目的用戶需求和風險管理方法之間的關系研究目前還比較缺乏，對需求度量和需求風險管理進行了一些研究。但這些研究中的單純的對需求度量的方法不足以支持在軟件項目中進行準確的風險預測。軟件項目風險管理方法應該以用戶需求為基礎，并應用其他軟

25、件工程方法，才能在最大程度上保證軟件產品滿足用戶的需求，實現軟件項目的成功。（五）國內外軟件項目需求風險研究綜述由于軟件需求本身的隱含性、用戶于開發者之間的溝通障礙，以及需求隨著時間、用戶的變化而變更等原因，可能使需求分析偏離實際需求而最終導致軟件開發的失敗，這種可能性稱為需求風險。關于需求風險的辨識、分析和控制，國內外很多學者進行了一系列的研究。1.國內研究付玉等討論了需求風險的控制方法。王延明則采用了一些軟計算的方法討論了需求風險的評價問題。楊皎平等建立了軟件需求風險的灰色模糊綜合評價模型。黃蒙基于用戶需求的軟件項目風險管理模型從用戶需求角度出發，通過軟件過程技術、產品工程技術和度量技術的

26、支持可以有效地控制軟件項目風險，保證了軟件產品滿足用戶需求的能力，從而使軟件項目達到成功。蔣海昌對降低軟件需求分析風險進行了探索，通過對需求分析的風險探索了解到對于一個需求分析師，需要不斷地積累需求開發、需求分析和設計經驗，通過溝通、可行性分析、需求等級劃分、需求范圍界定、定期向用戶決策層匯報、業務知識學習、提供系統原型、需求文檔編寫、數據分析、深入了解需求人員要求、建立需求評審機制和需求管理機制等方法可減少需求分析的缺陷、避免軟件返工，以降低需求分析的風險。2.國外研究羅伯特格拉斯（2002）指出，需求不斷變化是軟件項目失敗最主要的原因。The Standish Group Internat

27、ional,Inc.自1994年開始對IT項目的成功率進行統計研究，并發布了一系列題為“混沌（CHAOS）”的報告。導致許多項目失敗的原因并不是缺乏資金或技術，而是缺乏成熟的項目風險管理；以及低估項目的復雜度和忽視需求變化帶來的風險。基于需求風險對項目成敗的重大影響，很多學者提出了需求風險管理的思路，實踐上也出現了一些定性和定量分析風險的方法。Myers開發了一種用于幫助項目管理這今早識別在項目周期內引起需求風險原因的方法。Samson通過研究需求分析中潛在的問題來改進軟件需求定義。Robinson開發了一種需求工程風險評價方法，這種方法可以包含需求錯誤類型和風險事件的定量信息。Romano指

28、出了怎樣識別有潛在風險的需求的問題。由此，本文針對特定項目，研究其需求管理的風險控制，同時對XX系統項目提供一定的借鑒和參考。第三章 XX系統及其需求風險控制（一）XX系統概述及特點 根據總參謀部頒發“十二五”時期軍事訓練改革總體方案。為加快推進訓練管理信息化建設，按照“正規化組訓、標準化作業，精細化管理”的要求，依托軍隊現有信息化資源，建立覆蓋某部各級的軍事訓練信息系統，實現訓練組織網絡化、監控管理實時化、輔助決策智能化、統計評估精確化。用戶方組織力量深入基層調研論證，充分借鑒軍內外信息化建設經驗，研制XX系統。XX系統是針對用戶單位教學、訓練管理研發的一套信息化管理系統。通過信息化手段將訓

29、練過程中的各類業務融為一體，具備全面獲取信息、實施監控訓練進度、客觀分析訓練績效、自動管理訓練數據、有效輔助訓練決策等功能。依托軍隊網絡建立覆蓋用戶方各單位的雙向數據傳輸機制，自動匯總各單位的數據，通過直觀的圖形化方式進行展現，避免了因地域分布散、技術手段落后帶來的訓練管理難以“全程化、精細化、實時化”等問題，做到了“小的放大管，遠的拉近管，散的集中管”。根據XX系統本身的特點，本文主要介紹我們在系統需求風險管理中如何面對、處理和解決出現的風險問題，在此基礎上，為了處理需求中的各種風險，本文提出了對此系統的需求風險監控辦法，以保證此項目的正常進行。軟件項目是需求驅動典型，項目從立項、開發、測試

30、到交付，需求變化是正常的。需求變化控制不好，輕則嚴重拖延工期，重則導致項目失敗。在系統設計和開發過程中，隨著對系統需求理解的深入，客戶可能對需求補充或擴展，都會引發需求變更。即便系統交付，客戶在使用過程中仍然會對系統提出改進意見甚至增加新的功能。功能變更或增加的同時，給項目本身也帶來一定風險。而在項目的整個壽命周期內，不同階段的修改需求帶來的費用成本是不一樣。軟件各階段發現錯誤修復成本統計如圖2所示。圖2軟件各階段發現錯誤修復成本的統計（圖例說明，需求階段檢查和修改一個錯誤所需的費用只有設計階段的1/5，編碼階段的1/10，單元測試階段的1/20，到了交付階段則需要200倍的代價）從上圖及說明

31、可以看出，在軟件研發過程中，越到后面階段修復錯誤的成本越高，而且往往是需求階段成本的百倍。為了能夠提供高質量產品給用戶，更好地管理軟件項目，管理好需求成為項目成功的關鍵，而XX系統將用戶、開發人員和軟件質量保障人員等緊密聯系起來，協同工作，共同努力，從需求風險識別開始，然后對識別的需求風險進行分析，最后根據分析結果采取解決辦法，最終達到降低項目需求風險的目的。（二）項目需求的風險識別風險識別常用方法有：德爾菲法（專家調查法）、頭腦風暴法、魚刺圖（因果分析表）。而在XX系統開發中，常使用頭腦風暴、專家調查，對計劃、過程、需求評審等方式，形成包含業務、管理和技術等風險檢查表，借此進行風險識別。同時

32、，以以往經驗形成檢查表中的風險項（如表2所示）。表2 需求檢查表文檔編號版本號密級軟件需求檢查單項目名稱及版本號項目經理項目類別產品研發項目 客戶定制或應用開發項目 實施項目 維護項目序號檢查項是否不適用注釋清晰性1對需求的描述是否易于理解？2是否存在有二義性的需求？3是否定義了術語表，對特定含義的術語給予了定義？4最終產品的每個特征是用唯一的術語描述的嗎？組織和完整性1需求是否能為設計提供足夠的基礎？2是否包括了所有客戶代表或系統的需求？3在需求中是否遺漏了必要的信息？如果有的話，是否標記為“待確定”的問題？4是否每個需求都在項目的范圍內？與商業目標一致？5需求是否與一些業務限制、政策或規約

33、相沖突？6與組織機構或政策問題相關的需求是否與系統同的商業目標相沖突？7是否有的需求應該描述的更詳細些？8是否定義了功能需求在內的算法？9是否識別了設計約束？10是否對假設條件進行了說明？一致性1所有需求的編寫在細節上是否都一致？2對同一對象的術語定義存在矛盾嗎？3對同一對象的特征描述存在矛盾嗎？4是否多個需求相互沖突？可追蹤性1需求是否具有明確的來源，從而它可能被跟蹤？2是否每個需求都具有唯一性并且可以正確地被識別？可檢驗性1是否所有的需求都能實現？2是否每個需求都是可測試的？可修改性1每個需求描述是否清晰、符合邏輯？2組織結構是否合理、可接受？3是否每個需求都沒有內容上和語法上的錯誤？4是

34、否有冗余的信息？接口1是否對用戶界面進行了說明？2是否對硬件接口進行了說明？3是否對軟件接口進行了說明？4是否對接口的設計約束進行了說明？5是否對接口的安全性需求進行了說明？6是否對接口的可維護性需求進行了說明？質量、性能屬性1是否合理地定義了性能目標？2是否合理地確定了所有性能需求？如預期處理時間，數據傳輸速度等3是否合理地確定了安全與保密方面的需求？可靠性1是否描述了所有軟件故障的原因和結果？2是否記錄了所有可能的錯誤條件所產生的系統行為？3是否定義了防止故障或錯誤探查策略？4是否定義了修正策略？軟硬件1是否指明了硬件需求如內存、硬盤空間等？2是否對要求的軟件環境/操作系統進行了說明？3是

35、否說明了需要購買的軟件？4是否給出了要求的或估計的網絡吞吐率？5是否描述了將要使用的第三方軟件、中間件的應用及其批準？特殊問題1是否所有需求都是名副其實的需求而不是設計實現方案？2是否確定了對時間要求很高的功能并且定義了它們的時間標準？3使用實例是否是獨立的分散任務？4使用實例是否處于抽象級別上？而不是詳細的情節？5使用實例中是否記錄了所有可能的可選過程？6使用實例中是否記錄了所有可能的例外條件？7使用實例中的每一個操作和步驟是否都與所執行的任務相匹配？8使用實例中定義的每個過程是否都是可行的？可驗證？得分=“是”的項數/（總項數-“不適用”的項數）X100 通過風險識別方法進行風險識別后，X

36、X系統中存在以下問題:1. XX系統具有常規軟件存在的問題（1） 開發進度難以控制。（2） 質量難以控制。（3） 軟件修正以及維護困難。（4） 軟件工作量的準確度難以實現，進度難以把握，成本高，且復雜度隨規模增大指數增加。這不僅是技術問題，更是管理問題。2. XX系統本身特有的問題（1） 開發人員缺乏與用戶決策層深層次交流，對需求延伸性把握不好。（2） 用戶參與不足，溝通少，需求把握不準確，導致工作前期設計和后期使用截然不同。（3） 在開發過程中用戶隨時可能出現新的需求，或者業務發生變化，系統只能不斷增加投入，或者系統根本無法按時投入正常使用。（4） 用戶需求和流程在系統完善進步中逐漸清晰，軟

37、件實現也需要隨時跟進。（5） 前期無此需求，后期增加，系統考慮的兼容性不夠，嚴重影響系統可靠性。XX系統不僅有通用軟件固有問題，也有本身特有問題。系統要求一定要做好需求分析。整個需求階段要把系統中所有相關環節的風險，在系統初期風險計劃中體現出來。并對在風險檢查表中已識別的風險分配優先級，初步給出風險分析和解決或降低風險的策略。（三）項目需求的風險分析有資料研究表明，系統故障的44.1%是在規格說明階段出現的。79.6%的接口故障和20.4%的實現故障是因為不完備或者遺漏的需求所致。還有資料表明，8.12%的故障歸咎于功能需求中的問題，認為危害最大的是那些最早進入系統，而最后才被除掉的錯誤。因此

38、，花時間加深對于問題及其背景的理解，并在第一時間明確并完善需求是值得的。在軟件項目XX系統中需求通常包括用戶需求、項目需求和技術需求。其中，用戶需求和項目需求是需求分析基礎；而技術需求除了功能需求外，包括可靠性、可用性、安全性、操作性、可移植性等非功能需求。除了在項目內人員、物資和技術上保證外，還需要在實際分析過程中，通過需求分析方法的使用、文檔的建立和管理、與用戶間交流方式的選擇和應用等，切實掌握用戶各方面需求信息。在整個階段最主要的風險有：用戶不能提供足夠資料和信息或者用戶不能準確描述需求；用戶對需求沒有給出承諾，以后會經常修改；未挖掘用戶核心需求，或沒有深入理解需求，導致需求頻繁變動；需

39、求文檔不能準確完整地描述用戶需求，不能作為測試人員的測試輸入。同一體制內，不同用戶對于同一功能的需求不一致，甚至相沖突。在需求管理全過程中，不僅要對文檔進行嚴格管理，而且做到清晰明了，對所涉及的風險項目進行影響分析并采用全過程跟蹤方式，定期完成狀態更新。（四）項目需求的風險控制為了更好的控制整個系統風險，為軟件開發提供質量保證，將需求工作分為三部分：需求開發、需求管理和需求驗證。需求開發工作主要針對需求獲取、分析和編寫相關文檔；需求管理主要包括需求變更，需求跟蹤和配置管理工作；需求驗證包括評審、測試，讓獲得的需求得到有關人員認可。在XX系統需求管理實踐中，采用以下方式控制需求風險的相關過程。1

40、. 需求開發過程（1）首先，對需求進行確認。即需要確定系統用戶、項目范圍、工作流程和過程場景、確定需求重用等；同時，針對質量屬性和一些非功能需求，進行研究確認；通過與用戶交流、閱讀用戶工作文檔、了解用戶當前工作內容等方式進行需求確認。（2）其次，繪制需求各類圖。通過需求分析方法繪制系統組織結構圖、接口連接圖、數據流圖、實體關系圖、狀態轉換圖、時序圖等，通過軟件工程化方法中的原型開發技術進一步完善需求；對系統進行可行性分析；采用質量功能展開技術，對應一定的完成階段，將產品功能、性能和用戶需求緊密聯系，對需求進行優先級分類。（3）然后，將所有分析的結果，采用文檔方式進行記錄并確認，包括需求定義表和

41、軟件需求規格說明書（需求定義表，是面向軟件用戶，有關用戶需要完成的事情，包括使用環境、約束、監控和轉換等；而需求規格說明則面向技術人員，將需求描述成為系統構建和運轉）。在實施過程中，需求定義表中需求和需求規格說明中的需求必須有直接對應關系，以便于對今后實現的系統是否滿足需求進行跟蹤，同時也為工作量估算及實現難度提供了定量依據；同時需求定義可以作為用戶驗收依據，而規格說明則可以作為系統測試的準則。需求和軟件產品橫向跟蹤如圖3所示。圖3 需求和產品橫向跟蹤（6） 最后，完成對需求的沖突、技術難點及設備需求等的可行性分析。2. 需求管理過程通過需求的三部分工作內容進行需求過程管理；需求管理過程流程圖

42、，如圖4所示。圖4 需求管理過程流程圖（1） 通過對用戶需求調查，經需求分析形成需求規格說明和需求定義。（2） 獲取用戶或使用方的需求確認。（3） 管理需求的變更。通過需求跟蹤矩陣來維護需求的可跟蹤性，確保系統在計劃、產品和需求方面不會出現不一致。（4） 針對文檔的最終確認和有影響的需求變更，完成需求評審；將需求作為測試計劃的輸入，驗證需求是否完全符合用戶要求。定期對產品或文檔進行審查，對系統流程和工作狀況進行驗證。（五）項目需求的風險監控風險監控采用審核檢查法、監視單、項目風險報告、費用偏差分析表等方法，利用直方圖、因果分析圖、帕累托圖等工具直觀體現。在系統管理過程中，為了彌補軟件測試工作的

43、不足，成立過程與產品質量保證小組，主要完成軟件項目的第三方審計和過程審計，防患于未然。1. 需求階段的產品審計產品質量保證小組對需求的正確性、一致性、無二義性、組織和完整性、可檢驗性、可測試性、可跟蹤性、可修改性等通過檢查單方式確認，以保證能夠正確研發系統。針對用戶需求采用5W1H方法，明確是否正確反映用戶意圖。進行需求文檔檢查，即對需求分析人員提供的文檔或者原型以完整性、正確性和可行性為基礎進行嚴格評審；需求確認記錄檢查和需求不符合項報告。2. 需求階段過程審計（1） 對于需求變更的管理采用制定有關系統需求變更流程體系文件，并嚴格執行。（2） 采用需求變更7步法進行需求變更流程管理，具體內容

44、如下：第一步，變更申請。對客戶口述、電話、當面交流進行記錄，確認變更的必要性；第二步，評價工期、成本、質量等對系統的影響，對變更需求進行細化、量化和圖形化；第三步，評價變更需求對于不同項目階段的影響，主要針對項目穩定性、可靠性、安全性、測試性、缺陷密度等方面進行研究；第四步，對變更需求對項目帶來的風險進行風險分析，主要對人員、效率、變數等方面進行分析；第五步，估算需求變更帶來的人員、工時等人力成本及材料、軟硬件、差旅、調研等非人力成本；第六步，進行技術評審；第七步，記錄變更決定并登記變更記錄。（3） 需求風險控制方法對于需求的風險控制，可采用的控制方法有： 要求用戶簽署文件，達到控制需求變化的

45、目的； 對變更進行可行性分析，評估每次變更的成本及風險； 使用專家參與等方式有效控制需求變更； 受影響的組（系統測試組、軟件工程組、系統工程組、質量保證組、配置管理組合文檔支持組）均參與變更評審； 進行有效的配置管理； 變更后，重新完成測試。（4） 檢查需求的可追蹤性一旦發生需求變更，則產品的計劃、產品研發和活動將隨之變更。產品質量保障組采用需求和產品橫向跟蹤圖來檢查分配需求在各個階段狀態。確保需求定義中的文檔可以追蹤到規格說明及后期的設計文件和測試文件中；對每種需求評審、設計、測試等更新計劃安排，同時完成跟蹤；檢查測試用例的變更情況及完整性。（5） 定期進行狀態評審重新評估各需求的進展及狀態

46、，對需求在各階段的優先情況重新劃分，并完成評審；定期對于風險計劃中的風險項目重新評估其風險、概率及影響。（6） 定量評估對需求準確性進行定量評估的方法；根據需求的改變次數和規模可以按照需求類型來統計，有助于確定需求變更是否集中于特定類型的需求上；同時，將需求提供給設計人員和測試人員，就需求的理解程度（完全理解，部分新/可借鑒；全新/可以理解；不理解/不肯定；不理解/肯定不行等）進行打分，如果變更需求集中居多，則需要重新修訂需求。定期對于需求變更的范圍、強度和頻度進行評估。產品質量保障組定期對風險計劃、項目監控數據及項目進展情況進行報告，對風險系統較高的提交優先處理；對風險管理過程文檔（包括風險

47、檢查表和風險管理報告）完成配置管理產品質量保障組進行同步監控和跟蹤管理。需求分析階段是系統建設中任務最繁重，也是難度最大的階段。在XX系統中，采用各種協同工作方式，經過系統工程組、質量保證組及相關人員的共同努力，降低軟件需求分析的風險，就是為了能夠用系統前期的辛苦工作換取軟件可靠性的提高。由于對軟件能力成熟度模型的摸索中，系統中實現風險管理依然處于起步階段，對于需求風險的定量分析等工作需要以后進一步探索和加強。第四章 項目需求管理中風險管理的心得體會（一）項目需求管理中風險管理中的實踐及感悟從XX系統需求開發、管理和驗證的三部分工作內容或工作步驟來講，每一項工作的開始或完成都是一個風險管理的過

48、程，或是一個風險控制的過程。從識別出需求中的風險因素，到對這些因素的分析，找到對應這些風險因素控制的方案或降低這些風險因素的方法。雖然這個過程是復雜的，需求種類是多樣的，但是風險管理的過程是明確的，在軟件項目最初需求管理時，就做好風險管理，很大程度上已經保證了項目的成功。（二）項目需求管理中對項目風險管理的啟示在軟件項目的需求管理中，風險是多種多樣的，是無處不在的。在項目管理活動中，要積極面對風險。越早識別風險、越早管理風險，就越有可能規避風險，或者在風險發生時能夠降低風險帶來的影響。特別是在項目參與方多、涉及面廣、影響面大、技術含量高的復雜項目，應加強風險管理。如果不主動駕馭風險，就會面臨風

49、險。第五章 總結（一）論文總結本文以XX系統需求管理中的風險管理為研究案例，以項目管理知識體系為基礎，從XX系統需求的開發過程，到需求驗證的整個過程進行研究分析，同時結合風險管理中各階段應對解決辦法，詳細列舉了XX系統在需求管理過程中可能發生的各種風險及風險發生的相關解決辦法，然后提出了一套針對于XX系統需求管理的風險管理監控辦法，以供大家借鑒或參考，希望能將項目需求管理中風險發生后的不利影響范圍降到最低。通過本次論文的撰寫，讓我又重新梳理了整個項目管理知識體系，特別是對項目中的風險管理又有了新的認識，回想起自己在XX系統需求管理過程中的風險管理，往往都是遇到問題才去開始想處理辦法，很少會有一個系統的風險管理規劃，而且這也是當前需求管理中普遍存在的問題，通過這次學習，讓我認識到了自己項目管理中的一些不足，在今后的學習和工作中會更加的注重和加強這方面的學習。（二）論文的局限于不足項目管理知識體系涉及的范圍非常廣泛，本文只是從風險管理的角度對需求管理中存在的一些問題進行分析研究，從而忽略了項目管理中的其他方面，比如時間管理、成本管理