沈鑫

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

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

1 關(guān)于需求變更的認(rèn)識(shí)

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

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

軟件的基礎(chǔ)是需求，需求變更后數(shù)據(jù)庫、程序設(shè)計(jì)、編碼等都需要重新設(shè)計(jì)，嚴(yán)重的甚至?xí)品瓉硭鞯囊磺泄ぷ?。只有在一些特殊情況下，才能進(jìn)行需求變更。

2 必須進(jìn)行需求變更的情況

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

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

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

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

3 對(duì)需求變更的理解

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

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

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

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

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

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

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

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

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

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

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

5 需求變更評(píng)審

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

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

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

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

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

6 需求變更的注意點(diǎn)

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

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

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

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

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

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

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

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

參考文獻(xiàn)

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