（一）問卷調查法

所謂“問卷調查法”，是指開發方就用戶需求中的一些個性化的、需要進一步明確的需求（或問題），通過采用向用戶發問卷調查表的方式，達到有效弄清項目需求的一種需求獲取方法。

這種方法適合于開發方和用戶方都清楚項目需求的情況。因為開發方和建設方都清楚項目的需求，則需要雙方進一步溝通的需求（或問題）就比較少，通過采用這種簡單的問卷調查方法就能使問題得到較好的解決。

這種方法的一般操作步驟是：

步驟一、開發方先根據合同和以往類似項目的經驗，整理出一份《用戶需求說明書》和待澄清需求（或問題）的《問卷調查表》提交給用戶；

步驟二、用戶閱讀《用戶需求說明書》，并回答《問卷調查表》中提出的問題，如果《用戶需求說明書》中有描述不正確或未包括的需求，用戶可一并修改或補充；

步驟三、開發方拿到用戶返回的《用戶需求說明書》和《問卷調查表》進行分析，如仍然有問題，則重復步驟二，否則執行步驟四；

步驟四、開發方整理出《用戶需求說明書》，提交給用戶方確認簽字。

由于這種方法比較簡單、側重點明確，因此能大大縮短需求獲取的時間、減少需求獲取的成本、提高工作效率。

（二）會議討論法

所謂“會議討論法”，是指開發方和用戶方召開若干次需求討論會議，達到有效弄清項目需求的一種需求獲取方法。

這種方法適合于開發方不清楚項目需求（一般開發方是剛開始做這種業務類型的工程項目）但用戶方清楚項目需求的情況。因為用戶清楚項目的需求，則用戶能準確地表達出他們的需求，而開發方有專業的軟件開發經驗，對用戶提供的需求一般都能準確地描述和把握。

這種方法的一般操作步驟是：

步驟一、開發方根據雙方制定的《需求調研計劃》召開相關需求主題溝通會（可采用焦點小組會議或引導式研討會的形式）；

步驟二、會后開發方整理出《需求調研記錄》提交給用戶方確認；

步驟三、如果此主題還有未明確的問題則再次溝通，否則開始下一主題；

步驟四、所有需求都溝通清楚后，開發方根據歷次《需求調研記錄》整理出《用戶需求說明書》，提交給用戶方確認簽字。

由于開發方不清楚項目需求，因此需要花較多的時間和精力進行需求調研和需求整理工作。

（三）界面原型法

所謂“界面原型法”，是指開發方根據自己所了解的用戶需求，描畫出應用系統的功能界面后與用戶進行交流和溝通，通過“界面原型”這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。

這種方法比較適合于開發方和用戶方都不清楚項目需求的情況。因為開發方和用戶方都不清楚項目需求，因此此時就更需要借助于一定的“載體”來加快對需求的挖掘和雙方對需求的理解。這種情況下，采用“可視化”的界面原型法比較可取。

這種方法的一般操作步驟是：

步驟一、開發方根據其所了解到的需求（如通過合同、招投標文件或與用戶交流），采用界面制作工具描畫出應用系統的功能界面；

步驟二、將應用系統的功能界面提交給用戶并與用戶溝通，挖掘出新需求或就需求達成理解上的一致；

步驟三、開發方就不斷獲取的需求進行增量式整理，根據新的需求豐富和細化界面原型；

步驟四、雙方經過多次界面原型的交互，開發方最終整理出《用戶需求說明書》，提交給用戶方確認簽字。

由于開發方和用戶方都不清楚項目需求，因此此時需求獲取工作將會比較困難，可能導致的風險也比較大。采用這種“界面原型”的方式，能加速項目需求的“浮現”和雙方對需求的一致理解（俗話說百聞不如一見），從而減小由于需求問題可能給項目帶來的風險。

針對這種類型的項目，也可以采用下面將要介紹的“可運行原型系統法”，但由于開發方對需求不了解（證明以前缺乏類似項目的開發經驗和產品積累），如果開發一個可運行的原型系統，則幾乎需要從零開始編寫代碼，前期投入會很大。

（四）可運行原型系統法

所謂“可運行原型系統法”，是指開發方根據合同中規定的基本需求，在以往類似項目應用系統的基礎上進行少量修改得出一可運行系統，通過“可運行原型系統”這一載體，達到有效挖掘項目需求的一種需求獲取的方法。

這種方法比較適合于開發方比較清楚項目需求但用戶方不清楚項目需求的情況。這種類型的項目，開發方一般都有類似項目的建設經驗，因此可以在以往項目的基礎上，快速“構建”出一可運行系統，然后借助于這一“載體”來加快對需求的挖掘和雙方（特別是用戶方）對需求的理解。這種情況下，采用“所見即所得”的可運行原型系統法比較可取。

這種方法的一般操作步驟是：

步驟一、開發方根據其所了解到的需求（如通過合同或與用戶交流），在以往類似項目的基礎上，快速“構建”出一可運行系統；

步驟二、通過向用戶演示“可運行原型系統”，逐步挖掘并讓用戶確認項目需求；

步驟三、開發方就不斷獲取的需求進行增量式整理，根據新的需求豐富可運行原型系統；

步驟四、雙方經過多次可運行原型系統的交互，開發方最終整理出《用戶需求說明書》，提交給用戶方確認簽字。

由于開發方清楚用戶的需求（證明以前有類似項目的開發經驗和產品積累），但用戶方自己不清楚，因此此時開發一個“可運行原型系統”，開發方的投入不會很大，而對于用戶理解和確認項目需求非常有利，因此針對這種類型的項目這是一種比較理想的需求獲取方式。

這種方法的另一個好處是：正式系統一般可以在該“可運行原型系統”的基礎上演化而成，為后續開發工作節省了不少的工作量和成本。