需求調研該怎麼做

如何進行有效的需求調研

一、什麼是需求調研？

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

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

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

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

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

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

來源：http://www.cnblogs.com/SanMaoSpace/p/4967424.html