一、什么是需求調研？

需求調研對于一個應用軟件開發來說，是一個系統開發的開始階段，它的輸出“軟件需求分析報告”是設計階段的輸入，需求調研的質量對于一個應用軟件來說，是一個極其重要的階段，它的質量在一定程度上來說決定了一個軟件的交付結果。怎樣從客戶中聽取用戶需求、分析用戶需求就成為調研人員最重要的任務。

需求調研是為需求說明書撰寫做前期工作，需求說明書是從需求調研表中得到或抽取而出；是了解實際工作中真正需要什么樣的程序的過程，再把這些需求細節整理由設計部開發，給用戶使用。

需求調研，特別是合同額已經確定的項目的需求調研，就像外交一樣，實際上是一種策略藝術，它是在和客戶相互尊重、平等互利的基礎上，不卑不亢的去交流溝通，守住我方底線，盡可能的爭取有利于我方條件，在完成任務的同時，還能贏得客戶的理解和尊重。

需求調研，簡而言之就是和客戶進行談話溝通，把客戶的想法和要求記錄下來，最后整理成為《用戶需求說明》，以便進行下一步的需求分析、系統設計等，正因為后面的需求分析、系統設計，乃至開發等等都以需求調研的內容為依據，那么需求調研質量的好壞直接就決定了軟件系統的好壞，也即項目的成敗。

通常我們一提到某個系統，感覺上應該始終就是一個東西，但其實在不同人眼里，可能是不一樣的，比如按照一般軟件開發過程來說，就有如下幾種：

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）當時雖然記了，但寫的內容太簡單，回來后看當時記得內容已經想不起來是怎么回事了。