參考：http://www.ibm.com/developerworks/cn/java/l-anareq/
第1章前言
目的
需求調研是為需要說明書做前期工作，可以說需要說明書說是從需求調研表中得到或抽取而出。
需求調研是要了解現實世界中做實際工作的人們真正需要什么樣的程序的過程，再把這些需求開進細節整理由設計部開發，再由銷售部銷售給用戶。
用戶：系統分析人員
第2章前期準備
2.1. 確定工具
- 沒有什么工具是好還是壞的問題，問題是關鍵是如何使用它們，無論是什么工具也只是一個輔助工具，也不是生成工具。
- 工具的選取要求是自己（本組）熟悉的工具，不能是一件最新時髦工具而自己對它了解很少，結果大部分時間化在學習工具上，而不是使用它為你工作。
- 工具最好也是要求是普通流行的，因為要考慮交流的問題。
2.2. 要做什么就要先了解什么
- 如果做的項目是你所不了解的一個行業（專業）同組有要最好有要專家----最終用戶做為這個專家是最好的，最少你有了解這個專業，不是要你成為專家，但最少要了解一定的專業知識（最少專來詞匯你要知道），不然您甚至不知道去問什么問題或者如何去問他們，甚至于人家在說什么你也不知道。
- 相應的專業資料是必須的，最少要有專業入門書籍和對應的資料，也需要求更深入的一些資料。當然有專家的參入就另當別論。
- 如果行業的難度不是很大，可以通入分析人員的自我學習在短時間內了解行業，也許可以不用專家，否則專家是必須的。
2.3. 建立設計環境
一定建立一個專門的設計環境來為本項目服務，進行一定的資源分配，進行必要的文件管理。
2.4. 真正了解自己和用戶
- 那些是用戶可能明確要達到的目地
- 要知道那些是自己能做到的，那些是自己不能做的。
- 對于不能做的處理方法，如拒絕，轉包等
- 那些是用戶想要做到的
2.5. 列出人員分配表和所有工具列表
- 明確項目人員分工
- 統一項目所用的工具
- 統一項目文件模版
- 其它資源列表（資料，相關網站，資詢電話。。。）
第3章調研過程
3.1. 搜集需求得到需求說明書
注意：
- 雖然最終必須要編成基于計算機解決方案的描述，但到目前為止，我們關注的焦點的文檔在相應領域方面的部分。
- 記住這里沒有計算機方面的行話，如果是編寫一個會計軟件，那么一位會計師都應該清楚地理解程序員寫的會計方面的問題說明書
- 需求說明書問題中，不要太正式。只要描述能表達您想要做的事情就行了，就和另外一個人在說話一樣就可以。
- 對于客戶或相應人員了解問題時，一定要有記筆記的習慣，談上幾個小時，很多細節是記不住的。
3.2. 整理，檢查和細化需求說明書
- 對于客戶的需要進行必要的整理和分類有進從用戶那里會得到很多信息，不行進必要的整理就不能從中進行合理的分析
- 分清有用功能、可選功能用、無用功能及不可實現功能對于用戶來講他可以說出他想要的很多功能，但這些功能間的關系有時是清晰的，但對于很多用戶來講想通過計算機或新系統實現他以前沒有的功能，在這時他所提出的新需求的可行性和與其它模塊之間的關系就已經不清，所以對于分析員來講，要從用戶的需求中分清有用功能和無用功能和可選功能，進行分別區分處理，比如不可實現功能請用戶放棄。
- 不要忽略明顯的錯誤用戶倒是不經常提及他需要的東西，而這些東西對問題來說都是很基本的，要細化檢查一定有注意這個問題。
- 你認為的也許不是對的對于系統分析員對需求分析的自認為的情況要加以注意，對于一個行業來說，有些規則可以不是最合理，但它就是那樣存在和使用，所以對于每一個非明確確定的需求，要由專業人員來審定。除非你就是專家。
3.3. 改進
最初的第一次需求在分析，細化一定有不明及不確定之處，那么就把整理出一份問題細化問詢表，對發現的問題進行整理，列出不明之處，可根椐以下格式
問詢人：
問題：
業務不清問題列表（業務描述不清）：
1 ….是什么含義？
2 …..與XX是什么關系？
多種選擇可以列表（請用戶進行選擇）：
1 ……有多個可能，那么現在我們使用
A …… B……. C…….. D ……
|
3.4. 審核需求
- 自我審枋
把自己從用戶的角度來考慮
是否合理，是否可以提高效率，是否可以達到目的，是否有完整
- 由用戶來評價
由最終用戶來評價你所列的需求是否達到了用戶要求（用戶人數1-3人，再多也沒有什么益處）。
- 重復過程，最終通過審核完成需求說明書
參考資料
- 標準版API 規范，JAVA 2 核心技術和其他方面的信息。