李軍偉

（承德民族師專 信息中心，河北 承德 067000）

需求捕獲和需求分析方法探析

李軍偉

（承德民族師專 信息中心，河北 承德 067000）

需求捕獲和需求分析的目標(biāo)是發(fā)現(xiàn)真正的需求并以適合用戶、客戶和開發(fā)人員的方式加以表示，需求的成敗決定著待開發(fā)系統(tǒng)的成敗。本文詳細(xì)闡述了“界面原型法”中界面需求及用戶角色的需求方法，“用例模型法”中確定邊界、建模步驟、用例文檔及用例粒度的需求方法，并討論了兩種方法綜合應(yīng)用中功能比對和細(xì)化迭代的相關(guān)問題。

需求捕獲；需求分析；界面原型法；用例模型法

需求捕獲和分析是軟件開發(fā)的第一個階段，需求工作的成功與否決定著待開發(fā)系統(tǒng)的成敗。據(jù)權(quán)威部門統(tǒng)計，目前軟件的成功率約為25%，75%的軟件是失敗的。在這75%的失敗中，約有50%以上的軟件是由于需求的原因造成的。由于任何一個系統(tǒng)都會有很多的用戶，同時每個用戶只知道自己如何使用系統(tǒng)，一般沒有人知道系統(tǒng)的整個情況，因而不能對待構(gòu)造的系統(tǒng)有一個準(zhǔn)確、細(xì)致、全面的了解和闡述。同時需求人員在傾聽用戶的描述時不可避免會有理解上的不同，所以需求人員掌握的需求與實(shí)際需求經(jīng)常會有差距，如果這個差距在開發(fā)階段或后期才被發(fā)現(xiàn)，必然會影響系統(tǒng)的成敗。所以合適的需求捕獲和分析方法對系統(tǒng)的成敗所起的作用不可小視。本文將對“界面原型法”和“用例模型法”的需求方法進(jìn)行討論和分析。

1 界面原型法

軟件界面是人與計算機(jī)之間的媒介。由于在軟件開發(fā)前期，用戶對待開發(fā)的系統(tǒng)很模糊，甚至沒有自己的理想模型，用戶提出的要求就很難量化，結(jié)果很容易被需求分析人員忽略。界面原型法使用戶在最短的時間內(nèi)看到待開發(fā)系統(tǒng)的雛形，可以幫助用戶盡快完善自己的理想模型。根據(jù)軟件系統(tǒng)的需求產(chǎn)生出的軟件系統(tǒng)界面原型，用戶可以感性地認(rèn)識到未來系統(tǒng)的功能、界面風(fēng)格以及操作方式，從而迅速做出判斷：系統(tǒng)是否符合自己的期望，是否能夠滿足自己工作的需要。需求分析人員可以利用界面原型，通過對操作界面所完成的功能得到進(jìn)一步的功能需求，并誘導(dǎo)用戶修正自己的理想系統(tǒng)，提出新的需求，從而盡早獲得更完整、更正確的需求。以收銀系統(tǒng)為例，通過登陸、處理、出單、統(tǒng)計等界面操作，用戶可以對待開發(fā)的系統(tǒng)有一個明確的認(rèn)識，界面的流轉(zhuǎn)也就是功能或處理的流轉(zhuǎn)，從而將需求進(jìn)一步的挖掘，得到更加量化、具體、全面的需求。建立界面原型一般需要以下兩個步驟。

1.1 界面需求分析

通常一個軟件界面的元素包括界面主顏色、字體顏色、字體大小、界面布局、界面交互方式、界面功能分布、界面輸入輸出模式等。軟件界面作為一個整體，其中任何一個元素不符合用戶習(xí)慣、不滿足用戶要求都將降低用戶對軟件系統(tǒng)的認(rèn)可度，甚至影響用戶的工作效率，有可能使用戶最終放棄使用系統(tǒng)。圍繞界面元素所要達(dá)到的設(shè)計目的,讓最終用戶能夠獲得美感、提高工作效率、易于操作使用系統(tǒng)。如收銀系統(tǒng)，用戶需要進(jìn)行大量的數(shù)據(jù)處理，所以用鍵盤較多，所以盡可能減少鍵盤與鼠標(biāo)的交叉應(yīng)用。

