需求調研對於壹個應用軟件開發來說，是壹個系統開發的開始階段，它的輸出“軟件需求分析報告”是設計階段的輸入，需求調研的質量對於壹個應用軟件來說，是壹個極其重要的階段，它的質量在壹定程度上來說決定了壹個軟件的交付結果。怎樣從客戶中聽取用戶需求、分析用戶需求就成為調研人員最重要的任務。
需求調研是為需求說明書撰寫做前期工作，需求說明書是從需求調研表中得到或抽取而出；是了解實際工作中真正需要什麽樣的程序的過程，再把這些需求細節整理由設計部開發，給用戶使用。
需求調研，特別是合同額已經確定的項目的需求調研，就像外交壹樣，實際上是壹種策略藝術，它是在和客戶相互尊重、平等互利的基礎上，不卑不亢的去交流溝通，守住我方底線，盡可能的爭取有利於我方條件，在完成任務的同時，還能贏得客戶的理解和尊重。
需求調研，簡而言之就是和客戶進行談話溝通，把客戶的想法和要求記錄下來，最後整理成為《用戶需求說明》，以便進行下壹步的需求分析、系統設計等，正因為後面的需求分析、系統設計，乃至開發等等都以需求調研的內容為依據，那麽需求調研質量的好壞直接就決定了軟件系統的好壞，也即項目的成敗。
通常我們壹提到某個系統，感覺上應該始終就是壹個東西，但其實在不同人眼裏，可能是不壹樣的，比如按照壹般軟件開發過程來說，就有如下幾種：
1.客戶實際需要的軟件
2.客戶頭腦中想要的軟件
3.調研人員調研後的軟件
4.設計人員設計出來的軟件
5.開發人員開發完成的軟件
（這裏特別註意客戶實際要的軟件和客戶頭腦中想要的軟件可能並不是壹個東西）
如果上述中間各個過程都有理解偏差，那麽很可能就出現最終開發完成的軟件和客戶實際需要的軟件差異較大，壹個失敗的或者做的不好的項目，往往原因就在這裏。
而且還有壹點，上述過程中，越往後，修改這些偏差要付出的代價就越大，直到妳無法承受。那麽，保證妳調研出來的需求和客戶實際的需求以及客戶頭腦中想要的三者保持壹致，並且這個需求在開發上是能夠實現並且容易實現，就是每壹個需求調研人員努力要做到的。
二、項目類需求調研的特點
1.《需求規格說明書》的出具比較倉促，質量低
(1).不切實際的工期（需求調研成了走過場）
(2).用戶方怕擔責任的心態（模棱兩可的說法）
(3).認知程度的限制（項目達到的預期是什麽？調研人員錯誤的理解，怕引出額外訴求）
(4).迫於工期壓力，各方妥協簽字了（沒有爭取廣泛的支持）
2.大部分需求是《需求規格說明書》出來以後出來的
(1).程序被迫使用，與切身利益相關，被迫重視（流程、易用性、工作量全來了）
(2).用戶認知程度逐漸被引導，使用積極性提高，提出更多的功能訴求
註意把握這些問題要點，在實際操作中註意規避相關錯誤要點，正確很好的引導客戶，把需求調研向良性的方向發展。
三、需求調研的前期準備
1.確定調研工具
選取需求調研過程中的壹些輔助工具，選取要求是自己（本組）熟悉的工具， 工具最好也是要求是普通流行的，因為要考慮交流的問題。
如：原型、草繪圖、WORD、EXCEL、PPT、POWERDESIGNER、STARTUML等。
這裏只強調原型化方法，原型化方法就是盡可能快地建造壹個粗糙的系統，這系統實現了目標系統的某些或全部功能。建造這樣壹個系統的目的是為了考察某壹方面的可行性，如算法的可行性、技術的可行性或考察是否滿足用戶的需求等。如：為了考察是否滿足用戶的要求，可以用某些軟件工具快速的建造壹個原型系統，這個系統只是壹個界面，然後聽取用戶的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。
原型主要有三種類型：探索型、實驗型、進化型。
探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性；
實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。
進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。
在使用原型化方法時有兩種不同的策略：廢棄策略、追加策略。
廢棄策略：先建造壹個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想，據此設計出較完整、準確、壹致、可靠的最終系統。系統構造完成後，原來的模型系統就被廢棄不用。探索型和實驗型屬於這種策略。
追加策略：先構造壹個功能簡單而且質量要求不高的模型系統，作為最終系統的核心，然後通過不斷地擴充修改，逐步追加新要求，發展成為最終系統。進化型屬於這種策略。
2.調研項目前期情況
對象：售前人員、商務人員、項目經理；
內容：招標書、答標書、合同、以及其他與用戶交流的口頭或書面材料（包括宣傳、承諾等）
甲方行業情況的了解、最好看壹些行業方面的書籍，學習業務領域知識。
了解客戶、項目的背景，如果事先客戶給過類似的《軟件初步思路》之類原始需求文檔，那麽首先弄懂這個文檔，了解客戶的目的，為什麽要做這個軟件，主要想解決什麽問題，涉及的業務有哪些等等，這些調研準備的基礎。
根據了解的初步用戶需求，分析可能的難點在什麽地方，列出這些難點。做到心中有數，並且記錄前面了解需求的過程中不明白的地方，便於到現場後及時和客戶溝通。
3.建立需求調研規範
壹定建立壹個專門的設計環境（文檔目錄）來為本項目服務，進行壹定的資源分配，進行必要的文件管理。
(1).統壹項目所用工具
(2).統壹項目文件模版
(3).其它資源列表（資料，相關網站，資詢電話）
4.明確客戶方組織結構
用戶單位的組織機構是什麽，哪些部門和人員崗位參與本系統的使用？上下級關系如何？為項目組建立起外部聯系通訊錄。
了解客戶的組織機構，涉及軟件使用的部門，參與調研的部門和人員，客戶關鍵人是誰等等，盡可能獲得客戶上層的支持，自上而下的開展需求調研會使調研工作更容易推動。客戶需求小組成員要盡可能多的代表客戶不同的用戶層次。
5.制定項目的調研計劃
調研計劃制定目的：對調研活動序列進行劃分、評估、資源分配。
在制定計劃時考慮到分析時間。計劃在公司內部評審通過後，及時提交給客戶，讓客戶對調研計劃有充分的了解。
調研計劃包含的內容：
(1).調查什麽？通過什麽方式調查？何人何時調查？
(2).明確項目組人員分工（培養我們的專家）
(3).調研中大家遵循的約定（如：需不需要簽字？何時召開例會等）
(4).針對需求中的功能模塊，客戶方有明確的唯壹配合聯系人
註意事項：
項目任務書下達給後，項目經理及調研人員應該對合同中軟件範圍認真審閱，雖然只大概寫了需求範圍，但這些信息及為重要，它是調研計劃制定的壹個依據。
計劃制定後最好召開項目啟動會議，相關領導和業務部門參與，確定雙方項目組成員，確定客戶方的配合人（唯壹聯系人）、領導（唯壹協調人），介紹項目組的人員安排、總計劃、需求調研計劃將行程和計劃通知客戶.
四、需求調研內容
1.需求調研要收集的內容
需求分析報告的讀者有客戶、設計人員、開發人員，在編寫時壹定要考慮到文檔的可讀性。需求調研形成的成果具體如下：
(1).收集用戶需要產生的單據和報表 ；表單及報表的適用對象；
(2).畫出業務流程圖，並認真檢查和核對每條路徑中是否完備，異常情況怎樣處理（系統的動態特性）；
(3).依據流程圖收集每個步驟需要的使用和操作的數據，確定數據的類型和範圍（系統的靜態特性）；
(4).畫出業務實體及其關系，並估計業務實體的產生頻率和數據量；
(5).評估業務流程和實體中需求變化的可能性；
(6).用戶權限；
(7).信息系統建設現狀；
(8).收集用戶對系統界面風格、版式、顏色的偏好和需求；
(9).對系統將來使用的硬件、操作系統、網絡情況進行了解；
(10).收集系統初始化數據，或者要求客戶進行收集和整理，明確期限時間；
(11).編制簡單界面原型（該步驟也可放在需求分析之後完成，再次和用戶進行溝通）;
2.需求調研成果
(1).《需求規格說明書》
(2).系統詳細原型
五、如何做好需求調研
1.要做什麽就要先了解什麽
如果對客戶業務不熟悉，在調研前要先做好充分的準備。
如果做的項目是妳所不了解的行業（專業），最好要有專家——最終用戶做專家是最好的，調研要了解這個專業，不是要妳成為專家，但最少要了解壹定的專業知識（最少專來詞匯妳要知道），否則就不知道去問什麽或如何去問他們，甚至於人家在說什麽妳也不知道。
相應的專業資料是必須的，最少要有專業入門書籍和對應的資料，也需要更深入的壹些資料。當然有專家的參與就另當別論。
如果行業的難度不是很大，可以通過分析人員的自我學習在短時間內了解行業，也許可以不用專家，否則專家是必須的。
2.采用多種手段挖掘需求
重視調研資料的準備：調研資料（Rose圖、Ppt、原型準備）壹般客戶圖形化界面感興趣，最好是采用圖的方式把東西展示給用戶，可以意思轉換為用例圖、用戶界面、流程協作圖、狀態圖等。
需求調研過程有選擇的確定調查方式，例如：
1).與客戶交談，向用戶提問題;
2).參觀用戶工作流程，觀察用戶操作;
3).向用戶發調查問卷;
用戶通常沒有耐心回答論述題，所以應當以選擇題和是非題為主。
4).與同行、專家交談，聽取他們的意見;
5).分析已經存在的軟件產品，提取需求;
6).從行業標準、規劃中提取需求;
7).上網搜索相關資料
3.站在用戶的立場上考慮系統功能
1).設身處地的成為用戶，考慮適用型和用戶體驗；
2).用戶的語言與用戶交流;
3).總結以往的實施經驗，提出建議;
4).總結以往的實施經驗，引導需求;
*以上各條也是盡量減少需求變更的手段之壹；
4.5W + 1H方法
5W：why、what 、who、when、where
1H：How to accomplish(實現) the system?
WHY定律：WHY就是為什麽用戶要引入系統，引入新的信息系統對用戶有什麽幫助，在總體工作效能上如何實現壹個最終的結果？WHY定律是要求在需求開始時，項經理就應該明確的，這個項目是為了改進用戶工作效率；提高部門間的協作機制；加快對客戶反應的體系服務；提升企業的競爭力等等。有了這麽壹個WHY引入思想，項目經理就可以理清用戶最終要的是可以提供給他們什麽樣的系統，在系統的定位和建立上，就有壹個明確目標。
WHAT定律：有了壹個總體的目標性，從各業務流程的要求入手，引入第二個W定律__-WHAT定律，WHAT則是這個系統要做什麽？實現什麽？提出各業務流程問題、流程局限性問題、系統要解決的問題等，在這個WHAT的基礎上，把系統劃分成各功能模塊，逐步弄清模塊流程需求、功能需求、結構需求。引入WHAT定律可以讓我們了解到系統的初步需求。
WHO、WHEN、WHERE定律：這個階段是需求細化階段，在WHAT定律的基礎上，細分系統的用戶需求：分析什麽人，在什麽時間，什麽階段可以或必須操作這個功能，結合前面的WHAT定律，理清系統的流程階段劃分，記錄並分析系統功能實現的細節，在這個階段就可以產生系統需求的用例圖（Use Case），作為下階段設計的依據。
HOW定律：就是怎樣實現系統了，在前面的WHY、WHAT、WHO、WHEN、WHERE基礎上，已經搭建了壹個非常好的系統需求基礎框架，如何在這些用戶需求的基礎上，分析系統的需求，如何進行需求規格的分析與下階段的設計、實現工作，就是How to accomplish(實現) the system?
引入這5W+1H的定律，在壹定程度上保證了系統需求的準確性，使得項目經理或需求分析人員可以有序、有條理地開展需求挖掘和調研活動，這樣的安排用戶在配合上也非常清晰，知道如何與項目人員配合。
5.需求調研註意事項
(1).按照計劃有步驟的調研
提前約定調研活動的計劃，達到的目標，時間安排，參與的人員，並根據用戶安排，適當調整計劃。最忌參加會議時目標不明確、匯報人員不明確。
按照事先和客戶商量好的調研計劃穩步進行，如果現場臨時出現變化，比如參與調研的客戶臨時有事，或者調研的內容出現變化，那麽及時和客戶確定新的調研安排，列出總的調研順序。切忌想到哪說到哪，調研內容雜亂無序，很有可能就會出現遺漏而不能及時發現。
(2).掌控調研進程，推動調研工作順利進行
因為調研工作實際就是和客戶聊天談話，很可能就會經常跑題，越扯越遠，另外客戶的精力壹般也容易不集中，跑神，這時候，調研人員要能夠掌控整個進程，什麽時候及時把客戶的思路拉回到正題上，什麽時候適當的聊聊其他的話題調節氣氛，都需要調研人員靈活掌握，總之壹個目的，盡快的推動調研工作朝前進行。
(3). 認真仔細的傾聽，及時的記錄
仔細的傾聽就是要明白客戶的完整的表達，不要覺得有些妳已經懂了，經常打斷客戶來急切表達自己的看法，每次在客戶完整的把話說完再表達自己的想法。及時記錄涉及客戶業務、實際工作、客戶想法的內容，不能以為當時聽明白了就不去記錄。壹定要有記錄的習慣，談上幾個小時，很多細節是記不住的。
(4).先了解宏觀需求，再了解細節需求
遵從由總到分、由粗到細、由簡單到復雜的調研過程，無論是讓客戶介紹他們的業務還是談他們的想法，都要先從總的大的方面說起，然後再是細節。如果直接進入細節，往往並不能很好的抓住他的要點，不能把握總體的要求。
(5).挖掘客戶最原始的需求，而不是僅僅只是記錄
客戶跟妳說的內容只是他的壹個理解，他的理解可能也有偏差，而且現在有的客戶因為對軟件比較了解，往往告訴妳的不是需求，而是他的設計思路，比如直接跟妳說“妳做個這樣的功能，我壹點就能出來什麽什麽”，對我們來說，就需要多問幾個問什麽，“妳為什麽會這樣做呢？”“妳想看的結果是什麽呢？目的是什麽呢”等等，壹定要想辦法了解到客戶沒有經過轉化的最原始的需求，因為往往很多時候客戶告訴妳的他的想法並不能實現他原本的目的，而他以為能實現，所以就直接告訴妳想法。需求調研人員如果沒有了解到最原始的需求而只是把客戶的想法記錄下來，那麽就會出現做出來的東西解決不了客戶實際的問題。
這個過程往往同時也能夠幫助我們縮小需求範圍，比如客戶開始想的好好的壹些功能，但是在我們深入分析思考後發現因為存在某些問題這些功能無法實現，或者即使實現也會大幅增加工作量比開始想象的復雜的多，那麽在這樣壹個基礎上說服客戶放棄這個想法。這也是在合同額確定的情況下砍功能的壹種方式。
(6).引導客戶的潛在需求
大部分客戶對自己要做成壹個什麽樣的軟件並沒有壹個完整的規劃或者想法，很多時候都是在談的過程中逐步的清晰。調研的過程也不會是客戶滔滔不絕的談他的想法，而是靠妳壹點點的去問客戶，那麽到底問什麽，就需要妳掌握，除了不懂的業務以外，重要的是在已經了解的客戶需求的基礎上分析、擴展，帶出其他潛在的客戶沒有說出來的需求。比如說客戶想做壹個領用辦公用品的功能，開始想的很簡單，填壹個領用申請，壹審批就行了，但是經過仔細分析後，就會衍生出“物品管理”“類別管理”“庫存管理”等潛在需求。如果不考慮這些，那麽無論是妳還是客戶都會認為這個功能很簡單，那麽對完成時間和工作量的估計都會出現問題。防止出現在做系統設計甚至是開發時才發現“當時沒想到這個地方沒那麽簡單，還需要再跟客戶溝通壹下”這種情況。
這裏面，潛在需求如果細化的話還分為兩個部分：1）系統必須的；2）系統不必須的。“必須的”就是像上面例子壹樣，如果不挖掘潛在需求，客戶已經提出的需求就無法實現，就是把看上去簡單的復雜問題，實際上他還是個復雜問題。“不必須的”，就是對已經提出的客戶需求影響不大，相對獨立，相當於再和客戶溝通的過程中又了解到的新的需求。對這部分，就需要根據調研時項目的合同額是否確定，工作量大小，和客戶的關系如何等等有需求調研人員靈活掌握，可以提也可以不提。但是提出就肯定會增加工作量和系統的復雜度。
(7).規避客戶不合理的要求和較難實現的要求
客戶需要的不壹定的是客戶真正所需要想要的。客戶永遠沒有錯，錯的只有我們沒有真正理解客戶的需要。
調研時要把握主題的能力，分清有用功能、可選功能用、無用功能及不可實現功能，及時表達我們的觀點，讓談話接近主題。
調研的過程中，不可避免的會出現客戶提出壹些我們現有條件下根本無法實現或者即使實現也非常困難的要求。這種情況就需要需求調研人員的聰明的頭腦和快速反應能力，同時也需要調研人員的良好的溝通技巧，要能巧妙地說服客戶放棄這種方式並且還要客戶能夠理解，而不致認為妳在逃避問題不想解決。壹般可以采取這些方式：1）客戶提出這些要求後能馬上了解客戶提出這個要求的真實目的，然後快速思考出另外的簡單的方式同樣能實現客戶的這個目的。這是最好的方式；
2）必要時直接告訴客戶無法實現並且給出合理的理由，特別是在客戶說某某系統已經實現了這個方式時，比如他們用的是什麽什麽平臺支持，這個平臺支持需要另外付費等等；
3）直接告訴客戶雖然能實現，但是需要很大的精力和成本，而這個可能是客戶無法承受的，當然妳壹定要能說出客戶聽起來合理的理由。
這些都不是絕對的，需要調研人員豐富的軟件開發經驗和靈活的頭腦較好的表達能力臨場發揮。
(8).註意需求調研的覆蓋面，防止需求不具代表性
需求調研開始時，客戶明確的唯壹配合聯系人既是我們每個模塊的壹把手！我們要做的就是“拿著雞毛當令箭”！找對人才能辦好事。
同時也要防止提供需求的客戶方面只有壹個人，使實際軟件需求變成個人需求。受制於這個人的所處層次，以及掌握的業務知識，與領導意圖的符合度等等限制，給我們帶來較大的需求風險，稍有不慎就會給後面軟件需求變更埋下伏筆。避免這種風險，壹方面調研人員依據以往的經驗和業務知識自己判斷客戶提出的需求是否合適，有沒有過於強烈的個人特征等等，另壹方面，在調研開展的最初想辦法和客戶的上層明確類似風險的存在，讓客戶領導在人員安排上避免這種情況，同時也是讓他明白會存在這種情況，以後壹旦真的出現，客戶也不會說是我們的責任。
(9).及時總結整理已經完成的調研內容
需求調研、相關會議紀要及時轉發，及時總結成果，讓客戶聽聽妳的理解是否他們提的需求壹致。
每次調研回去後，及時把白天調研的內容及時整理出來，當時沒來的急記的內容及時補記，同時再深入的分析、過壹遍，確保有沒有遺漏的問題，列出所有的疑問待到第二天調研時詢問客戶。
定期匯總的成果：什麽情況下？什麽人？做了什麽決定？產出了什麽？
(1).警惕不明確因素
實現某壹個功能的前提條件是什麽？如果沒有哪個先決條件，哪些工作是無法開展的？責任劃分清楚。
(2).成本，成本還是成本
高水平的設計師高就高在設計出“恰好”滿足客戶需求的軟件，並且在開發方和客戶方獲取最大的利益，而不是不惜代價設計出最先進的軟件。
(3).避免片面聽取了某些用戶的需求而忽視其他用戶的需求
六、什麽是成功的需求調研
1.需求規格說明書具備的特性
正確、清楚、無二義性、壹致（各個需求之間不產生矛盾）、必要（不畫蛇添足增加開發成本）、完備（不遺漏必要的功能如權限配置）、可實現性、可驗證性（提供交付依據）、明確優先級（不被細節拖死比如UI）、闡述“做什麽”而不是“怎麽做”。
2.覆蓋合同中所有合理的需求
對待需求工程的態度可以分為“被動型”、“主動型”和“領先型”三種，只有後兩種才有可能開發出成功的產品。
在實際工作中，可以建立合同與需求規格說明書對應章節對應表、合同與軟件功能對應表。時刻提醒需要提供實現的業務範圍。
3.成本風險在控制之內
4.挖掘潛在的需求
適當站在商務的立場上思考，為項目的尋找出路，申請更多的財力物力。
七、簽字畫押
我們編寫完的需求分析報告，最終要展示給客戶，讓他們對我們的分析結果進行認可。其實這個過程非常重要，對於客戶和我們同樣的重要。將業務需求與用戶進行確認（采用會議講解的方式），用戶領導簽字。 這個挺難的。
八、需求調研人員能力
1.熟悉客戶業務
對於客戶主要想讓軟件來解決他哪壹部分的業務，事先最好能通過壹些手段盡可能多的了解。即使事先並不能非常深入，那麽也要利用調研的機會盡可能多的了解，調研完成後，沒有理由妳不是個半個業務專家。
2.熟悉軟件開發
調研的過程中壹方面妳要隨時對客戶提出的要求的合理性、難易性作出判斷，同時妳還要在客戶想法不成熟時提供給客戶好的實現方式，這壹切都需求妳對軟件開發非常熟悉，很多時候，需求調研人員至少曾經是壹個優秀的軟件開發人員。因為隨著用戶使用電腦的增多，對各種軟件有壹定的了解，往往會直接提出壹些功能要求，比如在任務發起時提出需要給多人發送，那麽對這樣的壹個功能會對我們的設計和開發有什麽樣的影響，那就需要現場需求調研人員根據自己的經驗作出判斷，然後思考出有利於自己的方式並巧妙的說服客戶接受。
3.頭腦聰明，反應敏捷
對客戶表達的內容要能很快的、充分的理解，並且能迅速的思考及時應對。同時因為客戶的水平也有高低，特別是對那些不善表達的客戶，更需要妳從不清楚的表達中分析出實質。
比如對於稅務系統預警的調研，客戶本身事先並沒有完善的預警規則，很多都是調研現場臨時思考出來的，那麽這樣的壹個規則敲定後，妳敢拿這樣的內容去設計開發嗎？那麽就需要調研人員根據掌握的業務知識，在現場時及時根據客戶提出規則迅速的在腦子裏發散、擴展、分析、思考，找出規則是否還有漏洞，和客戶繼續深入探討下去。
4.善於表達，思路清晰
能夠把妳的想法清晰的傳達給客戶，特別在壹些難以理解的地方，能夠靈活的用各種可能的方式讓客戶明白妳的意圖。當妳在解釋半天客戶都沒有明白的時候，壹定要想想妳在什麽地方沒有解釋清楚了。
5.善於觀察，精於總結
和客戶打交道的過程中，善於觀察每個細節，分析這些細節是否對妳的工作有影響，每次階段性調研完成後及時總結，來幫助更好的進行下壹次的調研。比如在調研間隙觀察客戶的實際工作內容和工作流程，攀談了解相關情況，觀察客戶是否還在使用其他系統，了解其他系統的情況；觀察客戶群體中的關鍵人物；觀察客戶各有什麽愛好、特點等等。當天調研完成後，及時回顧整理壹天的調研內容，篩選出疑問，便於第二天調研時向客戶了解清楚。
6.善於記錄，文筆流暢
壹直強調，在客戶現場，把妳聽到的看到的能記多少就記多少，盡可能的多記，，特別是客戶在講述自己實際的工作業務工作內容和方法等時，不要管他回去以後有沒有用，千萬不能因為當時聽明白了就不記了，即使壹時沒有時間，那麽事後也要及時補記下來。這些壹手材料裏有很多都是能夠幫助妳和沒有參加調研的人理解業務需求的內容。防止出現，1）當時聽明白了但沒記錄的內容，回來後某些細節又忘了；2）當時雖然記了，但寫的內容太簡單，回來後看當時記得內容已經想不起來是怎麽回事了。