前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇需求變更的管理流程范文，相信會為您的寫作帶來幫助，發(fā)現(xiàn)更多的寫作思路和靈感。

需求變更的管理流程范文第1篇

【關(guān)鍵詞】 需求開發(fā) 需求變更 需求分析

隨著計算機的不斷發(fā)展，軟件開發(fā)工程應(yīng)運而生。影響軟件開發(fā)的效率因素多種多樣，主要包括需求調(diào)研過程中理解產(chǎn)生的歧義、需求編寫的不完整性、需求表達的二義性、以及需求的頻繁變更等都將會影響到軟件開發(fā)的最終結(jié)果。隨著軟件開發(fā)規(guī)模的逐漸擴大，軟件需求分析與管理成為整體軟件開發(fā)的關(guān)鍵環(huán)節(jié)，直接決定著軟件開發(fā)的成敗。在軟件的開發(fā)過程中，只有設(shè)定清晰完善的需求開發(fā)與管理方案，才有助于軟件設(shè)計、開發(fā)人員正確理解和確定軟件的完整功能，從而達到客戶需求的滿意度。

本文將以軟件需求工程為側(cè)重點、從軟件需求變更的原因、影響、原則及管理方案為研究領(lǐng)域進行分析和討論。

一、軟件需求變更的主要原因分析

1、客戶需求因素。在軟件的開發(fā)過程中，客戶會隨著項目開發(fā)的進程逐漸達成對軟件系統(tǒng)的深入了解和認識，在不斷的思考過后形成了新的需求信息或改進的需求信息，進而會提出滿足其新需要的軟件變更條款。2、系統(tǒng)內(nèi)部因素。在軟件開發(fā)過程中，計算機外部硬件設(shè)備、系統(tǒng)軟件、系統(tǒng)數(shù)據(jù)等內(nèi)部系統(tǒng)之間的相互適應(yīng)要求都會引起軟件需求的變更。這種需求變更將會以硬件設(shè)備、操作系統(tǒng)、系統(tǒng)軟件等原始系統(tǒng)因素為基礎(chǔ)進行更新、升級、換代，以此確定軟件設(shè)計的安全性、兼容性和準(zhǔn)確性。3、業(yè)務(wù)環(huán)境因素。在軟件開發(fā)過程中，與軟件開發(fā)相關(guān)聯(lián)的制度、規(guī)范、政策等的重新改寫與設(shè)定，或是軟件開發(fā)業(yè)務(wù)要求的不斷改變都將會引起軟件需求變更。例如，軟件的需求會隨著保險制度的變化而變更，會隨著交通制度的變化而變更等等。4、需求開發(fā)缺陷因素。在軟件需求開發(fā)過程中，需求信息調(diào)查研究、需求文檔的編寫及評審等工作的不足都是影響軟件需求變更的主要原因。

二、軟件需求變更的主要影響分析

1、影響軟件開發(fā)的實際進度。頻繁的需求變更不僅需要大量項目人員的支持，還需要投入大量的經(jīng)費，如果投入的力度過大，將會導(dǎo)致軟件開發(fā)項目超過預(yù)期甚至導(dǎo)致失敗。

2、影響軟件開發(fā)質(zhì)量的優(yōu)良。在軟件開發(fā)過程中，需求的不斷變更將會導(dǎo)致原有的需求鏈斷裂，對原定需求的部分環(huán)節(jié)造成影響，而這些影響又將導(dǎo)致軟件開發(fā)項目設(shè)計的改變，最終導(dǎo)致系統(tǒng)質(zhì)量的下降，開發(fā)效率的降低。

3、影響客戶與開發(fā)者之間的相互合作。軟件開發(fā)是客戶與開發(fā)者之間的一種相互信任、相互合作的過程。如果二者之間在軟件需求變更上產(chǎn)生不同意見，而且沒有得到妥善的處理，將會導(dǎo)致二者之間的合作關(guān)系破裂，甚至造成軟件開發(fā)中斷等嚴重后果。

三、軟件需求變更的處理原則

1、完整性原則。完整性是軟件安全的基本要點。在軟件開發(fā)過程中，要保證需求變更信息的采納收集、匯總整理、評判審核、監(jiān)視追蹤等環(huán)節(jié)的完整性，保證軟件需求變更能夠按照規(guī)范的流程進行操作。

2、合理性原則。在軟件開發(fā)過程中，客戶與需求分析人員將會以不同的視角、不同的態(tài)度評估需求變更條件，要想達成軟件開發(fā)的精確性，就需要在用戶需求、軟件技術(shù)和整體開發(fā)能力的基礎(chǔ)上，達成需求變更的合理性，實際性。

四、軟件需求變更的有效管理方案

1、達成開發(fā)者與客戶之間的有效溝通。在發(fā)生軟件需求變更時，需求分析人員要與客戶進行及時有效的溝通和反復(fù)的確認，向客戶說明開發(fā)建議和解決方案并制定相應(yīng)的合同規(guī)范，以此來達成對客戶的承諾和軟件修改后的滿意度。2、制定軟件需求變更信息的整理報告。在軟件需求變更過程中，要對客戶需求的規(guī)范、變更后的功能、軟件質(zhì)量目標(biāo)、變更解決方案等信息進行整理、分析和記錄，制定明確的需求分析整理報告，以此來確保需求變更的準(zhǔn)確性、實際性與科學(xué)性。3、進行明確、合理的人員分工。在需求變更達成協(xié)議后，就需要對開發(fā)人員進行合理的安排和組織，對操作人員和測試人員進行明確的分工；利用合理的需求變更管理工具，達成整體軟件項目開發(fā)的高效和優(yōu)質(zhì)。4、做好需求和產(chǎn)品特性的評審和測試工作。做好需求變更相關(guān)信息的記錄后，需求分析人員要組織開發(fā)、測試與客戶等相關(guān)人員對更改后的需求進行評審和測試，篩出掉不符合實際的變更需求，確保需求變更流程的順利進行。在軟件變更實施的最后階段，要對軟件產(chǎn)品系統(tǒng)進行測試，以檢驗其是否滿足客戶的原定需求、是否達到了預(yù)期的效果和期望，以保證更改后產(chǎn)品系統(tǒng)的基準(zhǔn)性和安全性。

