改進(jìn)的軟件需求變更模型

王曉 張春海

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

關(guān)鍵詞：需求變更模型;軟件需求;項(xiàng)目管理

DOI：10. 11907/rjdk. 181669

中圖分類號(hào)：TP3-05文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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 引言

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

1 軟件開發(fā)及需求變更關(guān)系

1.1 軟件開發(fā)階段

項(xiàng)目一旦啟動(dòng)，則進(jìn)入軟件開發(fā)生命周期。軟件項(xiàng)目生命周期分為：可行性分析、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測試、維護(hù)7個(gè)階段。根據(jù)其不同的生命周期模型，又分為瀑布模型、V模型、原型化模型以及迭代模型等開發(fā)模型。軟件生命周期模型的出現(xiàn)始于W Royce在1970年發(fā)表的瀑布模型，使人們開始從更高視角審視軟件開發(fā)活動(dòng)[7-8]。然而實(shí)際的軟件項(xiàng)目開發(fā)并不是一帆風(fēng)順的，項(xiàng)目需求變更穿插于生命周期的每一個(gè)環(huán)節(jié)。軟件開發(fā)需要嚴(yán)格按照流程實(shí)施，并對(duì)需求變更流程路線進(jìn)行統(tǒng)一規(guī)范[9]。

1.2 理論論述

IEEE（電氣和電子工程師協(xié)會(huì)）定義軟件需求為：①為了讓客戶完成某項(xiàng)功能或處理某個(gè)難題而必須具有的能力;②為了讓系統(tǒng)能夠符合某一標(biāo)準(zhǔn)或達(dá)到合同要求而必須具備的功能[10]。

1.3 需求變更

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

1.4 需求變更與軟件生命周期關(guān)系

需求變更與軟件生命周期存在密不可分的聯(lián)系，如圖1所示。當(dāng)需求分析完成后，需求變更便貫穿于后續(xù)每一個(gè)環(huán)節(jié)，大到項(xiàng)目架構(gòu)設(shè)計(jì)，小到編碼實(shí)現(xiàn)，都可能發(fā)生變更。由于所處外界環(huán)境及客戶需求的不確定性，當(dāng)一個(gè)軟件需求發(fā)生變更時(shí)，可能會(huì)給軟件開發(fā)人員帶來較大工作量。另一方面由于需求變更的模糊性，也可能導(dǎo)致最后開發(fā)的軟件質(zhì)量不符合用戶要求。因此，如何評(píng)估并減少變更對(duì)工作的影響，既是對(duì)項(xiàng)目經(jīng)理管理層面的挑戰(zhàn)，也關(guān)系到項(xiàng)目能否按時(shí)交付。

1.5 需求變更與用戶滿意度關(guān)系

需求變更與用戶滿意度關(guān)系來自于KANO模型，該模型是東京理工大學(xué)教授狩野紀(jì)昭（Noriaki Kano）發(fā)明的可對(duì)用戶需求進(jìn)行分類與優(yōu)先排序的有用工具，體現(xiàn)了產(chǎn)品性能與用戶滿意度之間的非線性關(guān)系。其主要是從顧客角度認(rèn)識(shí)產(chǎn)品或服務(wù)需要，首先需要滿足的是顧客最基本的需求，即第四象限的“當(dāng)然質(zhì)量”，因?yàn)檫@些需求是顧客認(rèn)為必須達(dá)到的;其次需要盡力滿足客戶的“期望質(zhì)量”，即第一象限，這是質(zhì)量的競爭性因素;最后為了提升客戶忠誠度，需要爭取實(shí)現(xiàn)第二象限的“迷人質(zhì)量”。

2 需求變更因素分析

當(dāng)變更發(fā)生時(shí)，首先要詢問相關(guān)開發(fā)人員，綜合評(píng)定變更的影響，其次設(shè)計(jì)對(duì)應(yīng)方案并對(duì)其進(jìn)行工作量評(píng)估，最后根據(jù)設(shè)計(jì)方案進(jìn)行開發(fā)工作。本文提出在項(xiàng)目開發(fā)中影響需求變更工作量的兩個(gè)因素：自身因素與客戶因素。

2.1 自身因素

2.1.1 團(tuán)隊(duì)專業(yè)性

