軟體專案需求調研總結

一、需求調研準備：

在需求調研過程中，應該做好三種準備，保持兩種心態，做到五種提高：

三種準備

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.需求文件編寫完成後，在開發階段也應該做檢查和更新，避免文件錯誤對開發的誤導。我們在完成大量的需求文件編寫工作後，在開發階段有部分文件沒有做內容檢查和及時更新。

後期測試時才發現少數需求內容的矛盾和錯誤，導致需要重新修改。

建議：1、如果在編寫需求文件後，開發階段應該做一邊閱讀需求文件，一邊做需求文件的檢查，對於保證需求質量效果會更好。

2、應該指定人負責需求追蹤和更新，在開發階段、測試階段要保持和使用者的需求溝通，這不是乙個可有可無的簡單工作，很重要，並且會占用責任人50%的工作時間。

3、企業業務管理資訊系統的需求調研方法：我認為對調研的組織安排是非常重要的，好的調研安排雖然未必產生質量高的需求，但是乙個不遵循調研規律的調研活動，必然是低效的。下面是h專案調研組採取的調研流程，供參考：

4、第一步不是立刻和使用者當面討論需求細節，而是要業務關鍵使用者編寫初步的需求報告，提供給開發團隊閱讀分析。需求報告的內容是，對業務流程的描述，對業務需求的描述。需求報告的質量往往和關鍵使用者的投入多少有較大關係，經常在沒有面對面溝通時，關鍵使用者未必能對這份報告投入很多的時間和精力。

但這是當面調研的基礎，一定要做，有粗糙疏漏的地方可以再現場調研時再細化。這可以再調研前就和使用者溝通，讓使用者編寫。