注意：
雖然最終必須要編成基于計算機解決方案的描述，但到目前為止，我們關注的焦點的文檔在相應領域方面的部分。
記住這里沒有計算機方面的行話，如果是編寫一個會計軟件，那么一位會計師都應該清楚地理解程序員寫的會計方面的問題說明書
需求說明書問題中，不要太正式。只要描述能表達您想要做的事情就行了，就和另外一個人在說話一樣就可以。
對于客戶或相應人員了解問題時，一定要有記筆記的習慣，談上幾個小時，很多細節是記不住的。
3.2. 整理，檢查和細化需求說明書
對于客戶的需要進行必要的整理和分類
有進從用戶那里會得到很多信息，不行進必要的整理就不能從中進行合理的分析
分清有用功能、可選功能用、無用功能及不可實現功能
對于用戶來講他可以說出他想要的很多功能，但這些功能間的關系有時是清晰的，但對于很多用戶來講想通過計算機或新系統實現他以前沒有的功能，在這時他所提出的新需求的可行性和與其它模塊之間的關系就已經不清，所以對于分析員來講，要從用戶的需求中分清有用功能和無用功能和可選功能，進行分別區分處理，比如不可實現功能請用戶放棄。
不要忽略明顯的錯誤
用戶倒是不經常提及他需要的東西，而這些東西對問題來說都是很基本的，要細化檢查一定有注意這個問題。
你認為的也許不是對的
對于系統分析員對需求分析的自認為的情況要加以注意，對于一個行業來說，有些規則可以不是最合理，但它就是那樣存在和使用，所以對于每一個非明確確定的需求，要由專業人員來審定。除非你就是專家。
3.3. 改進
最初的第一次需求在分析，細化一定有不明及不確定之處，那么就把整理出一份問題細化問詢表，對發現的問題進行整理，列出不明之處，可根椐以下格式
問詢人：
問題：
業務不清問題列表（業務描述不清）：
1 ….是什么含義？
2 …..與XX是什么關系？
多種選擇可以列表（請用戶進行選擇）：
1 ……有多個可能，那么現在我們使用
A …… B……. C…….. D ……
把問詢表提交用戶，根據反饋對需求再分析，這個步驟可重復多次，最終了解需求，確定需求說明書
3.4. 審核需求
自我審枋
把自己從用戶的角度來考慮
是否合理，是否可以提高效率，是否可以達到目的，是否有完整
由用戶來評價
由最終用戶來評價你所列的需求是否達到了用戶要求（用戶人數1-3人，再多也沒有什么益處）。
重復過程，最終通過審核完成需求說明書
參考資料
標準版API 規范，JAVA 2 核心技術和其他方面的信息。
關于作者
王輝，具有八年的編程及系統管理經驗，所使用的語言為C和Java 編程語言。目前在深圳一家公司做程序員，使用C和JAVA為DB2數據庫編程.可通過 ddxxkk@21cn.com 聯系。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
