如何對待軟件項目的需求變更

沈鑫

摘要：一旦提到軟件開發(fā)項目進程中的需求變更，無論是項目經(jīng)理還是程序開發(fā)人員都感覺到頭疼。而且，在一些軟件項目管理的技術(shù)圖書和教程中，也把“需求變更”作為單獨的一項來研究。本文中，與您共同探討軟件開發(fā)項目中的需求變更發(fā)生的原因、需求變更控制，以及當發(fā)生需求變更的時候如何應(yīng)對解決。

【關(guān)鍵詞】軟件項目 需求變更 可行性分析信息化

1 關(guān)于需求變更的認識

需求通過評審就確定了本次軟件開發(fā)需實現(xiàn)的功能，到系統(tǒng)設(shè)計完成上線使用，除特殊情況外需求不再做任何改動。如果業(yè)務(wù)部門在項目建設(shè)過程中提出需求變更，會給項目帶來巨大的風險，導(dǎo)致項目的成本增加、開發(fā)周期延長、產(chǎn)品質(zhì)量下降及團隊工作效率下降，更會打亂軟件設(shè)計整體結(jié)構(gòu)，使程序難以理解和維護，更會給軟件承建單位帶來難以接受的打擊，因而需求變更應(yīng)該盡量避免。

好比在建造房屋時，原來設(shè)計的開間為3.6米。房屋建造到一半時，業(yè)主覺得開間小了點，要改為3.8米，對于業(yè)主來說，開間從3.6米變化到3.8米，變化僅為0.2米，變化不大，但真要實現(xiàn)這種變更，房屋可能要拆掉重建。

軟件的基礎(chǔ)是需求，需求變更后數(shù)據(jù)庫、程序設(shè)計、編碼等都需要重新設(shè)計，嚴重的甚至會推翻原來所作的一切工作。只有在一些特殊情況下，才能進行需求變更。

2 必須進行需求變更的情況

（1）國家相關(guān)政策的出臺，新政策對業(yè)務(wù)部門的工作流程提出了新的變化要求。

（2）由于業(yè)務(wù)部門組織機構(gòu)的調(diào)整，在行政管理上進行組織機構(gòu)調(diào)整，各個業(yè)務(wù)部門的行政職能也勢必調(diào)整，業(yè)務(wù)流程也會隨之調(diào)整。

（3）由于需求階段工作產(chǎn)生了嚴重問題，開發(fā)的系統(tǒng)達不到業(yè)務(wù)管理要求，必須要進行需求變更。

（4）上級部門的數(shù)據(jù)規(guī)范性要求，對數(shù)據(jù)、表單、報表提出了新的要求。

3 對需求變更的理解

（1）由于需求變更會大大的影響到軟件開發(fā)的進度、成本、質(zhì)量等諸多因素，所以必須明確變更的原因以及責任。

（2）變更的原因只能是以上所述的一些特殊情況，一般情況下應(yīng)盡量避免變更。

（3）軟件的需求變更也是一項復(fù)雜工作，業(yè)務(wù)部門、信息中心、軟件承建單位都將參與到其中，承擔各自的責任。

（4）業(yè)務(wù)部門是需求變更的主要責任部門，需求為什么要變，要變成什么樣都是由業(yè)務(wù)部門提出。

4 需求變更的各方工作流程

軟件承建單位負責參與需求變更可行性分析，根據(jù)業(yè)務(wù)部門提出的變更，用符合計算機規(guī)格的形式表現(xiàn)出來，比如變更需要系統(tǒng)調(diào)整的具體描述，涉及的模塊極其調(diào)整內(nèi)容，修改的數(shù)據(jù)庫（表，字段），修改的程序文件修改的其他文件和數(shù)據(jù)、報表等等。

信息中心負責的是組織軟件承建單位和相關(guān)業(yè)務(wù)人員進行可行性分析研究，完成《需求變更實施可行性分析報告》，并組織有關(guān)專家進行“需求變更可行性評審”。

在問題的考慮上要盡可能全面，業(yè)務(wù)部門應(yīng)該充分考慮是否必須進行需求變更。如果目前的系統(tǒng)并不影響業(yè)務(wù)的正常辦理，就應(yīng)該在系統(tǒng)日后進行升級改造時一并提出。比如：報表更換格式、附加表單等等，這些都可以在系統(tǒng)進行升級改造時考慮，而不需要以需求變更的形式提出來。

