企業(yè)需求管理及描述方法

1、.需求是整個軟件項目最關(guān)鍵的一個輸入，據(jù)統(tǒng)計，不成功的項目中有37%的問題是由需求造成的。和傳統(tǒng)的硬件生產(chǎn)企業(yè)相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點，在硬件生產(chǎn)企業(yè)中，產(chǎn)品的需求是明確的、有形的、客觀的、可描述的、可檢測的，而軟件需求不具備此特征。需求文檔作為客戶和開發(fā)人員、開發(fā)人員之間進行交互的文檔，它將系統(tǒng)的需求進行了“固化”，是需求的載體，其作用是至關(guān)重要的。筆者結(jié)合多年的企業(yè)管理信息系統(tǒng)的開發(fā)經(jīng)驗，總結(jié)了如下的需求描述的方法與經(jīng)驗，供各位同行參考。1 構(gòu)成企業(yè)管理信息系統(tǒng)的5個基本要素     對企業(yè)需求

2、的描述可以從2個方面來進行描述，一個方面是對客戶現(xiàn)行系統(tǒng)的描述，一個方面是對系統(tǒng)未來的設(shè)想?？偟亩?，無論是從那個方面來描述，構(gòu)成企業(yè)信息系統(tǒng)主要包括5個基本要素：企業(yè)的組織結(jié)構(gòu)、流程、數(shù)據(jù)、商務(wù)規(guī)則與功能（性能）。其中從用戶的角度主要關(guān)注流程，是以流程為核心的，通過流程將其他幾個要素貫穿起來，需求分析人員也應(yīng)該從這個角度來和用戶溝通；從開發(fā)者的角度主要關(guān)注企業(yè)的數(shù)據(jù)、商務(wù)規(guī)則與功能，以便于系統(tǒng)的實現(xiàn)；從實施者的角度主要關(guān)注企業(yè)的組織結(jié)構(gòu)與功能，以便于系統(tǒng)的發(fā)布與實施。1） 企業(yè)的組織模型     即企業(yè)的組織結(jié)構(gòu)關(guān)系，包括部門設(shè)置、

3、崗位設(shè)置、崗位職責等。樹型組織結(jié)構(gòu)圖是描述企業(yè)的組織模型的一種常用方法，它可用來搞清各部門之間的領(lǐng)導(dǎo)關(guān)系,每個部門內(nèi)部的人員配備情況, 職責分工等情況,它是劃分系統(tǒng)范圍,進行系統(tǒng)網(wǎng)絡(luò)規(guī)劃的基礎(chǔ)。在組織結(jié)構(gòu)圖中應(yīng)將用戶的組織結(jié)構(gòu)逐層詳細描述，每個部門的職責也應(yīng)進行簡單的描述。組織結(jié)構(gòu)是用戶企業(yè)業(yè)務(wù)流程與信息的載體，對分析人員理解企業(yè)的業(yè)務(wù)、確定系統(tǒng)范圍具有很好的幫助。取得用戶的組織結(jié)構(gòu)圖，是需求獲取步驟中的基礎(chǔ)工作之一。用戶環(huán)境中的企業(yè)崗位或角色，和組織機構(gòu)一樣，也是分析人員理解企業(yè)業(yè)務(wù)的基礎(chǔ)，也是分析人員提取對象的基礎(chǔ)。     對用

4、戶角色的識別常常遺漏的是計算機系統(tǒng)的系統(tǒng)管理人員，角色識別不全，對以后的功能識別會造成盲區(qū)。（2） 企業(yè)的流程模型     即企業(yè)的業(yè)務(wù)流程，包含哪些流程、流程之間的關(guān)系、每個流程中包括哪些活動、每個活動涉及到的崗位。企業(yè)的作業(yè)流程首先要有一個總的業(yè)務(wù)流程圖，將企業(yè)中各種業(yè)務(wù)之間的關(guān)系描述出來，然后對每種業(yè)務(wù)進行詳細的描述，使業(yè)務(wù)流程與部門職責結(jié)合起來。詳細業(yè)務(wù)流程圖可以采用直式業(yè)務(wù)流程圖形式。對企業(yè)而言需要定義關(guān)于業(yè)務(wù)流程圖的描述標準，大家采用相同的圖例來描述，便于管理。業(yè)務(wù)流程圖的優(yōu)點 :  