總之，在出現(xiàn)軟件需求變更狀況時，首要的就是與客戶做好溝通和協(xié)商，其次要做好需求變更信息的詳細記錄，最后做好軟件需求變更后的測試。只要做好這關(guān)鍵的三部，就能夠充分確保軟件開發(fā)的規(guī)范化和優(yōu)質(zhì)化。

參 考 文 獻

需求變更的管理流程范文第2篇

[關(guān)鍵詞] 需求分析 需求變更 需求控制

一、問題的提出

什么是需求分析?

要知道需求變更是什么,首先要知道什么是需求分析。

需求分析是指理解客戶需求,就軟件功能與客戶達成一致,估計軟件風(fēng)險和評估項目成本代價,最終形成開發(fā)計劃的一個復(fù)雜過程。需求分析的成果形成需求說明書。

什么是需求變更?

根據(jù)軟件工程思想定義,需求說明書一般要經(jīng)過論證,如果在需求說明書經(jīng)過論證以后,需要在原有需求基礎(chǔ)上追加和補充新的需求,或?qū)υ行枨筮M行修改和削減,均屬于需求變更。

二、需求變更的原因及影響

1.需求變更原因

一方面是用戶:他們是項目需求的提出者。一個十分常見的現(xiàn)象是用戶提出需求以后,在軟件開發(fā)過程中用戶改變了需求,這只能迫使開發(fā)工作返工,丟棄一些無法修正的部分。無疑這會造成一定的損失,但又無法完全避免。要求用戶一次性把需求講清楚,并且不允許此后需求有任何變更,這是不現(xiàn)實的。只能盡量減少需求變更,降低它所造成的影響。

二是系統(tǒng)因素:在系統(tǒng)內(nèi)部,如計算機硬件、系統(tǒng)軟件或數(shù)據(jù)的變更要求與其相適應(yīng)。

三是外部環(huán)境因素:與軟件運行相關(guān)的工作制度或法規(guī)、政策的變更,或是業(yè)務(wù)要求變更導(dǎo)致的需求變更。

四是需求分析階段工作缺陷:需求調(diào)研、分析、定義和評審工作不夠充分,致使需求規(guī)格說明中隱含著問題,在開發(fā)過程中才有所發(fā)現(xiàn)。或者需求開發(fā)中開發(fā)人員與用戶溝通不夠充分,如未能如實獲得用戶的潛在需求等。

軟件需求一旦出現(xiàn)變更,它可能要涉及到一些相關(guān)的代碼和文檔的修改,為此要把這一變更通知到所有相關(guān)人員。提出需求變更有可能在開發(fā)的任何階段,并且隨著項目的進展,越晚的需求變更引起的損失越大。

2.需求變更給軟件的開發(fā)工作帶來的影響

需求變更對軟件開發(fā)的影響是多方面的,概括的看,包括以下三個方面:

(1)增加項目的人員、費用開支,影響開發(fā)進度。需求變意味著原先的需求調(diào)研、分析的結(jié)果與預(yù)期的軟件實現(xiàn)存在偏差,需要進行需求變更。這無疑要增加項目的人員、費用的開支,并對開發(fā)進度造成影響。更有甚者,如果變更頻繁,可能對項目造成較大影響,嚴重時可能直接導(dǎo)致項目的失敗。

(2)影響軟件質(zhì)量。在一個復(fù)雜的軟件系統(tǒng)中,需求之間具有一定的聯(lián)系,相關(guān)需求可構(gòu)成需求鏈。如果由于需求變更導(dǎo)致需求鏈的某些環(huán)節(jié)脫節(jié),就可能引起一些難以察覺的錯誤。當(dāng)需求變更沒能及時修改項目的設(shè)計、開發(fā)文檔時,這些錯誤一般難以被測試人員發(fā)現(xiàn),將直接影響系統(tǒng)質(zhì)量,嚴重時可導(dǎo)致系統(tǒng)崩潰。

(3)影響開發(fā)者與用戶之間的合作關(guān)系。需求變更的實施是用戶和開發(fā)者相互協(xié)作的過程。開發(fā)者和用戶在是否采用變更問題上常常產(chǎn)生分歧,如果沒有恰當(dāng)處理,影響雙方的互信,從而影響項目開發(fā)進程。同時需求變更也會在項目開發(fā)人員之間產(chǎn)生分歧,影響合作關(guān)系。

三、采取的對策

1.首先是預(yù)防

盡量做好需求分析工作,以期減少需求變更的頻次,為此在需求分析階段著重處理好以下問題,力圖使需求分析的結(jié)果更接近目標(biāo)。

