如何進行有效的需求調研

1、什麼是需求調研？
需求調研對於一個應用軟件開發來講，是一個系統開發的開始階段，它的輸出「軟件需求分析報告」是設計階段的輸入，需求調研的質量對於一個應用軟件來講，是一個極其重要的階段，它的質量在必定程度上來講決定了一個軟件的交付結果。怎樣從客戶中聽取用戶需求、分析用戶需求就成爲調研人員最重要的任務。
需求調研是爲需求說明書撰寫作前期工做，需求說明書是從需求調研表中獲得或抽取而出；是瞭解實際工做中真正須要什麼樣的程序的過程，再把這些需求細節整理由設計部開發，給用戶使用。
需求調研，特別是合同額已經肯定的項目的需求調研，就像外交同樣，其實是一種策略藝術，它是在和客戶相互尊重、平等互利的基礎上，不卑不亢的去交流溝通，守住我方底線，儘量的爭取有利於我方條件，在完成任務的同時，還能贏得客戶的理解和尊重。
需求調研，簡而言之就是和客戶進行談話溝通，把客戶的想法和要求記錄下來，最後整理成爲《用戶需求說明》，以便進行下一步的需求分析、系統設計等，正由於後面的需求分析、系統設計，乃至開發等等都以需求調研的內容爲依據，那麼需求調研質量的好壞直接就決定了軟件系統的好壞，也即項目的成敗。

一般咱們一提到某個系統，感受上應該始終就是一個東西，但其實在不一樣人眼裏，多是不同的，好比按照通常軟件開發過程來講，就有以下幾種：
1.客戶實際須要的軟件
2.客戶頭腦中想要的軟件
3.調研人員調研後的軟件
4.設計人員設計出來的軟件
5.開發人員開發完成的軟件
（這裏特別注意客戶實際要的軟件和客戶頭腦中想要的軟件可能並非一個東西）
若是上述中間各個過程都有理解誤差，那麼極可能就出現最終開發完成的軟件和客戶實際須要的軟件差別較大，一個失敗的或者作的很差的項目，每每緣由就在這裏。
並且還有一點，上述過程當中，越日後，修改這些誤差要付出的代價就越大，直到你沒法承受。那麼，保證你調研出來的需求和客戶實際的需求以及客戶頭腦中想要的三者保持一致，而且這個需求在開發上是可以實現而且容易實現，就是每個需求調研人員努力要作到的。
 
2、項目類需求調研的特色
1.《需求規格說明書》的出具比較倉促，質量低
(1).不切實際的工期（需求調研成了走過場）
(2).用戶方怕擔責任的心態（模棱兩可的說法）
(3).認知程度的限制（項目達到的預期是什麼？調研人員錯誤的理解，怕引出額外訴求）
(4).迫於工期壓力，各方妥協簽字了（沒有爭取普遍的支持）
2.大部分需求是《需求規格說明書》出來之後出來的
(1).程序被迫使用，與切身利益相關，被迫重視（流程、易用性、工做量全來了）
(2).用戶認知程度逐漸被引導，使用積極性提升，提出更多的功能訴求 
注意把握這些問題要點，在實際操做中注意規避相關錯誤要點，正確很好的引導客戶，把需求調研向良性的方向發展。 

3、需求調研的前期準備
1.肯定調研工具
選取需求調研過程當中的一些輔助工具，選取要求是本身（本組）熟悉的工具， 工具最好也是要求是普通流行的，由於要考慮交流的問題。
如：原型、草繪圖、WORD、EXCEL、PPT、POWERDESIGNER、STARTUML等。
這裏只強調原型化方法，原型化方法就是儘量快地建造一個粗糙的系統，這系統實現了目標系統的某些或所有功能。建造這樣一個系統的目的是爲了考察某一方面的可行性，如算法的可行性、技術的可行性或考察是否知足用戶的需求等。如：爲了考察是否知足用戶的要求，能夠用某些軟件工具快速的建造一個原型系統，這個系統只是一個界面，而後聽取用戶的意見，改進這個原型。之後的目標系統就在原型系統的基礎上開發。
原型主要有三種類型：探索型、實驗型、進化型。
探索型：目的是要弄清楚對目標系統的要求，肯定所但願的特性，並探討多種方案的可行性；
實驗型：用於大規模開發和實現前，考覈方案是否合適，規格說明是否可靠。
進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程當中，逐步將原型進化成最終系統。

