需求收集方法

技術描述了在特定情況下如何執行任務。一個任務可能沒有任何相關技術，也可能有一個或多個相關技術。一項技術應至少與一項任務相關。

以下是一些眾所周知的需求收集方法：

頭腦風暴

頭腦風暴用於需求收集，以從一群人那裡獲得儘可能多的想法。通常用於識別解決問題的可能方案，並闡明機會的細節。

文件分析

審查現有系統的文件可以幫助建立現狀流程文件，以及推動差距分析以確定遷移專案的範圍。理想情況下，我們甚至會審查推動現有系統建立的需求——記錄當前需求的起點。現有文件中經常埋藏著資訊金礦，這些資訊可以幫助我們在驗證需求完整性時提出問題。

焦點小組

焦點小組是由代表產品使用者或客戶的人員組成的集合，以獲得反饋。可以收集有關需求/機會/問題的反饋以識別需求，也可以收集反饋以驗證和改進已收集的需求。這種形式的市場研究不同於頭腦風暴，因為它是一個由特定參與者參與的管理過程。

介面分析

軟體產品的介面可以是人機介面。與外部系統和裝置的整合只是另一種介面。以使用者為中心的設計方法非常有效地確保我們建立易於使用的軟體。介面分析——審查與其他外部系統的接觸點，這對於確保我們不會忽略使用者無法立即看到的需求非常重要。

訪談

對利益相關者和使用者的訪談對於建立優秀的軟體至關重要。如果不瞭解使用者和利益相關者的目標和期望，我們極不可能滿足他們。我們還必須認識到每個受訪者的觀點，以便我們能夠正確地權衡和處理他們的意見。傾聽是幫助優秀分析師從訪談中獲得比普通分析師更多價值的技能。

觀察

透過觀察使用者，分析師可以識別流程流程、步驟、痛點和改進機會。觀察可以是被動的（在觀察時提問）或主動的。被動觀察更適合獲取原型反饋（以改進需求），而主動觀察更有效地瞭解現有業務流程。兩種方法都可以使用。

原型設計

原型設計是一種相對較新的需求收集技術。在這種方法中，您收集初步需求，然後使用這些需求來構建解決方案的初始版本——原型。您將其展示給客戶，然後客戶會提供額外的需求。您更改應用程式並再次與客戶迴圈。這個重複的過程會持續進行，直到產品滿足關鍵的業務需求或達到商定的迭代次數。

需求研討會

研討會對於收集需求非常有效。比頭腦風暴會議更有條理，相關方協作記錄需求。捕獲協作的一種方法是建立領域模型工件（如靜態圖、活動圖）。有兩個分析師比只有一個分析師參加的研討會效果更好。

逆向工程

當遷移專案無法訪問現有系統的足夠文件時，逆向工程將識別系統所執行的操作。它不會識別系統應該執行的操作，也不會識別系統何時執行錯誤的操作。

調查/問卷

當從很多人那裡收集資訊時——由於預算和時間限制而太多人無法進行訪談——可以使用調查或問卷。調查可以強制使用者從選項中選擇，對某些內容進行評分（“非常同意，同意……”），或者提出開放式問題，允許自由形式的回答。調查設計很難——問題可能會影響受訪者。