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

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html