(1)培養(yǎng)正確的需求意識。優(yōu)秀軟件產(chǎn)品建立在優(yōu)秀的需求基礎(chǔ)之上,而高質(zhì)量的需求又來源于客戶與開發(fā)人員之間有效的交流與合作。因此,雙方的參與者都需要認識到:要想獲得成功,自己需要什么,合作方又需要什么。只有這樣,才能建立融洽的合作關(guān)系。因此,培養(yǎng)正確的需求意識是雙方都需要努力的,而開發(fā)人員在這個階段應(yīng)該發(fā)揮更加積極主動的作用。

首先,需求分析人員應(yīng)該接受一定的正規(guī)培訓(xùn),以提高與人溝通的能力、緩解矛盾的能力、善于傾聽和詢問的技巧,以及收集整理資料的能力等。在參與具體項目時,分析人員也應(yīng)主動學(xué)習(xí)一些項目所涉及的具體應(yīng)用領(lǐng)域的基本知識,以更好地理解用戶的需求。

其次,開發(fā)單位應(yīng)該對那些不想花時間在需求分析上的用戶明確指出:如果用戶不能充分地支持并參與,項目很可能會失敗;開發(fā)單位還可以通過學(xué)習(xí)一些前車之鑒的真實案例警告用戶:低質(zhì)量的需求分析可能導(dǎo)致嚴重的后果。通過對用戶代表和管理人員的培訓(xùn),使他們真正理解需求分析的重要性和忽略需求帶來的風(fēng)險,并對計算機系統(tǒng)有一個大體的了解,這樣用戶才能夠主動地參與需求分析。

同時,正因為不可能一次就完全了解用戶的需求,而且在系統(tǒng)開發(fā)過程中還需要不斷地請用戶參與,因此與用戶的溝通是需要貫穿始終的。需求分析中所采取的一些策略可能會讓用戶覺得意外和難以接受。因此,需求分析人員需要對用戶解釋一些做法的必要性和合理性,以得到用戶最大的支持與合作。

(2)從業(yè)務(wù)需求入手。用戶認識到了需求分析的重要性,但可能仍然不知道從何處入手表達自己的需求。這時可以從業(yè)務(wù)需求入手,任何企業(yè)對自己的經(jīng)營運作目標(biāo)應(yīng)該是比較清楚的,這樣的經(jīng)營背景讓用戶不僅有話說,也讓開發(fā)者有章可循。需求分析不可以完全與它所處的背景相脫離,只有當(dāng)系統(tǒng)真正置身于它的社會和組織環(huán)境中,它的需求才能清晰地反映出來。

(3)充分利用需求來源。有了以上需求背景,就比較容易做到有的放矢了。需求分析人員可以直接與系統(tǒng)未來的操作者探討他們希望有什么樣的軟件;觀察系統(tǒng)的潛在用戶當(dāng)前的日常工作以獲取有價值的信息;系統(tǒng)的使用者可能有很多,可以將他們分類以簡化需求;最后一定要與真正的決定者達成協(xié)議:對于有沖突的需求如何權(quán)衡,對于直接用戶的眾多需求如何取舍等。

同時,用戶往往對計算機期望過高,認為計算機可以解決當(dāng)前存在的所有問題,因此會提出很多的功能需求,并且希望在很短的時間內(nèi)看到成效。但是,由于技術(shù)、人力等資源的限制,并不一定能夠在設(shè)定的時間期限內(nèi)滿足用戶所有的期望,這時就應(yīng)該盡早確定出交付的產(chǎn)品應(yīng)具備的最重要功能,即設(shè)定需求的優(yōu)先級。

在這個階段,可以采用UML中的用例圖幫助用戶和需求分析人員之間的交流。一個用例圖描述用戶可以用軟件產(chǎn)品執(zhí)行的一個任務(wù)。它不是從軟件的性能和系統(tǒng)的行為方面出發(fā),而是從用戶到底能夠用這個軟件產(chǎn)品干什么入手。這樣的方式用戶比較熟悉,容易溝通;而且不會在需求分析的一開始就陷入過于細節(jié)化的設(shè)計,也有助于避免分析人員添加一些與所需任務(wù)無關(guān)的自認為很好的功能。

(4)提供選擇方案。由于用戶對軟件系統(tǒng)缺乏經(jīng)驗,或者由于用戶的運作機制還未完善,或者由于其他種種原因,用戶可能仍然不能對一些需求做出明確的說明,收集整理的需求中可能仍然存在一些不確定因素。這時可提出幾份比較詳細的方案。附帶不同做法的優(yōu)點,供用戶選擇或者啟發(fā)用戶確定需求。

如果需求分析做得好,文檔清晰且又有客戶簽字,那么后期客戶提出的變更就超出了合同范圍,需要另外收費。這個時候,開發(fā)方一定要據(jù)理力爭,此時這并非要刻意賺取客戶的錢財,而是不能讓客戶養(yǎng)成經(jīng)常變更的習(xí)慣,否則后患無窮。

2.分級管理客戶需求

軟件開發(fā)項目中,“客戶永遠是對的”和“客戶是上帝”并不完全的正確,因為在已經(jīng)簽定的項目合同中,任何新需求的變更和增加除了影響項目的正常進行以外,還影響到了客戶的投入收益,所以有的時候項目經(jīng)理反倒應(yīng)該為客戶著想。

對于項目中的需求變更,可以實行分級管理,以達到對需求變更的控制。

一級需求變更是關(guān)鍵性的需求,這種需求如果不滿足,意味著整個項目不能正常交付使用,前期工作也會被全部否定。這個級別的需求是必須滿足的,否則就意味著否定自已的項目成員和成員的所有努力,所以定為“Urgent”。

