基于案例推理的軟件需求分析研究

王 麗，杜曉明

(江蘇科技大學(xué) 經(jīng)濟(jì)管理學(xué)院，江蘇 鎮(zhèn)江 212003)

需求分析是軟件定義時期的最后一個階段，它所要做的工作是深入描述軟件的功能和性能，確定軟件設(shè)計(jì)的限制，以及軟件同其他系統(tǒng)元素的接口細(xì)節(jié)，定義軟件的其他有效性需求，因此，對需求階段進(jìn)行深入研究具有重要的意義。參考文獻(xiàn)[1]對軟件需求分析的含義、任務(wù)和過程進(jìn)行討論，突出了有效溝通、需求管理、團(tuán)隊(duì)協(xié)作在需求分析過程中的重要作用，同時探討了若干需求分析方法；參考文獻(xiàn)[2]重點(diǎn)描述按照RUP的要求進(jìn)行軟件需求分析的方法，給出了建立業(yè)務(wù)模型、需求模型的具體目的、內(nèi)容和步驟；參考文獻(xiàn)[3]闡述了UML的特點(diǎn)、UML架構(gòu)、軟件需求分析原則及UML對軟件建模的意義，并給出了UML技術(shù)在軟件需求分析和設(shè)計(jì)階段的成功應(yīng)用；參考文獻(xiàn)[4]利用形式化規(guī)格說明語言——B語言對軟件需求進(jìn)行了嚴(yán)格定義，在嚴(yán)格的數(shù)學(xué)基礎(chǔ)上進(jìn)行軟件開發(fā)，以獲得更好的軟件性能；參考文獻(xiàn)[5]討論和分析了軟件需求分析的概念、任務(wù)、過程、種類、原則、用戶和系統(tǒng)分析員的關(guān)系以及需求文檔的書寫。這些研究都具有較高的學(xué)術(shù)價(jià)值，并且各具特點(diǎn)，但極少有從知識管理的角度進(jìn)行需求分析，缺少對軟件企業(yè)所擁有案例的深入挖掘和充分利用。

本文從知識管理的角度運(yùn)用基于案例推理的方法提出了軟件需求分析的框架模型，并對該模型的關(guān)鍵技術(shù)進(jìn)行了詳細(xì)說明。本文的研究成果為軟件企業(yè)實(shí)現(xiàn)有效的案例管理提供了理論和技術(shù)上的保障，拓展了CBR的應(yīng)用領(lǐng)域。

1 軟件需求分析過程中的知識流動分析

需求分析本質(zhì)上是一個知識管理的過程，這一過程出現(xiàn)的主要問題可歸結(jié)為隱形知識顯性化的管理過程。多數(shù)從事軟件研究和軟件開發(fā)的專家認(rèn)為，需求獲取只有通過客戶和開發(fā)者有效的合作、減少合作中的障礙才能成功，客戶的參與直接影響到需求獲取的結(jié)果，沒有參與就沒有結(jié)果，而被動參與會產(chǎn)生不良結(jié)果。事實(shí)上，需求分析是分析專家通過挖掘客戶潛在需求相關(guān)知識，再將各類軟件開發(fā)人員的經(jīng)驗(yàn)、專業(yè)知識相融合，從而產(chǎn)生出客戶真正期望的需求的過程；需求分析的過程就是知識傳遞、創(chuàng)新、顯化的過程[6]。

圖1表明了知識流在需求過程中的流動，主要包括3個階段：與需求相關(guān)的知識傳遞；相關(guān)需求知識創(chuàng)新；需求顯化。需求知識的最初來源有客戶、領(lǐng)域知識與軟件團(tuán)隊(duì)內(nèi)部已有的軟件開發(fā)經(jīng)驗(yàn)、開發(fā)技術(shù)、開發(fā)模式等相關(guān)知識;在相關(guān)需求知識的創(chuàng)新階段，主要完成知識形態(tài)的轉(zhuǎn)化，將供需雙方的知識加以積聚融合;最后將用戶隱含的需求知識顯性化以形成客戶真正的需求，這是需求分析過程中最關(guān)鍵的環(huán)節(jié)。經(jīng)過反饋，最終流向用戶手中，在用戶需求得到確認(rèn)的同時，軟件開發(fā)團(tuán)隊(duì)的需求獲取過程完成，但并不意味著需求過程的結(jié)束，需求過程將隨著軟件項(xiàng)目的每一個不同的開發(fā)階段不斷地信息反饋而逐漸得到更新。

圖1 知識在需求獲取過程中的流動

2 基于案例推理進(jìn)行軟件需求知識模型