5、0; 繪圖的過程,實際上是作業(yè)流程條理化的過程    表達形象直觀,易于和用戶交流,易于項目組內(nèi)部交流調(diào)研的結(jié)果,需要得到用戶的認同,這就需要和用戶交流調(diào)研的結(jié)果,交流的文檔要通俗、易懂, 不能采用專業(yè)術(shù)語。    可以作為培訓(xùn)實施人員與技術(shù)服務(wù)人員的文檔業(yè)務(wù)流程圖的缺點 :    對高層管理人員的實際需求調(diào)查的不清楚.這一方面是由于用戶沒有接觸過計算機, 對采用計算機后的管理會是什么樣子?計算機能夠完成當前手工操作的哪些內(nèi)容?能夠作哪

6、些現(xiàn)在手工無法完成的工作等等沒有清楚的概念,因此用戶無法將這些問題反應(yīng)出來. 另一方面說明分析人員沒有經(jīng)驗,對原始材料挖掘不深,不能從用戶   提供的材料中提煉處來用戶的真正需求,不能找到當前管理中的問題。    對各種業(yè)務(wù)之間的總體關(guān)系沒有表達出來.采用直式業(yè)務(wù)流程圖可以將企業(yè)的每一種業(yè)務(wù)的處理流程清楚地表達出來, 但是各業(yè)務(wù)之間的聯(lián)系卻沒有表示出來,單看一種業(yè)務(wù)的流程圖很清楚,但是卻不能綜合在一起,沒有整體的概念,作為需求分析的文檔,在這方面表達的不夠完整。   

7、0;在不利用工具的情況下,畫法煩瑣。     圖形可以將流程描述的很清楚，但是還要附加以一些文字說明，如關(guān)于業(yè)務(wù)發(fā)生的頻率、意外事故的處理、高峰期的業(yè)務(wù)頻率等，不能在流程圖中描述出的內(nèi)容，需要用文字進行詳細描述。（3） 企業(yè)的數(shù)據(jù)模型      即企業(yè)中的信息載體有哪些？以及對這些信息載體的詳細刻畫，包括企業(yè)的各種單據(jù)、帳本、報表的描述。在需求報告中，應(yīng)該將單據(jù)的描述格式化，需要描述的內(nèi)容包括：   單據(jù)的用途，即單據(jù)用在什么地方？ &

8、#160; 單據(jù)的格式：需要明確的畫出來，并有實際的有數(shù)據(jù)的樣例，能夠具體直觀地說明問題；   單據(jù)中的數(shù)據(jù)項的具體描述：長度、類型、計算生成方法、約束條件等；   單據(jù)的數(shù)據(jù)項是由哪些不同類型的角色來填寫地，包括用計算機可以填那些數(shù)據(jù)項。   單據(jù)中哪些數(shù)據(jù)是必填的，哪些是可以不用填的。   單據(jù)流量：平均每天產(chǎn)生多少條記錄，高峰期的數(shù)量；   單據(jù)的分類：可以從多個角度上進行分類，如：按業(yè)務(wù)類型來分類（采購/銷售/生產(chǎn)），按生成的方

9、式來分類（手工錄入型/自動生成型），按格式變化的頻繁程度來分類（易變型/穩(wěn)定型），按表現(xiàn)形式來分類（列表型/卡片型）等等。   單據(jù)之間的關(guān)系：引用關(guān)系等等。    同樣對于需要的報表與帳本也可以參照上面的條目進行詳細的刻畫。（4） 企業(yè)的商務(wù)規(guī)則模型     即企業(yè)中的商務(wù)規(guī)則有哪些?這些規(guī)則用在哪些地方? 商務(wù)規(guī)則可以從影響的范圍劃分為2類：一類是局部的規(guī)則，如不允許出現(xiàn)負庫存，一類是整體的規(guī)則，如對所有的物料管理到批次。商務(wù)規(guī)則一般是隱藏在功能模型或

