基于軟件風險管理的需求變更原因識別框架和案例研究

嚴玉清+孫為軍+張振華

摘 要：識別軟件需求變更原因并建立原因分類框架符合軟件風險管理的要求。本文從軟件風險管理角度出發，分析軟件風險因素與需求變更原因的共通性；根據原因存在的客觀性與否，把需求變更原因分為內因和外因，并對內因和外因所包含的各因素進行分析，建立軟件生命周期中需求變更原因因素的分類結構框架。在問卷調查的基礎上，計算內外因各因素誘發需求變更的貢獻度，結果表明了原因分類框架的合理性和實用性。最后給出了進一步的研究方向。

關鍵詞：需求變更；軟件風險；內因；外因；貢獻度

中圖分類號：TP311.5 文獻標識碼：A

1 引言（Introduction）

軟件開發項目不論其類型或規模大小，需求變更的有效管理是必要的。實施需求變更如同給病人動手術，要花費成本，延誤開發進度，有可能使需求規格說明出現錯誤，影響軟件開發質量，甚至導致開發失敗。需求通常是很不穩定的，用戶希望把一個需要點擊兩次的功能，改成點擊一次，就會導致需求變更，并影響編碼、測試及軟件維護[1]。需求變更風險管理重在預防，有效預防需要有效的預測機制，需要有效識別需求變更原因，需要建立合理的原因分類依據和分類結構。

2 研究現狀概述（Previous studies）

20世紀80年代前，主張凍結需求的瀑布模型盛行，但隨著軟件應用的日益普及，軟件規模和復雜度不斷增大，凍結需求的做法已經行不通，需求頻繁變更給軟件開發及其維護帶來了巨大的挑戰。為迎合需求變更，減少變更帶來的影響和危害，出現了多種開發技術，例如：聯合應用設計、原型法、快速應用開發、敏捷方法等。同時，需求變更的原因成為業界和學術界一直關注的問題，學術界展開了廣泛的探討和研究。20世紀90年代，Harker等[2]詳細分析了組織和用戶需求有可能發生變更的五種來源：動態變更的環境、用戶參與需求獲取、用戶使用系統并參與開發、情景行動和任務變更、有計劃的組織開發約束，并探討預防變更的相應對策。Kotonya和Sommerville[3]探討了軟件開發過程中需求變更的各種可能原因，例如：需求錯誤、沖突、不一致；技術、進度或成本問題；用戶組織需求改變等。McGee和Greer[4，5]運用文獻分析和實證分析手段，建立需求變更來源的分層視圖并驗證這種分類在實際開發過程中的效果。事實上，需求變更是對需求問題的修正。在引起需求問題的眾多因素中，人是非常重要的因素。開發人員和客戶的認知能力、情緒及人際關系都與需求變更問題相關。Anitha等[6]重點研究了作為非技術因素的人在敏捷開發過程中有可能引起的需求變更問題以及相應的對策。Janes等[7]的研究涉及探討開發人員的感知和理解力、交際能力、情緒和行為特征在需求變更問題上所起的影響作用。

關于需求變更原因的識別和分類中，當前存在三個主要問題：（1）沒有建立需求變更原因與軟件風險因素間的聯系，沒有發掘這兩類因素之間的共通性；（2）需求變更原因的分類缺乏原則指導，分類結構層次不清晰、不完整。

針對這些問題，本文首先建立誘發需求變更的因素與軟件風險因素之間的共通性，然后從風險管理角度，提出需求變更原因分類依據，并對變更內因和外因進行分析，建立軟件生命周期需求變更原因分類結構，并通過問卷調查，獲得了開發人員的認可。

3 軟件風險與需求變更風險的共通性（The commonality

between software risk and requirements change）

3.1 軟件風險因素是需求變更的誘因

常見的軟件風險因素有[8]：（1）合同風險；（2）需求變更風險；（3）溝通不良風險；（4）缺乏領導支持風險；（5）進度風險；（6）質量風險；（7）系統性能風險；（8）工具風險；（9）技術風險；（10）團隊成員能力和素質風險；（11）團隊成員協作風險；（12）人員流動風險；（13）工作環境風險；（14）系統運行環境風險。這些風險因素會直接或間接地誘發各種需求問題（圖1），導致需求變更[7，9]。

requirements change

3.2 需求變更原因的分類依據

