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