王 爽，馬又良，劉 洋（.中訊郵電咨詢?cè)O(shè)計(jì)院有限公司，北京00048；.中國(guó)聯(lián)合網(wǎng)絡(luò)通信集團(tuán)有限公司，北京00033）

1 系統(tǒng)需求分析現(xiàn)狀及現(xiàn)存問題

企業(yè)信息系統(tǒng)需求，是指業(yè)務(wù)部門根據(jù)企業(yè)運(yùn)營(yíng)發(fā)展或管理的需求向后臺(tái)系統(tǒng)支撐部門提出，需要支撐部門安排時(shí)間、人員并通過IT系統(tǒng)實(shí)現(xiàn)的功能及要求。

需求管理是系統(tǒng)軟件項(xiàng)目中非常重要的工作。它是軟件開發(fā)的基礎(chǔ)和前提。只有在明確了軟件需求之后才能開展有針對(duì)性的軟件開發(fā)工作，并確定時(shí)間、成本和工作計(jì)劃。另外系統(tǒng)需求也是最終目標(biāo)軟件系統(tǒng)驗(yàn)收的標(biāo)準(zhǔn)。

企業(yè)信息系統(tǒng)需求管理工作中突出的問題包括以下幾點(diǎn)。

1.1 需求分析管控分散獨(dú)立

現(xiàn)有系統(tǒng)前期建設(shè)過程中，在一組業(yè)務(wù)需求被提出后，后臺(tái)支撐部門通常會(huì)組織系統(tǒng)新建項(xiàng)目。此類需求未經(jīng)過系統(tǒng)的分析論證，是否可在現(xiàn)有系統(tǒng)功能上稍加改動(dòng)、或通過組合、引用的方式實(shí)現(xiàn)。這種方式導(dǎo)致集團(tuán)企業(yè)范圍內(nèi)出現(xiàn)大量的“煙筒式”系統(tǒng)，造成重復(fù)建設(shè)，且給后續(xù)系統(tǒng)整合、數(shù)據(jù)共享帶來巨大難度。

1.2 系統(tǒng)功能性需求描述不準(zhǔn)確

集團(tuán)型企業(yè)的信息系統(tǒng)非常復(fù)雜和龐大，系統(tǒng)功能涉及多個(gè)部門、多管理層級(jí)。如何將軟件需求描述清楚、全面、準(zhǔn)確，是一項(xiàng)非常艱巨的挑戰(zhàn)。需求描述模糊和不一致是導(dǎo)致以往信息系統(tǒng)項(xiàng)目失敗的重要原因。

需求分析人員與用戶在業(yè)務(wù)術(shù)語表達(dá)上有所不同，交流過程中可能會(huì)理解有誤。特別是對(duì)于有二義性的需求，會(huì)導(dǎo)致不同的理解。

1.3 缺失IT 管理手段

目前的系統(tǒng)需求管理主要依靠“文檔+表格”記錄的方式，難以有效應(yīng)對(duì)集中化系統(tǒng)建設(shè)過程中的挑戰(zhàn)。

a）市場(chǎng)環(huán)境及公司管理要求變化，凸顯系統(tǒng)需求“多、快、急”。

b）運(yùn)營(yíng)職能細(xì)分和系統(tǒng)解耦趨勢(shì)，需求管理的范圍擴(kuò)大、復(fù)雜度增高。

這些都要求后臺(tái)支撐部門構(gòu)建規(guī)范的需求管理流程和方法，以滿足對(duì)外海量需求的高效管理，對(duì)內(nèi)參與需求建設(shè)的各方有效協(xié)同。

2 需求分析總體流程

需求分析總體流程包括用戶代表、需求管理職能、系統(tǒng)建設(shè)職能3類角色。根據(jù)企業(yè)信息系統(tǒng)需求開發(fā)工作的特點(diǎn)，總體流程可劃分為需求收集歸納、需求建模、需求評(píng)審、開發(fā)實(shí)施、需求實(shí)現(xiàn)及跟蹤5 個(gè)部分，5個(gè)部分之間相互影響、相互制約，形成需求管理的完整流程（見圖1）。

3 需求分析重點(diǎn)環(huán)節(jié)及方法

3.1 需求收集歸納