專業(yè)素質(zhì)表現(xiàn)在編碼與設(shè)計(jì)方面。作為一個(gè)專業(yè)軟件開發(fā)人員，在軟件項(xiàng)目開發(fā)過程中，應(yīng)該了解項(xiàng)目所處行業(yè)環(huán)境，關(guān)注行業(yè)動(dòng)態(tài)，從而能夠準(zhǔn)確獲取或描述客戶需求，對(duì)于客戶的大致需求可以從多個(gè)角度給出設(shè)計(jì)方案[12]，并且對(duì)后期可能存在的需求變更預(yù)留接口。此外，軟件設(shè)計(jì)人員需及時(shí)與客戶溝通，從客戶角度出發(fā)，了解對(duì)方需求中的專業(yè)術(shù)語，使團(tuán)隊(duì)具備較強(qiáng)執(zhí)行力。

2.1.2 文檔完整性

一套專業(yè)、系統(tǒng)的文檔，不但有益于邏輯梳理以及與客戶的溝通交流，而且在出現(xiàn)需求變更時(shí)，能夠準(zhǔn)確把握需求變更點(diǎn)，從而大大提高工作效率。軟件開發(fā)人員在需求變更不確定的情況下，通過閱讀完整文檔，能夠更深入地了解客戶需求、節(jié)省開發(fā)時(shí)間。因此，當(dāng)需求發(fā)生變更時(shí)，應(yīng)及時(shí)更新文檔，以有效保障項(xiàng)目品質(zhì)。

2.1.3 編碼規(guī)范性

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

2.2 客戶因素

2.2.1 客戶業(yè)務(wù)素質(zhì)

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

2.2.2 提出時(shí)間

軟件需求變更提出時(shí)間對(duì)需求變更工作也有著很大影響。例如：2016年開發(fā)了一套SAP系統(tǒng)，2017年進(jìn)入測試階段時(shí)發(fā)現(xiàn)已測試的A模塊業(yè)務(wù)需求與現(xiàn)實(shí)業(yè)務(wù)不符，想要對(duì)該模塊進(jìn)行修改，時(shí)隔一年之久進(jìn)行修改與剛開發(fā)一個(gè)月時(shí)即進(jìn)行修改，其工作量相差甚遠(yuǎn)。

2.2.3 修改位置

在軟件開發(fā)過程中，項(xiàng)目設(shè)計(jì)為項(xiàng)目架構(gòu)部分，然后根據(jù)設(shè)計(jì)進(jìn)行編碼。如果客戶提出的需求變更位置位于架構(gòu)部分，將可能對(duì)項(xiàng)目整體設(shè)計(jì)帶來重大影響。

3 常見需求變更模型

3.1 執(zhí)行優(yōu)先性模型

當(dāng)客戶提出需求變更時(shí)，可根據(jù)執(zhí)行優(yōu)先性模型對(duì)變更進(jìn)行評(píng)估，確定設(shè)計(jì)方案，然后指派人員執(zhí)行。

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

3.2 書面說明性模型

因執(zhí)行優(yōu)先性模型對(duì)于需求變更管理不夠嚴(yán)格，因此出現(xiàn)了書面說明性需求變更模型，如圖4所示。該模型詳細(xì)記錄了變更發(fā)生后對(duì)項(xiàng)目的分析、評(píng)估過程，并生成文檔加以保存。

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

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

針對(duì)上述需求變更模型存在的缺點(diǎn)，經(jīng)過改進(jìn)，提出一種新的需求變更模型——同步型需求變更模型，如圖5所示。

4.1 區(qū)分需求變更影響規(guī)模

根據(jù)需求變更對(duì)軟件項(xiàng)目的影響范圍，對(duì)項(xiàng)目執(zhí)行進(jìn)度的修改過程進(jìn)行優(yōu)化。對(duì)于小范圍的變更，如修改一個(gè)頁面的某個(gè)標(biāo)題或文字問題，開發(fā)者僅需要10分鐘即可完成的任務(wù)，則可直接提交開發(fā)人員修改，無需進(jìn)行可行性判定及評(píng)估審核。這樣不僅提高了客戶滿意度，而且提高了修改效率。對(duì)于中大范圍的修改，則需要由需求變更控制委員會(huì)確定需求變更影響范圍，并分析變更帶來的潛在影響[15]，采用的分析方法包括基于QFD與DSM的軟件需求變更影響分析方法[16]、面向?qū)ο蟮能浖兏绊懛治龇椒╗17]、基于語義的需求變更影響分析方法[18]等。

4.2 需求變更優(yōu)先級(jí)