二級需求變更是后續(xù)關(guān)鍵性需求,它不影響前面工作內(nèi)容的交付,但不加以滿足,新的項目內(nèi)容無法提交或繼續(xù),所以是“Necessary”。一般新模塊關(guān)鍵性的基礎(chǔ)組件,屬于這個級別。

三級需求是后續(xù)重要的需求,如果不被滿足會令整體項目工作的價值下降,為了體現(xiàn)項目價值,也是開發(fā)人員自已的技術(shù)價值的證明,所以定為“Needed”。一般性的重大的有價值的全新模塊開發(fā),屬于這個級別。

以上三個等級是應(yīng)該實施的,但時間性上可以作優(yōu)先級的排列。

四級需求是改良性需求,沒有滿足這類需求并不影響已有功能的使用,但如果實現(xiàn)了則會更好,定級為“Better”。界面和使用方式的需求,一般在這個檔次。

五級需求是可選性需求,更多的是一種設(shè)想,以及一種可能,通常只是客戶的的一種個人喜好而已,定級為“Maybe”。

對于四級需求,如果時間和資源條件都允許的話,不妨做下去。對于五級需求,正如對它的描述一樣做與不做是“Maybe”。

3.加強需求變更的控制

在需求分析階段工作完成后,需求變更仍可以會發(fā)生,因此就要加強對需求變更的控制,主要有以下原則:

(1)建立需求基線。需求基線是需求變更的依據(jù)。在開發(fā)過程中,需求確定并經(jīng)過評審后(用戶參與評審),可以建立第一個需求基線。此后每次變更并經(jīng)過評審后,都要重新確定新的需求基線。

(2)制訂簡單、有效的變更控制流程,并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個控制流程進行控制。同時,這個流程具有一定的普遍性,對以后的項目開發(fā)和其他項目都有借鑒作用。

(3)成立項目變更控制委員會(CCB)或相關(guān)職能的類似組織,負責(zé)裁定接受哪些變更。CCB由項目所涉及的多方人員共同組成,應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。

(4)需求變更一定要先申請然后再評估,最后經(jīng)過與變更大小相當(dāng)級別的評審確認。

(5)需求變更后,受影響的軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更,以保持和更新的需求一致。

(6)妥善保存變更產(chǎn)生的相關(guān)文檔。

這六大原則看起來簡單,但真正實施起來有難度,還需要依據(jù)理論知識配合開發(fā)項目組的實際工作情況,在實踐中不斷摸索總結(jié)。

四、總結(jié)

軟件項目的需求變更是對軟件產(chǎn)品的質(zhì)量、成本、工期帶來巨大的影響。通過預(yù)防性措施和加強需求變更的控制與管理,將需求變更的頻次大幅度降低,從而為軟件項目的順利實施打下堅實基礎(chǔ)。

參考文獻:

[1]王 莉 吳潔明:軟件項目中的需求變更管理的研究[J].計算機技術(shù)與發(fā)展,2007,17(1):120～121

[2]王 強:軟件開發(fā)項目中的需求變更管理[J].電腦知識與技術(shù)(學(xué)術(shù)交流),2007,(11)

需求變更的管理流程范文第3篇

北方工業(yè)大學(xué)教授

歷任北方工業(yè)大學(xué)軟件工程研究所、北方工業(yè)大學(xué)SEGUE軟件測試中心、以及與中國醫(yī)藥設(shè)備工程協(xié)會合作建立了“中國醫(yī)藥設(shè)備工程研究服務(wù)中心”負責(zé)人。

有人說開發(fā)軟件比建一幢大樓復(fù)雜多了，因為軟件行業(yè)缺乏準(zhǔn)確而又統(tǒng)一的語言來描述相應(yīng)的工作。有些“需求”實際上存在于人們的頭腦中，能否準(zhǔn)確無誤地用文字描述出來完全取決于客戶對計算機軟件的靈感和表達能力，而開發(fā)人員能否完整、正確地獲取和理解客戶的需求，取決于開發(fā)人員對客戶業(yè)務(wù)的熟悉程度和IT行業(yè)經(jīng)驗。

所有的開發(fā)商和用戶都希望獲得高質(zhì)量的需求，但是有許多因素影響需求的質(zhì)量，下面我們詳細分析影響需求質(zhì)量的幾個主要因素和解決方法。

用戶需求不斷變更

開發(fā)過程中需求不斷變化，會使軟件的整體結(jié)構(gòu)越來越混亂，補丁代碼使得整個程序難以理解和維護，破壞了軟件模塊高內(nèi)聚、低耦合的設(shè)計原則。如果項目管理工作不完善，帶來后果會更加嚴重。但是用戶通常不是計算機專家，對需求變更導(dǎo)致的軟件質(zhì)量問題認識不足，所以，不論開發(fā)人員如何強調(diào)需求變更的風(fēng)險，仍然無法阻攔用戶需求的變更。

為了減少用戶需求變更，可以從兩個方面入手:首先，必須從一開始就對軟件的范圍、目標(biāo)、規(guī)模、接口和成功標(biāo)準(zhǔn)給予明確的定義。其次，在項目管理上要制定需求變更控制流程，一旦用戶需求發(fā)生變更，嚴格按照規(guī)范的流程進行一系列的分析和審查。通過這兩種方法既可以有效地控制用戶需求變更的隨意性，又能夠滿足用戶需求變更的必要性。

用戶不配合