在使用原型化方法時有兩種不一樣的策略：廢棄策略、追加策略。
廢棄策略：先建造一個功能簡單並且質量要求不高的模型系統，針對這個系統反覆進行修改,造成比較好的思想，據此設計出較完整、準確、一致、可靠的最終系統。系統構造完成後，原來的模型系統就被廢棄不用。探索型和實驗型屬於這種策略。
追加策略：先構造一個功能簡單並且質量要求不高的模型系統，做爲最終系統的核心，而後經過不斷地擴充修改，逐步追加新要求，發展成爲最終系統。進化型屬於這種策略。
2.調研項目前期狀況
對象：售前人員、商務人員、項目經理；
內容：招標書、答標書、合同、以及其餘與用戶交流的口頭或書面材料（包括宣傳、承諾等）
甲方行業狀況的瞭解、最好看一些行業方面的書籍，學習業務領域知識。
瞭解客戶、項目的背景，若是事先客戶給過相似的《軟件初步思路》之類原始需求文檔，那麼首先弄懂這個文檔，瞭解客戶的目的，爲何要作這個軟件，主要想解決什麼問題，涉及的業務有哪些等等，這些調研準備的基礎。
根據瞭解的初步用戶需求，分析可能的難點在什麼地方，列出這些難點。作到心中有數，而且記錄前面瞭解需求的過程當中不明白的地方，便於到現場後及時和客戶溝通。
3.創建需求調研規範
必定創建一個專門的設計環境（文檔目錄）來爲本項目服務，進行必定的資源分配，進行必要的文件管理。
(1).統一項目所用工具
(2).統一項目文件模版
(3).其它資源列表（資料，相關網站，資詢電話）
4.明確客戶方組織結構
用戶單位的組織機構是什麼，哪些部門和人員崗位參與本系統的使用？上下級關係如何？爲項目組創建起外部聯繫通信錄。
瞭解客戶的組織機構，涉及軟件使用的部門，參與調研的部門和人員，客戶關鍵人是誰等等，儘量得到客戶上層的支持，自上而下的開展需求調研會使調研工做更容易推進。客戶需求小組成員要儘量多的表明客戶不一樣的用戶層次。
5.制定項目的調研計劃
調研計劃制定目的：對調研活動序列進行劃分、評估、資源分配。
在制定計劃時考慮到分析時間。計劃在公司內部評審經過後，及時提交給客戶，讓客戶對調研計劃有充分的瞭解。
調研計劃包含的內容：
(1).調查什麼？經過什麼方式調查？何人什麼時候調查？
(2).明確項目組人員分工（培養咱們的專家）
(3).調研中你們遵循的約定（如：需不須要簽字？什麼時候召開例會等）
(4).針對需求中的功能模塊，客戶方有明確的惟一配合聯繫人
注意事項：
項目任務書下達給後，項目經理及調研人員應該對合同中軟件範圍認真審閱，雖然只大概寫了需求範圍，但這些信息及爲重要，它是調研計劃制定的一個依據。
計劃制定後最好召開項目啓動會議，相關領導和業務部門參與，肯定雙方項目組成員，肯定客戶方的配合人（惟一聯繫人）、領導（惟一協調人），介紹項目組的人員安排、總計劃、需求調研計劃將行程和計劃通知客戶. 

4、需求調研內容
1.需求調研要收集的內容
需求分析報告的讀者有客戶、設計人員、開發人員，在編寫時必定要考慮到文檔的可讀性。需求調研造成的成果具體以下：
(1).收集用戶須要產生的單據和報表 ；表單及報表的適用對象；
(2).畫出業務流程圖，並認真檢查和核對每條路徑中是否完備，異常狀況怎樣處理（系統的動態特性）；
(3).依據流程圖收集每一個步驟須要的使用和操做的數據，肯定數據的類型和範圍（系統的靜態特性）；
(4).畫出業務實體及其關係，並估計業務實體的產生頻率和數據量；
(5).評估業務流程和實體中需求變化的可能性；
(6).用戶權限；
(7).信息系統建設現狀；
(8).收集用戶對系統界面風格、版式、顏色的偏好和需求；
(9).對系統未來使用的硬件、操做系統、網絡狀況進行了解；
(10).收集系統初始化數據，或者要求客戶進行收集和整理，明確期限時間；
(11).編制簡單界面原型（該步驟也可放在需求分析以後完成，再次和用戶進行溝通）;
2.需求調研成果
(1).《需求規格說明書》
(2).系統詳細原型
 
5、如何作好需求調研
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).避免片面聽取了某些用戶的需求而忽視其餘用戶的需求
 