需求收集的方法包括以下幾類，目的是收集用戶真正面臨的問題和業(yè)務(wù)場(chǎng)景。

3.1.1 資料收集

資料收集是指盡可能獲取更多的信息和資料，用于理解系統(tǒng)相關(guān)的術(shù)語概念、流程，掌握領(lǐng)域知識(shí)，包括以下幾點(diǎn)。

a）業(yè)務(wù)管理辦法（規(guī)范）、相關(guān)制度流程。

b）業(yè)務(wù)流水記錄、合同協(xié)議等。

c）相關(guān)的會(huì)議記錄、筆記、客戶的投訴。

3.1.2 訪談

面對(duì)面訪談是發(fā)現(xiàn)事實(shí)和收集信息的基本技術(shù)。面談?dòng)?種基本形式：結(jié)構(gòu)化的和非結(jié)構(gòu)化的。

a）結(jié)構(gòu)化訪談需要有一個(gè)明確的問題列表。

b）非結(jié)構(gòu)化訪談更像非正式的會(huì)議，沒有預(yù)定的問題或者預(yù)設(shè)的目的。

3.1.3 問卷調(diào)查

問卷調(diào)查是一種收集用戶信息的有效方法，一般用來作為訪談的補(bǔ)充形式。問卷調(diào)查這種方法的優(yōu)點(diǎn)在于回答者有時(shí)間去考慮如何回答，并且可以是匿名的，可避免受調(diào)查人員傾向性意見的影響。當(dāng)需要很多人的觀點(diǎn)而他們又是在地理上分散的時(shí)候，調(diào)查表非常經(jīng)濟(jì)實(shí)用。精心設(shè)計(jì)的題目和對(duì)結(jié)果的統(tǒng)計(jì)分析技巧是調(diào)查問卷達(dá)到效果的關(guān)鍵因素。

3.1.4 觀察實(shí)習(xí)

有些情況下訪談和問卷都不能獲得完整的信息，為解決這個(gè)問題，觀察實(shí)習(xí)可能是一種有效的方法。

要使觀察更具有代表性，觀察實(shí)習(xí)應(yīng)該持續(xù)較長(zhǎng)的一段時(shí)間，在不同的時(shí)間段和不同的工作負(fù)荷下挑選時(shí)間進(jìn)行。同時(shí)觀察實(shí)習(xí)也是其他需求收集方法所獲得信息的重要校驗(yàn)手段。

3.1.5 現(xiàn)有系統(tǒng)研究

研究現(xiàn)有軟件系統(tǒng)是發(fā)現(xiàn)系統(tǒng)需求的寶貴方法。企業(yè)現(xiàn)有軟件系統(tǒng)的研究應(yīng)包括現(xiàn)有系統(tǒng)操作手冊(cè)、系統(tǒng)需求文檔、系統(tǒng)設(shè)計(jì)文檔、系統(tǒng)開發(fā)文檔、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)備份、維護(hù)日志等。其中特別要關(guān)注系統(tǒng)的現(xiàn)存問題以及系統(tǒng)的變更需求。

3.2 需求建模

前面一個(gè)環(huán)節(jié)（即需求收集歸納）所獲取的文檔化的軟件需求存在一定的局限性：可能產(chǎn)生不準(zhǔn)確、二義、歧義、不能直觀揭示關(guān)聯(lián)、不全面等。

模型是對(duì)現(xiàn)實(shí)原型的一種抽象和模擬，以反映現(xiàn)實(shí)事物的某些特征。需求建模是指用模型描述系統(tǒng)的因果關(guān)系或相互關(guān)聯(lián)關(guān)系的過程，為業(yè)務(wù)概念、對(duì)象之間建立模型。它是需求分析成果的進(jìn)一步定型，為后續(xù)的系統(tǒng)開發(fā)做相應(yīng)的技術(shù)準(zhǔn)備。需求建模技術(shù)是軟件需求分析與系統(tǒng)初步設(shè)計(jì)的主要技術(shù)手段，能夠有效分析發(fā)現(xiàn)并糾正不一致、不準(zhǔn)確和不全面的需求，對(duì)系統(tǒng)需求的不同方面形成形式化的準(zhǔn)確描述。

3.2.1 環(huán)境圖