由于客戶提出的需求變更具有不同優(yōu)先級(jí)，此時(shí)可參考KANO模型對(duì)客戶需求進(jìn)行判定，并在其基礎(chǔ)上更新需求內(nèi)容，提高項(xiàng)目完成品質(zhì)，盡力提高客戶滿意度，以實(shí)現(xiàn)“迷人質(zhì)量”。因此，新模型強(qiáng)調(diào)按照需求變更的優(yōu)先級(jí)進(jìn)行修改，并對(duì)于可以分批次上線的項(xiàng)目進(jìn)行拆分，優(yōu)先對(duì)緊急上線的模塊進(jìn)行修改，對(duì)于不影響上線部分的需求變更，可以在此之后再與客戶溝通，詳細(xì)分析客戶需求，明確修改內(nèi)容。

4.3 設(shè)計(jì)符合度

當(dāng)設(shè)計(jì)人員完成詳細(xì)修改方案后，將設(shè)計(jì)后的版本內(nèi)容與客戶進(jìn)行溝通，只有當(dāng)設(shè)計(jì)方案得到雙方肯定后再進(jìn)行開發(fā)，才能防止因修改的設(shè)計(jì)不符合要求而造成返工，產(chǎn)生多余的工作量。

4.4 軟件開發(fā)與修改同步

對(duì)于設(shè)計(jì)人員提出的修改方案，由開發(fā)人員加以執(zhí)行，同時(shí)由項(xiàng)目經(jīng)理修改項(xiàng)目進(jìn)度，隨后反饋給開發(fā)人員，以防止開發(fā)人員因等待項(xiàng)目修改導(dǎo)致開發(fā)進(jìn)度延誤，提高開發(fā)效率。

4.5 多模塊協(xié)同并統(tǒng)一測試

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

5 應(yīng)用實(shí)例

在典寶網(wǎng)項(xiàng)目的信息維護(hù)模塊開發(fā)過程中，多次出現(xiàn)需求變更，其中包含頁面修改、邏輯修改、接口對(duì)接、傳值修改等方面。項(xiàng)目組對(duì)于需求變更帶來的影響，先后采用3種模型對(duì)工作量進(jìn)行了評(píng)估。對(duì)比結(jié)果如表1所示。

由表1不難看出，對(duì)于細(xì)微的修改，3個(gè)模型的工作量基本一致，書面型模型所需時(shí)間略長。因?yàn)榘凑諘嫘托枨笞兏Ｐ瓦M(jìn)行需求變更，編寫文檔會(huì)在一定程度上增加工作量。但當(dāng)修改內(nèi)容較為復(fù)雜時(shí)，同步型模型所需的工作量會(huì)降低。對(duì)于書面型模型而言，由于其邏輯比較明確，可以準(zhǔn)確定位問題點(diǎn)，且便于修改，但因編寫文檔時(shí)任務(wù)無法同步進(jìn)行，將延誤開發(fā)進(jìn)度。同時(shí)可以看出，執(zhí)行型模型的修改工作量顯著高于后兩個(gè)模型，主要是由于其業(yè)務(wù)邏輯較為復(fù)雜，不易定位，且文檔不夠完整，因而導(dǎo)致開發(fā)質(zhì)量大幅降低，并且在需求變更次數(shù)增加時(shí)，其工作量也會(huì)不斷加大，從而導(dǎo)致開發(fā)內(nèi)容與原需求區(qū)別較大，提交的文檔也與代碼內(nèi)容存在差異，同時(shí)增加了維護(hù)成本。需求變更模型工作量對(duì)比如圖6所示。

6 結(jié)語

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

參考文獻(xiàn)：

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

[2] 李引，李娟，李明樹. 動(dòng)態(tài)需求跟蹤方法及跟蹤精度問題研究[J]. 軟件學(xué)報(bào)，2009，20（2）：177-192.

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

[4] 盧曉東.? 中小IT企業(yè)項(xiàng)目變更管理研究[D]. 北京：中國科學(xué)院大學(xué)，2014.

[5] 繆晨輝. 新產(chǎn)品開發(fā)中的需求變更控制管理[J]. 項(xiàng)目管理技術(shù)，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與軟件生命周期模型關(guān)系的研究[J]. 計(jì)算機(jī)應(yīng)用研究，2007（11）：65-69.

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

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

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

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

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

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

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

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

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

[17] 劉志宏.? 一種面向?qū)ο筌浖兏绊懛治瞿Ｐ偷难芯颗c設(shè)計(jì)[D]. 鎮(zhèn)江：江蘇大學(xué)，2007.

[18] 蔣高，郭樹行. 基于語義的需求變更影響分析的技術(shù)研究[J]. 科技創(chuàng)新導(dǎo)報(bào)，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] 沈建明. 項(xiàng)目風(fēng)險(xiǎn)管理[M]. 北京：機(jī)械工業(yè)出版社，2003.

（責(zé)任編輯：黃 ?。?/p>