1.2 用戶角色

用戶角色是指按照一定參考體系劃分的用戶類型，是能夠代表某種用戶特征、便于統(tǒng)一描述的眾多用戶個體的集合。將用戶集合定義為角色模型，同時賦予不同的優(yōu)先級別，了解記錄其界面需求。在一個軟件系統(tǒng)中，用戶角色定義時所依據(jù)體系可以多種多樣，一個單一用戶可以屬于不同參考體系下的不同用戶角色，但是一個用戶角色要求能夠代表一種界面需求類型。如收銀員就是按照用戶工作職位劃分出來一個用戶角色，如果按照操作計算機(jī)的熟練程度，屬于收銀員角色中的系統(tǒng)用戶又可以分為：熟練用戶、生疏用戶。

之所以要定義用戶角色，是因?yàn)椴煌挠脩艚巧谛枨蠓治鲞^程中的需求目標(biāo)不同，側(cè)重點(diǎn)也不同，甚至互相矛盾。在一個大型系統(tǒng)中,需求分析人員面對的用戶只能是眾多單一的用戶個體，他們的需求也因人而異。只有明確了用戶角色，需求分析人員才能在紛亂復(fù)雜而又不甚明了的用戶要求中理出脈絡(luò)，依據(jù)用戶角色不同的優(yōu)先級別，平衡眾多用戶需求中的矛盾，抽象出完整的界面模型。例如，GSP認(rèn)證的醫(yī)藥經(jīng)營企業(yè)管理信息系統(tǒng)中，對于經(jīng)營商品的統(tǒng)計，管理部、質(zhì)檢部、計劃部、銷售部、財務(wù)部、倉儲部都要做相應(yīng)的統(tǒng)計，但側(cè)重點(diǎn)不同，需要統(tǒng)計的內(nèi)容也不同，管理部和計劃部側(cè)重于庫存合理、質(zhì)檢部和倉儲部側(cè)重于數(shù)據(jù)全面、銷售部和財務(wù)部側(cè)重于利潤，在做界面原型時，分別為各個部門做一組界面，每個部門針對自己的界面組提出具體的要求，分析時就可以將其中的共同點(diǎn)提取出來，而將不同點(diǎn)分別處理，從而可以得到整個系統(tǒng)關(guān)于統(tǒng)計方面的界面模型，并挖掘出相應(yīng)的業(yè)務(wù)功能，為系統(tǒng)功能的需求分析打下基礎(chǔ)。

2 用例模型法

用例(Use Case)已普遍用于捕獲軟件系統(tǒng)的需求，并得到越來越廣泛的應(yīng)用，它與其它需求捕獲技術(shù)相比，它成功的原因在于：

>用例把系統(tǒng)當(dāng)作一個黑盒

>用例提供了一種捕獲功能需求的系統(tǒng)而直觀的方法

>用例可以驅(qū)動整個開發(fā)過程，因?yàn)榇蟛糠只顒尤绶治觥⒃O(shè)計和測試都是從用例開始執(zhí)行的[1]。

用例用來捕獲系統(tǒng)的功能性需求，從用戶的視角描述了在邏輯上相對完整的一個功能流程。用例很直觀，用例模型是用來與用戶和客戶在“系統(tǒng)應(yīng)該為用戶做什么”方面達(dá)成共識，可以認(rèn)為用例模型是所有可能使用系統(tǒng)的方式的完整的規(guī)格說明。用例最主要的價值在于：它強(qiáng)調(diào)了用戶的目標(biāo)和觀點(diǎn)。用例模型法需遵循的原則：

