一、問卷調查法
所謂「問卷調查法」，是指開發方就使用者需求中的一些個性化的、需要進一步明確的需求（或問題），通過採用向使用者發問卷調查表的方式，達到有效弄清專案需求的一種需求獲取方法。
這種方法適合於開發方和使用者方都清楚專案需求的情況。因為開發方和建設方都清楚專案的需求，則需要雙方進一步溝通的需求（或問題）就比較少，通過採用這種簡單的問卷調查方法就能使問題得到較好的解決。
這種方法的一般操作步驟是：
步驟一、開發方先根據合同和以往類似專案的經驗，整理出乙份《使用者需求說明書》和待澄清需求（或問題）的《問卷調查表》提交給使用者；
步驟二、使用者閱讀《使用者需求說明書》，並回答《問卷調查表》中提出的問題，如果《使用者需求說明書》中有描述不正確或未包括的需求，使用者可一併修改或補充；
步驟三、開發方拿到使用者返回的《使用者需求說明書》和《問卷調查表》進行分析，如仍然有問題，則重複步驟二，否則執行步驟四；
步驟四、開發方整理出《使用者需求說明書》，提交給使用者方確認簽字。
由於這種方法比較簡單、側重點明確，因此能大大縮短需求獲取的時間、減少需求獲取的成本、提高工作效率。
二、會議討論法
所謂「會議討論法」，是指開發方和使用者方召開若干次需求討論會議，達到有效弄清專案需求的一種需求獲取方法。
這種方法適合於開發方不清楚專案需求（一般開發方是剛開始做這種業務型別的工程專案）但使用者方清楚專案需求的情況。因為使用者清楚專案的需求，則使用者能準確地表達出他們的需求，而開發方有專業的軟體開發經驗，對使用者提供的需求一般都能準確地描述和把握。
這種方法的一般操作步驟是：
步驟一、開發方根據雙方制定的《需求調研計畫》召開相關需求主題溝通會（可採用焦點小組會議或引導式研討會的形式）；
步驟二、會後開發方整理出《需求調研記錄》提交給使用者方確認；
步驟三、如果此主題還有未明確的問題則再次溝通，否則開始下一主題；
步驟四、所有需求都溝通清楚後，開發方根據歷次《需求調研記錄》整理出《使用者需求說明書》，提交給使用者方確認簽字。
由於開發方不清楚專案需求，因此需要花較多的時間和精力進行需求調研和需求整理工作。
三、介面原型法
所謂「介面原型法」，是指開發方根據自己所了解的使用者需求，描畫出應用系統的功能介面後與使用者進行交流和溝通，通過「介面原型」這一載體，達到雙方逐步明確專案需求的一種需求獲取的方法。
這種方法比較適合於開發方和使用者方都不清楚專案需求的情況。因為開發方和使用者方都不清楚專案需求，因此此時就更需要借助於一定的「載體」來加快對需求的挖掘和雙方對需求的理解。這種情況下，採用「視覺化」的介面原型法比較可取。
這種方法的一般操作步驟是：
步驟一、開發方根據其所了解到的需求（如通過合同、招投標檔案或與使用者交流），採用介面製作工具描畫出應用系統的功能介面；
步驟二、將應用系統的功能介面提交給使用者並與使用者溝通，挖掘出新需求或就需求達成理解上的一致；
步驟三、開發方就不斷獲取的需求進行增量式整理，根據新的需求豐富和細化介面原型；
步驟四、雙方經過多次介面原型的互動，開發方最終整理出《使用者需求說明書》，提交給使用者方確認簽字。
由於開發方和使用者方都不清楚專案需求，因此此時需求獲取工作將會比較困難，可能導致的風險也比較大。採用這種「介面原型」的方式，能加速專案需求的「浮現」和雙方對需求的一致理解（俗話說百聞不如一見），從而減小由於需求問題可能給專案帶來的風險。
針對這種型別的專案，也可以採用下面將要介紹的「可執行原型系統法」，但由於開發方對需求不了解（證明以前缺乏類似專案的開發經驗和產品積累），如果開發乙個可執行的原型系統，則幾乎需要從零開始編寫**，前期投入會很大。
四、可執行原型系統法
所謂「可執行原型系統法」，是指開發方根據合同中規定的基本需求，在以往類似專案應用系統的基礎上進行少量修改得出一可執行系統，通過「可執行原型系統」這一載體，達到有效挖掘專案需求的一種需求獲取的方法。
這種方法比較適合於開發方比較清楚專案需求但使用者方不清楚專案需求的情況。這種型別的專案，開發方一般都有類似專案的建設經驗，因此可以在以往專案的基礎上，快速「構建」出一可執行系統，然後借助於這一「載體」來加快對需求的挖掘和雙方（特別是使用者方）對需求的理解。這種情況下，採用「所見即所得」的可執行原型系統法比較可取。
這種方法的一般操作步驟是：
步驟一、開發方根據其所了解到的需求（如通過合同或與使用者交流），在以往類似專案的基礎上，快速「構建」出一可執行系統；
步驟二、通過向使用者演示「可執行原型系統」，逐步挖掘並讓使用者確認專案需求；
步驟三、開發方就不斷獲取的需求進行增量式整理，根據新的需求豐富可執行原型系統；
步驟四、雙方經過多次可執行原型系統的互動，開發方最終整理出《使用者需求說明書》，提交給使用者方確認簽字。
由於開發方清楚使用者的需求（證明以前有類似專案的開發經驗和產品積累），但使用者方自己不清楚，因此此時開發乙個「可執行原型系統」，開發方的投入不會很大，而對於使用者理解和確認專案需求非常有利，因此針對這種型別的專案這是一種比較理想的需求獲取方式。
這種方法的另乙個好處是：正式系統一般可以在該「可執行原型系統」的基礎上演化而成，為後續開發工作節省了不少的工作量和成本。
管理資訊系統需求調研分析指南
摘要 本文是在管理資訊系統需求調研實踐和學習中的一些經驗總結，有些是自己的體會，有些來自專家的書本或文章，希望與大家分享，並起到乙個拋磚引玉的作用，如有不妥之處歡迎指正。關鍵字 需求 調研 正文 一 軟體需求的定義 ieee軟體工程標準詞彙表 1997年 中定義的需求為 1 使用者解決問題或達到目標...
中小型資訊系統在專案需求
中小型資訊系統在專案型軟體中占有很大的比例，許多中小型軟體企業都是以此類專案為主要業務的。中小型資訊系統主要是面向中小型企業和單位的，其主要特點是專案邊界較小 涉及的業務和人員較少 功能較為單 一 資金投入較少 開發周期較短。所以，一般會認為中小型資訊系統的開發一定是較為簡單的。其實不然。在實踐當中...
資訊系統工程的專案管理
資訊系統工程的專案管理，重點還是專案管理，但是專注的領域是資訊系統。資訊系統領域如何管理專案，專案經理是關鍵！根據pmi的的觀點，專案經理應該重點關注三個關鍵技能 1 技術專案管理。與專案 專案集和專案組合管理特定領域相關的知識 技能和行為，即角色履行的技術方面技能。2.領導力。3戰略和商務管理。技...