實際工作中，用戶的熱情參與是項目成功的重要因素。如果用戶不熱心，項目將無法成功。對待這個問題主要是與用戶溝通，引導(dǎo)他們對項目感興趣，可以將做過的一些成功系統(tǒng)給用戶演示，提高用戶的信任度也是有效的方法。

過于精簡的需求說明

這是開發(fā)中最經(jīng)常犯的錯誤。盡管開發(fā)人員和用戶都認為應(yīng)該花大精力進行需求分析，但在實際項目中仍然很難抵御編程的誘惑。在初始階段，可將項目組成員分為兩部分，一部分做需求工作，另一部分（主要是程序員）熟悉開發(fā)環(huán)境，攻克開發(fā)中可能遇到的技術(shù)難題，或者驗證項目經(jīng)理所擔(dān)心的一些關(guān)鍵問題。在需求審查時，所有項目組成員都參加，由于后者沒有參加需求分析，對用戶需求了解甚少，他們對過于簡單的需求描述往往會提出許多問題，幫助彌補需求說明的不足。

忽略用戶分類

需求變更的管理流程范文第4篇

網(wǎng)站項目是以Web服務(wù)器為主體、瀏覽器為客戶端作為基本架構(gòu)的項目。這樣的架構(gòu)項目中包含Web服務(wù)器、瀏覽器和網(wǎng)絡(luò)三個關(guān)鍵主體。網(wǎng)站項目可能是一個網(wǎng)站，也可能是各種Web應(yīng)用程序，例如網(wǎng)上商店、虛擬郵局、網(wǎng)絡(luò)辦公管理系統(tǒng)、客戶關(guān)系管理系統(tǒng)等等。網(wǎng)站項目管理就是圍繞著網(wǎng)站項目運用知識、技術(shù)、技能、工具和方法進行組織管理。其特點表現(xiàn)在以下幾個方面：

1）涉及的領(lǐng)域很多。狹義地講，網(wǎng)站項目包括了網(wǎng)頁制作、美工設(shè)計、程序編碼、系統(tǒng)及網(wǎng)絡(luò)管理等專業(yè)技術(shù)，廣義上又包含了企業(yè)管理、市場營銷、心理學(xué)、廣告學(xué)等更多領(lǐng)域的知識，在項目進行過程中還涉及到項目管理工具、文檔和設(shè)計開發(fā)管理規(guī)范、開發(fā)及測試環(huán)境部署等特殊領(lǐng)域的問題。這對參與項目管理的人員提出了很高的要求。

2）參與項目的角色很多，水平可能參差不齊。對于網(wǎng)站項目管理，最關(guān)鍵的角色是項目經(jīng)理、業(yè)務(wù)流程分析師、用戶界面工程師、系統(tǒng)分析員、編碼人員（程序員）和質(zhì)量控制工程師等。根據(jù)項目的規(guī)模和開發(fā)的深度，由項目經(jīng)理進行角色劃分。假如嚴格細分，一個大型項目的角色可能達到50個以上，以確保每個細節(jié)都有專業(yè)的人員進行負責(zé)和管理。其中需求分析過程中主要角色有客戶代表、業(yè)務(wù)員、業(yè)務(wù)流程分析師、用戶界面工程師，另外還有項目經(jīng)理、數(shù)據(jù)庫工程師、文檔工程師等參與。

3）網(wǎng)絡(luò)應(yīng)用的開發(fā)技術(shù)在日新月異地進步，從而使網(wǎng)站應(yīng)用系統(tǒng)的開發(fā)模式具有多種選擇性，達到同樣的目標(biāo)可以采用很多不同的方式，現(xiàn)代的應(yīng)用系統(tǒng)越來越成為一個龐大的集成方案，需要考慮不同的操作平臺、不同的應(yīng)用服務(wù)器、不同的數(shù)據(jù)庫、不同的編程語言、不同的傳輸介質(zhì)等等，項目管理人員必須了解各種技術(shù)的利弊，幫助用戶選擇高效、廉價并富有前瞻性的方案。

2需求分析在網(wǎng)站項目管理中的作用及要求

需求分析是一個項目的開端，也是項目建設(shè)的基石。由于以上提出的網(wǎng)站項目的特殊性和行業(yè)覆蓋的廣闊性，以及需求分析的高風(fēng)險性，網(wǎng)站項目需求分析的重要性是不言而喻的，在以往建設(shè)失敗的項目中，80％是由于需求分析的不明確而造成的。因此一個項目成功的關(guān)鍵因素之一，就是對需求分析的把握程度。

在需求分析流程中，需要有客戶代表、業(yè)務(wù)員、業(yè)務(wù)流程分析師、用戶界面工程師等角色參與，業(yè)務(wù)員從客戶代表那里獲得需求，并形成需求報告；業(yè)務(wù)流程分析員從業(yè)務(wù)員那里獲得需求報告，分析生成項目模型報告；界面工程師得到項目模型后設(shè)計制作相應(yīng)的模板和用戶界面原型，最終由客戶代表確認。需求分析所形成的文檔最終達到如下要求。

1）正確性：每個功能必須清楚描寫交付的功能。

2）可行性：確保在當(dāng)前的開發(fā)能力和系統(tǒng)環(huán)境下可以實現(xiàn)每個需求。

3）必要性：功能是否必須交付，是否可以推遲實現(xiàn)，是否可以在削減開支情況發(fā)生時被“砍”掉。

4）簡明性：不要使用專業(yè)的網(wǎng)絡(luò)術(shù)語。

5）檢測性：如果開發(fā)完畢，客戶可以根據(jù)需求檢測。