需求問題的存在使得需求不得不發生變更[7，9，10]。需求問題可以出現在軟件生命周期中的任何階段，與各種要素相關：項目的復雜度和規模、開發人員的素質、客戶的參與程度和理解力、政策和市場競爭等等。圖1中，有些因素與人有關，例如：溝通不良、團隊成員協作、團隊成員的能力和素質、人員流動；有些因素與過程有關，例如：合同問題、進度問題；有些與組織有關，例如：缺乏領導支持、工作環境問題。從有效軟件風險管理角度出發，一定要從軟件生命周期去識別需求變更的原因，而且要考慮全面性并兼顧客觀性，不放過任何細小的可能導致需求變更的因素或小概率事件，因為這些微小的因素有可能使軟件開發過程及其產品出現災難性的后果[7]。因此，我們提出了四個原則[11]：全局性（Holistic）、相關性（Correlative）、強內聚性（Strong Cohesive）和弱耦合性（Weak Coupling）。

Microsoft的量化研究表明，在風險管理中投入5%的項目工作可以獲取50%—75%的如期完成的機會[12]，可見風險管理在軟件開發中的重要作用。軟件風險管理通常由六個步驟組成：風險識別、估計、分析、計劃、控制和監督。風險識別就是識別各種風險因素。一方面，軟件風險因素是誘發需求變更的因素。另一方面，需求變更是關鍵的軟件風險因素，誘發需求變更的各種因素就是潛在的軟件風險因素。因此，識別需求變更原因因素就是識別軟件風險因素。

4.1 需求變更的內因

內因是指與項目本性相關，并有可能會誘發需求變更的因素。

Janes等[7]認為誘發需求問題的內部因素有兩種：（1）項目的復雜度和開發持續時間；（2）組織結構。事實上，項目的復雜度是客觀存在的，是項目的本性之一，是影響開發人員認知的重要因素。開發持續時間與多方面因素有關，既有客觀的，例如項目的復雜度及規模、開發范圍，也有非客觀的，例如開發人員的素質、經驗、開發成本、進度計劃、客戶的配合等因素。這里我們所認為的內因是客觀存在的因素，因此開發持續時間不屬于我們所講的內因。組織結構包括開發組織和客戶組織。客戶組織通常指的是廣大用戶的代表。例如，淘寶購物平臺，社會的每一成員都是其潛在的用戶，但只有淘寶公司的運營部門成員能夠代表廣大的用戶去選擇開發組織，具有一定的主觀性。因此組織結構不屬于內因。我們所定義的需求變更的內因是：規模因素和復雜度因素。

這兩個因素之間的聯系是：項目規模大或復雜度高，將影響開發人員的認知（影響概念的完整性與一致性），影響需求的完整獲取，會誘發需求變更。而且規模大的項目其復雜度通常都高，例如，飛機導航系統，各種子系統之間的一致性、并發性、容錯性是復雜的。它們的區別是復雜度高的系統不一定規模大，例如植入人體的芯片系統，它涉及醫學、人體解剖學，其復雜性是不言而喻的。

4.2 需求變更的外因

外因是除內因外可能誘發需求問題和需求變更的因素。圖1的所有軟件風險因素都是需求變更的外因。外因分為六類[12，13]：干系人因素、組織因素、技術因素、過程因素、環境因素和軟件效能因素。

（1）干系人因素。干系人是指參與到軟件開發過程中的開發人員、項目經理、營銷人員、客戶等，分為兩類：a.開發人員：指參與項目開發、管理、銷售的人員以及軟件的維護人員；b.客戶：指項目委托方人員及終端用戶。開發人員會存在這些問題：知識結構不完整，缺乏溝通能力，經驗不足，技術不熟練，工具掌握不好，學習能力不強，缺乏鉆研精神，不熟悉項目背景，缺乏責任心，情緒不良。客戶存在的問題：對產品的認識和了解不足，參與積極性不高，不積極配合開發人員，不遵守合同要求。

（2）組織因素。組織分為兩類：開發組織與客戶組織（也稱用戶組織，亦包括作為客戶組織代表的提供開發資源的第三方組織）。開發組織存在的問題是：缺乏良好的企業文化和凝聚力，團隊成員之間溝通不足，對開發人員或客戶的培訓不足，領導的市場開拓能力不強、官僚主義，開發人員流動頻繁，辦公環境不佳。客戶組織存在的問題：組織結構、運作方式、商業策略發生改變，業務范圍擴展。

（3）技術因素。技術包括工具在內分為：a.開發技術。開發技術和工具的熟練使用能夠提高開發效率，減少開發過程中的錯誤包括減少需求問題及需求變更。常用的開發技術或手段有[8]：聯合應用設計（JAD）、原型法、快速應用開發（RAD）、需求檢查等。如果缺乏使用或不熟練使用恰當的技術，無疑會增加需求變更風險；b.管理技術。在開發過程中，除了要加強項目管理意識，在軟件生命周期中實施規范的管理細則，還要懂得借助于一些商業變更管理系統工具[14]來協助需求的開發、降低需求變更的影響；c.集成技術。不論是同一個軟件系統的開發還是大數據的應用，都存在著許多子系統，這些子系統必須集成在一起才能夠使軟件系統完整。這些子系統之間的集成依賴于接口需求的一致性，如果不一致，則會導致需求的變更。軟件系統賴以運行的硬件環境、網絡環境、支撐軟件（如操作系統）的配置要與性能需求保持一致性，否則會誘發需求的變更。

