嚴(yán)玉清+孫為軍+張振華

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

關(guān)鍵詞：需求變更；軟件風(fēng)險；內(nèi)因；外因；貢獻(xiàn)度

中圖分類號：TP311.5 文獻(xiàn)標(biāo)識碼：A

1 引言（Introduction）

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

2 研究現(xiàn)狀概述（Previous studies）

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

關(guān)于需求變更原因的識別和分類中，當(dāng)前存在三個主要問題：（1）沒有建立需求變更原因與軟件風(fēng)險因素間的聯(lián)系，沒有發(fā)掘這兩類因素之間的共通性；（2）需求變更原因的分類缺乏原則指導(dǎo)，分類結(jié)構(gòu)層次不清晰、不完整。

針對這些問題，本文首先建立誘發(fā)需求變更的因素與軟件風(fēng)險因素之間的共通性，然后從風(fēng)險管理角度，提出需求變更原因分類依據(jù)，并對變更內(nèi)因和外因進(jìn)行分析，建立軟件生命周期需求變更原因分類結(jié)構(gòu)，并通過問卷調(diào)查，獲得了開發(fā)人員的認(rèn)可。

3 軟件風(fēng)險與需求變更風(fēng)險的共通性（The commonality

between software risk and requirements change）

3.1 軟件風(fēng)險因素是需求變更的誘因

常見的軟件風(fēng)險因素有[8]：（1）合同風(fēng)險；（2）需求變更風(fēng)險；（3）溝通不良風(fēng)險；（4）缺乏領(lǐng)導(dǎo)支持風(fēng)險；（5）進(jìn)度風(fēng)險；（6）質(zhì)量風(fēng)險；（7）系統(tǒng)性能風(fēng)險；（8）工具風(fēng)險；（9）技術(shù)風(fēng)險；（10）團(tuán)隊成員能力和素質(zhì)風(fēng)險；（11）團(tuán)隊成員協(xié)作風(fēng)險；（12）人員流動風(fēng)險；（13）工作環(huán)境風(fēng)險；（14）系統(tǒng)運(yùn)行環(huán)境風(fēng)險。這些風(fēng)險因素會直接或間接地誘發(fā)各種需求問題（圖1），導(dǎo)致需求變更[7，9]。

requirements change

3.2 需求變更原因的分類依據(jù)

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

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

4.1 需求變更的內(nèi)因

內(nèi)因是指與項目本性相關(guān)，并有可能會誘發(fā)需求變更的因素。

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

這兩個因素之間的聯(lián)系是：項目規(guī)模大或復(fù)雜度高，將影響開發(fā)人員的認(rèn)知（影響概念的完整性與一致性），影響需求的完整獲取，會誘發(fā)需求變更。而且規(guī)模大的項目其復(fù)雜度通常都高，例如，飛機(jī)導(dǎo)航系統(tǒng)，各種子系統(tǒng)之間的一致性、并發(fā)性、容錯性是復(fù)雜的。它們的區(qū)別是復(fù)雜度高的系統(tǒng)不一定規(guī)模大，例如植入人體的芯片系統(tǒng)，它涉及醫(yī)學(xué)、人體解剖學(xué)，其復(fù)雜性是不言而喻的。

4.2 需求變更的外因

外因是除內(nèi)因外可能誘發(fā)需求問題和需求變更的因素。圖1的所有軟件風(fēng)險因素都是需求變更的外因。外因分為六類[12，13]：干系人因素、組織因素、技術(shù)因素、過程因素、環(huán)境因素和軟件效能因素。

（1）干系人因素。干系人是指參與到軟件開發(fā)過程中的開發(fā)人員、項目經(jīng)理、營銷人員、客戶等，分為兩類：a.開發(fā)人員：指參與項目開發(fā)、管理、銷售的人員以及軟件的維護(hù)人員；b.客戶：指項目委托方人員及終端用戶。開發(fā)人員會存在這些問題：知識結(jié)構(gòu)不完整，缺乏溝通能力，經(jīng)驗不足，技術(shù)不熟練，工具掌握不好，學(xué)習(xí)能力不強(qiáng)，缺乏鉆研精神，不熟悉項目背景，缺乏責(zé)任心，情緒不良?？蛻舸嬖诘膯栴}：對產(chǎn)品的認(rèn)識和了解不足，參與積極性不高，不積極配合開發(fā)人員，不遵守合同要求。

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

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

（4）過程因素。過程分為：a.計劃過程；b.開發(fā)過程；c.管理過程。計劃過程容易出現(xiàn)的問題有合同制訂不科學(xué)，項目范圍和目標(biāo)不明確，對人力、成本、進(jìn)度等資源估算不足；開發(fā)過程常常出現(xiàn)的問題是進(jìn)度延誤、成本超支、不遵守合同、開發(fā)范圍擴(kuò)大；管理過程常常存在的問題為項目缺乏合理統(tǒng)籌和管理，需求缺乏規(guī)范和有效的管理，不能夠預(yù)見問題的發(fā)生，不遵守科學(xué)的管理流程和規(guī)則。

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

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

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

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

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

5 變更原因貢獻(xiàn)度計算和結(jié)果分析（The calculation

and result analysis of the contribution rates of

cause factors）

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

5.1 問卷調(diào)查的主要內(nèi)容和方式

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

5.2 原因貢獻(xiàn)度

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

對回收的112份數(shù)據(jù)進(jìn)行統(tǒng)計，采用算術(shù)平均法計算每個原因的貢獻(xiàn)分值，分值再除以5得貢獻(xiàn)度，如表1所示。

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

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

5.3 加權(quán)原因貢獻(xiàn)度

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

6 結(jié)論（Conclusion）

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

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

參考文獻(xiàn)（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，F(xiàn)ourth 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].北京：機(jī)械工業(yè)出版社，2009.

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

[10] Karl E.Wiegers.劉偉琴，劉洪濤，譯.軟件需求（第2版）[M].北京：清華大學(xué)出版社，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] 胡勇，謝康，肖靜華.軟件項目風(fēng)險管理的協(xié)同過程模型[J].現(xiàn)代管理科學(xué)，2007（03）：8-10.

[13] 嚴(yán)玉清.需求演化及依賴關(guān)系研究[D].廣州：中山大學(xué)，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.

作者簡介：

嚴(yán)玉清（1963-），女，博士，副教授.研究領(lǐng)域：軟件工程，軟件需求管理，軟件度量，運(yùn)籌學(xué).

孫為軍（1975-），男，博士，講師.研究領(lǐng)域：軟件工程，機(jī)器學(xué)習(xí).

張振華（1972-），男，博士，副教授.研究領(lǐng)域：服務(wù)外包軟件項目風(fēng)險管理，模糊推理.