3網(wǎng)站項目需求分析的一般方法

根據(jù)以往的工程經(jīng)驗，需求分析工作方法，應(yīng)該定位在“三個階段”（也稱“三步法”）。

第一階段：“訪談式”。這一階段是和具體用戶方的領(lǐng)導(dǎo)層、業(yè)務(wù)層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運行系統(tǒng)等等具體情況和客觀信息，建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的接口人。

實現(xiàn)手段：訪談、調(diào)查表格。

輸出成果：調(diào)查報告、業(yè)務(wù)流程報告。

第二階段：“誘導(dǎo)式”。這一階段是在承建方已經(jīng)了解了具體用戶方的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運行系統(tǒng)等等具體實際和客觀信息的基礎(chǔ)上，結(jié)合現(xiàn)有的硬件、軟件實現(xiàn)方案，做出簡單的用戶流程頁面，同時結(jié)合以往的項目經(jīng)驗對用戶采用誘導(dǎo)式、啟發(fā)式的調(diào)研方法和手段，和用戶一起探討業(yè)務(wù)流程設(shè)計的合理性、準(zhǔn)確性，界面的便易性、習(xí)慣性。用戶可以操作簡單演示的DEMO，來感受一下整個業(yè)務(wù)流程的設(shè)計合理性、準(zhǔn)確性等等問題，及時地提出改進意見和改進方法。

實現(xiàn)手段：拜訪（誘導(dǎo)）、原型演示。

輸出成果：調(diào)研分析報告、原型反饋報告、業(yè)務(wù)流程報告。

第三階段：“確認式”。這一階段是在上述兩個階段成果的基礎(chǔ)上，進行具體的流程細化、數(shù)據(jù)項的確認階段，這個階段承建方必須提供原型系統(tǒng)和明確的業(yè)務(wù)流程報告、數(shù)據(jù)項表，并能清晰地向用戶描述系統(tǒng)的業(yè)務(wù)流設(shè)計目標(biāo)。用戶方可以通過審查報告來提出反饋意見，并對已經(jīng)可接受的報告、文檔簽字確認。

實現(xiàn)手段：拜訪（回顧、確認），提交業(yè)務(wù)流程報告、數(shù)據(jù)項表；原型演示系統(tǒng)。

輸出成果：需求分析報告、數(shù)據(jù)項、業(yè)務(wù)流程報告、原型系統(tǒng)反饋意見（后三者可以統(tǒng)一歸入需求分析報告中，提交用戶方、監(jiān)理方進行確認和存檔）。

整體來講，需求分析的三個階段是需求調(diào)研中不可忽視的一個重要部分，三個階段或者說三步法的實施和采用，對用戶和承建方都同樣提供了項目成功的保證。

4網(wǎng)站項目需求分析的注意事項和技巧

項目的整體風(fēng)險往往表現(xiàn)在需求分析不明確、業(yè)務(wù)流程不合理，導(dǎo)致用戶不習(xí)慣或不愿意去用承建方的軟件。承建方和客戶方都要重視需求分析的重要性。為更好地把握用戶的需求和方向，應(yīng)該采用必要的手段和方法來進行需求調(diào)研。

4.1挖掘用戶需求

鼓勵用戶將所有的想法盡可能地闡述清楚，并把所有的要求羅列出來。這時候不必擔(dān)心引起客戶的潛在需求而增加設(shè)計開發(fā)的工作量，應(yīng)直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都放到一邊，將用戶最原始、最完整的要求準(zhǔn)確地記錄下來。

很多情況下客戶并非專業(yè)人士，在他們的描述中很難凸現(xiàn)重點和技術(shù)難關(guān)，這需要我們?nèi)榭蛻暨M行分析、歸納和整理，尤其是客戶談的不多卻又是技術(shù)上實現(xiàn)難度和強度很高的地方特別值得注意。客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統(tǒng)而且尺度難以控制的，這就要求業(yè)務(wù)人員在傾聽了客戶的詳細說明以后，幫助客戶進行整理和分析，預(yù)測客戶在開發(fā)過程中變更及今后應(yīng)用中可能進行修改升級的潛在需求。

比如在為客戶設(shè)計辦公自動化系統(tǒng)的時候，也許就要為客戶預(yù)留將來與他們的業(yè)務(wù)單位進行交互的通道；在設(shè)計郵件系統(tǒng)的時候要考慮可能會需要廣告管理服務(wù)器；設(shè)計網(wǎng)絡(luò)電子商店時需考慮今后增加庫存產(chǎn)品進銷存統(tǒng)計分析等等；限于時間和財力的考慮，客戶通常能夠接受分階段實施的開發(fā)過程，在需求分析時，提早為客戶設(shè)想到今后的需求變更除了使項目開發(fā)更加順利以外，也為今后業(yè)務(wù)的進一步深入打下了更好的基礎(chǔ)。

4.2利用自然的語言和圖表描述項目模型

在業(yè)務(wù)員與客戶進行溝通和調(diào)查時撰寫的需求分析，盡可能用自然語言或形式化語言來描述，還可以添加圖形表述方式和模型表征方式。雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項目開發(fā)的各個成員都能清楚地理解需求含義，不至于在理解上產(chǎn)生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，并能以此為測試和驗收的依據(jù)。制作示意圖可以有很多種方式，關(guān)鍵是利用示意圖將客戶的需求和即將開始設(shè)計的系統(tǒng)體現(xiàn)出來。在進行系統(tǒng)分析和程序開發(fā)之前，雙方對今后要完成的產(chǎn)品就能夠有直觀的認識，換言之，就是在產(chǎn)品還沒有真正進入開發(fā)階段的時候，雙方就對工作的結(jié)果達成統(tǒng)一的意見，這將大大地減輕需求變更所帶來的困擾，同時客戶更容易地參與到項目的開發(fā)過程中。