（4）過程因素。過程分為：a.計劃過程；b.開發過程；c.管理過程。計劃過程容易出現的問題有合同制訂不科學，項目范圍和目標不明確，對人力、成本、進度等資源估算不足；開發過程常常出現的問題是進度延誤、成本超支、不遵守合同、開發范圍擴大；管理過程常常存在的問題為項目缺乏合理統籌和管理，需求缺乏規范和有效的管理，不能夠預見問題的發生，不遵守科學的管理流程和規則。

（5）社會環境因素。社會環境因素是指軟件在其生命周期中對其生存有影響的并且難于預測和控制的一些社會因素。這些因素具有一定的隨機性，是開發人員和客戶無法控制的[14]。它包括：a.市場：出現新需求導致現有產品過時；b.競爭壓力：競爭者發布新產品打壓、影響正在開發或已經交付的產品。這種競爭壓力常常出現在商業軟件中[10]，例如現在的手機軟件，同一種應用的軟件在手機商店上五花八門，相互之間形成巨大的競爭；c.政法：政策、法律、法規發生變更。例如稅收法的變更會影響稅務系統，商業過程的研究會使商業規則發生變更[10]。

（6）軟件效能因素。軟件交付使用之后，有可能軟件的使用成本高、易用性不好、沒有真正滿足用戶需求[15]。軟件效能因素包括：a.使用成本的可接受性；b.功能完整性；c.軟件性能。例如：易用性、時間響應性、兼容性、適用性、容錯性、安全性等。用戶滿意度就是軟件效能因素的綜合評價結果（通常是一個主觀量）。

4.3 需求變更原因分類框架圖

為了能夠認清需求變更原因，我們構造了一個軟件生命周期中需求變更原因分類框架圖（圖2）。內因有兩層，外因有三層。在葉子層，仍然可以找出底層的原因因素。例如合同的計劃問題屬于計劃過程問題，合同的遵循問題屬于開發人員問題或客戶問題。由此可見，底層的具體的原因可能屬于幾種類別，一定要分析清楚具體的原因才能找出其真正的出處，以便更有針對性地實施控制和管理需求變更。

圖2有助于完整識別各類需求變更的原因，也有助于找到更細小的原因及其所屬來源路徑，使得需求變更的實施更有針對性。在實際的開發過程中，當找出了各種可能原因，還要在這些原因中繼續判斷主要原因和次要原因，但絕不能夠忽略看似微不足道的誘因[2]。

5 變更原因貢獻度計算和結果分析（The calculation

and result analysis of the contribution rates of

cause factors）

專家訪談與問卷調查是軟件工程實證研究的主要手段[16]。為了對需求變更原因獲得更直觀、深入的理解，我們在廣州一家著名的專注于電子政務系統開發的軟件公司的開發人員中進行了一次問卷調查。

5.1 問卷調查的主要內容和方式

問卷主要了解四大部分內容：a.個人開發經歷及企業基本情況；b.開發過程中需求獲取與分析情況；c.開發過程中需求及變更管理情況；d.常見的軟件風險因素、需求問題及變更原因。與本研究相關的問題是：在軟件風險管理框架下，什么因素容易導致需求變更，其貢獻分值是多少（在0—5中選填一個數字，數字越大，貢獻分值越高）？

5.2 原因貢獻度

原因貢獻度是指某原因會誘發需求變更的可能性大小。貢獻度分值越高，表明該原因越關鍵，在軟件開發和項目管理時，越要重視這一因素及其與之關系密切的其他因素。

對回收的112份數據進行統計，采用算術平均法計算每個原因的貢獻分值，分值再除以5得貢獻度，如表1所示。

從表1可見，內因中的項目特征“復雜度”因素，貢獻度為70%，表明復雜度高，對開發人員的認知是一個挑戰。越復雜的項目，開發人員越要深入了解項目的背景并要與客戶保持良好的溝通關系。外因下面的“人”因素下的“客戶”子因素的貢獻度最高，達到82%。

