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