4.3需求分析要共同參與各施其職

項目經(jīng)理、系統(tǒng)分析員、開發(fā)經(jīng)理、交互設(shè)計師、測試人員、文檔人員包括客戶代表都應(yīng)該看需求分析，并進行共同討論，達成一致意見。參與項目開發(fā)的人員都應(yīng)該對這份需求有統(tǒng)一清晰的認識，并根據(jù)自己的工作對需求提出意見，通過與客戶的溝通修訂，最終確定項目實現(xiàn)的目標(biāo)。這樣可以盡量避免業(yè)務(wù)人員與開發(fā)人員、承建方和客戶方之間發(fā)生不必要的糾紛。

例如：項目經(jīng)理通過需求分析才能組建所需要的團隊包括配置工作環(huán)境，制定開發(fā)周期；開發(fā)周期的限制和功能上的要求可能會影響到程序員采用什么樣的語言和工具進行編寫；操作用戶的技能水平將影響到交互設(shè)計師進行前臺設(shè)計時做到什么樣的精度；界面設(shè)計人員根據(jù)項目的性質(zhì)和定位確定表現(xiàn)方式；測試人員了解測試環(huán)境和條件后才能對項目質(zhì)量進行跟蹤和檢測。

4.4將需求變更置于可控狀態(tài)

需求的變更幾乎是不可避免的，也許是出自客戶的遺漏，也可能是在開發(fā)過程中被激發(fā)出來的。如何以可控的方式管理網(wǎng)站項目需求的變更，對于項目的順利進行有著重要的意義。如果匆匆忙忙地完成用戶調(diào)研與分析，則往往意味著不穩(wěn)定的需求。所以需求管理要保證需求分析各個活動都得到了充分的執(zhí)行。

為了將變更及時反饋到項目的各個角色中，做好需求變更日志就顯得非常重要。在需求分析后面附上變更日志，并將修改后的需求分析制作成新版本，保留每次更改過的版本，而不是覆蓋，這樣就比較容易地跟蹤到需求變更過程中所帶來的工作調(diào)整。在新版本的需求分析中，將變更部分用特殊方式表示出來，并在日志中記錄變更明細。

4.5評審需求文檔

需求文檔完成后，需要經(jīng)過正式評審，以便作為下一階段工作的基礎(chǔ)。一般的評審分為用戶評審和同行評審兩類。用戶和開發(fā)方對于軟件項目內(nèi)容的描述，是以需求規(guī)格說明書作為基礎(chǔ)的；用戶驗收的標(biāo)準(zhǔn)則是依據(jù)需求規(guī)格說明書中的內(nèi)容來制訂，所以評審需求文檔時用戶的意見是第一位的。而同行評審的目的，是在軟件項目初期發(fā)現(xiàn)那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到項目的后續(xù)階段。

需求變更的管理流程范文第5篇

為使軟件既能高效又能保質(zhì)保量的完成，近幾年來，軟件開發(fā)單位采用專門的軟件管理團隊對軟件進行規(guī)范管理，與此同時改進軟件開發(fā)技術(shù)。軟件規(guī)范管理從近年的9001B質(zhì)量體系認證、GJB5000A軟件過程改進以及軟件工程化等都對軟件開發(fā)的各個階段產(chǎn)品進行了規(guī)范管理，地面測控軟件的管理日益規(guī)范，不斷改進。另一方面，為大幅度提高軟件的研發(fā)效率和質(zhì)量，可以采用軟件復(fù)用技術(shù)。本文結(jié)合測控軟件開發(fā)實踐，對復(fù)用技術(shù)在測控軟件中的有效應(yīng)用進行初步研究。

2軟件復(fù)用理論

2.1軟件復(fù)用的概念

為避免程序開發(fā)“從零開始”以及重復(fù)相同的工作，采用已有的經(jīng)驗和成果，將開發(fā)的重點集中在應(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ù)用的核心和基本單位，具有獨立的功能，是可復(fù)用的軟件組成部分，可供第三方進行軟件組裝。構(gòu)件可以是被封裝的對象類、類樹、功能模塊、軟件框架、軟件構(gòu)架(或體系結(jié)構(gòu))、文檔、分析件、設(shè)計模式等。基于構(gòu)件的軟件開發(fā)與傳統(tǒng)的軟件開發(fā)相比，基于構(gòu)件的軟件開發(fā)強調(diào)使用軟件構(gòu)件對軟件系統(tǒng)進行設(shè)計開發(fā)。基于構(gòu)件的軟件開發(fā)方法需要有相應(yīng)的軟件開發(fā)過程作為基礎(chǔ)，否則，就不會有與該系統(tǒng)相符合的質(zhì)量特性要求的軟件構(gòu)件。

2.3軟件復(fù)用的優(yōu)點

（1）改善軟件質(zhì)量：經(jīng)過測試以及經(jīng)過實踐的軟件往往缺陷更少。（2）降低開發(fā)風(fēng)險：開發(fā)新的組件，如果測試不夠充分，輕則有效性不高，重則可能是造成軟件失敗的原因。（3）支持快速原型開發(fā)：快速構(gòu)建實用可操作系統(tǒng)模型，憑借其與用戶進行有效溝通，最終獲得用戶有效意見反饋。（4）提高軟件開發(fā)效率，縮短軟件開發(fā)周期，從而降低軟件開發(fā)成本。

