需求并不是設計人員自己想出來的，我們只能與用戶去交流，使用科學的方法去搜集充分的信息，從而找出一組穩定的需求，那么我們先研究一些數據搜集的方法：

一、數據搜集：

1.問卷調查

所謂問卷調查，也就是設計出一系列的問題，通過網絡（EMAIL、IM、website），電話，紙張等形式大面積鋪放，然后回收問卷導出特定的信息。設計問卷時，首先要搞清楚調查的目的是什么，然后對每一個問題進行仔細審核，保證它們的含義清晰并且能夠容易回答，并且在問卷設計完成之后先找一小部分人試答一下。

在設計問卷和分析結果時，可能任何一點細節都會影響到結論的準確度和可信度，例如：

參加調查的用戶并不一定就代表所有用戶
用戶參加問卷調查的動機可能會影響研究結果，例如有些用戶為了表示友好，讓調查方高興，甚至猜測問卷人所期望的答案
問卷來源可能會影響研究結果，有些人對某個組織單位沒有好感，可能會心情不好等
研究問題的措辭可能會影響研究結果，他可能既不同意也不反對，但是沒有給他機會讓他說出他的想法

2.用戶訪談

也就是個人采訪，可以是面對面的也可以是電話的。訪談最好是在用戶的工作環境或者家里。訪談更能激發被訪者的響應，不過比較耗時，可以先訪談一些代表性用戶，在對更廣的用戶進行問卷調查，以驗證得到的信息。

3.觀察和提問

人們有時候很難說清楚自己在做什么，也很難描述自己是如何執行這個任務的，所以我們需要觀察他是如何完成任務的，并在他自然情形下的工作過程，同事記錄和提出適當的問題，有助于我們更透徹的理解用戶理解任務。

我們應該注意的地方是：觀察的人應當是最具代表性的用戶；要想透徹理解用戶，就需要在他的工作環境中觀察；提問要具體，重點放在他們正在做和剛剛做完的事情；你在這一過程中產生的想法要馬上告訴用戶以驗證你的理解是正確的。

4.集體討論

用戶訪談是一對一的，只能知道一個人的看法，你也可以召集若干用戶一起進行討論。一般需要一位主持人來組織，集體討論適合了解多數人的意見，能突出有沖突不一致的觀點。不過應該特別注意避免一個或幾個人壟斷談話的內容或者主導討論，尤其是職位高或者非常有影響力的人，應該保證所有人都有平等機會發表自己意見，有些人天生內向，有些人看到領導在場就想特意表現，針對這些不利于討論的行為，可以通過這個方式來避免：讓參與討論的用戶各自使用一臺電腦匿名在線會議。

二、各種方法比較

適用情形
優點
缺點

問卷調查
回答特定問題
適用資源少，調查人數多
問卷設計很關鍵，回答率不高，可能答非所問

用戶訪談
發掘和深入研究問題
必要時引導被訪者，促進開發人員和用戶的溝通
耗時，人為環境影響被訪者

觀察和提問
理解用戶活動環境
觀察實際工作，提供更多的細節
非常耗時，數據量巨大

集體討論
搜集多方觀點
突出不同觀點，促進開發人員和用戶溝通
討論可能由少數人主導與實際有偏差

三、數據搜集一些要注意的地方：

一切重點都是為了搞清楚用戶需要什么，每個用戶類別只派一位代表參與是不充分的，打組合拳，不要單一套路，在可能的情況下先小規模試驗，記錄數據同樣重要，如果得到的需求信息太多，我們可以采取以下步驟：

讓用戶列出他們希望通過產品完成的各種目標
讓他們籠統列出達到目標的各種需求
按自己的理解，把這些需求轉述給用戶，讓他們判斷是否正確
鼓勵用戶以更開放的思路提出更多需求
你提供幾個需求類別，讓用戶將所有需求“對號入座”。
列出各項需求的衡量標準，對不易衡量的，修改或刪除

四、解釋分析數據

在我們拿到了厚厚的一沓數據之后，可能會沒有一個清晰的思路，它們可能是音頻的視頻的文字的，看著就煩，但是我們又馬上必須去整理它，越早整理，記憶越清晰，出現的偏差也就越小，尤其對于訪談這類的，用戶在說話時的動作語氣還會回蕩在你腦海中。這個時候我們需要把需求文檔規范化，VOLERE需求記錄卡是非常實用的：

需求編號： 101
需求分類： 故障安全
描述： 當通信系統終端無法傳輸數據時，系統發生警告
原理：如果無法傳輸數據，則可能是系統終端發生故障需要維護，或數據定義可能出問題
來源：客戶系統安全工程師
滿足標準：當每小時每個類型通信數據超出制造商指定的誤差范圍，產品應當通知客戶
完成后客戶的滿意程度：滿意
未完成客戶的不滿意度：極為不滿意
相關需求沖突：無
支持材料：產品規格說明
歷史：**提出，于*年月日

原文：http://www.czlands.cn/?p=272