改進的軟件需求變更模型

王曉 張春海

摘 要：針對軟件需求變更的不確定性，從團隊自身因素與客戶因素兩方面出發，分析軟件項目開發過程中發生需求變更的主要原因。通過對多家公司及團隊的研究，比較多個需求變更模型，并比較不同模型對項目開發工作量的影響，得出最優需求變更模型。該模型具有文檔體現完整、開發與管理同步、后期維護成本低等特點。

關鍵詞：需求變更模型;軟件需求;項目管理

DOI：10. 11907/rjdk. 181669

中圖分類號：TP3-05文獻標識碼：A文章編號：1672-7800（2019）001-0051-05

Abstract： In view of the uncertainty of software requirement changes， this paper analyzes the main reasons for the changes of demand in the process of software project development from two aspects of team factors and customer factors. Through the study of a number of companies and teams， a number of demand change models are compared， the effects of different models on the project development work are compared， and the optimal requirement change model is obtained. This model has the characteristics of integrity of the document， synchronization of development and management and low maintenance cost.

0 引言

“項目的開始就代表需求變更的開始。”這句話直接表明在軟件開發工程中，需求變更是無法避免的。需求變更在軟件設計、編碼、測試甚至維護階段不斷出現，既會對開發效率與上線時間產生重大影響，也產生了很多無用工作量，而且在需求變更過程中，軟件的品質、成本也隨之變化。為了保證項目的順利完成，需要采取有效方法對項目變更進行管理，以減少需求變更帶來的工作量，因此首先必須對需求變更因素與應對措施進行研究。目前已提出很多需求工程方法[1-2]，在軟件能力成熟度集成模型（CMMI）中曾提出需求變更管理方法，其后一段時間，許多人在此基礎上改進了需求變更度量[3]并不斷加以完善，各軟件企業也開發出適合自己的需求變更框架。然而根據統計，中小IT企業的項目失敗率高達80%，這與企業未做好項目管理有著直接關系，其中項目需求變更是導致中小企業項目管理工作失敗的重要原因之一[4]。通過深入企業調研，發現多數企業需求變更的框架文檔不夠完善，甚至出現企業因文檔問題影響交付品質的情況。采納或拒絕針對項目需求的變更請求是變更控制委員會（CCB）的職責，項目管理工程研究領域普遍認為成立變更控制委員會是控制變更最好的策略之一[5]。Cooper 等[6]專家基于依賴控制和數據依賴的模型圖對軟件需求變更進行研究與分析，以分析需求變更帶來的影響。因為需求變更與軟件生命周期結合緊密，為了將軟件各個生命周期與需求變更整合起來，從而提高軟件開發效率，減少不必要的工作量，并且提高軟件交付質量，設計了需求變更框架。然而現有軟件需求變更模型仍存在一些缺陷，比如有的軟件需求變更可能導致工作量增加，或降低了軟件交付品質。如何在需求變更時既不用增加太多開發工作量，又可以保證軟件質量，是一個亟待解決的問題。因此，設計一個需求變更管理與開發并行的同步型軟件需求變更模型是十分必要的。

1 軟件開發及需求變更關系

1.1 軟件開發階段

項目一旦啟動，則進入軟件開發生命周期。軟件項目生命周期分為：可行性分析、需求分析、概要設計、詳細設計、編碼、測試、維護7個階段。根據其不同的生命周期模型，又分為瀑布模型、V模型、原型化模型以及迭代模型等開發模型。軟件生命周期模型的出現始于W Royce在1970年發表的瀑布模型，使人們開始從更高視角審視軟件開發活動[7-8]。然而實際的軟件項目開發并不是一帆風順的，項目需求變更穿插于生命周期的每一個環節。軟件開發需要嚴格按照流程實施，并對需求變更流程路線進行統一規范[9]。

1.2 理論論述

IEEE（電氣和電子工程師協會）定義軟件需求為：①為了讓客戶完成某項功能或處理某個難題而必須具有的能力;②為了讓系統能夠符合某一標準或達到合同要求而必須具備的功能[10]。

1.3 需求變更

需求變更又稱為需求變動，是指在與客戶簽訂了項目或軟件開發協議后，在完成交付之前，客戶提出對項目或軟件功能及非功能性的更改要求。需求最顯著的特點是“隨著項目而改變，隨著項目進展而漸進明晰”，可以看出需求管理與項目管理一樣，存在于項目整個生命周期中[11]。

1.4 需求變更與軟件生命周期關系