6、什麼是成功的需求調研
1.需求規格說明書具有的特性
正確、清楚、無二義性、一致（各個需求之間不產生矛盾）、必要（不多此一舉增長開發成本）、完備（不遺漏必要的功能如權限配置）、可實現性、可驗證性（提供交付依據）、明確優先級（不被細節拖死好比UI）、闡述「作什麼」而不是「怎麼作」。
2.覆蓋合同中全部合理的需求
對待需求工程的態度能夠分爲「被動型」、「主動型」和「領先型」三種，只有後兩種纔有可能開發出成功的產品。
在實際工做中，能夠創建合同與需求規格說明書對應章節對應表、合同與軟件功能對應表。時刻提醒須要提供實現的業務範圍。
3.成本風險在控制以內
4.挖掘潛在的需求
適當站在商務的立場上思考，爲項目的尋找出路，申請更多的財力物力。

7、簽字畫押
咱們編寫完的需求分析報告，最終要展現給客戶，讓他們對咱們的分析結果進行承認。其實這個過程很是重要，對於客戶和咱們一樣的重要。將業務需求與用戶進行確認（採用會議講解的方式），用戶領導簽字。 這個挺難的。 

8、需求調研人員能力
1.熟悉客戶業務
對於客戶主要想讓軟件來解決他哪一部分的業務，事先最好能經過一些手段儘量多的瞭解。即便事先並不能很是深刻，那麼也要利用調研的機會盡量多的瞭解，調研完成後，沒有理由你不是個半個業務專家。
2.熟悉軟件開發
調研的過程當中一方面你要隨時對客戶提出的要求的合理性、難易性做出判斷，同時你還要在客戶想法不成熟時提供給客戶好的實現方式，這一切都需求你對軟件開發很是熟悉，不少時候，需求調研人員至少曾經是一個優秀的軟件開發人員。由於隨着用戶使用電腦的增多，對各類軟件有必定的瞭解，每每會直接提出一些功能要求，好比在任務發起時提出須要給多人發送，那麼對這樣的一個功能會對咱們的設計和開發有什麼樣的影響，那就須要現場需求調研人員根據本身的經驗做出判斷，而後思考出有利於本身的方式並巧妙的說服客戶接受。
3.頭腦聰明，反應敏捷
對客戶表達的內容要能很快的、充分的理解，而且能迅速的思考及時應對。同時由於客戶的水平也有高低，特別是對那些不善表達的客戶，更須要你從不清楚的表達中分析出實質。
好比對於稅務系統預警的調研，客戶自己事先並無完善的預警規則，不少都是調研現場臨時思考出來的，那麼這樣的一個規則敲定後，你敢拿這樣的內容去設計開發嗎？那麼就須要調研人員根據掌握的業務知識，在現場時及時根據客戶提出規則迅速的在腦子裏發散、擴展、分析、思考，找出規則是否還有漏洞，和客戶繼續深刻探討下去。
4.善於表達，思路清晰
可以把你的想法清晰的傳達給客戶，特別在一些難以理解的地方，可以靈活的用各類可能的方式讓客戶明白你的意圖。當你在解釋半天客戶都沒有明白的時候，必定要想一想你在什麼地方沒有解釋清楚了。
5.善於觀察，精於總結
和客戶打交道的過程當中，善於觀察每一個細節，分析這些細節是否對你的工做有影響，每次階段性調研完成後及時總結，來幫助更好的進行下一次的調研。好比在調研間隙觀察客戶的實際工做內容和工做流程，攀談了解相關狀況，觀察客戶是否還在使用其餘系統，瞭解其餘系統的狀況；觀察客戶羣體中的關鍵人物；觀察客戶各有什麼愛好、特色等等。當天調研完成後，及時回顧整理一天的調研內容，篩選出疑問，便於次日調研時向客戶瞭解清楚。
6.善於記錄，文筆流暢
一直強調，在客戶現場，把你聽到的看到的能記多少就記多少，儘量的多記，，特別是客戶在講述本身實際的工做業務工做內容和方法等時，不要管他回去之後有沒有用，千萬不能由於當時聽明白了就不記了，即便一時沒有時間，那麼過後也要及時補記下來。這些一手材料裏有不少都是可以幫助你和沒有參加調研的人理解業務需求的內容。防止出現，1）當時聽明白了但沒記錄的內容，回來後某些細節又忘了；2）當時雖然記了，但寫的內容太簡單，回來後看當時記得內容已經想不起來是怎麼回事了。