企業(yè)管理軟件的需求描述方法
作者：任甲林 出處：SoftDriver.com.cn
需求是整個(gè)軟件項目最關(guān)鍵的一個(gè)輸入，據統計，不成功的項目中有37%的問(wèn)題是由需求造成的。和傳統的硬件生產(chǎn)企業(yè)相比較，軟件的需求具有模糊性、不確定性、變化性和主觀(guān)性的特點(diǎn)，在硬件生產(chǎn)企業(yè)中，產(chǎn)品的需求是明確的、有形的、客觀(guān)的、可描述的、可檢測的，而軟件需求不具備此特征。需求文檔作為客戶(hù)和開(kāi)發(fā)人員、開(kāi)發(fā)人員之間進(jìn)行交互的文檔，它將系統的需求進(jìn)行了“固化”，是需求的載體，其作用是至關(guān)重要的。筆者結合多年的企業(yè)管理信息系統的開(kāi)發(fā)經(jīng)驗，總結了如下的需求描述的方法與經(jīng)驗，供各位同行參考。
1 構成企業(yè)管理信息系統的5個(gè)基本要素
對企業(yè)需求的描述可以從2個(gè)方面來(lái)進(jìn)行描述，一個(gè)方面是對客戶(hù)現行系統的描述，一個(gè)方面是對系統未來(lái)的設想?？偟亩?，無(wú)論是從那個(gè)方面來(lái)描述，構成企業(yè)信息系統主要包括5個(gè)基本要素：企業(yè)的組織結構、流程、數據、商務(wù)規則與功能（性能）。其中從用戶(hù)的角度主要關(guān)注流程，是以流程為核心的，通過(guò)流程將其他幾個(gè)要素貫穿起來(lái)，需求分析人員也應該從這個(gè)角度來(lái)和用戶(hù)溝通；從開(kāi)發(fā)者的角度主要關(guān)注企業(yè)的數據、商務(wù)規則與功能，以便于系統的實(shí)現；從實(shí)施者的角度主要關(guān)注企業(yè)的組織結構與功能，以便于系統的發(fā)布與實(shí)施。
1） 企業(yè)的組織模型
即企業(yè)的組織結構關(guān)系，包括部門(mén)設置、崗位設置、崗位職責等。樹(shù)型組織結構圖是描述企業(yè)的組織模型的一種常用方法，它可用來(lái)搞清各部門(mén)之間的領(lǐng)導關(guān)系,每個(gè)部門(mén)內部的人員配備情況, 職責分工等情況,它是劃分系統范圍,進(jìn)行系統網(wǎng)絡(luò )規劃的基礎。在組織結構圖中應將用戶(hù)的組織結構逐層詳細描述，每個(gè)部門(mén)的職責也應進(jìn)行簡(jiǎn)單的描述。組織結構是用戶(hù)企業(yè)業(yè)務(wù)流程與信息的載體，對分析人員理解企業(yè)的業(yè)務(wù)、確定系統范圍具有很好的幫助。取得用戶(hù)的組織結構圖，是需求獲取步驟中的基礎工作之一。
用戶(hù)環(huán)境中的企業(yè)崗位或角色，和組織機構一樣，也是分析人員理解企業(yè)業(yè)務(wù)的基礎，也是分析人員提取對象的基礎。
對用戶(hù)角色的識別常常遺漏的是計算機系統的系統管理人員，角色識別不全，對以后的功能識別會(huì )造成盲區。
（2） 企業(yè)的流程模型
即企業(yè)的業(yè)務(wù)流程，包含哪些流程、流程之間的關(guān)系、每個(gè)流程中包括哪些活動(dòng)、每個(gè)活動(dòng)涉及到的崗位。企業(yè)的作業(yè)流程首先要有一個(gè)總的業(yè)務(wù)流程圖，將企業(yè)中各種業(yè)務(wù)之間的關(guān)系描述出來(lái)，然后對每種業(yè)務(wù)進(jìn)行詳細的描述，使業(yè)務(wù)流程與部門(mén)職責結合起來(lái)。詳細業(yè)務(wù)流程圖可以采用直式業(yè)務(wù)流程圖形式。對企業(yè)而言需要定義關(guān)于業(yè)務(wù)流程圖的描述標準，大家采用相同的圖例來(lái)描述，便于管理。
業(yè)務(wù)流程圖的優(yōu)點(diǎn) :
■繪圖的過(guò)程,實(shí)際上是作業(yè)流程條理化的過(guò)程
■表達形象直觀(guān),易于和用戶(hù)交流,易于項目組內部交流調研的結果,需要得到用戶(hù)的認同,這就需要和用戶(hù)交流調研的結果,交流的文檔要通俗、易懂, 不能采用專(zhuān)業(yè)術(shù)語(yǔ)。
■可以作為培訓實(shí)施人員與技術(shù)服務(wù)人員的文檔
業(yè)務(wù)流程圖的缺點(diǎn) :
■對高層管理人員的實(shí)際需求調查的不清楚.
這一方面是由于用戶(hù)沒(méi)有接觸過(guò)計算機, 對采用計算機后的管理會(huì )是什么樣子?計算機能夠完成當前手工操作的哪些內容?能夠作哪些現在手工無(wú)法完成的工作等等沒(méi)有清楚的概念,因此用戶(hù)無(wú)法將這些問(wèn)題反應出來(lái). 另一方面說(shuō)明分析人員沒(méi)有經(jīng)驗,對原始材料挖掘不深,不能從用戶(hù) 提供的材料中提煉處來(lái)用戶(hù)的真正需求,不能找到當前管理中的問(wèn)題。
■對各種業(yè)務(wù)之間的總體關(guān)系沒(méi)有表達出來(lái).
采用直式業(yè)務(wù)流程圖可以將企業(yè)的每一種業(yè)務(wù)的處理流程清楚地表達出來(lái), 但是各業(yè)務(wù)之間的聯(lián)系卻沒(méi)有表示出來(lái),單看一種業(yè)務(wù)的流程圖很清楚,但是卻不能綜合在一起,沒(méi)有整體的概念,作為需求分析的文檔,在這方面表達的不夠完整。
■在不利用工具的情況下,畫(huà)法煩瑣。
圖形可以將流程描述的很清楚，但是還要附加以一些文字說(shuō)明，如關(guān)于業(yè)務(wù)發(fā)生的頻率、意外事故的處理、高峰期的業(yè)務(wù)頻率等，不能在流程圖中描述出的內容，需要用文字進(jìn)行詳細描述。
（3） 企業(yè)的數據模型
即企業(yè)中的信息載體有哪些？以及對這些信息載體的詳細刻畫(huà)，包括企業(yè)的各種單據、帳本、報表的描述。在需求報告中，應該將單據的描述格式化，需要描述的內容包括：
單據的用途，即單據用在什么地方？
單據的格式：需要明確的畫(huà)出來(lái)，并有實(shí)際的有數據的樣例，能夠具體直觀(guān)地說(shuō)明問(wèn)題；
單據中的數據項的具體描述：長(cháng)度、類(lèi)型、計算生成方法、約束條件等；
單據的數據項是由哪些不同類(lèi)型的角色來(lái)填寫(xiě)地，包括用計算機可以填那些數據項。
單據中哪些數據是必填的，哪些是可以不用填的。
單據流量：平均每天產(chǎn)生多少條記錄，高峰期的數量；
單據的分類(lèi)：可以從多個(gè)角度上進(jìn)行分類(lèi)，如：按業(yè)務(wù)類(lèi)型來(lái)分類(lèi)（采購/銷(xiāo)售/生產(chǎn)），按生成的方式來(lái)分類(lèi)（手工錄入型/自動(dòng)生成型），按格式變化的頻繁程度來(lái)分類(lèi)（易變型/穩定型），按表現形式來(lái)分類(lèi)（列表型/卡片型）等等。
單據之間的關(guān)系：引用關(guān)系等等。
同樣對于需要的報表與帳本也可以參照上面的條目進(jìn)行詳細的刻畫(huà)。
（4） 企業(yè)的商務(wù)規則模型
即企業(yè)中的商務(wù)規則有哪些?這些規則用在哪些地方? 商務(wù)規則可以從影響的范圍劃分為2類(lèi)：一類(lèi)是局部的規則，如不允許出現負庫存，一類(lèi)是整體的規則，如對所有的物料管理到批次。商務(wù)規則一般是隱藏在功能模型或者流程模型中，不需要單獨描述，但是有些復雜的商務(wù)規則是需要單獨抽取出來(lái)描述，如企業(yè)的各種單據記帳的商務(wù)邏輯，5）企業(yè)的功能模型
功能需求是用戶(hù)的最主要的需求，對用戶(hù)功能需求的描述可以采用文字描述也可以采用語(yǔ)言加圖形的描述方式，只要能夠將用戶(hù)的需求描述地完整、準確、易于理解即可。對功能需求比較復雜的系統（如超過(guò)10個(gè)功能項），可以先描述一個(gè)概要，對簡(jiǎn)單的系統可以直接進(jìn)行詳細描述。對于用戶(hù)的功能需求要進(jìn)行分類(lèi)，分類(lèi)的方法應便于用戶(hù)理解，如按照用戶(hù)的部門(mén)設置情況，進(jìn)行描述每個(gè)部門(mén)的需求，這樣也便于組織用戶(hù)進(jìn)行評審。以下是分類(lèi)方法的舉例：
按部門(mén)分類(lèi)：如采購科、銷(xiāo)售科、計劃科、生產(chǎn)車(chē)間、財務(wù)科、統計科、總經(jīng)理等；
按功能類(lèi)型分類(lèi)：如單據錄入、單據審核、單據查詢(xún)、記帳、帳本查詢(xún)、統計報表、系統維護等。
對功能需求的分類(lèi)在不同的層次可以采用不同的方法。
對每一項功能應有一個(gè)功能編號，以便于與功能規格說(shuō)明書(shū)中的章節進(jìn)行對應。對每一項功能的描述，應指明用戶(hù)的輸入(input)、處理方法（process）、系統的輸出(output)及對此項功能的其他要求。功能需求還應注明使用此功能的崗位。對系統管理員要求的特殊功能可以在此注明，非特殊要求可以在需求分析規格說(shuō)明書(shū)中詳細論述。如用戶(hù)權限可分級，要有操作日志等。
功能需求與性能需求是密不可分的，籠統的性能需求沒(méi)有任何意思，必須具體到某項功能需求上來(lái)，這是分析人員在分析系統時(shí)容易忽略的一項。
對上述的5個(gè)基本元素可以將他們描述為一個(gè)五元組〈組織，流程，功能，數據，業(yè)務(wù)邏 輯〉，對于用戶(hù)來(lái)講，他們習慣于從組織維來(lái)看待系統，即某個(gè)部門(mén)有哪些崗位，每個(gè)崗位參與了哪些流程的哪些活動(dòng)（功能），在某個(gè)功能上操作了哪些數據，對這些數據進(jìn)行了哪些邏輯處理；對于開(kāi)發(fā)人員習慣于從功能維來(lái)看待系統，即某個(gè)功能操作了哪些數據，對這些數據進(jìn)行了哪些邏輯處理，這個(gè)功能屬于哪個(gè)流程，可以由哪些崗位來(lái)使用；對于設計人員可能習慣于從數據維來(lái)看待系統：即系統中有哪些數據，在這些數據上可以做哪些處理，這些處理用OO的思想來(lái)看即是對數據對象的操作。
對以上的5個(gè)基本元素進(jìn)行描述實(shí)際上就是系統建模的過(guò)程，為確保模型的可操作性，除了上面的5個(gè)基本要素外，還需要重點(diǎn)描述的內容有：
（1） 新系統對應用模式帶來(lái)的變化
包括對企業(yè)的組織結構、作業(yè)流程、單據帳本報表等的格式、商務(wù)規則等的改變。
（2） 新系統的界面模型
用開(kāi)發(fā)工具將用戶(hù)操作界面快速畫(huà)出來(lái)，使用戶(hù)心中有數。若時(shí)間允許，可將界面原型與數據庫表、字段連接起來(lái)，真正做出系統雛形，即快速原型法。
2 閱讀需求文檔的4類(lèi)讀者
需求報告的最終目的是給人來(lái)閱讀的，所以一定要考慮需求報告的讀者群，有4類(lèi)角色可能閱讀企業(yè)管理系統的需求文檔：
客戶(hù)與用戶(hù)業(yè)務(wù)高層；
用戶(hù)的中層管理人員與具體人員；
用戶(hù)IT主管與開(kāi)發(fā)人員，包括設計人員、編碼人員、同行的專(zhuān)家；
項目管理人員：包括項目經(jīng)理、質(zhì)量保證人員、測試人員、需求管理員、配置管理員、計劃人員等等；
不同的讀者對文檔的閱讀需求是不同的，他們關(guān)注的信息是不同的。我見(jiàn)過(guò)了很多次需求評審的失?。ㄈ绻龊眯枨笤u審我會(huì )另外再撰文描述），總結下來(lái)我認為和需求描述沒(méi)有區分讀者群是很有關(guān)系的。針對上述的4種分類(lèi)，我們具體的來(lái)分析一下每類(lèi)讀者的特點(diǎn)：
（1） 客戶(hù)與用戶(hù)業(yè)務(wù)高層
他們關(guān)心的企業(yè)是系統的目標性需求，關(guān)心的是系統總體的功能框架，關(guān)心的是系統解決了哪些管理問(wèn)題，對具體的需求是不關(guān)心的，所以給他們閱讀的文檔應該是從總體上來(lái)描述，要高度抽象。由于他們的工作很忙，很難有比較長(cháng)的時(shí)間來(lái)讀這些材料，所以要簡(jiǎn)短明了，能夠用1頁(yè)紙說(shuō)明問(wèn)題的就要不要用2頁(yè)紙，而且一般都要給高層進(jìn)行需求匯報，需要配上語(yǔ)言說(shuō)明，因此采用PowerPiont片子也就成了一種常用的方法，講解需求與討論一般應掌握不要超過(guò)1小時(shí)。需求人員常犯的毛病是過(guò)多地關(guān)注了企業(yè)的細節性需求，而忽略系統的目標性需求，所以在安排需求獲取的步驟上、需求報告的編寫(xiě)上往往沒(méi)有抓住企業(yè)高層最關(guān)心的問(wèn)題、沒(méi)有抓住根本性的問(wèn)題，在給企業(yè)的高層匯報時(shí)當然很難通過(guò)評審。
（2）用戶(hù)的中層管理人員與具體人員
企業(yè)的中層管理人員關(guān)注的是企業(yè)的局部需求，他們要求對自己的負責的局部系統能夠有總體的了解，能夠和其他的子系統銜接的很好，業(yè)務(wù)流程很流暢，覆蓋了自己需要的所有業(yè)務(wù)流程，能夠通過(guò)系統起到控制作用就行了。具體的操作人員更關(guān)心自己的的哪些活動(dòng)是否在系統中都能處理，軟件是否可以很容易地操作，他們關(guān)注的焦點(diǎn)更具體，要求更直觀(guān)。所以對這類(lèi)的讀者可以通過(guò)比較詳細的文檔來(lái)描述需求了，當然應該以他們習慣的思維方式來(lái)描述，不能從開(kāi)發(fā)人員的角度來(lái)描述。我看到過(guò)很多幾百頁(yè)的需求文檔給用戶(hù)去閱讀、去評審，結果要么用戶(hù)不置可否，要么直接講看不懂，為什么呢？一是開(kāi)發(fā)人員在文檔中分子系統、分模塊、分功能點(diǎn)一層深入下去描述，不符合用戶(hù)的思維習慣，他們希望能夠從業(yè)務(wù)流程、業(yè)務(wù)活動(dòng)的角度來(lái)考慮問(wèn)題，而不是功能；二是太多了，用戶(hù)也沒(méi)有時(shí)間靜下心來(lái)去消化、吸收如此多的文檔，需求畢竟不是小說(shuō)，能夠那么吸引讀者。
（3）用戶(hù)IT主管與開(kāi)發(fā)人員，包括設計人員、編碼人員、同行的專(zhuān)家
大多數分析人員可能最擅長(cháng)的就是些寫(xiě)這類(lèi)的文檔了，往往也是那這類(lèi)的文檔給所有的讀者看，其問(wèn)題我們上邊都說(shuō)了，這里我們就不贅述了。
需要注意的是在描述需求時(shí)候傳統的做法是以功能為主線(xiàn)，來(lái)展開(kāi)描述，實(shí)際上如果是以數據為主線(xiàn)來(lái)描述需求也是一種很好的辦法，在我們上面談到的五元組中，從數據的角度來(lái)分析系統可以更容易實(shí)現向OOA、OOD的切換。
（4） 項目管理人員：包括項目經(jīng)理、質(zhì)量保證人員、測試人員、需求管理員、配置管理員、計劃人員等等
把拿給開(kāi)發(fā)人員看的需求文檔給管理人員看，這也是分析人員常犯的毛病。管理人員實(shí)際上最關(guān)心的是需求列表。
在此基礎上項目經(jīng)理、質(zhì)量保證人員可以據此來(lái)進(jìn)入項目策劃過(guò)程，測試人員可據此進(jìn)入測試策劃過(guò)程，需求管理員、配置管理員可以識別配置項制定相關(guān)的活動(dòng)計劃。沒(méi)有這張表管理人員就很難高效地開(kāi)展他們的管理活動(dòng)，也就談不到最基本的需求復用了。在上述的表中，需求的優(yōu)先級是很重要的一列，對項目經(jīng)理進(jìn)行項目管理的平衡決策是很重要的，實(shí)際上需求的優(yōu)先級可能比需求本身更重要。
3 需求描述的表示技巧
上面我們談到了，需求文檔是人與人之間交互的文檔，是不同類(lèi)型的人之間交互的文檔，因此需求文檔的可讀性是一個(gè)很重要的方面，為了提高文檔的可讀性可以借鑒下面的一些做法：
在文檔的描述中，適當運用鏈接，增強文檔的可讀性；
多用窮舉的方式，以便于發(fā)現遺漏的需求；
通過(guò)適當的換行來(lái)提高可讀性 ；
采用黑體、斜體、下劃線(xiàn)、顏色等多種方式來(lái)突出重要內容；
定義標準的術(shù)語(yǔ)，以減少二義性，減少文檔的頁(yè)數；
在功能需求的描述中，對于類(lèi)似的、統一的功能可以單獨地進(jìn)行詳細描述，其他地方進(jìn)行引用，或做為術(shù)語(yǔ)進(jìn)行定義，以簡(jiǎn)化文檔，減少重復。如；
2 錄入功能
2 打印功能
2 條件查詢(xún)功能
2 排序功能等等
結 語(yǔ)
盡管你按照上述的方法去做了，也不要期望能夠編寫(xiě)出一份能體現需求應具備的所有特性的文檔，無(wú)論你如何去細化、分析、評論和優(yōu)化需求，都不可能達到完美，但是你能夠做到“可接受”，寫(xiě)一份客戶(hù)、用戶(hù)、開(kāi)發(fā)人員、管理人員都認可的一份需求，而不是完美的需求！