這表明客戶的積極參與以及開發人員與客戶進行有效溝通對避免需求變更有關鍵作用，這與我們已有的常識相符。“開發人員”的貢獻度為68%，表明開發人員對成功開發的關鍵作用，這是不言而喻的。“開發組織”與“客戶組織”分別為68%和66%，說明組織對開發過程的統一、協調配合及其管理的重要性。“開發過程”與“管理過程”分別為70%和68%，同樣表明開發過程的順暢性和管理過程的合理性的重要作用。另外，表1可反映這樣一個事實，需求變更的主要因素是與人相關的因素。

5.3 加權原因貢獻度

考慮到參與問卷調查的開發人員中有的經驗豐富（參與開發項目超過30個），有的是新手（只參與了五項）。為使回收的數據更具有客觀性，在計算原因貢獻分值時，把開發經驗折成一定的權值。我們設計了如表2所示的經驗權值賦權方法，計算出這批問卷表對應的平均權值為0.93。利用表1所使用的數據，并通過加權，得表3，最終結果與表1相吻合。

6 結論（Conclusion）

本文從軟件風險管理角度出發，建立了軟件生命周期需求變更的內外因結構框圖。這一分類方法具有客觀性、全面性和推廣性，有助于識別實際軟件開發過程中各種軟件風險因素和需求變更因素。我們所進行的實證研究分析結果表明了這一分類的合理性和因素之間的可區分性，結論是可靠的。

下一步，我們需要針對特定類型的軟件開發項目（例如基于大數據應用的軟件或各種手機APP軟件或政務軟件）研究這一分類模型的可裁剪性及其擴展性，通過收集實證數據，進一步分析因素之間的相關性，找出與特定項目開發相關的關鍵風險因素和關鍵需求變更誘因，用以構建理論上和實踐上都有指導作用的軟件風險和需求變更預測方法體系。

參考文獻（References）

[1] M.R.Strens and R.C.Sugden.Change Analysis：A Step towards Meeting the Challenge of Changing Requirements[C].IEEE Symposium and Workshop on Engineering of Computer-Based Systems，Proceedings，1996：278-283.

[2] S.D.P.Harker and K.D.Eason，J E Dobson.The Change and Evolution of Requirements as a Challenge to the Practice of Software Engineering[C].Proceedings of the IEEE International Symposium on Requirements Engineering（RE93）USA，IEEE Computer Society Press，1993：266-272.

[3] Gerald Kotonya and Ian Sommerville.Requirements Engineering-Processes and Techniques[M].John Wiley & Sons，1997.

[4] S. McGee and D.Greer.A Software Requirements Change Source Taxonomy[C].ICSEA'09，Fourth International Conference on Software Engineering Advances，2009：51-58.

[5] S.McGee and D.Greer.Software Requirements Change Taxonomy：Evaluation by Case Study[C].2011 IEEE 19th International Requirements Engineering Conference，2011：25-34.

[6] Anitha P.C.，Deepti Savio，V. S. Mani.Managing requirements volatility while "Scrumming" within the V-Model.2013 IEEE Third International Workshop on Empirical Requirements Engineering （EmpiRE），2013：17-23.

[7] Janes A，et al.Managing Changes in Requirements：an Empirical Investigation[J].Journal of Software： Evolution and Process，2013，25（12）：1273-1283.

[8] 韓萬江，姜立新.軟件項目管理案例教程（第2版）[M].北京：機械工業出版社，2009.

[9] Karl E.Wiegers.More About Software Requirements：Thorny Issues and Practical Advice[M].Microsoft Press，2005.

[10] Karl E.Wiegers.劉偉琴，劉洪濤，譯.軟件需求（第2版）[M].北京：清華大學出版社，2004.

[11] Yu-Qing YAN，Zhen-Hua ZHANG.A Method to Connect the Sources of Software Risk and Requirements Change[C].2016 International Conference on Management Economics and Social Development，2016：1179-1185.

[12] 胡勇，謝康，肖靜華.軟件項目風險管理的協同過程模型[J].現代管理科學，2007（03）：8-10.

[13] 嚴玉清.需求演化及依賴關系研究[D].廣州：中山大學，2011.

[14] Bano， M.，et al.Causes of Requirement Change-a Systematic Literature Review[C].The Institute of Engineering and Technology，2012：22-31.

[15] Tom DeMarco & Timothy Lister.Peopleware[M].2nd Edition.Beijing：Tsinghua University Press，2003.

[16] Annabella Loconsole.Empirical Studies on Requirement Management Measures[C].ICSE'04 Proceedings of the 26th International Conference on Software Engineering，2004：42-44.

作者簡介：

嚴玉清（1963-），女，博士，副教授.研究領域：軟件工程，軟件需求管理，軟件度量，運籌學.

孫為軍（1975-），男，博士，講師.研究領域：軟件工程，機器學習.

張振華（1972-），男，博士，副教授.研究領域：服務外包軟件項目風險管理，模糊推理.