一、需求調研準備：
在需求調研過程中，應該做好三種準備，保持兩種心態，做到五種提高：
三種準備
1） 調研前應該將所有專案前期資料進行彙總，與相關的前期銷售人員進行交流，以便對專案有乙個基本輪廓的認識。
2） 做好調研前使用資料的準備，如需求調研模板，需求調研問題列表等。
3） 做好不怕一切困難的準備。
兩種心態
1） 保持一種和客戶平等合作的心態，確定需求調研是為了給客戶解決問題，**問題，而不是接受問題，更不是來指導工作的。
2） 平靜面對需求變更的心態，在需求調研過程中，往往雙方對需求理解不一致，造成需求調研前後矛盾，應當心平氣和的去引導客戶，達到需求理解基本一致。
三種提高
1） 首先提高自己業務知識，對於人力資源的標準業務應該基本熟悉。
2） 其次應該努力的去熟悉使用者的行業，學習使用者使用的術語，標準，以便能夠準確的理解使用者。這就需要我們閱讀使用者所在行業的資料、文章，盡量多選取一些整體性介紹的文章，這樣可以在短時間內能夠對該行業有乙個全面的認識，這樣我們就能夠較好的和使用者進行交流了。
3） 需求調研中，學會盡量不使用it行業的術語，而採用淺顯易懂的口頭語言來解釋it行業中高深莫測的術語，以便使用者能夠很好的理解，提高自己的溝通交流能力。
4） 提高自己的速記能力，文字表述能力以及歸納，能迅速的記錄需求調研核心的問題，總結歸納形成原始的需求調研資料。
5） 提高自己的總結能力，書寫乙份完整的、前後一致的、可追蹤的需求報告。
二、需求調研過程的總體流程
需求調研中應遵循一定的流程，而且在調研過程中表現出規範，調研有條不紊，對客戶有理有據，調研中資料做好備份，做到有備無患：
三、需求調研過程中注意問題
四、需求報告書寫要求及標準
編寫優秀的需求是沒有公式化的方法的。這需要大量的經驗，要從你在過去的文件中發現的問題學習。請在組織軟體需求文件時，嚴格遵從這些方針。
句子和段落要簡練。使用正確的語法，拼寫，標點。使用術語，要保持一致性，並在術語表或資料字典中定義它們需求編寫者還要努力正確地把握粒度。多個需求盡可能拆分開。
整個需求文件細節上要保持一致。
避免在需求報告中過多的申述需求。在多處包含相同的需求可以使文件更易於閱讀，但也會給文件的維護增加困難。文件的多份文字要在同一時間內全部更新，避免不一致性。
需求調研對於系統的構造，系統測試以及最後的客戶滿意，都會成為好的奠基石。並且要記住，沒有高質量的需求，軟體就象一盒巧克力，你永遠不知道你會得到什麼。我希望我們能得到一塊「德芙」。
調研概要情況：x專案需求調研開始於2006-3-23結束於2006-6-15，內容包括現場需求調研4個人月和分析需求編寫需求文件6個人月。參與調研的包括專案經理、技術經理和兩個開發骨幹，編寫需求規格說明書字數95.4萬。
1.把二期專案當作乙個新專案來做調研，避免需求細節遺漏。在調研的初期我們曾經有過疑慮，這是乙個二期的專案，那麼調研的內容是否只針對二期的新需求，對需求內容二期和一期一致的部分就不必調研了?
經過討論我們還是決定把二期專案當作乙個新專案來做調研，即使二期和一期需求內容一致，我們也在調研會上討論，並記錄在調研筆記及以後的需求文件上。這樣的好處是最大限度地避免了需求細節的遺漏。在現場調研時，發現有不少地方原來以為是二期不必修改的，經過討論後發現還是需要修改。（往往危險的需求描述就在於「這部分做的和某個系統或某個版本的舊系統一樣就可以了」）
2.調研團隊參加所有子系統的調研會議，可以相互補充避免需求遺漏。這個專案規模比較大，根據業務的型別不同，分成了6個子系統，各個子系統的業務資訊互有介面。我們安排每個人至少負責乙個子系統的需求，但是在調研時，只要可能，我們都盡量讓每個人都參與所有系統的調研會議。對專案經理和技術經理則進一步要求了解所有系統的業務需求。這樣做的好處是，對於子系統之間的業務關係，調研團隊都可以有全面的了解，對業務的理解比較透徹全面，並且還可以相互補充遺漏。
3.多人調研，在會議後應該立刻回顧整理統一的會議筆記，消除歧義，避免遺漏。在開調研會時，全體與會人員都各自記自己的會議筆記，會後沒有強調當天整理會議筆記（會議進度很緊，每天開會到晚上8、9點鐘）。這導致以後閱讀會議筆記發現一些描述很簡單理解上有歧義的內容，或者同乙份需求在幾個筆記上記錄的內容細節上有差異，事後難以追溯正確的資訊。給編寫需求文件帶來了一些困難，需要再次討論需求。
4.需求文件編寫完成後，在開發階段也應該做檢查和更新，避免文件錯誤對開發的誤導。我們在完成大量的需求文件編寫工作後，在開發階段有部分文件沒有做內容檢查和及時更新。後期測試時才發現少數需求內容的矛盾和錯誤，導致需要重新修改。
2、應該指定人負責需求追蹤和更新，在開發階段、測試階段要保持和使用者的需求溝通，這不是乙個可有可無的簡單工作，很重要，並且會占用責任人50%的工作時間。
5.企業業務管理資訊系統的需求調研方法：我認為對調研的組織安排是非常重要的，好的調研安排雖然未必產生質量高的需求，但是乙個不遵循調研規律的調研活動，必然是低效的。下面是h專案調研組採取的調研流程，供參考：
1、第一步不是立刻和使用者當面討論需求細節，而是要業務關鍵使用者編寫初步的需求報告，提供給開發團隊閱讀分析。需求報告的內容是，對業務流程的描述，對業務需求的描述。需求報告的質量往往和關鍵使用者的投入多少有較大關係，經常在沒有面對面溝通時，關鍵使用者未必能對這份報告投入很多的時間和精力。但這是當面調研的基礎，一定要做，有粗糙疏漏的地方可以再現場調研時再細化。這可以再調研前就和使用者溝通，讓使用者編寫。
調研概要情況：x專案需求調研開始於2006-3-23結束於2006-6-15，內容包括現場需求調研4個人月和分析需求編寫需求文件6個人月。參與調研的包括專案經理、技術經理和兩個開發骨幹，編寫需求規格說明書字數95.4萬。
1.把二期專案當作乙個新專案來做調研，避免需求細節遺漏。在調研的初期我們曾經有過疑慮，這是乙個二期的專案，那麼調研的內容是否只針對二期的新需求，對需求內容二期和一期一致的部分就不必調研了?
經過討論我們還是決定把二期專案當作乙個新專案來做調研，即使二期和一期需求內容一致，我們也在調研會上討論，並記錄在調研筆記及以後的需求文件上。這樣的好處是最大限度地避免了需求細節的遺漏。在現場調研時，發現有不少地方原來以為是二期不必修改的，經過討論後發現還是需要修改。（往往危險的需求描述就在於「這部分做的和某個系統或某個版本的舊系統一樣就可以了」）
2.調研團隊參加所有子系統的調研會議，可以相互補充避免需求遺漏。這個專案規模比較大，根據業務的型別不同，分成了6個子系統，各個子系統的業務資訊互有介面。我們安排每個人至少負責乙個子系統的需求，但是在調研時，只要可能，我們都盡量讓每個人都參與所有系統的調研會議。對專案經理和技術經理則進一步要求了解所有系統的業務需求。這樣做的好處是，對於子系統之間的業務關係，調研團隊都可以有全面的了解，對業務的理解比較透徹全面，並且還可以相互補充遺漏。
3.多人調研，在會議後應該立刻回顧整理統一的會議筆記，消除歧義，避免遺漏。在開調研會時，全體與會人員都各自記自己的會議筆記，會後沒有強調當天整理會議筆記（會議進度很緊，每天開會到晚上8、9點鐘）。這導致以後閱讀會議筆記發現一些描述很簡單理解上有歧義的內容，或者同乙份需求在幾個筆記上記錄的內容細節上有差異，事後難以追溯正確的資訊。給編寫需求文件帶來了一些困難，需要再次討論需求。
4.需求文件編寫完成後，在開發階段也應該做檢查和更新，避免文件錯誤對開發的誤導。我們在完成大量的需求文件編寫工作後，在開發階段有部分文件沒有做內容檢查和及時更新。後期測試時才發現少數需求內容的矛盾和錯誤，導致需要重新修改。
軟體專案需求調研服務
作為非it業人士或非專業軟體開發人員，當您需要做乙個軟體來滿足生產、管理中的需要時，會遇到如下問題：
1、 說不清楚自己要做什麼
2、 不清楚怎麼做比較合適
3、 不知道需要花多少錢
4、 不知道需要花多少時間
5、 擔心開發機構過高估計工作量
我們在長期承接外包專案的過程中發現很多客戶都遇到了上述情況。對於這類客戶，由於對需求情況的無法把握而導致很多意向不到的麻煩，甚至花了大錢做了小事。鑑於服務客戶的經營宗旨，我們推出「軟體專案需求調研」服務，通過專業的軟體需求分析人員幫助客戶進行需求調研工作，以促進軟體外包行業的健康穩定的發展。
服務物件：企事業單位、個人
服務前提：
1、 需要開發軟體
2、 對軟體開發不了解
3、 時間緊，來不及調研
4、 專案太大，不容易調研
服務用途：
1、 了解確切的開發需求，確保開發專案的成功應用；
2、 了解開發的工作量和週期，可以進行時間上的統籌安排；
3、 了解大體的開發費用，為和開發方的商務談判提供理論依據；
4、 了解軟體驗收的標準和步驟，確保軟體的質量可靠，用的舒心。
合作步驟：
n 意向性溝通
就調研物件和調研費用協商一致後，簽訂合作協議，明確雙方權責。
n 商務操作
u 付30%定金
u 詳細需求調研
u 文件整理—開發內容、技術架構、預期時間、預期費用
u 付餘款交付需求調研文件
n 後續服務
我們將對專案進行跟蹤，可以為客戶提供軟體驗收測試服務，也可以為開發方進行必要的需求意見。
需求調研總結
以前零零散散的做過一些需求調研的工作，但是都是打醬油似的，對需求調研的乙個流程還是不清楚 經過這段時間和使用者關於乙個模組的二次開發的討論，對需求調研的工作算是有了乙個大致的了解。一 需求調研準備 1 文件方面 彙總相關的文件資料，對專案要有個基本輪廓的認識，需求調研模板，需求調研問題列表相關的資料...
軟體系統 需求調研
調研內容 客戶想要什麼，想達到什麼樣的結果，為什麼會有這樣的想法，會不會有潛在的需求 具體為 1 業務現狀及現狀下工作出現的問題 2 業務涉及的部門，崗位及負責人 3 業務在部門內部和部門間的流轉流程 4 具體業務的先決條件及異常情況 5 使用者對業務的理想想法 6 非功能需求 7 對需求進行評估和...
軟體需求調研題綱
專案背景 在高校教育階段，為提高 教育管理的針對性與有效性，需要從學生和教師獲知其對學校 專業 教學情況 教學資源配套 學校管理水平等多方面評價的資訊收集。網際網路是效率最高 短 時間內涉及人員廣的渠道之一，所以依託網際網路的調查問卷需求應運而生，通過資訊的反饋，進行資訊的初步帥選與分析，能夠及時反...