環(huán)境圖是一種有效的界定系統(tǒng)范圍的方法，它描述了系統(tǒng)與外部系統(tǒng)的集成關(guān)系。

系統(tǒng)范圍可以通過識(shí)別外部實(shí)體以及外部實(shí)體和系統(tǒng)之間的輸入、輸出數(shù)據(jù)流（或服務(wù)）來確定。系統(tǒng)獲得輸入信息，進(jìn)行處理，產(chǎn)生輸出信息。例如，智能監(jiān)控系統(tǒng)的環(huán)境圖（見圖2）。圖2 中圓角矩形表示智能監(jiān)控系統(tǒng)，它周圍的長(zhǎng)方形表示外部實(shí)體，箭頭描繪了數(shù)據(jù)交互的內(nèi)容和方向，同時(shí)也明確了系統(tǒng)的邊界。在上例中，智能監(jiān)控從資源管理獲得資源信息、資源關(guān)系、資源拓?fù)涞?，一旦發(fā)現(xiàn)設(shè)備故障，就向電子運(yùn)維發(fā)出故障派單的請(qǐng)求，電子運(yùn)維處理故障工單在各管理層級(jí)的流轉(zhuǎn)、處理，并向電子運(yùn)維反饋同步工單狀態(tài)、割接信息、重保信息等。

從圖2 可以看出，智能監(jiān)控系統(tǒng)提供統(tǒng)一的網(wǎng)絡(luò)監(jiān)控和告警處理功能，與資源管理、電子運(yùn)維分別存在交互接口。

3.2.2 活動(dòng)圖

活動(dòng)圖描述一個(gè)業(yè)務(wù)流程中活動(dòng)的順序，主要表示活動(dòng)之間的控制關(guān)系（如判斷分支、連接、合并等）。一般情況下，在活動(dòng)和活動(dòng)圖之間具有一對(duì)一的關(guān)系，即一個(gè)活動(dòng)圖表示一項(xiàng)活動(dòng)。

圖3 示出的是以客服支撐系統(tǒng)中的“省內(nèi)漫游用戶無法主被叫”預(yù)處理流程。

圖3 活動(dòng)圖

該流程包含如下動(dòng)作、節(jié)點(diǎn)。

a）確認(rèn)用戶手機(jī)號(hào)、身份證號(hào)，詢問用戶姓名是否正確。如果“正確”，進(jìn)入下一個(gè)節(jié)點(diǎn)，如果“不正確”返回重新查詢。

b）判斷用戶是否為預(yù)付費(fèi)用戶。如果“是”，則轉(zhuǎn)入預(yù)付費(fèi)子流程，如果“否”則進(jìn)入下一個(gè)節(jié)點(diǎn)。

c）判斷用戶是否為集團(tuán)VPN用戶。如果“是”，則轉(zhuǎn)入集團(tuán)VPN 處理流程，如果“否”則進(jìn)入下一個(gè)節(jié)點(diǎn)。

d）判斷用戶是否欠費(fèi)。如果“是”，則引導(dǎo)用戶繳費(fèi)，如果“否”則進(jìn)入下一個(gè)節(jié)點(diǎn)。

e）詢問用戶是否有信號(hào)。如果“無”，則轉(zhuǎn)入無信號(hào)處理流程，如果“有”，則進(jìn)入下一個(gè)節(jié)點(diǎn)。

f）建議用戶換手機(jī)、換SIM卡進(jìn)行測(cè)試。

g）詢問用戶撥打是否正常，如果“否”，則派發(fā)故障工單，如果“是”則流程結(jié)束。

3.2.3 類圖

類圖表示系統(tǒng)的靜態(tài)視圖，用來表示數(shù)據(jù)模型、數(shù)據(jù)關(guān)系。類圖可以定義那些捕獲系統(tǒng)內(nèi)部狀態(tài)的結(jié)構(gòu)。類的結(jié)構(gòu)由其屬性來定義，當(dāng)類被加到模型中之后，要給類分配主要屬性。而不同類之間的關(guān)系則需要在類圖中用關(guān)聯(lián)線來表示。