需求變更與軟件生命周期存在密不可分的聯系，如圖1所示。當需求分析完成后，需求變更便貫穿于后續每一個環節，大到項目架構設計，小到編碼實現，都可能發生變更。由于所處外界環境及客戶需求的不確定性，當一個軟件需求發生變更時，可能會給軟件開發人員帶來較大工作量。另一方面由于需求變更的模糊性，也可能導致最后開發的軟件質量不符合用戶要求。因此，如何評估并減少變更對工作的影響，既是對項目經理管理層面的挑戰，也關系到項目能否按時交付。

1.5 需求變更與用戶滿意度關系

需求變更與用戶滿意度關系來自于KANO模型，該模型是東京理工大學教授狩野紀昭（Noriaki Kano）發明的可對用戶需求進行分類與優先排序的有用工具，體現了產品性能與用戶滿意度之間的非線性關系。其主要是從顧客角度認識產品或服務需要，首先需要滿足的是顧客最基本的需求，即第四象限的“當然質量”，因為這些需求是顧客認為必須達到的;其次需要盡力滿足客戶的“期望質量”，即第一象限，這是質量的競爭性因素;最后為了提升客戶忠誠度，需要爭取實現第二象限的“迷人質量”。

2 需求變更因素分析

當變更發生時，首先要詢問相關開發人員，綜合評定變更的影響，其次設計對應方案并對其進行工作量評估，最后根據設計方案進行開發工作。本文提出在項目開發中影響需求變更工作量的兩個因素：自身因素與客戶因素。

2.1 自身因素

2.1.1 團隊專業性

專業素質表現在編碼與設計方面。作為一個專業軟件開發人員，在軟件項目開發過程中，應該了解項目所處行業環境，關注行業動態，從而能夠準確獲取或描述客戶需求，對于客戶的大致需求可以從多個角度給出設計方案[12]，并且對后期可能存在的需求變更預留接口。此外，軟件設計人員需及時與客戶溝通，從客戶角度出發，了解對方需求中的專業術語，使團隊具備較強執行力。

2.1.2 文檔完整性

一套專業、系統的文檔，不但有益于邏輯梳理以及與客戶的溝通交流，而且在出現需求變更時，能夠準確把握需求變更點，從而大大提高工作效率。軟件開發人員在需求變更不確定的情況下，通過閱讀完整文檔，能夠更深入地了解客戶需求、節省開發時間。因此，當需求發生變更時，應及時更新文檔，以有效保障項目品質。

2.1.3 編碼規范性

程序代碼風格的規范性，對于后期需求變更的開發效率也有著很大影響。規范的編碼風格，使代碼具有很高的可閱讀性，降低了不同開發人員之間的溝通障礙。當文檔與代碼可以一一對應，即使開發者中途離開項目組，繼任者通過對應關系，也可以很快進行定位，節省了瀏覽業務邏輯的時間，提高了代碼的可擴展性、可閱讀性與可維護性。規范的編碼風格對于排查需求變更點可提供很大便利，從而當需求發生變更時能夠盡量降低對現有開發功能的影響，并且有效降低軟件開發人員工作量。

2.2 客戶因素

2.2.1 客戶業務素質

客戶業務素質是影響軟件需求變更的重要因素[13]。對于客戶而言，業務素質主要體現在對專業詞匯的表達及期望業務需求的描述方面。其中由于部分專業詞匯的使用可能非常頻繁，因此對于需求初始的定位與設計而言，保證初始需求的完整性以及與客戶溝通的及時性，會使需求變更發生的可能性大大降低。

2.2.2 提出時間

軟件需求變更提出時間對需求變更工作也有著很大影響。例如：2016年開發了一套SAP系統，2017年進入測試階段時發現已測試的A模塊業務需求與現實業務不符，想要對該模塊進行修改，時隔一年之久進行修改與剛開發一個月時即進行修改，其工作量相差甚遠。

2.2.3 修改位置

在軟件開發過程中，項目設計為項目架構部分，然后根據設計進行編碼。如果客戶提出的需求變更位置位于架構部分，將可能對項目整體設計帶來重大影響。

3 常見需求變更模型

3.1 執行優先性模型

當客戶提出需求變更時，可根據執行優先性模型對變更進行評估，確定設計方案，然后指派人員執行。