2.1 明確系統(tǒng)邊界。需求管理的目標(biāo)是為了確定正確范圍，明確系統(tǒng)邊界，即對在里面的對象和在外面的對象進(jìn)行區(qū)分。明確系統(tǒng)邊界的關(guān)鍵在于描述交互，而不是內(nèi)在的系統(tǒng)活動。參與者代表在系統(tǒng)邊界之外的真實(shí)事物，并不是系統(tǒng)的成份，參與者透過系統(tǒng)邊界直接與系統(tǒng)交互，參與者的確定代表系統(tǒng)邊界的確定。如圖書館系統(tǒng)的用例圖中,讀者、工作人員、管理員是使用系統(tǒng)，所以在邊界之外；而相應(yīng)的借書、圖書管理、系統(tǒng)維護(hù)是系統(tǒng)所要完成的工作，屬于系統(tǒng)成份，在邊界之內(nèi)。

2.2 遵循建模步驟。建模時首先要進(jìn)行領(lǐng)域分析，建立領(lǐng)域模型；其次整理用戶的業(yè)務(wù)流程，建立業(yè)務(wù)模型；第三對業(yè)務(wù)模型的輸入輸出進(jìn)行分析，建立用例模型，此時不考慮怎么實(shí)現(xiàn)，只是初步的劃分，考慮的重點(diǎn)是結(jié)構(gòu)和交互行為，包括用例圖；第四是分析階段的分析模型，分析階段是進(jìn)行抽象的過程，不解決具體的實(shí)現(xiàn)，包括類圖、序列圖、協(xié)作圖、活動圖和狀態(tài)圖；第五是設(shè)計階段的設(shè)計模型，包括組件圖；第六是部暑階段的實(shí)施模型，包括部署圖；最后是測試模型。

2.3 使用有效用例文檔。用例可以驅(qū)動整個開發(fā)過程，用例文檔是對用例的詳細(xì)內(nèi)容進(jìn)行說明的文檔，包括用例名稱、標(biāo)識符、參與者、狀態(tài)、頻率、前置條件、后置條件、基本操作流程、可選操作流程等內(nèi)容，在用例文檔中對于相關(guān)內(nèi)容必須明確和正確的說明，不能含糊，不能有二義性。

2.4 確定用例粒度。確定用例粒度遵循以下基本原則：

（1）控制用例的總體數(shù)量：一般來說，一個比較復(fù)雜的系統(tǒng)的用例數(shù)量可能在30-50個之間。

（2）避免功能分解：功能分解是正確使用用例技術(shù)的最大敵人，很多用例粒度的討論其實(shí)都是功能分解的思想在作怪。如醫(yī)院的管理系統(tǒng)要將收費(fèi)和取藥兩個流程改為一個，兩個流程要銜接好是主要目標(biāo)，所以要用一個用例；而如果是把收費(fèi)和取藥一個流程改為兩個，因?yàn)榻鉀Q的問題不同，所以要用兩個用例；對于領(lǐng)導(dǎo)要查看的門診量和收費(fèi)情況統(tǒng)計，因?yàn)椴樵兘y(tǒng)計只是整個工作流程中的一個環(huán)節(jié)，所以不能作為一個單獨(dú)的用例。

（3）不斷調(diào)整。很多時候在初步規(guī)劃用例模型的階段，有時很難判斷一個用例的粒度是否合適，不要執(zhí)迷于一次獲得一個完美的用例模型和用例粒度。不妨先得出一個初稿，然后在實(shí)際寫用例的過程中，根據(jù)需要進(jìn)行調(diào)整。

3 界面原型法和用例模型法的綜合

“界面原型法”具有直觀、清晰、容易量化的特點(diǎn)，用戶參照界面原型可以將需求提的更具體、更準(zhǔn)確，但缺乏功能捕獲的優(yōu)勢；而“用例模型法”是一種捕獲功能需求的系統(tǒng)而直覺的方法，可以驅(qū)動整個開發(fā)過程。