系統(tǒng)中的類包括實(shí)體類、表現(xiàn)類、控制類、資源類、調(diào)解類等5類，需求分析主要關(guān)注實(shí)體類，它是指與業(yè)務(wù)流程、業(yè)務(wù)處理，緊密相關(guān)的類。

發(fā)現(xiàn)并定義類及其屬性的過程是一項(xiàng)反復(fù)迭代的工作，需要深入理解需求，并歸納、抽象。以客服支撐系統(tǒng)為例，產(chǎn)品、產(chǎn)品類型、故障原因、產(chǎn)品動(dòng)作的相關(guān)類圖如圖4所示。

圖4中，包含4個(gè)類。

a）產(chǎn)品類型：產(chǎn)品類型ID 為主鍵，包含產(chǎn)品類型名稱一個(gè)屬性。產(chǎn)品類型包括固話、寬帶、IPTV等。

b）障礙原因：障礙原因ID 為主鍵，包含障礙原因名稱、父障礙原因列ID、產(chǎn)品類型、顯示順序4 個(gè)屬性。與產(chǎn)品類型關(guān)聯(lián)，一個(gè)產(chǎn)品類型包含多個(gè)障礙原因。如產(chǎn)品類型為寬帶，障礙原因包含無法連接、連接成功但網(wǎng)頁無法打開等。

c）產(chǎn)品動(dòng)作：產(chǎn)品動(dòng)作ID 為主鍵，包含產(chǎn)品動(dòng)作名稱、父產(chǎn)品動(dòng)作ID、產(chǎn)品類型、顯示順序4 個(gè)屬性。與產(chǎn)品類型關(guān)聯(lián)，一個(gè)產(chǎn)品類型包含多個(gè)產(chǎn)品動(dòng)作。如產(chǎn)品類型為寬帶，產(chǎn)品動(dòng)作包含裝機(jī)、拆機(jī)、移機(jī)、修機(jī)。

d）產(chǎn)品：產(chǎn)品ID 為主鍵，包含產(chǎn)品編碼、產(chǎn)品名稱、產(chǎn)品類型、顯示順序4 個(gè)屬性。與產(chǎn)品類型關(guān)聯(lián)，一個(gè)產(chǎn)品類型包含多個(gè)產(chǎn)品。如產(chǎn)品類型為寬帶，產(chǎn)品包括xDSL專線、LAN專線等。

3.2.4 交互視圖

圖4 類圖示意圖

交互視圖捕獲對(duì)象之間的交互，為了執(zhí)行一個(gè)用例或用例的一部分，這些對(duì)象之間需要通信。與活動(dòng)圖相比，交互圖更詳細(xì)?；顒?dòng)圖描述整個(gè)活動(dòng)的各個(gè)環(huán)節(jié)，交互視圖則對(duì)活動(dòng)圖中的單個(gè)活動(dòng)建模。以客服支撐系統(tǒng)為例，查詢用戶欠費(fèi)信息的交互視圖如圖5所示。圖5中包含2個(gè)參與者（用戶、客服人員），3個(gè)類（系統(tǒng)界面、用戶驗(yàn)證、用戶）。

圖5 交互視圖示意圖

圖5中，一個(gè)箭頭表示一條消息，消息可以只有名字也可以包括消息的參數(shù)及其他信息。

a）用戶撥通客服電話，向客服人員描述產(chǎn)品類型及障礙現(xiàn)象（3G手機(jī)無法主叫）。

b）根據(jù)用戶描述的產(chǎn)品類型、現(xiàn)象，客服人員在系統(tǒng)界面上選擇產(chǎn)品類型及障礙現(xiàn)象，并獲取用戶號(hào)碼，傳遞給用戶驗(yàn)證類。

c）用戶驗(yàn)證類是一個(gè)控制對(duì)象，負(fù)責(zé)程序的邏輯。由于當(dāng)前系統(tǒng)界面發(fā)起的驗(yàn)證用戶請(qǐng)求與特定的用戶對(duì)象有關(guān)，用戶驗(yàn)證類將這個(gè)請(qǐng)求發(fā)送給用戶類。

d）用戶類將查詢結(jié)果（余額不足）返回給用戶驗(yàn)證類，系統(tǒng)界面接收返回結(jié)果并顯示在屏幕上。