基于案例推理的思想最早是由R Shanker在1982在《Dynamic Memory》書中提出的，以后由他的學(xué)生經(jīng)過多年的工作逐漸發(fā)展起來。它的核心思想為：在問題求解時，人們可以使用以前對該類問題的求解經(jīng)驗(yàn)，即案例，來進(jìn)行推理。在這種求解問題的方法中，人們將過去對問題的求解案例按一定的組織方式存儲在案例庫中，當(dāng)用戶輸入待求解的新問題時，系統(tǒng)首先從案例庫中尋找這種案例或與其近似案例。如果找到的案例與待求解案例的描述完全一致，則將找到的案例中的結(jié)論輸出。否則，根據(jù)對待求解問題的描述，對檢索出來的案例進(jìn)行修改，以產(chǎn)生一個符合問題求解要求的解并將其輸出；同時將這個問題案例作為一個新的案例再存儲到案例庫中。因此，在以后求解時，便可利用案例庫中已知的案例，而不必每次都從頭開始。一個經(jīng)驗(yàn)豐富的醫(yī)生可以從他過去的治病生涯中總結(jié)大量經(jīng)驗(yàn)，對于新遇到的病癥，有經(jīng)驗(yàn)的醫(yī)生可以從過去醫(yī)治過的相同病癥或類似病癥中很快找到新的治療方法。而每次成功的治療又都為將來積累新的經(jīng)驗(yàn)。

依據(jù)上述對軟件需求分析過程中的知識流動分析，這里將基于案例推理(CBR)技術(shù)引入到了需求分析過程中來，提出了一個如圖2所示的基于案例推理進(jìn)行軟件需求知識模型(CBRDA)。

2.1 CBRDA的定義

定義1針對圖2模型，本文將基于案例推理進(jìn)行軟件需求分析CBRDA，定義如下：

圖2 基于案例推理進(jìn)行軟件需求知識模型(CBRDA)

其中，Sset={Ea，Eb}，表示需求分析專家及其擁有的知識和經(jīng)驗(yàn)，Ea表示進(jìn)行需求分析的專家，Eb表示其擁有的知識；Cset={Ci，qi|i=1，2，3，…n}表示客戶 Ci及其知識需求qi，包括功能需求非功能需求以及領(lǐng)域需求；CASEset表示聯(lián)系Sset和Cset的基于案例推理的系統(tǒng)，它是由案例庫、基于案例推理活動及其對應(yīng)的規(guī)則組成。CASEset＝{I，F(xiàn)，W，C，T，S}，其中，I＝{I1，I2，…Im}是 1 個有限集合，表示案例的說明信息；F＝{F1，F(xiàn)2，…Fn}是 1 個有限非空集合，表示案例所具有的各種特征，即特征集；W＝{W1，W2，…Wn}是1個有限非空集合，表示案例所具有的各種特征的權(quán)值，即權(quán)值集；C＝{C1，C2，…CX}是 1 個有限非空集合，表示由特征集引起的結(jié)論集；T＝{T1，T2，…Ty}是1個有限非空集合，表示驗(yàn)證結(jié)論成立與否的檢測，即測試集；S＝{S1，S2，…Sz}是 1 個有限集合，表示結(jié)論集的解決方案。上述多元式提供了求解案例的表達(dá)模型，其中特征集和結(jié)論集可作為求解案例的索引[7]。

2.2 CBRDA中的CASEset工作過程

在圖2所示的架構(gòu)中，CASEset作為需求分析最關(guān)鍵的部分以及聯(lián)系分析專家和客戶之間關(guān)系紐帶，其工作過程遵循如下步驟：

(1)根據(jù)客戶知識需求，以規(guī)范的形式描述出新問題案例；

(2)檢索與新問題案例類似的案例，通過案例推理和相似度分析，確定最類似的案例；

(3)修訂解決方案以使其更加適應(yīng)新問題案例；

(4)客戶對得到的新方案進(jìn)行評估，判斷是否滿足客戶的需求；

(5)再次審查和評估修訂后的解決方案，判斷是否有必要保留新問題案例；

(6)修改案例庫中的案例索引和特征權(quán)重。

3 CBRDA中的關(guān)鍵技術(shù)

3.1 案例知識的表示

在CBRDA中，存在大量支持已有的解決方案的知識與經(jīng)驗(yàn)，這些解決方案對應(yīng)著諸多源案例，其中就包括求解案例;而在需求分析過程中，客戶的知識需求又會產(chǎn)生諸多問題案例。案例表示是CBRDA的基礎(chǔ)，其表示方法直接關(guān)系到推理的效率和準(zhǔn)確度。案例表示涉及求解案例和問題案例2個方面，而準(zhǔn)確和完整地表達(dá)求解案例是CASEset的重要步驟。求解案例和問題案例定義如下。

定義2 CBRDA中的問題案例是一組反映了客戶知識需求的約束的集合，表示為 P={Ak，Pk}，k=1，2，…，m，其中，Ak＝{aki|i=1，2，…n}表示第 l個問題案例所包含的特征集，n表示 Al所包含特征的個數(shù)；Pk={wki，fki}表示與對應(yīng)特征的結(jié)論。wxi表示特征權(quán)值，其值越大，該特征越重要。