3.1 功能比對

最初的需求分析采用界面原型法，由于界面原型法直觀、容易量化，所以在與客戶交流時更容易獲得相對準(zhǔn)確的需求，在大體確定界面應(yīng)有功能后，根據(jù)該界面的功能描述，可以確定哪些功能由哪些用戶實(shí)現(xiàn)，從而與用例模型中相應(yīng)參與者的功能進(jìn)行比對?！敖缑嬖头ā敝小坝脩艚巧倍x與“用例模型法”中“參與者”的確定有大致相同的功效，所以針對這個交叉點(diǎn)，除去“用例模型法”中參與者的非“使用者”因素，將二者進(jìn)行疊加，互相補(bǔ)充、互相比對，將不相交和不相容部分進(jìn)行進(jìn)一步挖掘，補(bǔ)正糾誤，因?yàn)閺牟煌慕嵌瓤紤]問題，所以在獲得的需求上能夠更全面、更準(zhǔn)確，為項(xiàng)目的順利進(jìn)行打下良好的基礎(chǔ)。

以“GSP認(rèn)證的醫(yī)藥經(jīng)營企業(yè)管理信息系統(tǒng)”為例，在進(jìn)行銷售部的界面設(shè)計時，需要的信息是銷售單位、庫存數(shù)量、單價，在銷售單位中又要明確應(yīng)收款額度、信用度信息，但缺少對GSP認(rèn)證時需要的單位資質(zhì)信息。在GSP認(rèn)證的用例設(shè)計中，單位的資質(zhì)信息是必須的，而這個資質(zhì)信息又是銷售部門在為銷售單位建立原始檔案時提供的，所以在進(jìn)行銷售單位的數(shù)據(jù)處理時，就需要增添必要的資質(zhì)信息。銷售單位的應(yīng)收款額度、信用度又是財務(wù)部提供的信息。所以在進(jìn)行銷售單位的數(shù)據(jù)處理時，還要為財務(wù)部預(yù)留相應(yīng)的字段空間。通過“界面原型法”和“用例模型法”綜合應(yīng)用，為系統(tǒng)的需求捕獲和分析提供了一種行之有效的解決辦法。

3.2 細(xì)化迭代

在確定了界面元素后，就要為控件的行為及狀態(tài)變化制定相應(yīng)的狀態(tài)遷移圖，狀態(tài)圖和時序圖把重要的控件狀態(tài)變化及相應(yīng)順序進(jìn)行了描述，基本上完成了界面設(shè)計。針對功能性需求，建立問題跟蹤圖表，對每一個提出的問題，均需要記錄上去，把問題結(jié)果記錄下來，根據(jù)這些表，可以很好地了解自己工作中的核心問題，并有了解決它的方向，提高了工作效率。每進(jìn)行一層的細(xì)化，都把結(jié)果交付客戶審核，由他們進(jìn)行提出何時能終止細(xì)化，當(dāng)對方認(rèn)為已達(dá)到了效果，確認(rèn)可以結(jié)束。選用迭代法，把一些錯誤的影響在功能分析和界面分析的不斷迭代過程中加以改正。

4 小結(jié)

需求的成功與否決定著系統(tǒng)的成敗，恰當(dāng)?shù)姆椒ㄒ餐瑯記Q定著需求的成敗，不拘泥于一種形式，善于在多種方法中尋找各自的優(yōu)劣并加以綜合應(yīng)用，無論在軟件開發(fā)還是在其他工作中都可以離成功更近一些。

[1]周伯生譯.統(tǒng)一軟件開發(fā)過程[M].機(jī)械工業(yè)出版社，2004.

[2]王立福等譯.軟件工程最佳實(shí)踐項(xiàng)目經(jīng)理指南[M].電子工業(yè)出版社，2004.

TP3

A

1005-1554（2010）02-0024-03

2009-12-20

李軍偉（1982-），女,河北唐山人,承德民族師專信息中心助教。