e）客服人員根據(jù)系統(tǒng)界面顯示結(jié)果，告知用戶無法主叫的故障是由余額不足引起的，并引導(dǎo)用戶繳費(fèi)。

3.2.5 狀態(tài)機(jī)視圖

狀態(tài)機(jī)視圖描述對(duì)象生命周期中的屬性變化情況，屬性變化的原因可能是滿足某些條件、執(zhí)行某些活動(dòng)等。

狀態(tài)機(jī)視圖一般會(huì)附到類圖上，也可以附到其他建模概念上。狀態(tài)機(jī)視圖決定當(dāng)對(duì)象接收到一個(gè)事件時(shí)，它執(zhí)行什么動(dòng)作。以客服支撐系統(tǒng)為例，工單實(shí)體“工單狀態(tài)”屬性的狀態(tài)機(jī)圖如圖6所示。圖6中，工單狀態(tài)有6個(gè)，它們之間的轉(zhuǎn)換過程如下。

圖6 狀態(tài)機(jī)視圖

a）預(yù)處理流程未解決用戶的問題，系統(tǒng)生成工單后，狀態(tài)機(jī)模型開始啟動(dòng)，首先判斷用戶描述的故障是否是由群障引起的，如果“是”，則轉(zhuǎn)換為群障狀態(tài)，如果“否”，則轉(zhuǎn)換為綜合調(diào)度狀態(tài)。

b）工單以人工或自動(dòng)的方式派發(fā)給指定施工人員后，狀態(tài)轉(zhuǎn)換為“處理”。施工正?？⒐ず鬆顟B(tài)轉(zhuǎn)換為“回訪”。施工過程中出現(xiàn)異常，則狀態(tài)轉(zhuǎn)換為“異?！?。

c）異常解決后，需要重新派單施工，狀態(tài)由“異?！鞭D(zhuǎn)換為“綜合調(diào)度”。

d）“回訪”狀態(tài)的工單在電話回訪或人工回訪、且回訪通過后，進(jìn)入“歸檔”狀態(tài)，最終到達(dá)終態(tài)。

e）“群障”狀態(tài)的工單，經(jīng)過群障解除的動(dòng)作后，進(jìn)入“歸檔”狀態(tài)，最終到達(dá)終態(tài)。

3.3 需求評(píng)審

需求評(píng)審是指將整理好的需求規(guī)格進(jìn)行評(píng)審，最終決定開發(fā)工作如何執(zhí)行。

需求的評(píng)審一般由專業(yè)人士來完成，主要包括：a）系統(tǒng)建設(shè)職能方：部門開發(fā)經(jīng)理、維護(hù)經(jīng)理、項(xiàng)目經(jīng)理及資深開發(fā)人員。

b）需求管理職能方：需求分析設(shè)計(jì)人員。

c）用戶代表：典型客戶代表、實(shí)施人員代表。

d）公司的內(nèi)部專家及外部專家：公司內(nèi)部一般包括高層管理人員、中層管理人員；外部專家包括技術(shù)專家等。

評(píng)審的目的主要就軟件需求規(guī)格中定義的各事項(xiàng)做進(jìn)一步討論，根據(jù)評(píng)審過程中各專家提出的問題再作整理、修改，最終確定需求的狀態(tài)。并確認(rèn)開發(fā)所需的工作量、時(shí)間、成本，及開發(fā)實(shí)施初步計(jì)劃。

3.4 需求實(shí)現(xiàn)及跟蹤

3.4.1 功能性測(cè)試

功能性測(cè)試用于驗(yàn)證開發(fā)成果是否滿足目標(biāo)用戶的業(yè)務(wù)需求，目的是盡可能早的發(fā)現(xiàn)，并糾正實(shí)際開發(fā)與預(yù)期需求的偏差。

功能性測(cè)試也叫黑盒測(cè)試，只需考慮需要測(cè)試的各個(gè)功能，不需要考慮整個(gè)軟件的內(nèi)部結(jié)構(gòu)及代碼，一般從軟件產(chǎn)品的界面或模塊出發(fā)，包括以下步驟。

a）按照需求編寫出測(cè)試用例，規(guī)定每個(gè)功能的輸入、操作方法、輸出，如有必要可提前準(zhǔn)備部分表單數(shù)據(jù)。

