李軍偉

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

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

李軍偉

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

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

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

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

1 界面原型法

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

1.1 界面需求分析

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

1.2 用戶角色

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

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

2 用例模型法

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

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

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

>用例可以驅(qū)動整個開發(fā)過程，因為大部分活動如分析、設計和測試都是從用例開始執(zhí)行的[1]。

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

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

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

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

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

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

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

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

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

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

3.1 功能比對

最初的需求分析采用界面原型法，由于界面原型法直觀、容易量化，所以在與客戶交流時更容易獲得相對準確的需求，在大體確定界面應有功能后，根據(jù)該界面的功能描述，可以確定哪些功能由哪些用戶實現(xiàn)，從而與用例模型中相應參與者的功能進行比對。“界面原型法”中“用戶角色”定義與“用例模型法”中“參與者”的確定有大致相同的功效，所以針對這個交叉點，除去“用例模型法”中參與者的非“使用者”因素，將二者進行疊加，互相補充、互相比對，將不相交和不相容部分進行進一步挖掘，補正糾誤，因為從不同的角度考慮問題，所以在獲得的需求上能夠更全面、更準確，為項目的順利進行打下良好的基礎。

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

3.2 細化迭代

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

4 小結(jié)

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

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

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

TP3

A

1005-1554（2010）02-0024-03

2009-12-20

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