一、問題的提出
什么是需求分析？
要知道需求變更是什么，首先要知道什么是需求分析。
需求分析是指理解客戶需求，就軟件功能與客戶達(dá)成一致，估計(jì)軟件風(fēng)險(xiǎn)和評(píng)估項(xiàng)目成本代價(jià)，最終形成開發(fā)計(jì)劃的一個(gè)復(fù)雜過程。需求分析的成果形成需求說明書。
什么是需求變更？
根據(jù)軟件工程思想定義，需求說明書一般要經(jīng)過論證，如果在需求說明書經(jīng)過論證以后，需要在原有需求基礎(chǔ)上追加和補(bǔ)充新的需求，或?qū)υ行枨筮M(jìn)行修改和削減，均屬于需求變更。
二、需求變更的原因及影響
1、需求變更原因
一方面是用戶：他們是項(xiàng)目需求的提出者。一個(gè)十分常見的現(xiàn)象是用戶提出需求以后，在軟件開發(fā)過程中用戶改變了需求，這只能迫使開發(fā)工作返工，丟棄一些無法修正的部分。無疑這會(huì)造成一定的損失，但又無法完全避免。要求用戶一次性把需求講清楚，并且不允許此后需求有任何變更，這是不現(xiàn)實(shí)的。只能盡量減少需求變更，降低它所造成的影響。
二是系統(tǒng)因素：在系統(tǒng)內(nèi)部，如計(jì)算機(jī)硬件、系統(tǒng)軟件或數(shù)據(jù)的變更要求與其相適應(yīng)。
三是外部環(huán)境因素：與軟件運(yùn)行相關(guān)的工作制度或法規(guī)、政策的變更，或是業(yè)務(wù)要求變更導(dǎo)致的需求變更。
四是需求分析階段工作缺陷：需求調(diào)研、分析、定義和評(píng)審工作不夠充分，致使需求規(guī)格說明中隱含著問題，在開發(fā)過程中才有所發(fā)現(xiàn)?；蛘咝枨箝_發(fā)中開發(fā)人員與用戶溝通不夠充分，如未能如實(shí)獲得用戶的潛在需求等。
軟件需求一旦出現(xiàn)變更，它可能要涉及到一些相關(guān)的代碼和文檔的修改，為此要把這一變更通知到所有相關(guān)人員。提出需求變更有可能在開發(fā)的任何階段，并且隨著項(xiàng)目的進(jìn)展，越晚的需求變更引起的損失越大。
2、需求變更給軟件的開發(fā)工作帶來的影響
需求變更對(duì)軟件開發(fā)的影響是多方面的，概括的看，包括以下三個(gè)方面：
（1）增加項(xiàng)目的人員、費(fèi)用開支，影響開發(fā)進(jìn)度。需求變意味著原先的需求調(diào)研、分析的結(jié)果與預(yù)期的軟件實(shí)現(xiàn)存在偏差，需要進(jìn)行需求變更。這無疑要增加項(xiàng)目的人員、費(fèi)用的開支，并對(duì)開發(fā)進(jìn)度造成影響。更有甚者，如果變更頻繁，可能對(duì)項(xiàng)目造成較大影響，嚴(yán)重時(shí)可能直接導(dǎo)致項(xiàng)目的失敗。
（2）影響軟件質(zhì)量。在一個(gè)復(fù)雜的軟件系統(tǒng)中，需求之間具有一定的聯(lián)系，相關(guān)需求可構(gòu)成需求鏈。如果由于需求變更導(dǎo)致需求鏈的某些環(huán)節(jié)脫節(jié)，就可能引起一些難以察覺的錯(cuò)誤。當(dāng)需求變更沒能及時(shí)修改項(xiàng)目的設(shè)計(jì)、開發(fā)文檔時(shí)，這些錯(cuò)誤一般難以被測(cè)試人員發(fā)現(xiàn)，將直接影響系統(tǒng)質(zhì)量，嚴(yán)重時(shí)可導(dǎo)致系統(tǒng)崩潰。
（3）影響開發(fā)者與用戶之間的合作關(guān)系。需求變更的實(shí)施是用戶和開發(fā)者相互協(xié)作的過程。開發(fā)者和用戶在是否采用變更問題上常常產(chǎn)生分歧，如果沒有恰當(dāng)處理，影響雙方的互信，從而影響項(xiàng)目開發(fā)進(jìn)程。同時(shí)需求變更也會(huì)在項(xiàng)目開發(fā)人員之間產(chǎn)生分歧，影響合作關(guān)系。
三、采取的對(duì)策
1、首先是預(yù)防
盡量做好需求分析工作，以期減少需求變更的頻次，為此在需求分析階段著重處理好以下問題，力圖使需求分析的結(jié)果更接近目標(biāo)。
（1）培養(yǎng)正確的需求意識(shí)。優(yōu)秀軟件產(chǎn)品建立在優(yōu)秀的需求基礎(chǔ)之上，而高質(zhì)量的需求又來源于客戶與開發(fā)人員之間有效的交流與合作。因此，雙方的參與者都需要認(rèn)識(shí)到：要想獲得成功，自己需要什么，合作方又需要什么。只有這樣，才能建立融洽的合作關(guān)系。因此，培養(yǎng)正確的需求意識(shí)是雙方都需要努力的，而開發(fā)人員在這個(gè)階段應(yīng)該發(fā)揮更加積極主動(dòng)的作用。
首先，需求分析人員應(yīng)該接受一定的正規(guī)培訓(xùn)，以提高與人溝通的能力、緩解矛盾的能力、善于傾聽和詢問的技巧，以及收集整理資料的能力等。在參與具體項(xiàng)目時(shí)，分析人員也應(yīng)主動(dòng)學(xué)習(xí)一些項(xiàng)目所涉及的具體應(yīng)用領(lǐng)域的基本知識(shí)，以更好地理解用戶的需求。
其次，開發(fā)單位應(yīng)該對(duì)那些不想花時(shí)間在需求分析上的用戶明確指出：如果用戶不能充分地支持并參與，項(xiàng)目很可能會(huì)失敗；開發(fā)單位還可以通過學(xué)習(xí)一些前車之鑒的真實(shí)案例警告用戶：低質(zhì)量的需求分析可能導(dǎo)致嚴(yán)重的后果。通過對(duì)用戶代表和管理人員的培訓(xùn)，使他們真正理解需求分析的重要性和忽略需求帶來的風(fēng)險(xiǎn)，并對(duì)計(jì)算機(jī)系統(tǒng)有一個(gè)大體的了解，這樣用戶才能夠主動(dòng)地參與需求分析。
同時(shí)，正因?yàn)椴豢赡芤淮尉屯耆私庥脩舻男枨螅以谙到y(tǒng)開發(fā)過程中還需要不斷地請(qǐng)用戶參與，因此與用戶的溝通是需要貫穿始終的。需求分析中所采取的一些策略可能會(huì)讓用戶覺得意外和難以接受。因此，需求分析人員需要對(duì)用戶解釋一些做法的必要性和合理性，以得到用戶最大的支持與合作。
（2）從業(yè)務(wù)需求入手。用戶認(rèn)識(shí)到了需求分析的重要性，但可能仍然不知道從何處入手表達(dá)自己的需求。這時(shí)可以從業(yè)務(wù)需求入手，任何企業(yè)對(duì)自己的經(jīng)營運(yùn)作目標(biāo)應(yīng)該是比較清楚的，這樣的經(jīng)營背景讓用戶不僅有話說，也讓開發(fā)者有章可循。需求分析不可以完全與它所處的背景相脫離，只有當(dāng)系統(tǒng)真正置身于它的社會(huì)和組織環(huán)境中，它的需求才能清晰地反映出來。
（3）充分利用需求來源。有了以上需求背景，就比較容易做到有的放矢了。需求分析人員可以直接與系統(tǒng)未來的操作者探討他們希望有什么樣的軟件；觀察系統(tǒng)的潛在用戶當(dāng)前的日常工作以獲取有價(jià)值的信息；系統(tǒng)的使用者可能有很多，可以將他們分類以簡(jiǎn)化需求；最后一定要與真正的決定者達(dá)成協(xié)議：對(duì)于有沖突的需求如何權(quán)衡，對(duì)于直接用戶的眾多需求如何取舍等。
同時(shí)，用戶往往對(duì)計(jì)算機(jī)期望過高，認(rèn)為計(jì)算機(jī)可以解決當(dāng)前存在的所有問題，因此會(huì)提出很多的功能需求，并且希望在很短的時(shí)間內(nèi)看到成效。但是，由于技術(shù)、人力等資源的限制，并不一定能夠在設(shè)定的時(shí)間期限內(nèi)滿足用戶所有的期望，這時(shí)就應(yīng)該盡早確定出交付的產(chǎn)品應(yīng)具備的最重要功能，即設(shè)定需求的優(yōu)先級(jí)。
在這個(gè)階段，可以采用UML中的用例圖幫助用戶和需求分析人員之間的交流。一個(gè)用例圖描述用戶可以用軟件產(chǎn)品執(zhí)行的一個(gè)任務(wù)。它不是從軟件的性能和系統(tǒng)的行為方面出發(fā)，而是從用戶到底能夠用這個(gè)軟件產(chǎn)品干什么入手。這樣的方式用戶比較熟悉，容易溝通；而且不會(huì)在需求分析的一開始就陷入過于細(xì)節(jié)化的設(shè)計(jì)，也有助于避免分析人員添加一些與所需任務(wù)無關(guān)的自認(rèn)為很好的功能。
（4）提供選擇方案。由于用戶對(duì)軟件系統(tǒng)缺乏經(jīng)驗(yàn)，或者由于用戶的運(yùn)作機(jī)制還未完善，或者由于其他種種原因，用戶可能仍然不能對(duì)一些需求做出明確的說明，收集整理的需求中可能仍然存在一些不確定因素。這時(shí)可提出幾份比較詳細(xì)的方案。附帶不同做法的優(yōu)點(diǎn)，供用戶選擇或者啟發(fā)用戶確定需求。
如果需求分析做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費(fèi)。這個(gè)時(shí)候，開發(fā)方一定要據(jù)理力爭(zhēng)，此時(shí)這并非要刻意賺取客戶的錢財(cái)，而是不能讓客戶養(yǎng)成經(jīng)常變更的習(xí)慣，否則后患無窮。
2、分級(jí)管理客戶需求
軟件開發(fā)項(xiàng)目中，“客戶永遠(yuǎn)是對(duì)的”和“客戶是上帝”并不完全的正確，因?yàn)樵谝呀?jīng)簽定的項(xiàng)目合同中，任何新需求的變更和增加除了影響項(xiàng)目的正常進(jìn)行以外，還影響到了客戶的投入收益，所以有的時(shí)候項(xiàng)目經(jīng)理反倒應(yīng)該為客戶著想。
對(duì)于項(xiàng)目中的需求變更，可以實(shí)行分級(jí)管理，以達(dá)到對(duì)需求變更的控制。
一級(jí)需求變更是關(guān)鍵性的需求，這種需求如果不滿足，意味著整個(gè)項(xiàng)目不能正常交付使用，前期工作也會(huì)被全部否定。這個(gè)級(jí)別的需求是必須滿足的，否則就意味著否定自已的項(xiàng)目成員和成員的所有努力，所以定為“Urgent”。
二級(jí)需求變更是后續(xù)關(guān)鍵性需求，它不影響前面工作內(nèi)容的交付，但不加以滿足，新的項(xiàng)目?jī)?nèi)容無法提交或繼續(xù)，所以是“Necessary”。一般新模塊關(guān)鍵性的基礎(chǔ)組件，屬于這個(gè)級(jí)別。
三級(jí)需求是后續(xù)重要的需求，如果不被滿足會(huì)令整體項(xiàng)目工作的價(jià)值下降，為了體現(xiàn)項(xiàng)目?jī)r(jià)值，也是開發(fā)人員自已的技術(shù)價(jià)值的證明，所以定為“Needed”。一般性的重大的有價(jià)值的全新模塊開發(fā)，屬于這個(gè)級(jí)別。
以上三個(gè)等級(jí)是應(yīng)該實(shí)施的，但時(shí)間性上可以作優(yōu)先級(jí)的排列。
四級(jí)需求是改良性需求，沒有滿足這類需求并不影響已有功能的使用，但如果實(shí)現(xiàn)了則會(huì)更好，定級(jí)為“Better”。界面和使用方式的需求，一般在這個(gè)檔次。
五級(jí)需求是可選性需求，更多的是一種設(shè)想，以及一種可能，通常只是客戶的的一種個(gè)人喜好而已，定級(jí)為“Maybe”。
對(duì)于四級(jí)需求，如果時(shí)間和資源條件都允許的話，不妨做下去。對(duì)于五級(jí)需求，正如對(duì)它的描述一樣做與不做是“Maybe”。
3、加強(qiáng)需求變更的控制
在需求分析階段工作完成后，需求變更仍可以會(huì)發(fā)生，因此就要加強(qiáng)對(duì)需求變更的控制，主要有以下原則：
（1）建立需求基線。需求基線是需求變更的依據(jù)。在開發(fā)過程中，需求確定并經(jīng)過評(píng)審后（用戶參與評(píng)審），可以建立第一個(gè)需求基線。此后每次變更并經(jīng)過評(píng)審后，都要重新確定新的需求基線。
（2）制訂簡(jiǎn)單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個(gè)控制流程進(jìn)行控制。同時(shí)，這個(gè)流程具有一定的普遍性，對(duì)以后的項(xiàng)目開發(fā)和其他項(xiàng)目都有借鑒作用。
（3）成立項(xiàng)目變更控制委員會(huì)（CCB）或相關(guān)職能的類似組織，負(fù)責(zé)裁定接受哪些變更。CCB由項(xiàng)目所涉及的多方人員共同組成，應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。
（4）需求變更一定要先申請(qǐng)然后再評(píng)估，最后經(jīng)過與變更大小相當(dāng)級(jí)別的評(píng)審確認(rèn)。
（5）需求變更后，受影響的軟件計(jì)劃、產(chǎn)品、活動(dòng)都要進(jìn)行相應(yīng)的變更，以保持和更新的需求一致。
（6）妥善保存變更產(chǎn)生的相關(guān)文檔。
這六大原則看起來簡(jiǎn)單，但真正實(shí)施起來有難度，還需要依據(jù)理論知識(shí)配合開發(fā)項(xiàng)目組的實(shí)際工作情況，在實(shí)踐中不斷摸索總結(jié)。
四、總結(jié)
軟件項(xiàng)目的需求變更是對(duì)軟件產(chǎn)品的質(zhì)量、成本、工期帶來巨大的影響。通過預(yù)防性措施和加強(qiáng)需求變更的控制與管理，將需求變更的頻次大幅度降低，從而為軟件項(xiàng)目的順利實(shí)施打下堅(jiān)實(shí)基礎(chǔ)。
400 186 1886
