[摘 要] 需求分析是軟件生命周期中的重要階段，決定軟件項目的成敗;需求變更會嚴(yán)重影響軟件項目的質(zhì)量、成本和工期。本文分析了需求變更的原因和影響，并給出了對需求變更進(jìn)行有效控制的對策。

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

一、問題的提出

什么是需求分析?

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

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

什么是需求變更?

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

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

1.需求變更原因

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

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

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

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

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

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

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

(1)增加項目的人員、費(fèi)用開支，影響開發(fā)進(jìn)度。需求變意味著原先的需求調(diào)研、分析的結(jié)果與預(yù)期的軟件實現(xiàn)存在偏差，需要進(jìn)行需求變更。這無疑要增加項目的人員、費(fèi)用的開支，并對開發(fā)進(jìn)度造成影響。更有甚者，如果變更頻繁，可能對項目造成較大影響，嚴(yán)重時可能直接導(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ì)量，嚴(yán)重時可導(dǎo)致系統(tǒng)崩潰。

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

三、采取的對策

1.首先是預(yù)防

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

(1)培養(yǎng)正確的需求意識。優(yōu)秀軟件產(chǎn)品建立在優(yōu)秀的需求基礎(chǔ)之上，而高質(zhì)量的需求又來源于客戶與開發(fā)人員之間有效的交流與合作。因此，雙方的參與者都需要認(rèn)識到:要想獲得成功，自己需要什么，合作方又需要什么。只有這樣，才能建立融洽的合作關(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)致嚴(yán)重的后果。通過對用戶代表和管理人員的培訓(xùn)，使他們真正理解需求分析的重要性和忽略需求帶來的風(fēng)險，并對計算機(jī)系統(tǒng)有一個大體的了解，這樣用戶才能夠主動地參與需求分析。

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

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

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

同時，用戶往往對計算機(jī)期望過高，認(rèn)為計算機(jī)可以解決當(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)品干什么入手。這樣的方式用戶比較熟悉，容易溝通;而且不會在需求分析的一開始就陷入過于細(xì)節(jié)化的設(shè)計，也有助于避免分析人員添加一些與所需任務(wù)無關(guān)的自認(rèn)為很好的功能。

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

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

2.分級管理客戶需求

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

對于項目中的需求變更，可以實行分級管理，以達(dá)到對需求變更的控制。

一級需求變更是關(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.加強(qiáng)需求變更的控制

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

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

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

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

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

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

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

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

四、總結(jié)

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

參考文獻(xiàn):

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

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

[3]李師賢 張珞玲:需求分析的常見問題及其對策分析[J].計算機(jī)工程，2002，28(1):7～8

[4]小 莊:軟件開發(fā)項目中的需求變更分析和解決之道[EB/OL].http://www.mypm.net/articles/show_article_content.asp?articleID=11472pageNO=1，2007～6～28