b）測(cè)試人員按照測(cè)試用例中的輸入、操作方法，在系統(tǒng)上進(jìn)行測(cè)試操作。

c）在預(yù)期輸出結(jié)果和實(shí)際結(jié)果之間進(jìn)行評(píng)測(cè)、改進(jìn)，使產(chǎn)品更加滿足用戶使用的要求。

驗(yàn)證全部完成后，下發(fā)相關(guān)業(yè)務(wù)上線文件及管理要求文件，并視情況組織培訓(xùn)。

3.4.2 需求評(píng)估

評(píng)估需求開發(fā)成本、需求實(shí)現(xiàn)的滿意程度等。定期對(duì)上線使用的需求使用率進(jìn)行統(tǒng)計(jì)，通過客觀、科學(xué)的量化指標(biāo)，評(píng)估IT需求管理的最終效果。

根據(jù)需求后評(píng)估的管理目標(biāo)，可以將需求后評(píng)估分為以下5個(gè)維度。

a）目標(biāo)評(píng)估。關(guān)注需求達(dá)成的情況，例如業(yè)務(wù)偏差、需求的完成及時(shí)率等。

b）質(zhì)量過程評(píng)估。關(guān)注需求開發(fā)、交付的質(zhì)量，例如交付質(zhì)量、開發(fā)交付及時(shí)率等。

c）影響評(píng)估。關(guān)注對(duì)最終客戶感知的影響情況，例如對(duì)業(yè)務(wù)的中斷影響、需求引起的投訴情況。

d）效益評(píng)估。關(guān)注需求的成本與收益情況，例如需求開發(fā)工作量、業(yè)務(wù)用戶數(shù)等。針對(duì)占用資源較大的系統(tǒng)功能，跟蹤使用頻次、使用效果等。清理使用頻次低、重要性低的需求，將資源向高價(jià)值需求傾斜。

e）持續(xù)性評(píng)估。關(guān)注需求的可持續(xù)發(fā)展情況，例如系統(tǒng)重用率、系統(tǒng)的可配置性等。

4 需求管理的電子化支撐方案

對(duì)于集團(tuán)型企業(yè)來說，信息系統(tǒng)需求管理存在范圍廣、復(fù)雜度高的特點(diǎn)。采用郵件和人力維護(hù)的傳統(tǒng)需求管理方式難以對(duì)需求進(jìn)行有效的管理。因此有必要引入專業(yè)化的需求管理電子化支撐手段，即需求管理系統(tǒng)。

4.1 需求管理系統(tǒng)目標(biāo)定位

a）面向業(yè)務(wù)部門的對(duì)外窗口。所有IT 需求統(tǒng)一由需求管理系統(tǒng)接入、管理，提高IT服務(wù)水平，實(shí)現(xiàn)需求全生命周期管理與實(shí)時(shí)監(jiān)控預(yù)警。

b）需求管理工作人員的工作平臺(tái)。需求管理職能、系統(tǒng)建設(shè)職能、用戶代表的需求工作均在系統(tǒng)內(nèi)操作，固化IT 需求管理流程，確保全流程電子化、可追溯、可計(jì)量。

4.2 需求管理系統(tǒng)整體功能架構(gòu)

通過對(duì)IT需求管理重點(diǎn)環(huán)節(jié)梳理總結(jié)，結(jié)合項(xiàng)目管理、質(zhì)量管理、知識(shí)管理、運(yùn)維管理的要求，IT 需求管理系統(tǒng)功能包括以下幾點(diǎn)。

a）需求收集。支持使用專業(yè)需求模板在線擬寫需求，提供需求模板說明幫助規(guī)范填寫。

b）需求歸納整理。支持自動(dòng)編號(hào)、逐級(jí)分解、標(biāo)記優(yōu)先級(jí)、關(guān)聯(lián)關(guān)系維護(hù)等。

c）需求跟蹤。動(dòng)態(tài)更新IT需求的進(jìn)度和狀態(tài)，流程關(guān)鍵環(huán)節(jié)透明可見，并記錄過程中的關(guān)鍵成果文檔，與需求建立關(guān)聯(lián)。

