需求變更管理

在 MES 實施過程中，負責人一方面要好需求的實現(xiàn)，另一個工作重點就是要控制好需求的變更，尤其是在系統(tǒng)上線的前后，業(yè)務部門會提出五花八門的變更需求出來，這時候項目負責人要堅信的理念是：“此時的 80％以上的需求變更是可以不用響應的（注意是響應，不是理會）。”原因何在？

此時業(yè)務部門所提出的需求所產(chǎn)生的原因往往集中在以下幾方面：

• 對軟件操作不熟悉。

• 操作模式同之前的有較大的區(qū)別

• 業(yè)務流程還未理順，尤其是部門之間的銜接還不順暢

• 相關的基礎數(shù)據(jù)不完善，甚至有錯誤的地方

• 出于部門利益的考慮（尤其是初期的數(shù)據(jù)錄入等環(huán)節(jié)）

因此要灌輸?shù)乃枷胧牵骸跋裙袒賰?yōu)化“先強力推進應用，即便有問題也要用（很多企

業(yè)往往會在這出問題），但同時對業(yè)務部門所提出的需求也不是不理會（這樣會喪失員工的積極性，根基會虛，對未來的實施應用帶來影響），而是要認真的處理。

處理的原則就是：收集，整理，分類，處理。

• 收集：要廣開問題及需求獲取的渠道，認真地聽。

• 整理：對所收集的問題，認真地整理，形成清晰的需求（這點非常重要）。

• 分類：對問題進行分類，通常可以分為不響應，暫時不響應，響應等。

• 處理：對不同分類的問題，采取不同的處理原則。

如果是涉及到上面所提到的:

“對軟件操作不熟悉”等原因的需求，可以不響應，但要做好說明和培訓工作;

對于的確是需求的問題，但不涉及全局工作的，可暫時不響應（但對提出者要給予鼓勵，說明將在后續(xù)的工作中給予響應）;

對于影響了企業(yè)全局工作或影響實施效果的工作，經(jīng)過判斷，要響應的，需要同實施方共同提出響應意見。

經(jīng)過以上的處理原則，可以對需求變更進行較為合理的控制。但要做到這點，負責人除

了做好內部溝通外還要做好外部溝通。

當系統(tǒng)運行半年左右，項目負責人應結合業(yè)務應用的情況，對之前所提的變更需求進行徹底的分析，提出真正的變革需求。因為此時業(yè)務部門對 MES 系統(tǒng)有了一個熟悉的過程，對操作，流程等已經(jīng)比較熟悉，此時所提出的變更是相對客觀的，富于建設性的。

需求變更及對策

一、問題的提出

什么是需求分析？

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

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

什么是需求變更？

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

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

1、需求變更原因

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

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

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

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

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

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

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

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

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

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

三、采取的對策

1、首先是預防

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

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

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

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

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

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

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

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

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

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

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

2、分級管理客戶需求

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

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

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

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

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

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

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

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

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

3、加強需求變更的控制

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

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

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

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

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

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

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

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

四、總結

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