之所以用捕獲這個詞，而不是獲取、獲得一類詞彙，僅僅是想說明需求不是信手拈來的、它是跳動的、不穩定的，你必須下點功夫才可能有所收穫
主要方式
圓桌會議
最常見、最普通的需求獲取方式，就是需求人員與使用者（代表）坐下來就某個（業務）主題展開培訓或討論，使用者稱述、需求人員提問的方式，這種方式通常能獲得業務問題的基本流程等整體感性認識，但要形成明確的需求陳述，一、兩次是遠遠不夠的；
其優點是快速切入主題，使需求人員對使用者業務有粗粒度的整體性認識
這種方式的另一種常見場景是：需求人員對於當前業務已形成一定程度的認知、但仍存在一些不確定或不理解的業務問題，此時主要是需求分析人員提問、使用者回答的方式，這種互動的過程中，很多情況下都會出現新的業務問題或引出使用者潛在需求（這種需求使用者沒有直接稱述或指出），這個過程是需求分析前期的重要過程，是需求不斷深入、不斷細化、不斷明朗的過程
個人認為，必須通過這種方式解決需求前期的如下問題
使用者當前是否已使用或正在使用其他mis系統 是：
當前系統的使用狀況如何，解決了哪些業務問題；還有哪些業務問題沒解決；當初，引入舊系統的出發點是什麼；現在，要引入新系統，最急切要解決的業務問題是什麼（出現了舊系統不能勝任的新業務需求、產生了需求變更，但是在原系統上修改又無法滿足等等、舊系統資料吞吐量不足、舊系統可能是c/s的想要遷移到b/s上以適應異地辦公的需要，等等）？
在需求前期可以利用舊系統挖掘使用者需求，保留其合理的部分，如有可能，可以構造出系統原型
要充分利用舊系統所包含的業務資訊和業務資料處理流程；根據實際情況同使用者確認 否：
企圖引入（新）資訊系統實現什麼或者要達成什麼目標？
大部分公司告訴你他們想資訊化、提高生產效率、降低生產成本，諸如此類；個人認為，這個和沒問這個問題的效果是一樣的；大多數需求人員也知道他們不可能從這個問題得到什麼實惠的東西
因為這個問題所涵蓋的內容相當泛，很多時候，這個問題都被有意或無意的被忽略了，但這是乙個必須面對且需要明確陳述的問題，最好能夠有定量的描述（資料才是最客觀的），比如，想降低庫房管理成本30％（哪些庫房業務會產生庫房成本，如何改進（或僅僅通過資訊化）這些業務來降低管理成本；系統實施後，如何跟蹤庫房管理以測量系統是否真的達到了預期的30％，表面看來，這是乙個很難回答的問題，其實，系統還是有辦法盡量靠近這個目標的，比如定期預警、設定最低庫存等等）；確保每月資金回籠率達到85％（如何才能達成，有哪些相關業務去支撐），這是自然而然可以想到的；這一部分的任務是很難完成的，需要使用者的密切配合和大力支援
但這一部分是很關鍵的，它是目標系統願景的主要組成成分
使用者管理層的參與
能取得使用者的主動參與自然是相當好的事情，事實上，這比較困難；退而求其次，鎖定幾個關鍵使用者，這幾個關鍵使用者必須對所在領域（比如採購、銷售）的業務流程相當清楚並有可能協助bpr（業務流程再造），如有可能，可以通過msn、qq類似im工具和他們建立realtime聯絡，提高需求溝通效率
業務資料蒐集
使用者業務資料，最主要的是各種
日常業務單據（牽涉到業務流程） 報表
因為各種業務處理最終通過這些紙質**上的資料反應出來，整理、歸類、分析這些單據、報表可以找出資料源頭（對映到系統的原始資料錄入）、流轉、存檔及分析、提取等，資料上面的公式、表示式等直觀反應了現實的業務規則。
這個是任何乙個需求團隊都不能避開的步驟。
將蒐集到的使用者需求不斷分析、比較才可能發現問題；因此這是需求細化的乙個前提條件
頭腦風暴
這裡借用一下brains storm，簡單的說，就是需求人員充分發揮主觀能動性、各抒己見、甚至異想天開對於業務問題給出自己的認知和解決方案，如果有對該行業業務熟悉的同事參加更好，這樣大家在一起討論的效率會更高，否則極有可能出現「公說公有理、婆說婆有理」的僵持局面，這種情況下，頭腦風暴的主持人必須作出仲裁，結束爭端。
這種方式在需求人員對於行業業務缺乏認識或者認識較少的時候充分發揮團隊成員想象力、利用集體智慧型和常識、邏輯構造出乙個業務問題模型和解決方案模型，這種模型具有很大的主觀性，在對行業的真實需求逐漸明朗的過程中，往往可能要將以前的假想全部否定（這是一件極其痛苦的事情），而且真實的業務問題比構想出來的業務問題要複雜的多；但是這種方式在早期對行業需求缺乏認知的時候能積極推動需求工作向前進行，同時通過對比也能讓需求人員對需求過程的理解獲得更深入的認知，一定程度的採用是不無裨益的。
輔助方式
文捲調查
草擬使用者可能關注的目標系統特性、業務問題解決方案等
個別訪談
就某一具體業務問題刨根究底的明確
需求匯出
使用者很多時候很難表達出他想要什麼，一旦你把軟體交付給他使用時，他會說：「我們，這裡不是這樣處理的」、「還有一種情況，你們的系統不能夠支援啊」等等；其實，這種現狀反應的是系統需求的不完整性，這種不完整性有使用者本身的原因，也有需求分析人員不可逃脫的責任，如何盡可能降低這種需求不完整性（因為這種情況是不能杜絕的），要從兩個方面入手：
需求分析人員：
需求人員的責任就是從使用者那裡取得需求並表達、組織，因此需求人員要盡一切可能從使用者那裡獲得完整認識，要獲得相對完整的認識，如下的工作必須做到位
1、分析各需求之間的關係，有制約、依賴、關聯等
2、構造業務流程圖，仔細分析每個可能的業務路徑，每個業務路徑觸發條件是什麼，如何處理，需要哪些前置條件，其結果是什麼，對其他需求有何影響
3、開發需求匯出工具或系統原型
以當前流行的b/s架構，可以用html生成簡單的業務demo，簡單的表達目標系統可能的「模樣」，對於現時業務的處理方式，ui等等
使用者更多的喜歡這種直觀明了的方式，也更易於幫助他們清理出「藏在他們心底的」需求
需求工程 需求管理
需求以自然語言進行描述，應該以某種標識方案進行編號。幾種常見的需求標識和分類的技術 最靈活和不容易出錯的方法是利用資料庫生成唯一識別符號的方法。這是因為資料庫系統支援在併發的情況下對每個新資料記錄生成唯一的識別符號。有些資料庫還可以通過版本號擴充套件唯一識別符號的方式來支援對相同記錄的多個版本的維護...
《需求管理》系列之二需求定義 表達與組織
描述使用者的某個需求看似一件簡單易做的事情，感覺上只需要指出使用者想要幹什麼，系統能夠提供什麼就可以了，實則不然。比如，使用者在商品建檔時有如下需求 使用者可以臨時調整商品的 其規則是 使用者申請對某個商品臨時調價，並設定臨時 啟用期的起止日期，臨時調價審批通過後，在該臨 啟用期內系統按臨時 開單銷...
需求管理系列之二 軟體需求分析關注什麼？
需求開發沒有做好會出現什麼後果？需求問題的代價？需求分析如何做？為什麼要做？首先來看下需求問題產生的代價模型 一 需求問題的代價 通過圖形可以看出，在需求階段消除問題的代價最小，而如果需求問題等到產品發布出去後才發現的話，那修復的成本就會 n倍的增加。不合格的需求分析 1 沒有足夠的使用者參與 2 ...