3軟件復(fù)用在測控軟件開發(fā)中的應(yīng)用

近年來，隨著任務(wù)數(shù)量的增多，測控軟件的開發(fā)團隊越來越小，軟件開發(fā)周期越來越短，軟件的研制要求卻不斷的提高；隨著衛(wèi)星工作模式的增加，地面接收設(shè)備也需增加相應(yīng)的工作模式完成相應(yīng)的接收任務(wù)。因此，測控軟件不但需要完成原有工作模式的監(jiān)控管理功能，還需完成新增工作模式的監(jiān)控管理功能。測控軟件必須有效繼承原有成熟的計劃管理、自動標(biāo)校/測試及自動運行管理技術(shù)，同時需要開發(fā)適合新增工作模式的計劃管理、自動標(biāo)校/測試及自動運行管理技術(shù)，并且要為后續(xù)其它型號軟件提供高效的功能繼承。基于軟件復(fù)用技術(shù)的測控軟件開發(fā)，使用大量的已經(jīng)過驗證的高效軟件，對傳統(tǒng)瀑布模型的各個研制階段的產(chǎn)品（如需求分析、軟件設(shè)計、軟件編碼、軟件測試）進行優(yōu)化和簡化，節(jié)省了人力和時間，提高了軟件的可靠性，降低了軟件成本和開發(fā)周期。在軟件的研制過程中，需要對軟件的復(fù)用架構(gòu)進行設(shè)計，對可復(fù)用的構(gòu)件進行適應(yīng)性修改設(shè)計以適應(yīng)新的軟件需求，還需對新研的部件進行軟件設(shè)計。測控軟件對原有成熟的設(shè)備監(jiān)控、計劃管理、自動標(biāo)校/測試及自動運行管理功能的繼承，就成為軟件的復(fù)用的內(nèi)容。其中包括四個階段的復(fù)用：需求復(fù)用、設(shè)計復(fù)用、代碼復(fù)用、測試復(fù)用。

3.1需求復(fù)用

測控軟件的變更原因主要有兩種：（1）用戶需求變更。（2）軟件自身技術(shù)升級。其中，用戶需求變更是導(dǎo)致軟件變更的首要因素；軟件技術(shù)升級的部分工作往往也是為了更好的適應(yīng)用戶的需求。首先，同類任務(wù)的需求是逐漸增加的，并且有一定的可繼承性，當(dāng)增加新的需求時，已驗證過的任務(wù)需求即可成為后續(xù)任務(wù)需求的可復(fù)用的構(gòu)件。其次，不同的測控任務(wù)需求之間同樣存在相同或相似的元素。例如，任何一個任務(wù)都有相同或相似的任務(wù)流程；根據(jù)工作計劃及自動運行策略進行站前標(biāo)校、任務(wù)宏配置、啟動自動運行流程；監(jiān)控數(shù)據(jù)的存儲、顯示、查詢等任務(wù)需求存在一定的共性，對其通用的任務(wù)需求，是完全可以復(fù)用或部分復(fù)用的。因此，任務(wù)需求變更與軟件需求變更為因果關(guān)系，直至后續(xù)的各個階段活動都受到任務(wù)需求變更的影響。從需求分析、軟件設(shè)計、軟件編碼直至軟件測試，都會因為任務(wù)需求的變更而必須進行相應(yīng)的更動。

3.2設(shè)計復(fù)用

多年以來，很多任務(wù)的測控軟件都有相同或相似的軟件結(jié)構(gòu)，因此，這一有利條件，在軟件結(jié)構(gòu)設(shè)計時，得到了充分的利用。從軟件復(fù)用的角度來說，在進行軟件結(jié)構(gòu)設(shè)計時，需將軟件中相對穩(wěn)定的部分（如設(shè)備監(jiān)控、數(shù)據(jù)庫管數(shù)據(jù)庫管理、計劃管理、用戶管理）與新增加的部分不僅從結(jié)構(gòu)上分開，而且要求其接口相對單一穩(wěn)定。這樣，從軟件設(shè)計到代碼開發(fā)都可以復(fù)用。

3.3代碼復(fù)用

對程序代碼的復(fù)用，以設(shè)備的監(jiān)控線程為例介紹如下：目前，測控站內(nèi)設(shè)備通過局域網(wǎng)進行通信，各個設(shè)備與測控軟件之間的通信接口都已進行了標(biāo)準(zhǔn)化，因此，對不同設(shè)備的監(jiān)控線程可以進行代碼復(fù)用；如果重新設(shè)計代碼，不但要耗費大量的人力和時間，延長軟件開發(fā)周期，而且重新設(shè)計的代碼必須進行充分的軟件測試，否則難以保證其正確性和健壯性。開發(fā)者使用以往可復(fù)用的程序代碼，或全部吸收或加以優(yōu)化，大大避免了重復(fù)性工作，將精力集中于關(guān)鍵技術(shù)的攻關(guān)，如此設(shè)計更加高效可靠的軟件系統(tǒng)。

3.4測試用例復(fù)用

軟件測試復(fù)用主要包括測試流程的復(fù)用、測試方法的復(fù)用和測試用例的復(fù)用。其中，測試用例的復(fù)用是測試復(fù)用中的關(guān)鍵技術(shù)。測試用例的復(fù)用對于縮短軟件的開發(fā)周期和降低軟件開發(fā)成本具有極其重要的意義。

4結(jié)束語