d）功能性測(cè)試。記錄測(cè)試方案、測(cè)試過程、測(cè)試結(jié)果、測(cè)試中的問題與后續(xù)跟蹤；記錄與跟蹤系統(tǒng)上線、初驗(yàn)等關(guān)鍵環(huán)節(jié)。

e）需求評(píng)估。采集評(píng)估指標(biāo)所需數(shù)據(jù)，支持評(píng)估結(jié)果的記錄與分析。

f）需求管理關(guān)鍵指標(biāo)實(shí)時(shí)獲取，支持報(bào)表圖形化展示，為決策、考核提供量化依據(jù)。

g）需求知識(shí)庫(kù)。將以往需求中形成的經(jīng)驗(yàn)、收集的資料形成知識(shí)庫(kù)，方便學(xué)習(xí)共享。

5 總結(jié)與展望

隨著企業(yè)信息系統(tǒng)建設(shè)的不斷推進(jìn)，需求管理將作為貫穿項(xiàng)目始終的重要內(nèi)容，通過需求收集歸納、需求建模、需求評(píng)審、需求實(shí)現(xiàn)及跟蹤等流程環(huán)節(jié)，大大提高信息系統(tǒng)建設(shè)的效率與滿意度，有利于降低企業(yè)的管理成本，更好地發(fā)揮信息系統(tǒng)在企業(yè)運(yùn)營(yíng)中的核心支撐作用。

［1］ 麥沙塞克. 需求分析與系統(tǒng)設(shè)計(jì)［M］. 北京：機(jī)械工業(yè)出版社,2003.

［2］ 孔軍，孫怡寧，蔣敏，等.基于UML的系統(tǒng)需求分析［J］.計(jì)算機(jī)工程域應(yīng)用，2003（15）：58-61.

［3］ 呂冠艷，李?yuàn)^華.基于UML的信息系統(tǒng)需求分析模型［J］.微型機(jī)與應(yīng)用，2010（20）：10-13.

［4］ 姜天慧.某成人高校招生信息系統(tǒng)分析與設(shè)計(jì)［D］.北京：北京郵電大學(xué)，2011：32-49.

［5］ 王楓，石冰心，羅莉敏.UML 建模機(jī)制研究及在系統(tǒng)需求分析中的應(yīng)用［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2005（4）：27-29.

［6］ 孫鐵昆，楊新軒.管理信息系統(tǒng)需求管理工具的研究與實(shí)現(xiàn)［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2006（12）：53-57.

［7］ 郝建青，張仲義.信息系統(tǒng)需求分析方法研究［J］.管理工程學(xué)報(bào)，2001（2）：13-16.

［8］ 王小明，馮德民.信息系統(tǒng)需求分析的面向?qū)ο髮哟畏治龇椒皯?yīng)用［J］.計(jì)算機(jī)工程與應(yīng)用，2001（3）：67-71.

［9］ 賈曉輝，韓愷，樂嘉錦.基于UML 的系統(tǒng)需求分析［J］.計(jì)算機(jī)應(yīng)用與軟件，2007（8）：45-49.

［10］劉峰，王潁，伊文敏. UML 在信息管理系統(tǒng)需求分析中的應(yīng)用［J］.河北建筑工程學(xué)院學(xué)報(bào)，2006（2）：46-50.

［11］徐建民，劉進(jìn)坡，邵艷華.一種基于UML 的信息系統(tǒng)需求分析方法［J］.河北大學(xué)學(xué)報(bào)(自然科學(xué)版)，2005（2）：46-50.

［12］張?zhí)?，劉珊艷.UML在系統(tǒng)需求分析中的應(yīng)用［J］.長(zhǎng)江大學(xué)學(xué)報(bào)（自然科學(xué)版），2006（1）：23-25.

［13］楊志磊，秦曉，楊新軒.基于自定義狀態(tài)機(jī)制的需求管理工具的研究與實(shí)現(xiàn)［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2005（4）：84-88.

［14］謝越偉.軍用軟件需求工程中部隊(duì)用戶的地位與作用研究［J］.軍事運(yùn)籌與系統(tǒng)工程，2004（1）：3-7.

［15］馬麗，李平.信息管理系統(tǒng)開發(fā)中的需求管理過程實(shí)踐［J］.微計(jì)算機(jī)信息，2006（4）：13-17.