需求變更的管理流程精選(九篇)
前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的需求變更的管理流程主題范文，僅供參考，歡迎閱讀并收藏。
第1篇：需求變更的管理流程范文
1軟件需求分析
軟件需求是指用戶對新系統在功能、行為、性能、設計約束等方面的期望。包括業務需求、用戶需求、系統需求3個不同層次。在需求獲取階段所得到的需求是雜亂的而不明確的，很多需求既重復又矛盾，而一個合格的需求描述應該具備完整性、可測試性、確定性、無歧義、可跟蹤性、正確性、必要性等特性，而需求分析就是把這些雜亂的用戶要求和期望轉化有效而合格的需求描述的過程。首先，系統分析師通過對所獲取的需求進行分類，創建出不同的業務模型：通過由領域專家（當系統分析師具有足夠的領域經驗時，可泛化為領域專家）途徑得到業務類模型，制作出被領域廣泛認可的需求模型；通過與客戶/用戶溝通得到業務用例模型，獲得當前業務的獨有特征，再將兩個需求集合統一，構成業務模型。1.1需求分析的方法在軟件工程的研究中，人們提出了多種需求分析的方法，其中主要有結構化分析法（StructureAnalysis，SA）、面向對象分析法（Object-OrientedAnalysis，OOA）和面向問題域的方法。另外，還有一些形式化方法，但由于實用性不強，一般只用在學術研究中。1.1.1SA方法SA方法主要關注于功能的分層和分解。這非常符合人們自上而下，逐步分解問題直到可解決的自然思考方式。但通過細分系統模塊的功能來描述整個系統做法，很容易混淆需求和設計的界限，使系統分析師感到迷惑，不知道系統需求應該詳細到何種程度。并且從用戶的角度來看，他們并不想了解系統內部結構和設計，他們所關心的是系統所能提供的服務。SA方法模型的核心是數據字典（DataDictionary，DD），圍繞這個核心分3個層次的模型，分別是：數據模型、功能模型和行為模型（也稱狀態模型）。1.1.2OOA方法OOA方法主要是運用面向對象的方法，對問題域進行分析和理解。OOA模型獨立于具體實現，即不考慮與系統具體實現有關的因素。僅思考“做什么”的問題。OOA使用統一建模語言進行需求的分析，利用用例模型獲取需求，進而由分析模型描述系統的基本邏輯結構等。統一建模語言（UnifiedModelingLanguage，UML）通過邏輯視圖、進程視圖、實現視圖、部署視圖以及用例視圖來體現系統架構。其中又包含了多種不同的圖來對所開發系統的某一特定方面進行分析。1.1.3PODA方法面向問題域的分析方法（ProblemOrientedDomainAnalysis，PODA）是一項很新的技術，目前還處于研究階段，它主要關注問題域，并關注系統實現的待求行為，用一個文檔對解系統的待求行為進行描述。1.2結構化分析方法實例下面以一個嵌入式接口處理軟件為例，介紹結構化分析方法的實例。該軟件使用串口1與控制器進行交互：要求具備串口升級功能，要求具備由控制器進行啟動模式設置完成重啟、保存控制器發送的重要配置數據以及將常規指令通過串口2轉發至一個外部模塊。下面用狀態轉換圖（StateTransitionDiagram，STD）以及數據流圖（DataFlowDiagram，DFD）舉例說明結構化分析方法。根據以上需求可分析出當程序正常啟動后進入就緒狀態，等待串口語句指令：若接收到升級指令則進入升級狀態，升級過程中等待升級數據包，升級完成程序結束等待重啟；若接收到啟動指令，則進入重啟狀態；若接收到配置及常規轉發指令則完成不同狀態處理后重新進入就緒狀態。數據流圖按照自頂向下的分解方法，首先繪制一張頂層圖，將整個待開發系統表示為一個加工。系統頂層如圖1所示，頂層用來描述系統有什么輸入輸出的數據流，與哪些外部實體直接相關。完成頂層圖建模之后，在此基礎上進一步分解，得到圖2的1層圖示例，1層圖將系統細化為3個加工。繼續對1層圖中的加工1進行分解，并將所分解的加工命名為1.1，1.2……，可以看到在細化的2層圖中引入了數據存儲，看到對于配置參數、啟動設置數據等需要進行存儲操作。就這樣在不斷細化的過程中完成分析工作。1.3面向對象分析方法實例同樣根據上述需求的例子，利用面向對象的分析方法進行分析，通過分析不同參與者所關注的不同需求，得到以下的用例圖示例，如圖4所示。在獲取用例后，還需要繼續深入分析，對用例間的活動關系進行研究，同時對升級用例進行了細化分析，便得到了以下的活動圖示例。在后續分析中可使用該方法進行進一步的活動細化。
2軟件需求管理
需求是軟件項目成功的核心所在，它是后續軟件工作開展的基礎和基石。在軟件需求工程中，需求管理貫穿于整個過程。首先，最重要的是系統分析師應充分思考客戶的需求，制定計劃前要有充分的溝通，若這點沒有實現，繼續展開下一步制作，只會使得雙方的理念偏離越來越大，最終做出來的軟件也很有可能不符合用戶的商業用途。編寫需求文檔，確定需求的范圍和標準，加以約束限制，然后對需求進行細化，在具體實施過程中還需進行不斷地調整。有時計劃趕不上變化，受許多非確定因素影響，若不能及時有效處理這些改變，將會拖延工期，面臨很大的風險。系統設計師對系統自身需求、客戶需求都要有深刻認識，要充分了解各個階段的計劃，預測軟件開發的進程，軟件生產做到有目的性、階段性、可行性，才能保證項目開發的順利進行。在需求管理中，應該認識到整個需求開發過程的各個階段并不是瀑布式發展的，而是應該采用迭代方式。由這一思想去進行需求管理及控制，保證項目的順利進行是非常有必要的。需求管理涉及3個主要問題：將需求進行標識、分類以及組織，并為需求建立文檔；管理需求的變更，說明不可避免的需要變更是如何被提出、協商、確認的，并且將整個變更過程記錄在案；對需求進行跟蹤，保持需求和軟件產品之間的一致性，及相互關聯性。[參考文獻][1]雷斯澤克，馬克扎克.需求分析與系統設計[M].馬素霞，王素琴，謝萍，譯.北京：機械工業出版社，2009.[2]張友生.系統分析師教程[M].北京：清華大學出版社，2010.[3]李超，謝坤武.軟件需求分析方法研究進展[J].湖北民族學院學報（自然科學版），2013（2）：204-211.間的一致性，及相互關聯性。圖5活動圖示例2.1需求變更的原因分析需求變化問題是一直存在的，也是不可避免的，需求不可能一開始就做到百分之百完善，往往都需要在后續階段不斷地改進，對于項目團隊而言，必須要正確對待變更，按照既定流程管理變更，盡量降低由于變更帶來的成本、進度及質量的負面影響。需求變更的原因常見有：（1）最初對用戶需求缺乏認識，產生了錯誤，需要改變；（2）用戶產業有了變化，軟件開發概念也要隨之改變；（3）需求了解不夠全面，需求要增加；（4）系統的升級換代使軟件的運行環境發生改變，軟件的兼容性必須滿足，安全性也必須提高。無論是哪種情況所導致的需求變更通常都意味著新需求的增加和原有需求的修改，對于較少發生的減少需求的情況，則比較容易處理。無論對何種變更，都必須采取規范的流程去管理，以保證變更后不會帶來新的問題。2.2需求變更的管理控制為保證需求變更不對軟件質量產生負面影響，必須規范軟件開發過程，開發出標準的管理流程。近些年，軟件大量生產，若沒有一個規范統一的開發流程模式，軟件開發過程中由于需求的變更，增加了生產工期，生產成本提高，擴大了風險，很可能導致項目失敗。需求變更動機往往是為了滿足用戶需要，順應市場的動態變化，但是為了能使整個工程能夠如期完成，必須制定一個合理有效的變更機制，確定一個變化范圍，考慮到軟件制作的合理性，不能一味地聽從用戶的體驗需求，而不思考項目組能否在不違背完整性約束的條件下開發出軟件。對以往的需求變更進行收集、整理、分類，將變更方案的檔案記錄下來，在下次遇到需求變更時能夠快速應對，迅速制作出處理方案。軟件開發做到嚴格按照流程實施，對需求變更流程路線做到統一規范。首先是對各種需求變更的詳細原因進行收集，并寫成需求變更請求報告，提交評審小組進行變更評審。在需求評審過程中，對需求變更項目進行審查，將可執行的需求挑選出來，不合理的需求進行排除，還有一部分尚不確定的還需要和用戶進行下一階段的溝通處理，再次通過審核，直到通過評審才能到下一步的流程。而當變更周期完成后，還需要對變更情況進行測試及跟蹤。在中途有新的變更時，需要通重新進行這一流程處理。因此看似簡單的變更，實施過程中卻并不簡單。只有嚴格按照規定流程進行管理，才能得到質量保證與質量的控制。初步的需求變更完成后，為了加強需求變更后的準確性，技術人員必須對軟件進行測試，檢查該階段的性能，保證與其他方面的合理銜接，預測軟件的整體運行情況，做到一致和統一，而質量控制部門也必須有質量保證人員執行測試，保證得到高質量的最終產品。
3結語
第2篇：需求變更的管理流程范文
論文關鍵詞：軟件工程需求 管理軟件項目
論文摘要：需求管理是整個軟件工程的管理的基拙，也是項目成功的關健所在。本文論述了軟件項目中需求管理的重要性及存在的問題，并針對這些問題提出相關解決方法。
1背景
1. 1需求管理的概念
理解需求管理的第一步就是對什么是需求管理達成共識。Rational把需求定義為“(正在構建的)系統必須符合的條件或具備的功能”。
由于需求是正在構建的系統必須符合的事務，而且符合某些需求決定了項目的成功或失敗，因此找出需求是什么，將它們記下來，進行組織，并在發生變化時對它們進行追蹤，這些活動都是有意義的。換句話說，需求管理就是:一種獲取，組織并記錄系統需求的系統化方案，以及一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程。
1.2需求管理在軟件項目管理中的地位
簡單地說，系統開發團隊之所以管理需求，是因為他們想讓項目獲得成功。滿足項目需求即為成功打下了基礎。若無法管理需求，達到目標的幾率就會降低。以下最近收集的證據很有說服力:Standish Group從1994年到2001年的CHAOS Reports證實，導致項目失敗的最重要的原因與需求有關。2001年，Standish Group的CHAOS Reports報導了該公司的一項研究，該公司對多個項目作調查后發現，百分之七十四的項目是失敗的，即這些項目不能按時按預算完成。其中提到最多的導致項目失敗的原因就是“變更用戶需求”。
在軟件項目的開發過程中，需求變更貫穿了軟件項目的整個生命周期，在軟件項目管理中需求工程是軟件開發的第一步，是關鍵的一步，也是最難把握的一步。需求管理做得好壞直接影響到軟件的質量，甚至軟件項目的成敗。從軟件的項目立項、研發、維護，用戶的經驗在增加，對使用軟件的感受有變化，以及整個行業的新動態，都為軟件帶來不斷完善功能、優化性能、提高用戶友好性的要求。在項目管理過程中，項目經理經常面對用戶的需求變更，如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，項目研發人員的士氣將越來越低落，將直接導致項目成本增加、質量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。
2需求管理現狀
隨著信息時代的發展，計算機軟件的需求愈來愈復雜，規模愈來愈大，而且隨著企業的發展，工作過程重組，需求變更已愈來愈成為必然。軟件危機持續了30年之久，至今仍無法得以很好地解決。究其原因，軟件本身具有的特點固然有關，但長期以來，缺乏軟件開發和維護的正確方法以及忽視軟件開發過程的質量控制乃是最為關鍵的原因。其中軟件開發和維護方法的不正確性主要體現在:忽視軟件開發前期的需求分析;開發過程缺乏統一的、規范化的方法論的指導;文檔資料不齊全或不準確;忽視與用戶之間、開發組員之間的交流;忽視測試的重要性;不重視維護或由于上述原因造成維護工作的困難。
這樣，就經常出現用戶對“已完成”系統不滿意，軟件產品的質量經常出現漏洞，補丁一大堆。因此人們意識到以工程化的原則和方法組織軟件開發工作是解決軟件危機的一個主要出路。
需求分析作為軟件生命周期的第一個階段，并貫穿于整個軟件生命周期，其重要性越來越突出，到20世紀80年代中期，逐步形成了軟件工程的子領域—需求工程。進人20世紀90年代后，需求工程成為軟件界研究的重點之一。從1993年起，每兩年舉辦一次需求工程國際研討會(ISRE) ，1994年起，每兩年舉辦一次需求工程國際會議(ICRE)。一些關于需求工程的工作小組相繼成立。
3存在的問題
3. 1需求描述的細致性問題
在文章的開頭就說明了軟件需求在整個軟件系統開發中的重要性，正是由于它的重要性，一般來說，需求描述越詳細越好。項目的開發方與用戶在各種問題上的要求都是基本輪廓達到一致即可，具體的細節可以以后再填充，這是一種非常危險的思想。不管需求分析做的多么細致，以后對需求的變更都是必然的。另一方面，在需求分析階段，開發人員希望再多投人一些時間，但是用戶卻不這么認為，因為需求階段是軟件系統開發首先要進人的階段，離最終開發出可用的系統還有很長一段距離，這導致了雙方的不一致。但如果在需求階段投人很多時間，時間越長，可能的變化就越多，對設計的限制越嚴格，因此在需求描述的問題上，沒有統一的界定，需要開發人員學會適當的把握。
3.2需求描述的正確性
軟件開發是一種專業行為，一般的業主難以理解軟件開發人員的開發理念。所以在和業主交流時，他們講述的需求在實際中利用現有的技術是實現不了的，用戶以為自己很清楚自己的需求了，但實際上他們只是依據當時的工作需求提出的。隨著開發工作的不斷進展，用戶可能想到更多的功能和特色，進而對以前的需求進行改動，導致需求的不一致。
另外一種情況就是開發人員和業主交流時，由于業主本身對需求的描述不清晰，導致開發人員誤解或曲解了業主最初的要求，最后開發出來的系統不是不能滿足用戶，就是一個發生需求錯誤的系統。事實上這種錯誤在需求階段也會經常發生。更可怕的是，對于需求階段出現的錯誤，如果在軟件項目進行到后期的時候才發現，修復費用是非?？膳碌?，甚至會超出項目本身的費用。因此做好需求管理、減少需求錯誤的出現對于降低軟件項目的成本是必要的，也是至關重要的。
3. 3需求描述的完備性
系統的需求是層出不窮的，我們不可能做到把所有的需求都一一列舉出來，并且隨著時間的推進，用戶的需求也會越來越多，要窮舉需求是不可能做到的。另外，并不是用戶提出的所有需求都要滿足，在項目的最后，改變一個需求對整個項目的影響或損失很可能會超過需求本身給用戶帶來的益處。
3. 4需求的變更
需求的變化問題是每個開發人員、每個項目經理都遇到的問題，也是最頭痛的問題，一旦發生了需求變化，你不得不來修改你的設計、重寫你的代碼、修改你的測試用例、調整你的項目計劃等等，需求的變化好比是萬惡之源，為項目的正常的進展帶來不盡的麻煩，怎么辦?管理它!使需求在受控的狀態下發生變化，而不是隨意變化，需求管理就是要按照標準的流程來控制需求的變化。難題隨之而來，需求中的變化一般不是突發的革命性的變化，最常見的是項目需求的漸變(Project Scope Creep)問題，這種漸變很可能是客戶與開發方都沒有意識到的，當達到一定程度時，雙方才驀然回首，發現已經物是人非，換了一番天地。
4解決問題的策略
4. 1對需求文檔版本控制
客戶簽收的所有過程文檔都要作為基線確定下來，做好相關文檔的管理工作。需求的基線是指是否容許需求變更的分界線，需求分析人員在充分與客戶用戶進行溝通的基礎上形成第一個版本的需求文檔，這個需求文檔在通過需求評審后即可以建立第一個需求基線。此后每次需求變更并經過需求評審后，都要重新確定新的需求基線，以免將來用戶需求發生變更時，原來的需求無法查找。為有效進行需求變更控制，必然要做的工作就是保存好各個版本的需求基線，維護需求基線文檔，以備不時之需。
4. 2正確認識需求變更
在軟件開發過程中有這樣一條真理:需求的變化是永恒的，需求不可能是完備的。軟件開發的過程實際上是一個變化的過程，需求的變更不一定是壞事，也有可能是好事。
變更的需求之所以變得難以管理，不僅是因為一個變更了的需求意味著要花費或多或少的時間來實現某一個新特性，而且也因為對某個需求的變更很可能影響到其他需求。應確保賦予需求一個有彈性的結構，使它能適應變更，并且確保使用可追蹤性鏈接可以表達需求與開發生命周期的其他工件之間的依賴關系。管理變更包括建立基線，確定需要追蹤的重要依賴關系，建立相關項之間的可追蹤性，以及變更控制等活動。
需求變更貫穿了軟件項目的整個生命周期，通過建立規范的變更控制流程，改進軟件分析與設計，把變化納人計劃之中，在應對需求變更時可以更加的從容和有信心。
4. 3管理需求變更
變更控制不應該只是軟件開發過程應該考慮的事情，隨著軟件產品的開發和時間的推進，用戶會提出越來越多的新需求，甚至在交付軟件產品的最后階段用戶還會有不同的需求，因此需求變更的管理應貫穿于整個項目生命周期的全過程。
為了使變更對項目的影響降到最小，就應當采取合適有效的變更控制策略，確定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此流程。對需求的變更的處理應該分以下幾個步驟:提出變更、變更評估、實施變更、監督變更過程。
4. 4建立需求管理模型
需求建模是表達需求的一種形式，是對需求的一種描述與闡釋，它使用標準的語言，利用類似積木的概念來建模，最大的好處是大家可以直接根據需求，輕易地反復修改需求模型。并且不會產生歧義，從而可以使大多數人快速地理解。
需求建模的目的是要消除人際溝通隨意性很強的弱點，所以需要致力于將溝通標準化、自動化、準確化，而且責任到人負責的具體階段。具有可測試、可驗證性的特點。建模的過程就是通過需求的特點和要求進行分析，以建模標準為基礎進行準確、完備和有效的闡述，以確保客戶和開發方都能夠明確無誤地、通用的理解。
4. 5與用戶充分溝通
在需求管理過程中與用戶的溝通很重要，因為它直接決定著最終軟件產品是否滿足客戶的要求，即很大程度上決定著項目的成敗。在溝通時，雙方對需求的認識要一致，不能模棱兩可。討論需求及變更需求時，需求人員與客戶及用戶應該盡量采取協作的態度，良好的工作氛圍也會提高工作效率，很難想象雙方在“刁難”與“對付”的態度下是多糟糕的工作場景。確定需求基線的過程也是與客戶用戶交流的過程，而頻繁大量的需求變更在很大程度上也是交流不充分的后果。所以，有效的充分的交流尤為重要，需求人員認真聽取客戶用戶的要求，進行分析和整理，并最終取得用戶的確認。
4. 6利用需求管理工具
需求變更控制委員會可以采取商業化的需求管理工具，以此來在數據庫中存儲不同類型的需求。這些工具提供了對每項需求的屬性描述、狀態跟蹤等，并可以在需求與其它的相關工作產品間建立跟蹤能力聯系鏈。
第3篇：需求變更的管理流程范文
【關鍵詞】金融軟件 需求管理 需求變更
一、引言
隨著金融市場的蓬勃發展，創新模式的不斷增多，金融軟件的需求越來越多，開發規模也逐漸增大。如何提高軟件項目的開發質量和開發效率成為首要問題。需求管理作為軟件開發項目的關鍵，對于軟件項目的質量和進度具有重要的影響。
二、需求管理的重要性
軟件開發的初始輸入是給定需求，在此基礎上進行需求分析，然后以文檔的形式將分析的結果輸出。需求分析中的輸出即為需求管理的輸入。需求分析是軟件開發的第一步，而需求管理則是對需求分析的結果進行管理和控制，保障開發活動符合分析結果。需求管理的目的是建立和維護軟件項目和客戶需求之間的共識，要求客戶的需求合理，軟件產品能滿足客戶的需求。需求管理作為軟件開發不可或缺的組成部分，貫穿項目的整個生命周期，至關重要。
三、金融軟件項目需求管理存在的問題
金融軟件產品專業領域性較強，應用于金融機構內部支撐業務運轉的軟件產品多是由企業內部開發完成的。大多數國內金融機構，通常業務部門是產品需求提供者和最終用戶，軟件開發部門是產品的開發者和維護者，各個業務部門直接對口軟件開發小組，因此在需求管理過程中常常存在許多問題，導致項目未能按時完成，返工，甚至失敗。主要的問題如下：
表達與理解的不一致。業務部門在需求描述過程中，使用的往往是業務語言或者專業詞匯，技術人員不能準確理解這些業務的做法和要求。技術人員也未就此需求同業務人員進行確認，后期的開發就產生問題。
描述不清楚。業務部門對軟件系統只能提出一個大概的需求，或是一個設想，對于需求的細節，具體要包含的業務處理功能表述不清，表達方式不規范，往往口頭表達，沒有文檔記錄。
需求缺乏規劃。作為內部需求，目前大多數企業并未對軟件項目進行開發，維護成本的分攤，導致業務部門對需求的提出比較隨意，沒有經過深入的思考和可行性分析。其一，業務部門僅從各自角度考慮功能要求，未能對整體業務鏈梳理。其二，缺乏獨立部門對需求統一管理，面對來自各個不同業務部門的需求，開發部門對需求的合理性沒有足夠的控制權。造成業務邏輯不清晰，甚至出現矛盾。
需求變更頻繁。金融行業的特點具有發展快，創新多，為了滿足市場的需求，業務也隨之需要改變，導致需求變更頻繁。如果提出的需求不具備前瞻性和普遍性，僅局限于當前的業務模式，導致很容易產生需求變更。
四、解決的方法
基于以上幾點問題，在軟件需求管理上要采用有效的方法，以促進項目的順利進展。
（一）業務知識的預先了解和學習
在項目初期，邀請行業專家，組織開發人員進行有針對性的業務知識的培訓，統一業務術語，避免出現不熟悉的業務知識而導致的需求理解上的失誤。
（二）需求的有效溝通
軟件開發項目的首要目的就是獲取用戶的需求。需求的獲取有多種方式，如電話，郵件，單獨溝通，小組討論。根據軟件用戶，有針對性的設計和使用不同的內容及問題詢問或溝通。在溝通過程中，單純的語言交流可能不能準確表達雙方意圖，可通過建立原型系統，以可視化的方式與用戶進一步溝通，從而有效幫助用戶確認自己的需求，雙方理解達成一致。
（三）需求文檔化
每一次需求調研，都要做好筆錄，與用戶交流后，要對交流的結果進行分析，整理，形成《業務需求書》。然后，技術人員同業務人員一起對《業務需求書》進行討論分析，最終形成《需求規格說明書》。針對《需求規格說明書》，逐一與用戶進行確認，對于描述不準確的地方加以細化，對于錯誤的地方進行修改，并請用戶方面的領導簽字。簽字確認后的《需求規格說明書》，將成為最終用戶和開發機構之間的合同書，也是最終用戶驗收軟件系統的依據。
（四）需求變更的管理
需求變更由于各種原因在軟件開發項目的整個生命周期不可避免，但變更通常會對項目的進度、質量和成本產生很大的影響，因此在項目過程中控制好變更十分重要，可以從以下幾點加以控制：
建立需求基線。需求基線是需求變更的依據。需求確定并經過評審后，可以建立第一個基線。此后每次變更并經過評審后，都要重新確定新的需求基線。
制定變更控制流程，并形成文檔。在建立了需求基線后所提出的所有變更都必須遵循這個流程。
對需求變更影響進行分析與評審。要及時召集業務人員和開發人員，對項目的需求變更所帶來的影響進行分析，明確變更的工作量大小，最后經過相應級別的評審確認。
需求文檔的版本控制。所有發生變更的需求都需要清楚的記入文檔形成新的版本，包括變更描述，原因，記錄人，更新后的新版本號。并使得項目組內的每個成員都能夠得到需求的最新版本。
五、結束語
軟件需求管理作為項目管理的重要環節，直接關系到軟件項目能否高質量的如期完成。提高金融軟件項目的成功率，必須要重視需求管理工作，采用科學有效的方法，保證開發工作的順利進行和軟件產品的最終投產使用。
參考文獻：
第4篇：需求變更的管理流程范文
關鍵詞：軟件需求；開發方法；管理方法；評價
中圖分類號：TP311文獻標識碼：A 文章編號：1009-3044(2008)27-1960-02
The Research and Application on Software Requirements Management in Development of Software Project
JING Shen-yan
(Department of Information Technology Liaoning University of International Business and Economics, Dalian 116052, China)
Abstract: The software requirements is very important in the the entire life cycle of software products, and that has decisive significance for the follow-up of software development and maintenance. In practice, the requirements management can not get sufficient attention. This paper demand from software requirements and software engineering, and analyze the internal and external issues in the management of software requirement, and focus on the effective ways in the development and management of the requirements, and put forward some simple and feasible standards for the analysis and evaluation of software requirements.
Key words: software requirements; development method; management method; evaluation
1 引言
軟件需求在軟件產品的整個生命周期中占有十分重要的位置。我們應該看到，它是軟件項目的依據和出發點，無論是軟件的開發還是軟件的維護都是以軟件需求作為前提的。如果將軟件需求比做是一座建筑物的地基，一點都不夸張。因此，重視需求工作，重視軟件需求的質量，可以為后續的工作打下良好基礎，否則可能會給開發的成本、周期以及產品的質量帶來嚴重的影響，造成不良的后果。據調查顯示，在眾多失敗的軟件項目中，需求管理失誤原因約占到45%。
在項目開發工作中，很多人對需求的認識還遠遠不夠，有的是開發者本身不重視原因、有的是技術原因、有的是人員組織原因、有的是溝通原因、有的是機制原因，以上種種原因都表明做好軟件需求開發是一項系統工作，而不是簡單的技術工作，只有系統的了解和掌握需求的基本概念、方法、手段、評估標準、風險等相關知識，并在實踐中加以應用，才能真正做好需求的開發和管理工作。
2 什么是軟件需求和需求工程
2.1 軟件需求的定義
按照IEEE-STD-610標準的定義，軟件需求是用戶為解決某個問題或是為實現某個目標，要求軟件必須滿足的能力。軟件需求可能由分配給軟件的需求得到，也可能由用戶或最終用戶提出。軟件需求主要分為3個層次，如圖1所示。
1) 業務需求：指客戶對軟件的高層次目標要求。
2) 用戶需求：指用戶使用軟件必須達到的要求和完成的任務。
3) 功能和非功能需求：規定了開發人員必須實現的需求，它的實現滿足上述業務需求和用戶需求。通常以需求規格說明書的形式體現。
4) 非功能性需求包括過程需求和外部需求。過程需求包括交付需求、實現需求、遵循的標準，外部需求包括安全性、性能、機密性、互操作性等。
2.2 需求工程的定義
需求工程是系統工程或軟件工程中解決需求問題的一個嶄新領域。其目標在于使工程得到的產品能夠準確、真實的體現客戶的需求，令客戶滿意。需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發和需求管理兩個部分。
需求開發是指從信息收集、分析和評價到編寫文檔、評審等一系列產生需求的活動，分為四個階段：獲取需求、分析需求、定義需求和驗證需求。這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反復的。需求管理是一種用于查找、記錄、組織和跟蹤系統需求變更的系統化方法。它包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作。
3 需求開發過程中存在的問題
需求開發過程中存在的任何問題，最終導致的結果都是需求變更。為了順利的提供高質量的軟件產品，按照開發人員的觀點，軟件需求應該是清晰、正確、穩定的。所謂穩定是指：希望用戶一次提供所有需求，并且以后不再改變，但這往往是不現實的。用戶在開發過程中變更先期確定的需求的現象非常普遍，也就是說需求變更是不可完全避免的。從開發人員的角度來看，可以把需求變更的原因分為兩類：
3.1 內部原因
由于開發人員需求開發工作的缺陷使得需求發生了變更，主要有兩種情況：
1) 需求分析、定義、評審工作不夠充分，使得需求規格說明書中隱含著問題，到下一階段才發現。例如：為了趕工期忽視了需求的質量、需求開發的方法不當。
2) 需求開發過程中，與客用戶的溝通不充分或開發人員的經驗缺乏，沒有挖掘出用戶的潛在需求。
3.2 外部原因
外部原因是指開發人員外部的原因引起的需求變更，主要是用戶的原因。
1) 隨著用戶對需求的理解逐漸深入，可能會有新的想法，所以會要求改變原來的需求。
2) 業務變化導致軟件需求發生變化。計算機運行環境發生變化，導致需求發生變更。如計算機硬件、系統軟件等發生了變化。
3) 相關制度、法律法規發生了變化導致需求變更。
無論何種原因引起的需求變更，開發人員都要積極面對。因為需求絕對不變更是不可能的。好的需求開發方法和管理的方法會對降低需求變更對系統開發產生的影響。
4 需求開發與管理的一些方法
需求開發是一項復雜的工作，使用的方法也很多，不同的開發方式有不同的方法，這里簡單介紹一些相關的方法。
4.1 需求開發方法
需求開發有很多最佳實踐以及好的方式方法，下面根據實踐經驗介紹幾種有效的方法。
1) RUP與UML的結合
RUP（Rational Unified Process）：Rational公司推出的一種軟件考法過程框架，UML（Unified Modeling Language）：統一建模語言。業界已經證實，RUP與UML的結合是一種最佳實踐。因為RUP過程框架，能夠有效的指導我們，有條不紊的進行需求開發工作。同時UML又能直觀、形象的表達出我們想要表達的意思。圖形化的需求建模會讓開發人員和用戶對需求的理解保持一致。這對于需求質量的提高會有很大的幫助。
2) 繪制關聯圖
繪制系統關聯圖是用于定義系統與系統外部實體間的界限和接口的簡單模型。
3) 可行性分析
在允許的成本、性能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。
4) 需求優先級
確定功能實現的優先級。根據優先級來確定每個產品版本要實現的需求。
5) 系統原型法
原型法是一個非常有用的獲取需求的方法，不論系統規模的大小，都非常適用。有時用戶用語言難以表達出他們的意思，所以通過真實的應用界面會更好的引導用戶提出他們的潛在需求。
6) 圖形分析模型
繪制圖形分析模型是編制軟件需求規格說明重要手段。它們能幫助分析人員理清數據、業務模式、工作流程以及他們之間的關系，找出遺漏、冗余和不一致的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。
7) 數據字典
數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員和用戶使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項，確保客戶與開發小組是使用一致的定義和術語。
4.2 需求管理方法
需求管理主要是對需求變更、需求狀態的管理。主要包括以下幾個方面：
1) 確定需求變更控制過程。
制定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程。
2) 進行需求變更影響分析。
評估每項需求變更，以確定它對項目計劃安排和其它需求的影響，明確與變更相關的任務并評估完成這些任務需要的工作量。通過這些分析將有助于需求變更控制部門做出更好的決策。
3) 建立需求基準版本和需求控制版本文檔。
確定需求基準，這是項目各方對需求達成一致認識時刻的一個快照，之后的需求變更遵循變更控制過程即可。每個版本的需求規格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。
4) 維護需求變更的歷史記錄。
將需求變更情況寫成文檔，記錄變更日期、原因、負責人、版本號等內容，及時通知到項目開發所涉及的人員。為了盡量減少困惑、沖突、誤傳，應指定專人來負責更新需求。
5) 跟蹤每項需求的狀態。
可以把每一項需求的狀態屬性（如已推薦的，已通過的，已實施的，或已驗證的）保存在數據庫中，這樣可以在任何時候得到每個狀態類的需求數量。
6) 衡量需求穩定性。可以定期把需求數量和需求變更（添加、修改、刪除）數量進行比較。過多的需求變更“是一個報警信號”，意味著問題并未真正弄清楚。
5 需求分析評價標準
如何判斷需求規格說明的好壞，不同的軟件工程規范都有自己的一套標準，這里向大家介紹一個比較常見的NASA SEL推薦方法，它是由美國國家航空和航天局軟件工程實驗室開發的五大常用國際軟件工程規范之一，它對軟件需求過程的評價標準是：清晰、完整、一致、可測試。
1) 清晰：目前大多數的需求分析采用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性，所以開發人員需要對需求分析中采用的語言做某些限制。例如盡量采用主語＋動作的簡單表達方式。需求分析中的描述一定要簡單，千萬不要采用疑問句、修飾這些復雜的表達方式。 除了語言的二義性之外，注意不要使用行話，就是計算機術語。需求分析最重要的是和用戶溝通，可是用戶多半不是計算機的專業人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難。
2) 完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返工，在軟件開發過程中，最糟糕的事情莫過于在軟件開發接近完成時發現遺漏了一項需求。但實際情況是，需求的遺漏是常發生的事情，這不僅僅是開發人員的問題，更多發生在用戶那里。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各個方面，貫穿整個過程，從最初的需求計劃制定到最后的需求評審。
3) 一致：一致性是指用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。在需求過程中，開發人員需要把一致性關系進行細化，比如用戶需求不能超出預前指定的范圍。嚴格的遵守不同層次間的一致性關系，就可以保證最后開發出來的軟件系統不會偏離最初的實現目標。
4) 可測試：一個項目的測試從什么時候開始呢？有人說是從編碼完成后開始，有人說是編碼的時候同時進行單元測試，編碼完成后進行系統測試，這些結論都不完全正確。實際上，測試是從需求分析過程就開始了，因為需求是測試計劃的輸入和參照。這就要求需求分析是可測試的，只有系統的所有需求都是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統是成功的。
6 結束語
需求管理是軟件開發的整個生命周期中最基礎、最關鍵的部分，隨著軟件開發研究與實踐水平的推進，需求開發也越來越受到企業與開發管理人員的重視。本文提出的需求技術與需求管理方法意在讓更多的人能夠充分意識到需求管理的決定性作用，能夠在長期的實踐中對需求技術與需求管理方法進行不懈的探索與研究，推進軟件開發水平與開發能力的飛躍和提高。
參考文獻：
[1] 李明.需求管理中數據和信息的關系及應用[J].UML軟件工程組織技術期刊,2008,(4).
[2] 毛明志,沈賢義,黃春賢.基于特性的軟件需求管理工具的研究與應用[J].計算機技術與發展,2007(5).
第5篇：需求變更的管理流程范文
中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2012)01-0189-03
軟件工程需求分析是指定義和描述軟件系統的范圍、目標、定義及功能時所要做的所有的工作。簡言之，需求分析就是分析軟件用戶的需求是什么，即全面地理解用戶的各項要求，并準確地表達所接受的用戶需求。需求分析是軟件工程中最重要也是最困難的一項工作。
1準確、有效需求分析的必要性
由于軟件系統復雜性日益提高，軟件規模日益龐大，上世紀六十年代末后爆發了深刻的軟件危機，表現為：進度拖延，費用超支，軟件不符合用戶要求、可靠性差且難以維護。其最主要的原因就是缺乏準確、有效的需求分析。時至今日，軟件危機問題一直沒有得到很好解決。
有效需求分析的重要性和必要性體現在：第一，軟件需求文檔是軟件工程項目驗收的依據。不準確、不完備的需求必然會導致生產出來的軟件無法滿足客戶要求，并造成項目進度推遲、項目費用超支。第二，在軟件生命周期中，一個錯誤發現得越晚，修復錯誤的費用越高，甚至是指數式增長。國外
另外，軟件工程項目開發過程中，很多軟件錯誤在需求過程就已產生并潛伏，而這些錯誤在需求過程中是可以被檢查出來的[1]。由此可見，準確、有效的需求分析，是軟件項目得以正確、及時完成的前提，是人們擺脫軟件危機的最有效、最重要的方法。
2有效需求分析的主要障礙
在需求分析的實踐中，由于以下原因，使得需求分析往往無法有效地進行：
①系統開發需要用戶、領域專家、開發小組共同參與并密切溝通；
②用戶單位組織機構與業務關系及業務流程復雜，客戶很難清晰完備地表述需求；
③用戶與開發人員很難進行有效交流；
④用戶的需求是動態變化的；
⑤缺乏有效的、系統的開發、維護大型軟件項目的技術手段和管理方法；
⑥軟件開發的技術人員和管理人員缺乏軟件工程化的素質和要求，對工程化的開銷認識不足。
正是基于這樣的背景，本文在認真分析研究導致人們無法進行有效需求分析的原因的基礎上，提出以下進行有效需求分析的簡單易行而又行之有效的方法。
3進行有效需求分析的方法
1）為項目前景制定共同目標，并為共同目標承諾
為了達到項目的成功，需要在客戶和開發公司之間達成共同目標，在共同完成項目的各個單位、小組、個人間建立一種協調合作解決問題的氛圍和機制。
在項目確定后，應盡快召開一個由客戶和開發公司各方人員（包括客戶和開發公司有決策權的管理人員）參加的項目合作工作會。項目合作工作會要討論和解釋項目目標、各方共同利益以及實現共同利益的障礙，并在此基礎上，制定項目團隊的共同目標，確定解決問題與爭端的指導原則及具體程序。
2）建立聯合需求領導小組，并維護各小組間的溝通
在項目合作工作會就項目前景達成共同目標，并為共同目標承諾后，需要一種機制來維護項目參加人員之間的有效溝通與協作，促進問題的及時解決，并在需求方面作出決策。聯合需求領導小組就是一種有效機制。
由于聯合領導小組代表項目組跟蹤需求過程，負責完成需求定義（包括需求的變更），并在需求方面作出決策，因此，聯合需求領導小組成員必須包含客戶單位和開發公司。同時，為利于小組決策，小組成員應盡量精煉，成員必須精挑細選，成員必須具有豐富的客戶領域知識或需求工程知識或兩者兼備、出色的溝通與協作能力和良好的合作精神。
聯合需求領導小組要定期聚會，維護項目各方之間的溝通與協作，指導與協調各小組的工作，及時解決需求工作中出現的問題，控制需求變更，最終定義真實的客戶需求。
過多的需求變更是導致項目超支和延遲交付的主要原因。因此，聯合需求領導小組工作的重點和難點之一是跟蹤和控制需求變更。為此，需要使用自動化需求工具建立需求跟蹤矩陣，實現對需求變更的跟蹤和控制。
3）使用熟悉的需求過程
使用需求過程是指在項目開發過程中定義完成工作的步驟、過程并形成文檔，當需要在另一個機構或項目上完成相同或類似工作時，就可以復用相同的過程。
使用需求過程方法，需要定義需求過程流程圖并形成文檔。需求過程文檔用于描述完成項目開發工作所涉及的步驟，活動流程，每個活動的工作內容、輸入條件、責任人、活動成果等內容。過程流程圖要包括一個宏觀流程圖和多個微觀流程圖。宏觀流程圖從宏觀的角度描述整個開發工作的主要目標、主要工作任務、主要組成步驟及流程等。一個微觀流程圖是對宏觀流程圖中的一個步驟的細化，用于描述該工作步驟的任務、輸入信息、責任人、產生的活動成果、子活動流程等信息。如果微觀流程圖中存在比較復雜的子活動，還可以用另一個微觀流程圖來說明該子活動。
當需要在另一個機構或項目上完成相同或類似工作時，通過復用需求過程可以大大加快開發進度并節省資金。這是因為復用過程有以下優點：
①使得每個項目參加人員都清楚整個項目的目標、任務以及自己的工作任務、流程、需要完成的成果等信息。簡單的說，可以使每個參加人員更好地理解要干什么以及怎樣干。
②通過不斷改進過程，可以獲得完成相同工作或類似工作的最佳方法。
使用需求過程方法需要對開發人員進行培訓，使之熟悉過程，更好地理解要干什么以及怎樣干。對新團隊或新隊員進行培訓時，使用以前的相同或相似項目案例進行培訓（使用項目的需求過程流程圖及各步驟成果文檔等），可以收到很好的效果。如果軟件開發公司能夠經常對員工進行培訓并維持穩定的開發團隊，需求過程方法將會取得非常明顯的效果。
4）使用熟悉而有效的方法和技術
盡管目前已經存在很多支持需求工程的技術、方法和自動化工具，但是只有其中幾個技術和手段特別有用。要根據開發公司及項目實際情況慎重選擇適當的技術和手段。
美國Software Productivity Research（SPR）公司從1984年到2000年對650多個公司和機構的約9000個項目所使用的技術、方法和手段進行了研究，并得出如表2所示的評估結果：[2]
表2需求工程方法有效性與開銷評估表
JAD（即聯合應用系統設計）方法要求客戶代表和開發公司與專家共同工作，開發雙方共同認可的聯合需求規范。JAD方法有助于定義真實的客戶需求，有效地減少需求變更。JAD方法已在信息系統開發方面得到廣泛應用。
建立快速原型的方法也是非常有效的需求方法。由于客戶也常常不知道自己想要什么東西，也不知道所要的東西是否能夠實現，只有當客戶與軟件系統交互時，很多更改要求和更詳細的需求才能提出、很多軟件需求中的缺陷才能發現，因此，在項目開發早期建立快速原型可以有效減少需求變更。同時，可以在原型代碼的基礎上進行正式編碼，可以減少正式編碼的時間。建立原型方法與JAD方法配合使用，可以取得更好的效果。如果開發團隊曾經開發過類似系統，通過復用以前系統的部件和代碼，或者運用開發人員的熟練技能，可以以很低的成本快速構建出原型。
對需求工程技術、方法和工具的選擇，應根據開發團隊和項目的情況進行慎重選擇。最重要的是要選擇開發人員熟悉的技術、方法和工具。開發機構應該努力使用同一組在自己環境證明有效的方法和工具。
5）認真執行需求檢查
業界研究發現：軟件系統中的絕大部分缺陷（80%以上）是在需求階段被引入的；需求缺陷的類型主要是“不正確的事實”、“遺漏”、“不一致”，占比達到90%以上。[3]
而業界研究表明，需求錯誤是可以被檢查出來的：通過需求檢查，通常可以發現65%以上的需求錯誤[1]。因此，在項目開發的需求階段必須認真執行需求檢查，以有效地減少軟件系統的錯誤。
要執行需求檢查，就必須建立完備的需求文檔?？梢杂米詣踊ぞ呓⒁粋€需求跟蹤數據庫，并標明每條需求及其理由，作為需求分析的成果和需求檢查的依據。
6）培訓員工并維持穩定的隊伍
軟件系統開發是一種高度智力活動，完全依賴于開發人員的智力活動，項目的成敗完全取決于開發人員的熟練技能和對技能的熟練運用。開發團隊是軟件開發公司最為寶貴的財富。因此，必須努力維護開發隊伍的文檔，并不斷對員工進行培訓。這可以收到如下回報：
①員工有較強的歸屬感和較高的忠誠度，工作更盡責；
②員工對項目開發流程及自己的工作任務、流程非常熟悉，這既有利于工作效率的提高，而且有助于員工發現并提出工作方法的改進；
③員工對開發工作中所使用的技術、方法和工具非常熟悉并能熟練運用于系統開發。這有助于定義真實完備的客戶需求，減少設計和編碼的錯誤，大大加快開發進度，得到更好的系統產品；
④開發人員間能更有效地溝通和密切合作。
4總結
軟件危機的爆發，使得人們認識到解決軟件危機的真正有效的辦法是定義完備真實的客戶需求。因此，業界產生了很多用于需求分析的技術、方法和工具。盡管如此，要得到真實完備的客戶需求，仍然是一件很困難的事情。業界實踐表明，要進行有效的需求分析，不僅僅依賴于所采用的技術、方法和手段，更取決于對需求實踐過程的管理。本文提出的進行有效需求分析實踐的方法既簡單易行，又具有很好的效果，具有很強的指導作用。
參考文獻：
[1]周之英.現代軟件工程（第2冊）[M].北京：科學出版社，2002.
第6篇：需求變更的管理流程范文
本文通過分析了解軟件產業現狀，對軟件的最佳實踐進行闡述，提出軟件項目中需求管理對項目成敗有著至關重要的作用。
本文從軟件危機的產生、軟件產品最佳實踐開發辦法、需求管理對項目的影響等幾方面闡述了需求管理對項目的重要性。
關鍵詞：軟件；需求管理；基線；項目
一、前言
以計算機軟件、集成電路技術為主導的信息技術革命正以迅猛之勢更新著我們生存的社會，信息技術不再僅作為一項高科技技術而存在，而是廣泛滲透于各個行業領域的生產、經營、管理等過程，成為它們發展的輔助手段和管理工具。
信息的采集、分析、處理、整合、是信息產業的核心內容，它們都離不開軟件。軟件是計算機的核心，信息社會需要眾多功能靈活的軟件系統。
與此蓬勃發展的軟件產業前景相反的是，自20世紀60年代以后，全球軟件行業落后的軟件生產方式無法滿足目前信息化時代飛速增長的軟件需要，傳統的軟件開發方式與軟件產品設計過程已不能滿足當今對軟件產品多樣化的業務需要，從而導致軟件開發與生命周期維護過程中出現一系列嚴重的問題。
作者認為在此軟件產業形式之下，需要突破傳統的軟件開發手段，找尋新的軟件項目管理方法。作者經過分析國內外最新軟件著作，參與高級軟件研發討論，結合國內軟件產業所涉及的行業范圍，及作者本身的軟件開發項目經驗，提出“軟件項目中的需求管理”是軟件項目成敗的關鍵，對項目成敗具有決定性的作用。擬此文以闡述軟件項目中需求管理的重要性。
二、軟件危機
1.軟件危機癥狀
（1）軟件項目中范圍、進度、成本估算準確率低。
軟件項目開發的實際成本遠遠高出估算成本高出；同時實際進度比預期進度延后幾個月甚至幾年。這種現象降低了軟件組織的信譽。
（2）客戶對最終交付產品滿意度低。
軟件開發人員在對用戶需求未有清晰了解的基礎上，對所面對的問題領域還沒有確切分析與設計的情況下，即著手進行開發、編寫程序。造成實際產品與客戶期望功能產生偏離，無法解決客戶的真實需求而造成客戶滿意度降低。
（3）軟件產品質量差強人意。
軟件質量保證技術沒有貫徹地采用到軟件開發的過程中，這必會導致軟件產品發生質量問題。缺乏審核、復審和全面測試的軟件難免質量低下，出錯率高。
（4）軟件不可維護、生命周期短。
軟件程序中錯誤難以改正，出現新的需求或者需求變更時原有架構不易于維護，不能根據用戶的新需求在原有架構中進行改變。造成軟件的使用年限縮短，軟件成本加深。
（5）軟件缺乏配套文檔資料。
軟件產品應具備整套文檔資料。然而在進度與成本的制約下，文檔的編寫與更新工作也使得軟件組織疲憊不堪，每個人對文檔內容的深度與闡述程度不盡相同。加之企業缺乏與之配合的文檔制度、文檔模板，更為文檔編寫帶來困難之處。而缺乏相關文檔對軟件的二次開發與維護增加許多困難和問題。
（6）系統集成項目中軟件成本不斷上升。
集成電路技術發展日趨成熟、生產自動化水平日益提高，使得硬件采購成本持續下降，但由于人力成本的增加，軟件成本隨著通貨膨脹、軟件規模、軟件數量的不斷擴大而逐年上升。
2.軟件危機深層次原因
從軟件危機誕生的環境與信息爆炸時代人們對軟件產品的渴求可以對軟件危機產生的原因窺探一二。
需求管理不善是軟件危機的基本原因，這體現在以下幾個方面：在軟件開發最終交付之前，客戶自己也不清楚自身的真實需求；加以需求人員技術有限，采集到存在遺漏、具有歧義性、誤解的需求；而在軟件開發過程中，需求也在不斷地變更；需求管理人員沒有更好的把握住需求的變化，造成后期維護成本不斷增加，以致項目失敗。
軟件管理由于是新興的門類學科，缺乏實踐性較高的方法學和理論工具。軟件開發不同于傳統制造行業，軟件開發過程是邏輯思維過程，軟件產品的質量依賴于人員。綜合性人才的缺乏也造成了現有軟件開發模式無法適應現今的軟件需求而造成了軟件危機。
軟件從業人員自身技能也對軟件危機有所影響：
其一，軟件產品同樣是產品，由人員設計制造，因此軟件產品質量最終取決于整體軟件人員的經驗積累；
其二，大型軟件產品相對于小型軟件產品失敗風險度更高，這是由于參與的人數翻倍，軟件開發人員之間溝通互動，在開發過程中難免發生偏差，在缺乏管理的情況下，導致后續設計、實現工作產生偏離，要解決這些問題不僅需要好的制度同樣需要高素質人才；
其三，軟、硬件技術發展迅速，信息爆炸、知識更新率加快，外部環境使得軟件從業人員處于不斷地學習過程之中，這對從業人員無論是智力或是體力上都是不小的挑戰。
軟件產業知識密集、人力密集的特點造成了軟件危機。
3.軟件發展趨勢
軟件開發規模持續變大，隨著互聯網時代的到來，軟件從桌面走向網絡，從小范圍使用走向企業管理信息化，軟件開發的規模越來越大。軟件項目的開發工作不再是個人所能承擔，不再是單一角色所能承擔，而是需要組織一定的人力、不同的工作角色共同完成。然而多數項目管理人才不熟悉軟件開發方法，而軟件開發人員又缺乏管理技能。項目中信息交流延遲、理解偏差、造成對項目最終目標的誤解使得軟件項目偏離軌道。軟件開發項目開發人員不能有效地、獨立自主地處理大型軟件開發的全部關系和各個分支，因此容易產生疏漏和錯誤。
軟件產品復雜度持續加深，規模的擴大必將帶來結構上更為繁多的分支情況。傳統的結構式分析方法已不再適用如今信息化的軟件產品需求。軟件開發工作也無法在一次迭代中完成，而是根據用戶需求的優先級程序，客戶共同協商，定制產品階段性的交付周期。產品使用人數、實施規模都在隨著信息化的發展而不斷增加。這也使得軟件使用場景不斷增多，軟件功能復雜度加深，對需求管理的迫切性也日益提高。
三、最佳軟件開發實踐
在此軟件危機之下，新的軟件開發方法不斷地被挖掘與探索，以下六點被認為是解決軟件危機，為客戶研發良好系統的最佳軟件實踐。
迭代式開發：在軟件開發的早期階段就獲取完整而精準的用戶的真實需求是不可能的。這是因為隨著項目的進展，客戶對最終產品的需求在整個軟件開發階段會持續改變。現代軟件開發所倡導的迭代式開發允許在每個迭代過程中需求可以發生變化，通過不斷細化來加深對問題的理解。迭代式開發既可以降低后期交付的風險，也可以支持在每個迭代過程都產生可以交付的版本，提供給客戶試用，即緩解了客戶的等待性又可以產生積極的反饋信息激勵開發人員。
對需求進行管理：對客戶業務建模的過程隨著整個開發周期都是持續進行的，隨著項目進入一個個迭代，新需求與變更需求都使得業務模型在不斷的依據最新需求進行修改，指導著開發等后續工作。
采用組件式架構開發：組件是軟件技術中重大的技術突破。組件使復用成為可能，系統的靈活性大大提高。基于高內聚、低耦合的模塊化組件體系結構降低了管理復雜性，提高了代碼重用率。
建立視覺模型：UML已逐漸成為軟件工程師所廣泛采納的建模工具，軟件從業者一致認為可視化的建模對需求管理有著重要的作用?？蛻艉烷_發方都可以從中受益，盡早地獲取有關軟件結構和行為的信息，可以盡早地發現隱藏的風險。
對軟件質量進行驗證：軟件質量測評不再是交付后或單獨進行的活動，而是伴隨著生命周期，從需求基線定義的那一刻起而持續進行的。
控制變更：對需求變更采用控制、跟蹤、監控、修改的方式，在變更產生之初，判斷其原因并確認涉及范圍，進而采用合適的變更處理方法。積極地控制項目中所產生的變更，而不是被變更所控制。
四、需求管理的對軟件項目的影響
需求管理是隨著軟件產業的發展而逐漸成熟的，在軟件業發展的早期，軟件規模不大，軟件產品開發所關注的是代碼編寫，產品需求分析較少受到重視。在開發技術不再是軟件產品的瓶頸時，客戶對軟件的需求日益復雜，軟件產業出現生命周期這一概念，需求分析自然而然成為其初始階段。
隨著軟件系統規模與信息化的發展，需求分析作為整個項目的基礎，其定義的業務基準在整個軟件項目中越來越重要，直接關系到項目的成功與否。
自1995年起的一項美國調查顯示，通過對全美境內8000個軟件項目的跟蹤分析調查，與需求相關原因引起項目失敗的比率高達45%，而這其中由于需求不明確，缺乏用戶認可的需求基線而導致項目失敗的原因占了25%。需求管理是項目范圍管理的基礎，只有明確的定義了用戶需要哪些產品范圍，才可以作為后期開發的前提。如果一開始就沒有一個清晰的業務范圍與業務模型，將會使后期的開發偏離軌道。
需求管理活動分為兩部分，一部分屬于需求開發，一部分屬于需求管理。
（1）需求開發是通過對客戶及其所處行業進行調查與分析，捕獲用戶需求，并定義系統需求的過程。
（2）需求管理是在客戶與承建方之間建立對產品需求的一致認可，對需求管理方法與手段達成一致，并共同控制需求變更的過程。
需求開發又可再分為兩個階段：“業務分析”與“系統分析”。
需求管理又可再分為：需求確認、需求跟蹤、需求變更控制。
需求確認是指項目甲方、乙方共同對需求文檔進行審核，甲乙方對需求基線達成一致后作出紙質協議，使得需求文檔具有審核驗收的作用效力。需求跟蹤是指通過比較需求基線與項目最終產品之間的匹配關系，持續維護“需求跟蹤矩陣”，確保產品依據客戶所提出的需求進行開發。需求變更控制是指根據“變更提出-范圍分析-方案選擇-審核確認”的流程處理需求變更，確保項目中需求變更處于可控制的流程之下，而不至于失控導致項目失敗。
軟件項目同樣遵循項目管理的一般原則，具有項目范圍管理、進度管理、成本管理、質量管理、人力管理、溝通管理、風險管理、采購管理等過程。
需求管理大致上可以被認為是范圍管理，需求管理所定義的軟件功能基線決定了項目產品范圍，明確指出了待開發的系統具有哪些功能，不具有哪些功能。需求管理定義的基線是甲乙雙方共同遵守并為后續的工作提供基石。
只有以清晰的需求基線為基礎，才可以在此之上制定進度管理計劃，進行逐層任務分解。實現對進度的控制，并且可以在時間結點處依據需求基線進行小范圍測試工作。在此之上，軟件組織中的成本管理小組可以依據進度計劃制定成本-績效管理計劃，根據員工的工作完成情況統計人員的績效信息。這一切都是基于需求管理所定義的明確的需求基準。
實現了范圍、進度、成本的動態管理，質量管理、人力管理、溝通管理才具有實際意義。軟件質量保證小組可以依據需求基準對已完成的系統部件進行早期的跟蹤測試；人力部門也可依據成本、進度計劃隨時進行人力資源調整；清晰的需求基準減少了團隊成員之間的矛盾，使得溝通變得簡單有效。
需求管理所倡導的在早期準確的挖掘客戶的需求可以使得項目人員盡早識別與發現項目中隱藏的風險，在項目早期減輕或者避免潛在風險。同時清晰的需求基線可以為組件產品采購帶來判斷標準。
綜上所述，需求管理是有效實現項目管理各部分的基礎，只有為項目打好一個堅實的基礎，才可以順利展開后續工作，實現客戶與開發方的雙贏。
五、需求管理的方法與技術
業務背景分析：業務背景分析可以通過了解客戶的最初需要，提出概念解決方案來實現。它是為找出客戶的真實需求而進行的分析、推理。在業務背景分析期間，將對“業務背景”和“項目干系人”等問題達成甲乙雙方的一致。
初步需求建模：需求來自客戶各個層面，比如來自客戶決策層、管理層、執行層，第三方等。掌握如何準確判斷需求的判斷與來源，及如何接近這些來源并從中獲取原始需求信息，在此之上，整合提取的原始需求，建立初始需求模型。
需求模型完善：進一步根據客戶需求，整理待構建信息系統的明確的功能規格說明。在需求階段對以下內容進行明確的定義與衡量標準：需求基線，文檔種類，內容形式，需求描述程度，需求的優先級與可預計工作量，可能存在的技術及管理風險、系統的最初規模。
項目規模：為使項目工作成功地運作，需求管理者應對所有涉眾的需求確定優先級，并對需求的范圍進行管理，而不是早早將精力投入到大量的開發工作中。為確保盡早發現并降低項目中的風險，軟件組織首選遞增與迭代的方式開發系統。更加謹慎的對待需求，務求每次增加的內容都能減輕項目中的風險，要達到良好的管理效果，需要需求管理人員和客戶共同協商每次迭代的范圍。
需求變更：不斷變更的需求之所以難以管理，不僅是因為一個新特性的需求變更需要花費額外的時間來實現，也是因為某項需求變更極有可能影響到其他已經實現的需求。基于此原因，需求管理者應建立一個有彈性的業務模型結構，使它具有靈活性，能適應變更，并且確保需求源頭的可追溯性。管理變更包括建立需求基線，確定需求源關系，建立相關需求項之間的可追溯性，以及不斷地開展變更控制等活動。
六、需求管理的發展與展望
綜上所述，需求管理作為軟件工程中的一部分，得到各軟件組織越來越多的重視與認可。其重要性與必要性得到了廣大計算機從業人員的認同。越來越多的軟件組織建立了屬于自己的需求管理小組，負責從項目初期進行業務獲取與建模，并對需求進行全生命周期的管理。越來越多的軟件資深開發人員亦從代碼編寫工作轉型到需求管理與實踐方式方法的探索上，深厚的技術基礎使得他們更容易掌握判斷需求的能力。同樣地，越來越多的工程技術人員、領域專家也在不斷的加強自身軟件方面的知識，實際業務背景與需求管理方法的結合必將提高需求建模的準確率。在這種雙向結合的前景下，相信在不久的將來，軟件需求工程理論與實踐的相結合將產生出更貼近實際情況運用的技術與方法，軟件質量的提高亦指日可待。
參考文獻：
[1]金芝，劉，金英著. 軟件需求工程：原理和方法[M]. 北京：科學出版社，2008.
[2]康雁 著. 軟件需求工程[M]. 北京：科學出版社，2012.
[3]（美）普雷斯曼 著，鄭人杰 等譯. 軟件工程：實踐者研究方法[M]. 北京：機械工業出版社，2011.
第7篇：需求變更的管理流程范文
[關鍵詞]軟件項目；需求管理；措施
doi：10.3969/j.issn.1673-0194.2015.02.064
[中圖分類號]TP311.5 [文獻標識碼]A [文章編號]1673-0194（2015）02-0084-01
1 需求管理概念及其特點
1.1 需求管理
需求是指通過和客戶協商，建立并及時更新的關于軟件工作的協議，屬于系統需求的重要組成部分，主要體現于系統的軟件部分。需求分析在開發技術行為具有關鍵性作用，需求管理就是為了有效管理需求研究結果，保證軟件項目開發與它同步發展。需求管理的目的是在客戶和依據客戶需求的軟件項目中間建立共識。這種情況表明用戶需求必須是合理的，項目的發展目標要與用戶需求一致。需求管理活動就是積極保證這種共識的實現。
1.2 需求管理特點
1.2.1 需求描述方面
在制訂正式的需求文檔時耗費大量的人力物力，但真正擁有了需求文檔后又會產生新問題。需求評審會上只是走過場，這是由于廣大用戶誰也不會去聽那沒完沒了的需求文檔。不同層次的客戶感興趣的問題不同，每一個客戶都是需求專家是不可能的。
1.2.2 開發工期方面
為了保證需求的正確性和完整性，項目經理都會要求眾人在需求階段消耗大量的時間，但客戶和公司的主要領導關心的卻是實際應用的軟件。在此情況下，項目組成員一方面，要應對公司領導的壓力；另一方面，還要考慮項目經理的要求，因此，常常處于進退兩難境地，都希望盡快結束這一階段。
1.2.3 需求細致程度方面
對需求的精細度到底要求到什么程度才能結束，對于此沒有統一的認識。但是需求周期越長，存在的變化因素就會越多，設計要求也會越來越嚴格，對需求的共性提取要求也會提高，因此，只要全體工作人員認為描述達到了一定程度，就可以著手進行設計了。
1.2.4 需求的變化方面
如果軟件開發過程存在一條真理，那必然是需求存在無休無止的變化，需求不可能是完整的。因為軟件系統存在一定的復雜性，要想提前說出所有的需求是不可能的。系統原來的操作環境不可能一成不變，用戶的理解不可能一成不變，系統的角色不會一成不變。這些因素都會引起需求改變。所以，需求是容易發生改變。
2 需求管理策略
2.1 建立需求管理模型
根據人際溝通的隨意性做出軟件需求建模，只有溝通準確和預案標準化，才能解決這個缺點，要驗證和測試需求的變更可行性首先要掌握需求管理模型，是表達軟件需要的一種形式。建模的基本原理就像搭積木，使它能用較標準的語言詮釋和表達軟件的目的。能依據個人的需要進行反復的修改，這就是軟件需求模型最大的優點，模型怎樣經過修改都不會有問題。就能使使用者更容易掌握。在了解軟件的需求特點之后進行相關討論，之后再進行準確有效的闡述，讓使用者和開發者都能準確理解，就是建模的基本過程。
2.2 對需求的變化要有正確認識
需求管理的變化包括變化的控制、基線的建立等許多內容。軟件的開發過程都是根據軟件的需求變化而改變的。需要建立起較規范的需求變化流程。在進行初期軟件設計和分析的過程當中，就要把那些不確定的因素歸納到設計的程序當中來，也能使軟件開發中需求變化把握更大成功率更高。需求變化在軟件開發過程當中不好管理是因為項目的投資成本及項目開發所需要的時間會受到需求變化的直接影響。因此，要想讓軟件開發能跟得上需求的變化速度，就更需要建立起一個彈性的需求結構。
2.3 對需求文檔版本進行有效把握
先要掌握客戶需要的需求文檔的基線，對文檔做好管理。對需求變更得到認可的基本分界線就是基線，在和客戶進行溝通之后由需求分析人員建立其需求文檔，在經過評審人員對文檔進行評價，達到標準后就能建立最后的需求基線。如果再次出現需求變化，只需要經過需求評審的通過，就能建立新的軟件需求基線。這就使客戶在想要查找原來的需求時更加簡便。想對軟件需求變更進行有效控制，首先要做到保存好各個版本的需求基線，保存好這些資料才能使以后的查找更方便。
2.4 和客戶進行良好溝通
盡量和客戶做好溝通，充分了解客戶需要的產品，在進行軟件開發的過程中，成功的幾率是取決于怎樣才能滿足客戶的需要。能夠達到與客戶之間的認同一致，是與客戶交流中的重要環節。應以一種協作的態度來和客戶討論對軟件的需求以及需求的變更，交流的過程中了解客戶對軟件的需求信息。
2.5 需求管理變化。
對需求周期的管理是需求工作的主要內容，從設計開始的提出需求，再到軟件設計成功被客戶接受的程度一直在不斷變化。不論怎樣的變更需求都需要經過分析、選擇、及決策的過程。軟件的開發有個比較復雜的生命周期，要先實現就需要經過客戶要求、軟件需要、開發、單元測試等，因客戶的要求一直變化，所以要先采取策略實施變更控制，把需求軟件變化對項目產生的影響降到最低。
3 結 語
軟件的開發、設計及維護當中最關鍵的是軟件的需求管理，只有做到對需求管理工作的完整、充分、認真，才能順利完成軟件的設計，做出正確的軟件開發計劃，使新軟件開發進展更順利。
第8篇：需求變更的管理流程范文
一、企業項目管理的具體實踐
項目管理在我國的發展很晚，但是其發展的速度非?？欤罱鼛啄暌詠恚髽I的項目管理在整個市場營銷中地位逐漸變高。在我國有很多企業對引進外國的先進項目管理的研究理論非常重視，對外國的企業在實施項目的管理模式時候得出的經驗和教訓進行總結。根據自己企業發展的實際情況，將整個市場營銷的角度作為基礎，制定出具有自己企業特點項目管理的方案。將與企業相符的可持續化的發展項目管理形式建立好，能夠提高市場營銷活動中的工作效率。同時我們要將整個項目管理過程中的控制工具和計劃工作利用好，將整個營銷活動戰略性的目標作為項目，采取專業項目的管理方法對其進行管理，給自身企業帶來經濟利潤。為此，主要從以下方面對項目管理在市場營銷活動中具體的應用進行闡述：
（一）制定好計劃的方案
市場營銷活動中正確的戰略是幫助企業在市場競爭過程中獲取成功關鍵的地方。企業需要用正確營銷的戰略作為整個企業的指導，對公司現有的資源進行組織和合理的分配，對市場與消費者的需求進行很好的把握，將市場上潛在的消費者挖掘出來，生產出適合消費者和市場上所需的產品，給整個企業帶來經濟和利潤。同時為了能夠與現在經濟市場的競爭相適應，要加強對于整個營銷活動的流程計劃和控制：第一要從自己公司的可持續發展方面看，將營銷活動目標確定好，如將具體銷售的金額確定好等，按照具體目標將具體執行的計劃方案制定好；第二在將具體市場營銷的活動方案擬定好之前，要將具體資料收集起來，例如市場上的消費者對于產品的耐用程度、質量、外觀以價格可接受的范圍，市場上經濟、政治和法律外界的環境對于產品銷售、推廣的渠道影響。
（二）制定好詳細戰略
對整個市場調查之后，可以對調研獲取的資料進行具體的分析和統計，將目標的群體確定好，對市場進行細分。按照市場的調查報告對產品生產優勢和劣勢進行一定的分析，將優秀產品的組合建立好，同時對于產品組合深度和寬度以及互相之間關聯程度進行有效規范處理。將市場的競爭現狀充分考慮好，制定出合理產品價格，并且建立高素質、優秀銷售的團隊，將產品的銷售渠道不斷拓寬，使得產品銷售額不斷增加，給企業帶來非常多經濟的利潤。分析所有市場的營銷活動里面工作的任務，尤其是針對某些工作，要對其進行科學、系統的安排，將每一個工作都落實到位。在整個銷售的過程中，企業里所有職能的部門都需要共同參與，確保每一個參與的員工都具備團隊的協作精神，保證整個工作的流程能夠正常運行。
（三）具體實施企業項目
產品的生產和研發部門需要按照市場的調研報告，重新定位和審核現有的產品，與不同產品生產的周期相結合進行適度調整。一旦現在的產品不能夠滿足消費者和市場的需求，需要其研發的部門按照企業里科學的技術水平開發新的產品，使得整個企業能夠在競爭激烈的市場上占有一席之地。同時市場的部門要按照現有產品市場的營銷策略，確定好消費者能夠接受價格的范圍，將新產品上市總成本估算好。并且相關的銷售部門也要根據新產品的不同特點以及不同消費的人群，對產品銷售的方式和銷售的渠道進行認真的選擇，盡量占取大量消費者的市場，將企業市場的占有率提高，給企業帶來非常多經濟的利益。
二、項目管理中需求的管理
（一）界定科學的需求管理范圍
確定好各個階段項目的任務目標，對整個項目的背景、實施的相關要求和目標有綜合的了解，與項目現在狀態、整體的實施安排以及未來的發展方向相結合之后，有效分析整個項目所涉及的內容，將項目的需求管理范圍規劃好。與此同時，按照各個需求的重要性以及現在企業的資源情況，將項目實施任務的清單制定好，保證與之相關的各級人員都認可該任務清單。將需求的范圍制定好之后，要充分分析項目的內容，分析的時候可以運用模型和圖表工具來描述分析的結果，方便相關的人員能夠更好地了解需求情況，分析的時候一定要注意不能夠出現遺漏、含糊或者是前后不一的情況，確保該需求分析能夠給企業提供項目實施的保障基礎，與相關人員溝通的時候需要綜合運用各種溝通的技巧和方式。
1.注重肢體運用肢體語言。在與溝通對象進行溝通的時候，要注意傾聽溝通對象的表達，觀察對方所表達出的肢體動作，正確把握對方想要表達的內容，討論到復雜內容的時候要注意雙向的溝通，表達自己的意見給對方，保證雙方對該內容的了解相一致。
2.充分了解溝通的對象。在與相關人員進行溝通之前需要對其情緒、愛好和性格等有所了解，選擇合適的溝通方案，并且將一些容易歪曲理解的信息排除，表達溝通對象比較感興趣的內容，最終使得溝通對象有注重想要溝通的意識。
（二）制定科學的規劃方案
企業在實施項目的時候提出實施的目的，其主要原因是為了將工作的效率提高、方案控制經營的風險、對管理的模式進行優化、不斷推動企業經營業務的發展以及讓監管的要求得到滿足，并且企業提出的各個任務一定會與企業未來的發展有一定關系。在企業提出的各個任務中，怎樣針對現在企業的發展情況和資源配置的情況，對企業的需求管理進行有效的規劃是非常重要的一個工作內容。為了能夠確保各個任務得到合理的規劃，首先要對各種因素進行綜合的考慮，分析和評定各項任務，并且需要與企業制定的發展戰略相結合，對企業的各個項目充分分析之后，還需要對項目進行總體統籌的規劃，最后再將各種任務的需求按照企業每年的任務需求進行有效分配，按照任務的重要程度和難易程度進行分配，再細分為月度和季度甚至是每周的任務量，使得各種任務的實施能夠得到合理的規劃，進而推動企業的項目管理進度能夠有效實施。
（三）嚴格控制需求的變更情況
在實施項目的時候，經常會遇到很多突然改變的情況，但是需求的改變會對項目進程、質量和成本產生很大的影響，所以需要項目管理人員有效控制需求的變更情況。首先企業需要制定規范的管理流程來控制需求變更情況，針對不同需求來制定不同處理的流程，保證需求變更的管理能夠有一定的章法；其次當提出需求變更的情況之后，管理需求的人員要對變更的背景進行充分的了解，例如市場的變動、監管部門的要求或者是規則的調整等，然后再分析變更的內容，主要包括變更的內容、主題、影響范圍以及可行性等相關的內容。對變更情況充分分析之后，如果只是一些比較小的變動，不會對項目的整體實施產生影響并且各個部分都認可該需求的變更，就可以不要改變方案直接按照之前的方案實施，但是假如變更的范圍和內容比較大，則需要對變更內容、范圍、可行性和利弊進行分析，將該情況向上級的領導匯報，方便領導進行最后方案的決策；最后將領導最終決策的方案與相關管理人員的意見進行溝通，形成各個部門都認可的變更方案，有效實施各種變更的程序，將變更之后的需求分析做好，保障項目實施的質量和進度。
第9篇：需求變更的管理流程范文
【關鍵詞】軟件復用 測控軟件 開發
1 引言
隨著交會對接、空間實驗室、探月工程、深空探測等一系列任務的全面展開，地面測控站內的測控軟件的可靠性和高效性將面臨空前的挑戰。在軟件開發的各個階段，保證階段產品高質高效以及縮短研發周期是保障多任務并發的重條件，二者互相影響。為使軟件既能高效又能保質保量的完成，近幾年來，軟件開發單位采用專門的軟件管理團隊對軟件進行規范管理，與此同時改進軟件開發技術。軟件規范管理從近年的9001B質量體系認證、GJB5000A軟件過程改進以及軟件工程化等都對軟件開發的各個階段產品進行了規范管理，地面測控軟件的管理日益規范，不斷改進。另一方面，為大幅度提高軟件的研發效率和質量，可以采用軟件復用技術。本文結合測控軟件開發實踐，對復用技術在測控軟件中的有效應用進行初步研究。
2 軟件復用理論
2.1 軟件復用的概念
為避免程序開發“從零開始”以及重復相同的工作，采用已有的經驗和成果，將開發的重點集中在應用系統的新研部分，提高工作效率和軟件質量，這就是軟件復用。復用形式包括基于構件的復用和基于過程的復用，基于構件的復用是目前主要的復用形式。
2.2 軟件構件及基于構件的軟件開發
軟件構件是軟件復用的核心和基本單位，具有獨立的功能，是可復用的軟件組成部分，可供第三方進行軟件組裝。構件可以是被封裝的對象類、類樹、功能模塊、軟件框架、軟件構架（ 或體系結構） 、文檔、分析件、設計模式等。基于構件的軟件開發與傳統的軟件開發相比，基于構件的軟件開發強調使用軟件構件對軟件系統進行設計開發。基于構件的軟件開發方法需要有相應的軟件開發過程作為基礎，否則，就不會有與該系統相符合的質量特性要求的軟件構件。
2.3 軟件復用的優點
（1）改善軟件質量：經過測試以及經過實踐的軟件往往缺陷更少。
（2）降低開發風險：開發新的組件，如果測試不夠充分，輕則有效性不高，重則可能是造成軟件失敗的原因。
（3）支持快速原型開發：快速構建實用可操作系統模型，憑借其與用戶進行有效溝通，最終獲得用戶有效意見反饋。
（4）提高軟件開發效率，縮短軟件開發周期，從而降低軟件開發成本。
3 軟件復用在測控軟件開發中的應用
近年來，隨著任務數量的增多，測控軟件的開發團隊越來越小，軟件開發周期越來越短，軟件的研制要求卻不斷的提高；隨著衛星工作模式的增加，地面接收設備也需增加相應的工作模式完成相應的接收任務。因此，測控軟件不但需要完成原有工作模式的監控管理功能，還需完成新增工作模式的監控管理功能。測控軟件必須有效繼承原有成熟的計劃管理、自動標校/測試及自動運行管理技術，同時需要開發適合新增工作模式的計劃管理、自動標校/測試及自動運行管理技術，并且要為后續其它型號軟件提供高效的功能繼承。
基于軟件復用技術的測控軟件開發，使用大量的已經過驗證的高效軟件，對傳統瀑布模型的各個研制階段的產品（如需求分析、軟件設計、軟件編碼、軟件測試）進行優化和簡化，節省了人力和時間，提高了軟件的可靠性，降低了軟件成本和開發周期。在軟件的研制過程中，需要對軟件的復用架構進行設計，對可復用的構件進行適應性修改設計以適應新的軟件需求，還需對新研的部件進行軟件設計。軟件的研制流程參見圖1。
測控軟件對原有成熟的設備監控、計劃管理、自動標校/測試及自動運行管理功能的繼承，就成為軟件的復用的內容。其中包括四個階段的復用：需求復用、設計復用、代碼復用、測試復用。
3.1 需求復用
測控軟件的變更原因主要有兩種：
（1）用戶需求變更。
（2）軟件自身技術升級。其中，用戶需求變更是導致軟件變更的首要因素；軟件技術升級的部分工作往往也是為了更好的適應用戶的需求。
首先，同類任務的需求是逐漸增加的，并且有一定的可繼承性，當增加新的需求時，已驗證過的任務需求即可成為后續任務需求的可復用的構件。
其次，不同的測控任務需求之間同樣存在相同或相似的元素。例如，任何一個任務都有相同或相似的任務流程；根據工作計劃及自動運行策略進行站前標校、任務宏配置、啟動自動運行流程；監控數據的存儲、顯示、查詢等任務需求存在一定的共性，對其通用的任務需求，是完全可以復用或部分復用的。
因此，任務需求變更與軟件需求變更為因果關系，直至后續的各個階段活動都受到任務需求變更的影響。從需求分析、軟件設計、軟件編碼直至軟件測試，都會因為任務需求的變更而必須進行相應的更動。
3.2 設計復用
多年以來，很多任務的測控軟件都有相同或相似的軟件結構，因此，這一有利條件，在軟件結構設計時，得到了充分的利用。
從軟件復用的角度來說，在進行軟件結構設計時，需將軟件中相對穩定的部分（如設備監控、數據庫管數據庫管理、計劃管理、用戶管理）與新增加的部分不僅從結構上分開，而且要求其接口相對單一穩定。這樣，從軟件設計到代碼開發都可以復用。
3.3 代碼復用
對程序代碼的復用，以設備的監控線程為例介紹如下：
目前，測控站內設備通過局域網進行通信，各個設備與測控軟件之間的通信接口都已進行了標準化，因此，對不同設備的監控線程可以進行代碼復用；如果重新設計代碼，不但要耗費大量的人力和時間，延長軟件開發周期，而且重新設計的代碼必須進行充分的軟件測試，否則難以保證其正確性和健壯性。
開發者使用以往可復用的程序代碼，或全部吸收或加以優化，大大避免了重復性工作，將精力集中于關鍵技術的攻關，如此設計更加高效可靠的軟件系統。
3.4 測試用例復用
軟件測試復用主要包括測試流程的復用、測試方法的復用和測試用例的復用。其中，測試用例的復用是測試復用中的關鍵技術。測試用例的復用對于縮短軟件的開發周期和降低軟件開發成本具有極其重要的意義。
4 結束語
測控軟件在當前開發周期越來越短，任務量越來越大，軟件質量要求越來越高的前提下，軟件設計開發者如能有效的利用長期工作實踐中積累的大量的軟件工程經驗，以及大量的經過驗證的軟件相關文件及代碼較好的實行軟件復用技術，則能夠大大降低軟件開發成本，提高軟件開發效率，提高軟件質量。
因此，軟件復用技術在測控軟件開發中既實用，又有效，對軟件開發起著至關重要的作用。
參考文獻
[1]楊芙清，梅宏，李克勤.軟件復用與軟件構件技術[J].電子學報，1999（2）：69-71.
[2]楊芙清，王千祥，梅宏.基于復用的軟件生產技術[J].計算機科學，2001，4（21）：363-370.
[3]陳菲，劉克勤.計算機軟件復用技術研究[J].現代電力，2002，19（6）：95-101.
[4]劉述忠.軟件復用-提高計算機軟件質量與效率的途徑[J].中國金融電腦，2002（2）：20-22.
[5]劉艷艷，羅克露.基于特定領域軟件體系結構的軟件復用[J].計算機信息，2011（1）：173-174+394.
作者簡介
王德芳（1979-），河南省鄭州市人。學士學位?，F為中國電子科技集團公司第二十七研究所工程師。研究方向為電子工程。
