需求獲取技術
需求獲取的目的：（1）清楚地理解所要解決的問題；（2）完整地獲取用戶需求。
需求獲取面臨的挑戰：問題的復雜性和問題空間；理解的不完備性與不一致性；交流障礙；需求易變性。
所以，分析人員必須掌握一些基本技術，包括初步需求獲取技術、需求建模、問題抽象與問題分解快速原型技術。需求獲取技術包括兩方面的工作：建立獲取用戶需求的方法的框架；支持和監控需求獲取的過程的機制。
一、需求獲取的常用方法
1.組織人員
組織人員，建立分析小組，其中包括領域專家：主角，也就是用戶方面的問題專家，了解軟件所解決問題的領域知識。系統分析員：導演，軟件開發人員方面的人，其主要分析，抽象領域專家的知識，形成軟件模型。
2。客戶訪談
客戶訪談，也就是獲取用戶需求，其主要方法是調查研究。其主要內容包括：
(1）了解系統的需求。軟件開發常常是系統開發的一部分.仔細分析研究系統的需求規格說明，對軟件的需求獲取是很有必要的.
（2）市場調查。了解市場對待開發軟件有什么樣的要求；了解市場上有無與待開發軟件類似的系統。如果有，在功能上、性能上、價格上情況如何。
（3）訪問用戶和用戶領域的專家。把從用戶那里得到的信息作為重要的原始資料進行分析；訪問用戶領域的專家所得到的信息將有助于對用戶需求的理解。
（4）考察現場。了解用戶實際的操作環境、操作過程和操作要求。對照用戶提交的問題陳述，對用戶需求可以有更全面、更細致的認識。
在做調查研究時，可以采取如下的調查方式：
·制定調查提綱，向不同層次的用戶發調查表。
·按用戶的不同層次，分別召開調查會，了解用戶對待開發系統的想法和建議。
·向用戶領域的專家或在關鍵崗位上工作的人個別咨詢.
·實地考察，跟蹤現場業務流程。
·查閱與待開發系統有關的資料.
·使用各種調查工具，如數據流圖、任務分解圖、網絡圖等。
為了能夠有效地獲取和理清用戶需求，應當打破用戶（需方）和開發者( 供方)的界限，共同組成一個聯合小組，發揮各自的長處，協同工作。
3。問題分析與確認
問題分析與確認，主要組織分析并評審，最終確定問題是否比較完整。
二、需求獲取的內容
需求分析目標主要搞清楚軟件用戶要“做什么"，其用戶需求內容主要是兩方面：一是功能性需求：定義了系統做什么（描述系統必須支持的功能和過程)；二是非功能性需求（技術需求）：定義了系統工作時的特性（描述操作環境和性能目標）；
兩類需求包括的內容：功能；性能；環境；界面；用戶或人的因素；文檔；數據；資源；安全保密；軟件成本消耗與開發進度；質量保證。下面分別對其作一定解釋：
（1）功能需求：系統做什么?系統何時做什么？系統何時及如何修改或升級？
(2) 性能需求：軟件開發的技術性指標：例如：存儲容量限制；執行速度、相應時間、吞吐量。
（3）環境需求：硬件設備：機型、外設、接口、地點、分布、溫度、濕度、磁場干擾等；軟件操作系統；網絡；數據庫.
（4）界面需求：有來自其他系統的輸入嗎?到自其他系統的輸出嗎？對數據格式有規定嗎？對數據存儲介質有規定嗎?
（5）用戶或人的因素：用戶類型？各種用戶熟練程度?需受何種訓練？用戶理解、使用系統的難度?用戶錯誤操作系統的可能性？
（6)文檔需求：需哪些文檔?文檔針對哪些讀者？
(7）數據需求：輸入、輸出數據的格式？接收、發送數據的頻率?數據的準確性和精度? 數據流量？數據需保持的時間?
（8) 資源需求：軟件運行時所需的數據、軟件.內存空間等資源。軟件開發、維護所需的人力、支撐軟件、開發設備等。
（9) 安全保密要求：需對訪問系統或系統信息加以控制嗎？如何隔離用戶之間的數據？用戶程序如何與其他程序和操作系統隔離？系統備份要求？
（10）軟件成本消耗與開發進度需求：開發有規定的時間表嗎？軟硬件投資有無限制？
（11）質量保證：系統的可靠性要求？系統必須監測和隔離錯誤嗎?規定系統平均出錯時間？出錯后，重啟系統允許的時間？系統變化如何反映到設計中?維護是否包括對系統的改進？系統的可移植性？
摘要：我們知道，需求調研不充分、用戶需求描述不完整不準確，輕則影響項目建設的順利程度，重則影響應用系統的質量，甚至決定項目的成敗。
俗話說，“良好的開端是成功的一半”.需求獲取作為項目伊始的活動，是非常重要的.
目前我們所開發的軟件項目一般有兩種類型：產品項目和工程項目.
產品項目一般都會有充足的時間進行非常仔細的需求調研和分析，而工程項目卻并非如此(因為它往往受諸多因素的影響)。
本文擬討論如何根據工程項目的實際特點，采用合適的方法低成本高效率地獲取用戶的需求。
關鍵詞：工程項目需求獲取方法
產品項目一般是根據公司戰略和市場需求研發的旨在進行批量出售或推廣的項目，工程項目一般是根據
與用戶簽定的合同研發的旨在滿足特定用戶需求的項目.
筆者所開發和管理的項目主要是工程項目，在項目的建設過程中，感覺到最頭疼的是項目需求的獲取；我們往往要花相當大的精力在需求獲取和需求確認上，然而有時效果還很不理想。
經過幾年時間的項目實踐，我們逐步總結出針對不同項目情況所適合采用的需求獲取方法，這些方法能大大提高需求獲取的效率?，F總結之，愿與大家分享。
我們知道，一個工程項目，如果從開發方(即承建方）和用戶方（即建設方）對需求的清楚程度來分，大致可以分為如下四種：開發方和用戶方都清楚項目需求、開發方不清楚項目需求但用戶方清楚、開發方和用戶方都不清楚項目需求、開發方清楚項目需求但用戶方不清楚。
針對這四種類型的項目，我總結出四種對應的需求獲取方法：問卷調查法、會議討論法、界面原型法和可運行原型系統法。
以下逐一解析之
一、問卷調查法
所謂“問卷調查法”，是指開發方就用戶需求中的一些個性化的、需要進一步明確的需求(或問題），通過采用向用戶發問卷調查表的方式，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于開發方和用戶方都清楚項目需求的情況.因為開發方和建設方都清楚項目的需求，則需要雙方進一步溝通的需求（或問題）就比較少，通過采用這種簡單的問卷調查方法就能使問題得到較好的解決.
這種方法的一般操作步驟是：
步驟一、開發方先根據合同和以往類似項目的經驗，整理出一份《用戶需求說明書》和待澄清需求（或問題）的《問卷調查表》提交給用戶;
步驟二、用戶閱讀《用戶需求說明書》，并回答《問卷調查表》中提出的問題，如果《用戶需求說明書》中有描述不正確或未包括的需求，用戶可一并修改或補充；
步驟三、開發方拿到用戶返回的《用戶需求說明書》和《問卷調查表》進行分析，如仍然有問題，則重復步驟二，否則執行步驟四
步驟四、開發方整理出《用戶需求說明書》，提交給用戶方確認簽字.
由于這種方法比較簡單、側重點明確，因此能大大縮短需求獲取的時間、減少需求獲取的成本、提交工作效率。二、會議討論
所謂“會議討論法"，是指開發方和用戶方召開若干次需求討論會議，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于開發方不清楚項目需求（一般開發方是剛開始做這種業務類型的工程項目)但用戶方清楚項目需求的情況。因為用戶清楚項目的需求，則用戶能準確地表達出他們的需求，而開發方有專業的軟件開發經驗，對用戶提供的需求一般都能準確地描述和把握。
這種方法的一般操作步驟是：
步驟一、開發方根據雙方制定的《需求調研計劃》召開相關需求主題溝通會;
步驟二、會后開發方整理出《需求調研記錄》提交給用戶方確認；
步驟三、如果此主題還有未明確的問題則再次溝通，否則開始下一主題;
步驟四、所有需求都溝通清楚后，開發方根據歷次《需求調研記錄》整理出《用戶需求說明書》，提交給用戶方確認簽字。
由于開發方不清楚項目需求，因此需要花較多的時間和精力進行需求調研和需求整理工作。
三、界面原型法
所謂“界面原型法”，是指開發方根據自己所了解的用戶需求，描畫出應用系統的功能界面后與用戶進行交流和溝通，通過“界面原型”這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法.
這種方法比較適合于開發方和用戶方都不清楚項目需求的情況。因為開發方和用戶方都不清楚項目需求，因此此時就更需要借助于一定的“載體"來加快對需求的挖掘和雙方對需求理解。這種情況下，采用“可
視化”的界面原型法比較可取。
這種方法的一般操作步驟是：
步驟一、開發方根據其所了解到的需求（如通過合同或與用戶交流），采用界面制作工作描畫出應用系統的功能界面；
步驟二、將應用系統的功能界面提交給用戶并與用戶溝通，挖掘出新需求或就需求達成理解上的一致；
步驟三、開發方就不斷獲取的需求進行增量式整理，根據新的需求豐富和細化界面原型;
步驟四、雙方經過多次界面原型的交互，開發方最終整理出《用戶需求說明書》，提交給用戶方確認簽字。
由于開發方和用戶方都不清楚項目需求，因此此時需求獲取工作將會比較困難，可能導致的風險也比較大.采用這種“界面原型"的方式，能加速項目需求的“浮現"和雙方對需求的一致理解，從而減小由于需求問題可能給項目帶來的風險。
針對這種類型的項目，我們也可以采用下面將要介紹的“可運行原型系統法”，但由于開發方對需求不了解（證明以前缺乏類似項目的開發經驗和產品積累)，如果開發一個可運行的原型系統，則幾乎需要從零開始編寫代碼，前期投入會很大.
四、可運行原型系統法
所謂“可運行原型系統法”，是指開發方根據合同中規定的基本需求，在以往類似項目應用系統的基礎上進行少量修改得出一可運行系統，通過“可運行原型系統”這一載體，達到徹底挖掘項目需求的一種需求獲取的方法。
這種方法比較適合于開發方清楚項目需求但用戶方不清楚項目需求的情況.這種類型的項目，開發方一
般都有類似項目的建設經驗，因此可以在以往項目的基礎上，快速“構建”出一可運行系統，然后借助于這一“載體”來加快對需求的挖掘和雙方（特別是用戶方）對需求的理解。這種情況下，采用“所見即所得”的可運行原型系統法比較可取。
這種方法的一般操作步驟是：
步驟一、開發方根據其所了解到的需求（如通過合同或與用戶交流），在以往類似項目的基礎上，快速“構建”出一可運行系統；
步驟二、通過向用戶演示“可運行原型系統”，逐步挖掘并讓用戶確認項目需求；
步驟三、開發方就不斷獲取的需求進行增量式整理，根據新的需求豐富可運行原型系統;
步驟四、雙方經過多次可運行原型系統的交互，開發方最終整理出《用戶需求說明書》，提交給用戶方確認簽字。
由于開發方清楚用戶的需求(證明以前有類似項目的開發經驗和產品積累），但用戶方自己不清楚，因此此時開發一個“可運行原型系統”，開發方的投入不會很大，但對于用戶理解和確認項目需求非常有利，因此針對這種類型的項目這是一種比較理想的需求獲取方式。
這種方法的另一個好處是：正式系統一般可以在該“可運行原型系統”的基礎上演化而成，為后續開發工作節省不少的工作量和成本.
值得注意的是，以上總結出的這四種需求獲取方法不是互斥的，我們可以根據項目的實際特點獨立應用或組合應用.
“忙碌，不代表有效率；方法，遠勝于苦干”。但愿我們從事軟件項目開發的朋友們，都能掌握好恰當的方法，以圖能獲得“事半功倍"的效果．