10、者流程模型中，不需要單獨描述，但是有些復(fù)雜的商務(wù)規(guī)則是需要單獨抽取出來描述，如企業(yè)的各種單據(jù)記帳的商務(wù)邏輯，5）企業(yè)的功能模型功能需求是用戶的最主要的需求，對用戶功能需求的描述可以采用文字描述也可以采用語言加圖形的描述方式，只要能夠?qū)⒂脩舻男枨竺枋龅赝暾蚀_、易于理解即可。對功能需求比較復(fù)雜的系統(tǒng)（如超過10個功能項），可以先描述一個概要，對簡單的系統(tǒng)可以直接進行詳細描述。對于用戶的功能需求要進行分類，分類的方法應(yīng)便于用戶理解，如按照用戶的部門設(shè)置情況，進行描述每個部門的需求，這樣也便于組織用戶進行評審。以下是分類方法的舉例：   按部門分類：如采購科、銷售科、

11、計劃科、生產(chǎn)車間、財務(wù)科、統(tǒng)計科、總經(jīng)理等；   按功能類型分類：如單據(jù)錄入、單據(jù)審核、單據(jù)查詢、記帳、帳本查詢、統(tǒng)計報表、系統(tǒng)維護等。  對功能需求的分類在不同的層次可以采用不同的方法。對每一項功能應(yīng)有一個功能編號，以便于與功能規(guī)格說明書中的章節(jié)進行對應(yīng)。對每一項功能的描述，應(yīng)指明用戶的輸入(input)、處理方法（process）、系統(tǒng)的輸出(output)及對此項功能的其他要求。功能需求還應(yīng)注明使用此功能的崗位。對系統(tǒng)管理員要求的特殊功能可以在此注明，非特殊要求可以在需求分析規(guī)格說明書中詳細論述。如用戶權(quán)限可分級，要有操作日志等。

12、0;    功能需求與性能需求是密不可分的，籠統(tǒng)的性能需求沒有任何意思，必須具體到某項功能需求上來，這是分析人員在分析系統(tǒng)時容易忽略的一項。     對上述的5個基本元素可以將他們描述為一個五元組組織，流程，功能，數(shù)據(jù)，業(yè)務(wù)邏   輯，對于用戶來講，他們習慣于從組織維來看待系統(tǒng)，即某個部門有哪些崗位，每個崗位參與了哪些流程的哪些活動（功能），在某個功能上操作了哪些數(shù)據(jù)，對這些數(shù)據(jù)進行了哪些邏輯處理；對于開發(fā)人員習慣于從功能維來看待系統(tǒng)，即某個功能操作了哪些數(shù)據(jù)，對這些數(shù)據(jù)進行

13、了哪些邏輯處理，這個功能屬于哪個流程，可以由哪些崗位來使用；對于設(shè)計人員可能習慣于從數(shù)據(jù)維來看待系統(tǒng)：即系統(tǒng)中有哪些數(shù)據(jù)，在這些數(shù)據(jù)上可以做哪些處理，這些處理用OO的思想來看即是對數(shù)據(jù)對象的操作。    對以上的5個基本元素進行描述實際上就是系統(tǒng)建模的過程，為確保模型的可操作性，除了上面的5個基本要素外，還需要重點描述的內(nèi)容有：（1） 新系統(tǒng)對應(yīng)用模式帶來的變化包括對企業(yè)的組織結(jié)構(gòu)、作業(yè)流程、單據(jù)帳本報表等的格式、商務(wù)規(guī)則等的改變。（2） 新系統(tǒng)的界面模型     用開發(fā)工具將用戶操作

14、界面快速畫出來，使用戶心中有數(shù)。若時間允許，可將界面原型與數(shù)據(jù)庫表、字段連接起來，真正做出系統(tǒng)雛形，即快速原型法。2 閱讀需求文檔的4類讀者     需求報告的最終目的是給人來閱讀的，所以一定要考慮需求報告的讀者群，有4類角色可能閱讀企業(yè)管理系統(tǒng)的需求文檔：   客戶與用戶業(yè)務(wù)高層；   用戶的中層管理人員與具體人員；   用戶IT主管與開發(fā)人員，包括設(shè)計人員、編碼人員、同行的專家；   項目管理人員：包括項目經(jīng)理、

