李軍偉

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

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

李軍偉

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

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

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

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

1 界面原型法

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

1.1 界面需求分析

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

1.2 用戶角色

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

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

2 用例模型法

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

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

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

>用例可以驅(qū)動(dòng)整個(gè)開發(fā)過程，因?yàn)榇蟛糠只顒?dòng)如分析、設(shè)計(jì)和測(cè)試都是從用例開始執(zhí)行的[1]。

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

2.1 明確系統(tǒng)邊界。需求管理的目標(biāo)是為了確定正確范圍，明確系統(tǒng)邊界，即對(duì)在里面的對(duì)象和在外面的對(duì)象進(jìn)行區(qū)分。明確系統(tǒng)邊界的關(guān)鍵在于描述交互，而不是內(nèi)在的系統(tǒng)活動(dò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 遵循建模步驟。建模時(shí)首先要進(jìn)行領(lǐng)域分析，建立領(lǐng)域模型；其次整理用戶的業(yè)務(wù)流程，建立業(yè)務(wù)模型；第三對(duì)業(yè)務(wù)模型的輸入輸出進(jìn)行分析，建立用例模型，此時(shí)不考慮怎么實(shí)現(xiàn)，只是初步的劃分，考慮的重點(diǎn)是結(jié)構(gòu)和交互行為，包括用例圖；第四是分析階段的分析模型，分析階段是進(jìn)行抽象的過程，不解決具體的實(shí)現(xiàn)，包括類圖、序列圖、協(xié)作圖、活動(dòng)圖和狀態(tài)圖；第五是設(shè)計(jì)階段的設(shè)計(jì)模型，包括組件圖；第六是部暑階段的實(shí)施模型，包括部署圖；最后是測(cè)試模型。

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

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

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

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

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

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

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

3.1 功能比對(duì)

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

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

3.2 細(xì)化迭代

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

4 小結(jié)

需求的成功與否決定著系統(tǒng)的成敗，恰當(dāng)?shù)姆椒ㄒ餐瑯記Q定著需求的成敗，不拘泥于一種形式，善于在多種方法中尋找各自的優(yōu)劣并加以綜合應(yīng)用，無(wú)論在軟件開發(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-），女,河北唐山人,承德民族師專信息中心助教。