一、大家心目中的需求
1. 客戶：對他們業務描述正確的、詳細的需求，需求所描述的系統能真真正正解決他們的問題，切切實實讓他們省力省心。
2. 開發人員：通過需求能最清楚的知道業務的流程和系統的樣子；需求無歧義，按照需求開發出來的系統是客戶想要的；容易實現，比如不要爲一個可有可無的字段寫很多程序，查很多數據庫表。
3. 需求人員：用最少的文字、最簡單的圖表描述清楚業務和系統，讓客戶滿意，讓開發人員和測試人員清楚系統的樣子。
二、談談開發人員想要的需求。
現在的需求已經非常的好了，我求全責備總結了以下幾點建議：
1、 集中描述：<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
由於種種原因我們的需求很厚，開發人員是不希望看到二三百頁的需求，所以折中，建議把開發人員關心的部分集中描述，可以集中在兩個部分，不看仔細研究其他部分也不會遺漏規則。
（1） 系統通用規則部分，在這裏把所有系統共性的東西描述清楚，比如日期格式、權限控制、數值精度等等。
（2） 功能分析部分，在這一部分中，
Ø 模塊業務流程圖，能做到描述清楚業務邏輯，尤其是複雜的，不是常規操作的更要詳細描述，如果畫圖困難可以在業務規則中用文字補充詳細。
Ø 數據描述（界面元素說明部分），這部分非常好了，但是很重要所以強調下：輸入輸出描述清楚、輸出的數據來源描述清楚、非部標的字典描述清楚。
Ø 業務規則，這部分是最核心的業務描述了，開發中最多的時間是耗在這部分的實現上。建議如下:
A. 不要出現“業務規則同其他規則”的描述，不要出現“在其他業務規則上增加以下規則”的描述，如果規則有交叉，建議把規則拷貝過來不要引用位置。
B. 規則的描述與“數據描述（界面元素說明部分）”要保持一直。
C. 對於日期、年齡、天數等數值範圍的描述要清楚，是否含當天這類有歧義的地方要說清楚，複雜的最好舉個例子。
D. 規則描述的順序要合理，儘量按照頁面上的“查詢”、“新增”、“修改”、“導入”、“導出”等操作順序描述。
2、 需求評審：
對於業務較多、較複雜的需求，複雜報表類的需求。通過開發人員看需求，然後再用兩三個小時去評審，對於及時發現問題和讓開發人員完全理解需求是不夠的。建議需求人員先講解需求，開發人員研習需求，最後需求評審。由於開發人員能否完全理解需求人員所描述的需求對於開發出成功的系統很關鍵，對於複雜的系統又不可能用文字描述的沒有遺漏沒有歧義，所以建議在需求評審上增加需求講解這個步驟和評審的時間。
3、 開發過程的需求問題
開發過程中最能看到需求的問題，尤其是那些深層的業務規則是否有問題，規格說明書各個部分之間是否有矛盾，往往是在開發時才發現，但這時需求規格說明書客戶又已經簽字，不能來來回回的修改需求說明書，但這些問題很重要必須記錄下來，口頭上交流很容易遺忘漏掉，所以建議用規範的文檔記錄下這些變更，方便以後測試和一次性補充修改需求規格說明書。
4、上線維護期間的需求問題
上線後客戶往往發現系統不完美，這個地方優化下，那個地方改變下，即使我們需求變更的問題不修改，但時間一長優化的問題一多，需求和系統差別就大了。如果以後再按照新的政策，在原來的系統上開發新系統就會出問題，尤其是在系統和需求不一直的時候再去提交測試，這時候測試部和配合測試的人員就浪費了很多時間糾纏在需求和系統不一致的缺陷上。所以建議上線後也要有規範的文檔來記錄系統的變更。
總之：需求人員能準確的通過需求規格說明書描述客戶的需求，設計出功能全操作簡易的系統；開發人員能清楚的瞭解需求所描述的系統，開發出和需求一直的系統；需求規格說明書和需求變更記錄形成需求體系，這個體系與我們系統保持同步性、一致性。