此時的評估變更審核是對工作量及可行性的評審，因為一旦需求發生變更，往往需要對原有進度進行重估，并修改設計、重寫代碼、修改測試用例、調整項目計劃等，從而影響整個項目完成時間、質量及成本等多個要素。如果對當前項目影響過大，則會駁回變更或與客戶方面協商解決方案。審核變更不僅僅是同意或駁回，更是對項目的整體把握，并進一步確定合同范圍。因此，該模型只適用于小型項目，由于缺乏明確的文檔管理，無法對客戶需求進行追蹤記錄。如果項目體積過大或需求變更頻繁，則需要開發人員重復閱讀與修改既定代碼，從而增加了工作量，并影響開發進度。如果審核環節控制不好，還會導致項目進度延遲、質量不過關及成本嚴重超支等諸多問題，甚至可能因變更過多產生分歧導致項目半途而廢。因此，需要使用拓展性強、性價比高的需求管理系統對需求管理流程進行固化[14]。

3.2 書面說明性模型

因執行優先性模型對于需求變更管理不夠嚴格，因此出現了書面說明性需求變更模型，如圖4所示。該模型詳細記錄了變更發生后對項目的分析、評估過程，并生成文檔加以保存。

當客戶提出需求變更時，首先需要提出《需求變更說明書》，然后由產品經理配合書面化《需求分析說明書》，評估需求變更的影響，形成“兩表一書”，并由需求變更控制委員會進行審核。若審核通過，則對產品進行修改及測試，驗證變更效果。該模型可對變更需求進行書面化約束，以方便對項目的管理，但在需求分析說明書完成后，無法及時與客戶再次確認變更內容，可能造成對產品修改不夠準確的情況。由于需求變更可能經常發生，即使與客戶確認變更內容之后，客戶仍有可能再次改變需求。如果每次發生需求變更時，項目人員都需要提交變更申請，再對變更需求進行分析、估算與審批，則會嚴重影響項目進度。而且每次提出需求變更的緊迫性不同，如果按照客戶提出的變更順序進行項目修改，勢必會影響項目總體規劃及進度，增加開發人員工作量。

4 新的需求變更模型——同步型需求變更模型

針對上述需求變更模型存在的缺點，經過改進，提出一種新的需求變更模型——同步型需求變更模型，如圖5所示。

4.1 區分需求變更影響規模

根據需求變更對軟件項目的影響范圍，對項目執行進度的修改過程進行優化。對于小范圍的變更，如修改一個頁面的某個標題或文字問題，開發者僅需要10分鐘即可完成的任務，則可直接提交開發人員修改，無需進行可行性判定及評估審核。這樣不僅提高了客戶滿意度，而且提高了修改效率。對于中大范圍的修改，則需要由需求變更控制委員會確定需求變更影響范圍，并分析變更帶來的潛在影響[15]，采用的分析方法包括基于QFD與DSM的軟件需求變更影響分析方法[16]、面向對象的軟件變更影響分析方法[17]、基于語義的需求變更影響分析方法[18]等。

4.2 需求變更優先級

由于客戶提出的需求變更具有不同優先級，此時可參考KANO模型對客戶需求進行判定，并在其基礎上更新需求內容，提高項目完成品質，盡力提高客戶滿意度，以實現“迷人質量”。因此，新模型強調按照需求變更的優先級進行修改，并對于可以分批次上線的項目進行拆分，優先對緊急上線的模塊進行修改，對于不影響上線部分的需求變更，可以在此之后再與客戶溝通，詳細分析客戶需求，明確修改內容。

4.3 設計符合度

當設計人員完成詳細修改方案后，將設計后的版本內容與客戶進行溝通，只有當設計方案得到雙方肯定后再進行開發，才能防止因修改的設計不符合要求而造成返工，產生多余的工作量。

4.4 軟件開發與修改同步

對于設計人員提出的修改方案，由開發人員加以執行，同時由項目經理修改項目進度，隨后反饋給開發人員，以防止開發人員因等待項目修改導致開發進度延誤，提高開發效率。

4.5 多模塊協同并統一測試

現代軟件的開發都是團隊型作業，對于大的項目，該分工方式可以提高效率，同時降低代碼耦合。企業中眾多需求變更模型都是以單一模塊開發為主，一旦對其它模塊造成影響，只能依托集成測試與系統測試才能發現。如果在變更前即能考慮到變更的影響模塊，并分模塊解決問題，則可提高團隊間協作能力，降低開發成本。

5 應用實例

在典寶網項目的信息維護模塊開發過程中，多次出現需求變更，其中包含頁面修改、邏輯修改、接口對接、傳值修改等方面。項目組對于需求變更帶來的影響，先后采用3種模型對工作量進行了評估。對比結果如表1所示。