定義3 CBRDA中的求解案例是在滿足問題案例需求條件的下通過知識檢索所得到的結(jié)果案例，表示為T={Ak，Pk}，k=1， 2，…，m，其中 ，m 為當(dāng)前案例庫中的源案例數(shù)；Ak={aki|i=1，2，…n}表示第k個案例所包含的特征集，n 表示 Ak所包含特征的個數(shù)；Pk={fki，ski|i=1，2，…n}表示與對應(yīng)特征的結(jié)論以及解決方案。

求解案例是已經(jīng)存在案例，擁有特定知識結(jié)構(gòu)和內(nèi)容描述，每一個求解案例對應(yīng)一個解決方案，而客戶的知識需求是一些零散的知識，為了在案例檢索中獲得類似案例(求解案例)，則需要在由知識需求產(chǎn)生的問題案例時，使問題案例以一種與求解案例相近的結(jié)構(gòu)進(jìn)行組織。

3.2 案例知識的檢索

案例檢索的本質(zhì)是問題案例與求解案例之間的相似匹配，目前，適用于 CBRs的檢索方法主要有:最近相鄰法、歸納索引法和知識導(dǎo)引法等?？紤]到軟件需求分析的特點(diǎn)，這里將采用最近相鄰法(Nearest neighbor approach)，它是指從案例庫中找出與當(dāng)前情況距離最近的案例的方法。把問題案例與案例庫中的求解案例進(jìn)行逐索引域的比較，求出案例之間的每個域的相似度，再根據(jù)以前定義的加權(quán)向量，最終確定求解案例與問題案例的相似度，將相似度超過閾值的案例輸出。該策略既是案例的檢索策略，也是案例的組織策略。案例的相似度是抽取案例各方面的特征值，并確定各特征的權(quán)，通過計(jì)算問題案例和求解案例的加權(quán)距離，來確定案例相似程度的大小。

設(shè)案例集合(案例庫)C＝{C1，C2，…，Cn}，第 i個案例的屬性集，，…，，則案例間的相似度為：

其中kj表示第j個特征的取值范圍。

3.3 案例的改寫與案例的存儲

案例的改寫表現(xiàn)為案例庫的學(xué)習(xí)功能，它的主要目的是：通過適當(dāng)調(diào)整在檢索操作中獲得的求解案例中的解決方案，使之適合于待求解的當(dāng)前問題。案例的改寫往往與特定的領(lǐng)域密切相關(guān)。改寫過程中所用到的知識可以包括領(lǐng)域知識和啟發(fā)式改寫規(guī)則。由于系統(tǒng)完全自動修訂技術(shù)非常困難，所以在CBRDA中，案例的修訂也采用專家干預(yù)的形式，由系統(tǒng)分析專家根據(jù)用戶知識需求的具體情況，參照案例的建議，修訂整個解決方案，改寫后的案例是原案例庫中不存在的案例，當(dāng)將其加入到案例庫中后，就在原領(lǐng)域中形成了對問題求解能力的擴(kuò)充[8]。

軟件需求分析是軟件生命周期中重要的一步，也是關(guān)鍵的一步。只有通過軟件需求分析，才能從總體上把軟件功能和性能描述為具體的軟件需求規(guī)格說明?；诎咐评淼能浖枨蠓治龇椒ㄓ兄谲浖髽I(yè)更加深入的挖掘已有的知識案例，快速、準(zhǔn)確地獲取客戶的需求，從而提高本身的競爭力。

[1]邱樹偉.關(guān)于軟件需求分析的探究[J].福建電腦，2008(7)：48-50.

[2]苗炬.基于RUP的軟件需求分析 [J].計(jì)算機(jī)與網(wǎng)絡(luò)，2003(5)：53-54.

[3]田茵.基于UML的軟件需求分析和設(shè)計(jì)[J].實(shí)驗(yàn)技術(shù)與管理，2004(21)：74-79.

[4]周紹景，唐艷，邱發(fā)林.淺談軟件需求分析方法[J].計(jì)算機(jī)與信息技術(shù)，2007(1)：37.

[5]塔維娜，何積豐.基于形式化方法的需求分析[J].實(shí)驗(yàn)技術(shù)與管理，2003(29)：107-108.

[6]李曉明，孫林巖，汪應(yīng)洛.基于知識管理的軟件需求管理研究[J].研究與發(fā)展管理，2005(17)：28-32.

[7]王雪瑞，劉文煌.知識管理系統(tǒng)中的CBR技術(shù)研究[J].計(jì)算機(jī)工程與應(yīng)用，2002(2)：181-183.

[8]王君，潘星，李靜.基于案例推理的知識管理咨詢系統(tǒng)[J].清華大學(xué)學(xué)報(bào)(自然科學(xué)版)，2006，46(z1).