15、質(zhì)量保證人員、測試人員、需求管理員、配置管理員、計劃人員等等；     不同的讀者對文檔的閱讀需求是不同的，他們關(guān)注的信息是不同的。我見過了很多次需求評審的失?。ㄈ绻龊眯枨笤u審我會另外再撰文描述），總結(jié)下來我認為和需求描述沒有區(qū)分讀者群是很有關(guān)系的。針對上述的4種分類，我們具體的來分析一下每類讀者的特點：（1） 客戶與用戶業(yè)務(wù)高層      他們關(guān)心的企業(yè)是系統(tǒng)的目標性需求，關(guān)心的是系統(tǒng)總體的功能框架，關(guān)心的是系統(tǒng)解決了哪些管理問題，對具體的需求是不關(guān)心的，所以給他們閱讀的

16、文檔應(yīng)該是從總體上來描述，要高度抽象。由于他們的工作很忙，很難有比較長的時間來讀這些材料，所以要簡短明了，能夠用1頁紙說明問題的就要不要用2頁紙，而且一般都要給高層進行需求匯報，需要配上語言說明，因此采用PowerPiont片子也就成了一種常用的方法，講解需求與討論一般應(yīng)掌握不要超過1小時。需求人員常犯的毛病是過多地關(guān)注了企業(yè)的細節(jié)性需求，而忽略系統(tǒng)的目標性需求，所以在安排需求獲取的步驟上、需求報告的編寫上往往沒有抓住企業(yè)高層最關(guān)心的問題、沒有抓住根本性的問題，在給企業(yè)的高層匯報時當然很難通過評審。（2）用戶的中層管理人員與具體人員     企

17、業(yè)的中層管理人員關(guān)注的是企業(yè)的局部需求，他們要求對自己的負責的局部系統(tǒng)能夠有總體的了解，能夠和其他的子系統(tǒng)銜接的很好，業(yè)務(wù)流程很流暢，覆蓋了自己需要的所有業(yè)務(wù)流程，能夠通過系統(tǒng)起到控制作用就行了。具體的操作人員更關(guān)心自己的的哪些活動是否在系統(tǒng)中都能處理，軟件是否可以很容易地操作，他們關(guān)注的焦點更具體，要求更直觀。所以對這類的讀者可以通過比較詳細的文檔來描述需求了，當然應(yīng)該以他們習慣的思維方式來描述，不能從開發(fā)人員的角度來描述。我看到過很多幾百頁的需求文檔給用戶去閱讀、去評審，結(jié)果要么用戶不置可否，要么直接講看不懂，為什么呢？一是開發(fā)人員在文檔中分子系統(tǒng)、分模塊、分功能點一層深入下去描述，不符合

18、用戶的思維習慣，他們希望能夠從業(yè)務(wù)流程、業(yè)務(wù)活動的角度來考慮問題，而不是功能；二是太多了，用戶也沒有時間靜下心來去消化、吸收如此多的文檔，需求畢竟不是小說，能夠那么吸引讀者。（3）用戶IT主管與開發(fā)人員，包括設(shè)計人員、編碼人員、同行的專家     大多數(shù)分析人員可能最擅長的就是些寫這類的文檔了，往往也是那這類的文檔給所有的讀者看，其問題我們上邊都說了，這里我們就不贅述了。     需要注意的是在描述需求時候傳統(tǒng)的做法是以功能為主線，來展開描述，實際上如果是以數(shù)據(jù)為主線來描述需求也是一種很好的辦法

19、，在我們上面談到的五元組中，從數(shù)據(jù)的角度來分析系統(tǒng)可以更容易實現(xiàn)向OOA、OOD的切換。（4） 項目管理人員：包括項目經(jīng)理、質(zhì)量保證人員、測試人員、需求管理員、配置管理員、計劃人員等等     把拿給開發(fā)人員看的需求文檔給管理人員看，這也是分析人員常犯的毛病。管理人員實際上最關(guān)心的是需求列表。   在此基礎(chǔ)上項目經(jīng)理、質(zhì)量保證人員可以據(jù)此來進入項目策劃過程，測試人員可據(jù)此進入測試策劃過程，需求管理員、配置管理員可以識別配置項制定相關(guān)的活動計劃。沒有這張表管理人員就很難高效地開展他們的管理活動，也就談不到最基本的需求復(fù)用了。在上述的表中，需求的優(yōu)先級是很重要的一列，對項目經(jīng)理進行項目管理的平衡決策是很重要的，實際上需求的優(yōu)先級可能比需求本身更重要。3 需求描述的表示技巧     &#