由表1不難看出，對于細微的修改，3個模型的工作量基本一致，書面型模型所需時間略長。因為按照書面型需求變更模型進行需求變更，編寫文檔會在一定程度上增加工作量。但當修改內容較為復雜時，同步型模型所需的工作量會降低。對于書面型模型而言，由于其邏輯比較明確，可以準確定位問題點，且便于修改，但因編寫文檔時任務無法同步進行，將延誤開發進度。同時可以看出，執行型模型的修改工作量顯著高于后兩個模型，主要是由于其業務邏輯較為復雜，不易定位，且文檔不夠完整，因而導致開發質量大幅降低，并且在需求變更次數增加時，其工作量也會不斷加大，從而導致開發內容與原需求區別較大，提交的文檔也與代碼內容存在差異，同時增加了維護成本。需求變更模型工作量對比如圖6所示。

6 結語

根據Zowghi等[19]對軟件開發組織歷史數據的分析，得出需求變更對軟件項目的延期與超支有著顯著影響。由于在需求管理過程中具有很大風險[20]，因此采用一個好的項目需求管理模型進行進度控制是非常重要的。該需求管理模型既要能夠產生足夠的文檔以保證項目產品品質、降低維護成本，又要避免開發延誤，防止產生額外工作量。本文對于多家公司及團隊的需求變更模型進行分析，發現同步型需求變更模型可有效解決傳統需求變更模型工作量較大、易阻塞的缺點，其良好的文檔管理過程既減少了需求變更造成的工作量，并能有效保證軟件品質，又減少了后期維護成本，從而使開發過程更加順暢。

參考文獻：

[1] 陳小紅，尹斌，金芝. 基于問題框架的需求建模：一種本體制導的方法[J]. 軟件學報，2011，22（2）：177-194.

[2] 李引，李娟，李明樹. 動態需求跟蹤方法及跟蹤精度問題研究[J]. 軟件學報，2009，20（2）：177-192.

[3] 李萍，許曉兵. 基于CMMI的信息系統需求變更度量問題及其改進方法[J]. 科技與管理，2011，13（6）：72-75.

[4] 盧曉東.? 中小IT企業項目變更管理研究[D]. 北京：中國科學院大學，2014.

[5] 繆晨輝. 新產品開發中的需求變更控制管理[J]. 項目管理技術，2008（S1）：315-318.

[6] COOPER D， CHAN M W， HARDING M， et al. Using dependence graphs to assist manual and automated object oriented software inspections[C]. Proceedings of Software Engineering Conference，2006： 42-58.

[7] 邢彬彬，姚鄭. CMM/CMMI與軟件生命周期模型關系的研究[J]. 計算機應用研究，2007（11）：65-69.

[8] BROOK S F P. 人月神話[M]. 汪穎，等，譯. 北京：清華大學出版社，2002：367.

[9] 李俊煒. 軟件開發中的需求分析及變更管理研究[J]. 無線互聯科技，2017（10）：60-62.

[10] COMMITTEE S E S. IEEE recommended practice for software requirements specifications[C]. IEEE STD， 2002：1-40.

[11] 陳冬冬. IT項目需求管理淺析[J]. 電腦知識與技術，2017，13（32）：117-119.

[12] 王煥青. 基于需求條目的變更管理[J]. 科技資訊，2017，15（13）：100-101.

[13] 李波. 軟件需求變更的影響因素和控制管理研究[J]. 通訊世界，2015（18）：221.

[14] 魯先鵬. A公司軟件需求管理研究[D]. 北京：北京交通大學，2016.

[15] 劉華虓，金英，馬鵬飛. 一種需求變更影響分析方法[J]. 計算機研究與發展，2013，50（8）：1769-1777.

[16] 王躍鵬，張春海. 基于QFD和DSM的軟件需求變更影響分析方法與應用[J]. 微型機與應用，2017，36（9）：74-77.

[17] 劉志宏.? 一種面向對象軟件變更影響分析模型的研究與設計[D]. 鎮江：江蘇大學，2007.

[18] 蔣高，郭樹行. 基于語義的需求變更影響分析的技術研究[J]. 科技創新導報，2013（25）：248-249.

[19] ZOWGHI D，NURMULIANI N. Proceedings of the 9th Asia pacific software engineering conference[C]. IEEE Computer Society，2002： 3-11.

[20] 沈建明. 項目風險管理[M]. 北京：機械工業出版社，2003.

（責任編輯：黃 健）