如果是影響業(yè)務(wù)正常辦理的變更，例如：上級部門對工作流程有了新的要求，并要求立即執(zhí)行，在這種情況下應(yīng)由申請業(yè)務(wù)部門填寫《需求變更申請表》，并報本部門分管局領(lǐng)導(dǎo)批準后提交信息中心。內(nèi)容包括：新增、變更需求調(diào)整內(nèi)容，需求變更原因，期望完成時間，申請部門負責人意見等。

最后， 由信息中心組織完成《需求變更實施可行性分析報告>，并組織有關(guān)專家進行“需求變更可行性評審”。

信息中心對需求和系統(tǒng)情況作初步識別和分析后，組織軟件承建單位和相關(guān)業(yè)務(wù)人員進一步進行可行性分析研究，形成《需求變更實施可行性分析報告》。內(nèi)容包括：需求變更是否影響系統(tǒng)架構(gòu)的設(shè)計、需求變更所引起的工作量的變化、需求變更是否與原有其他業(yè)務(wù)流程有沖突、實施的難易程度、優(yōu)先等級如何、對進度的影響等等。

5 需求變更評審

信息中心組織專家召開需求變更評審會議。需求變更評審會議由軟件承建單位、業(yè)務(wù)部門和信息中心共同參與。必須有業(yè)務(wù)部門負責人、本部門分管領(lǐng)導(dǎo)參加，要求業(yè)務(wù)部門負責人和分管領(lǐng)導(dǎo)仔細閱讀《需求變更實施可行性分析報告》，并簽署意見，最終各方意見要達成一致，明確該變更實施還是不實施。評審結(jié)束應(yīng)有軟件承建單位、業(yè)務(wù)部門、分管領(lǐng)導(dǎo)的結(jié)論意見及簽字。

需求變更實施可行性評審的結(jié)論可以是以下三種：

（1）需求可變可不變，那就可以暫不考慮：

（2）需求變更影響到正常辦理業(yè)務(wù)，必須要變，但與原來開發(fā)思路有較大差異，會打亂整體軟件架構(gòu)，使得其他功能也受影響，會導(dǎo)致無法使用，那么這樣的需求變更也不能實施；

（3）需求變更影響到正常辦理業(yè)務(wù)，必須要變，經(jīng)過評審，各方也一致認為該變更可以實施；那么就由信息中心開始組織進行需求變更的具體工作。

6 需求變更的注意點

6.1 在軟件通過評審后開始需求變更，意味著成本投入增加

一般來講，需求的變更通常意味著需求的增加。當業(yè)務(wù)部門提出新需求的時候，軟件承建單位項目開發(fā)人員會分析這些新需求對項目現(xiàn)階段帶來的風險，得出實現(xiàn)變更需求需要的成本，包括時間、人力、資源等等方面，再與業(yè)務(wù)部門和信息中心商討是否有必要進行變更和如何在最小代價下實現(xiàn)變更。

6.2 任何需求變更都需要經(jīng)過業(yè)務(wù)部門負責人、業(yè)務(wù)分管局領(lǐng)導(dǎo)的認可，業(yè)務(wù)部門需慎重地對待需求的變更，變更需要重新簽訂合同

當業(yè)務(wù)部門確實希望進行需求變更時，可以讓軟件承建單位開發(fā)一個快速原型系統(tǒng)，讓業(yè)務(wù)操作人員體驗一下，以確認確實希望添加這些需求。在《需求變更實施可行性分析報告》通過評審后，軟件承建單位需要與信息中心簽訂一份新的合同。

6.3 在項目的不同階段對待需求變更的態(tài)度是不同的

如果在項目的需求調(diào)研階段（需求評審之前）提出需求變更，軟件承建單位會積極配合用戶進行變更，并及時合并到需求說明書中。業(yè)務(wù)部門需要注意溝通技巧，盡可能的將需求變更控制在需求階段。但是，一旦項目通過需求評審后，業(yè)務(wù)部門再提出需求變更，軟件承建單位就會對變更進行詳盡的評估。

7 需求變更實施要分優(yōu)先級

在對需求變更進行分析時，業(yè)務(wù)部門應(yīng)對變更的實施有一個時間進度上的規(guī)劃。針對那些對系統(tǒng)影響不大和一些優(yōu)先權(quán)十分高的需求變更可以立即要求在項目中實施，而對于那些對于整個系統(tǒng)現(xiàn)階段的開發(fā)影響很大，而且又不是十分緊急的需求可以放在軟件的下一個版本中進行。無論是立即實施還是放在下一個版本中，都應(yīng)該給新的需求一個充足的開發(fā)和測試時間，保證產(chǎn)品質(zhì)量。

參考文獻

[1]王莉，吳潔明.軟件項目中的需求變更管理的研究[J].計算機技術(shù)與發(fā)展，2007，17 （01）：119-122.