需求擷取屬于軟體需求工程裡的需求開發階段。
随着系統規模的擴大，需求分析與定義在整個系統開發過程中越來越重要，直接關系到系統的成功與否。需求分析活動不再僅限于系統開發的最初階段，而是貫穿于系統開發的整個生命周期。于是形成了軟體工程的子領域：軟體需求工程。
軟體需求工程是包括建立和維護軟體需求文檔所必需的一切活動的過程，可分為需求開發和需求管理兩大工作。需求開發包括需求擷取、需求分析、需求定義和需求驗證4個階段；而需求管理包括定義需求基線，處理需求變更和需求跟蹤等方面的工作。這兩大部分相輔相成，其中需求開發是主線，是目标；需求管理是支援，是保障。
本文主要學習需求開發中的需求擷取技術。
一、需求概述
1、需求的層次
需求是多層次的，包括業務需求、使用者需求和系統需求。這三個不同層次從目标到具體，從整體到局部，從概念到細節。
1）業務需求
業務需求反映企業或客戶對系統的高層次目标要求。這些要求通常來自客戶高層和管理人員。通過業務需求，可以确定項目的視圖和範圍，為後面的開發工作奠定基礎。
2）使用者需求
使用者需求描述的是使用者的具體目标，或使用者要求系統必須能完成的任務。也就是說，使用者需求描述了使用者能使用系統來做些什麼。通常采取使用者訪談和問卷調查等方式，對使用者使用的場景進行整理，進而建立使用者需求。
3）系統需求
系統需求是從系統的角度來說明軟體的需求，包括功能需求、非功能需求和設計限制等。功能需求也稱為行為需求，規定了開發人員必須在系統中實作的軟體功能，使用者利用這些功能來完成任務，滿足業務需要。非功能需求是指系統必須具備的屬性或品質，又可細分為軟體品質屬性（例如可維護性，安全性，效率等等）和其他非功能需求。
2、需求的分類
【正常需求】
使用者認為系統應該做到的功能或性能，實作越多使用者越滿意。
【期望需求】
使用者想當然認為系統應當具備的功能或性能，但并沒有或不能正确地描述自己想要這些功能或性能。如果期望需求沒有實作，使用者會不滿意。
【意外需求】
也稱為興奮需求。是使用者要求範圍外的功能或性能，實作了使用者會更高興，但不實作也不影響購買決策。意外需求實施與否，控制在開發人員手中。開發人員可以選擇實作，以便獲得使用者的更高忠誠度；也可以從成本角度出發，不予實作。
二、需求擷取
1、使用者訪談
使用者訪談是最基本的一種需求擷取手段，形式包括結構化和非結構化兩種。結構化是指事先準備好一系列問題，有針對地進行；而非結構化則是隻列出一個粗略的想法，根據訪談的具體情況發揮。最有效的訪談是結合這兩種方法進行，畢竟不可能事先一一計劃清楚。
為了進行有效的使用者訪談，需要在三個方面進行組織，分别是準備訪談、主持訪談和訪談的後續工作：
1）準備訪談
（1）确定訪談目的
（2）确定訪談中應該包括哪些使用者
（3）為訪談準備一些詳細的問題
問題可以分為開放式問題和封閉式問題。開放式問題鼓勵使用者讨論和說明細節；封閉式問題旨在獲得具體的事實。
（4）作出最終訪談安排，并把這些安排通知所有參加者。具體安排應征求客戶同意。每個參加者都應該知道訪談目的，可能的話，還可以預覽一下訪談的問題和材料。
作為系統分析師，應該在訪談之前加強了解領域相關知識，充分閱讀有關材料，以保證自己有較專業的了解和認識，讓使用者能夠信任自己。
2）訪談過程
具體訪談時，猿一定要準時到達，可能的話，早一點到。訪談過程，要做好幾項工作：
（1）限制訪談時間
時間控制在90分鐘内，如果需要更多時間，應安排下一次。幾次比較短的訪談，比一次馬拉松式訪談效果要好得多。
（2）尋找異常和錯誤情況。要找機會問一些類似“如果。。。那會怎樣”的問題，有意識地去确定所有特殊的情況，并與使用者深入探讨。
（3）深入調查細節
（4）認真做好記錄
（5）注意措辭，尊重使用者；避免使用IT專業術語；保持談話輕松氣氛。
3）訪談的後續工作
訪談後首要任務是吸收、了解和記錄訪談所獲得的資訊；對于使用者回答不上來、或錯過的問題，不要丢失或遺忘，準備下一次再問；談話備忘錄要送客戶一份。
4）訪談的優缺點
使用者訪談具有良好的靈活性，有較寬廣的應用範圍。但使用者時間不好安排；談話資訊量大，不好記錄；需要溝通技巧和足夠的領域知識、豐富的應對經驗等。
2、問卷調查
通過精心設計調查表，下發到相關人員手中，讓他們填寫答案，可以有效克服使用者訪談方法中存在的問題。
一張好的問卷調查表要花費大量的時間來進行設計與制作，包括确定問題及其類型、編寫問題、設計問卷調查表的格式三個重要活動。
【問卷調查的優缺點】
與使用者訪談相比，問卷調查可以在短時間内，以低廉的代價從大量的回答中收集資料；由于問卷調查允許匿名填寫，大多數使用者可能會提供真實資訊；調查結果比較好整理和統計。
最大的缺點是缺乏靈活性；其次還有由于雙方未見面，無法從表情等細節擷取隐性資訊，使用者也無法即時澄清含糊或錯誤的回答；使用者可能心理上不夠重視，回報資訊不全面；調查表不利于展開回答，不利于了解細節；回答人數可能不及預期，效果打折扣。
較好的做法是使用者訪談與問卷調查相結合。先問卷調查，整理分析的基礎上，小範圍使用者訪談。
【提高問卷返還率的方法】
向所有人解釋問卷的目的，以及如何使用
說明問卷所有人都要回答
拜托客戶上司督促手下回答并返還
盡量參加一次企業全體會議，會上回答大家的問題，并解釋這些資訊的用處
更改問卷中的問題，盡量減少回答問卷所花費的時間
設定獎勵措施
3、采樣
采樣是指從種群中系統地選出有代表性的樣本集的過程，通過認真研究所選出的樣本集，可以從整體上揭示種群的有用資訊。對于資訊系統的開發而言，系統文檔就是采樣種群。當開始對一個系統做需求分析的時候，檢視現有系統的文檔是初步了解系統的最好辦法。當文檔數量龐大，無法一一研究時，就需要使用采樣技術選出有代表性的資料。
樣本大小 = 啟發式因子 * （可信度系數 / 可接受的錯誤）^2 = 可信度系數由題目給出，可信度越高，可信度系數越大
啟發式因子 預設為 0.25；但也可以變。比如，如果已知每10張訂單中可能有1張存在問題，則啟發式因子 = 0.1 * （1 - 0.1）。
【采樣的優缺點】
加快了資料收集的過程，提高了效率，降低了開發成本；采樣技術采用了數學統計原理，減少資料收集的偏差。采樣技術不僅可以用于收集資料，還可以對人員進行采樣。
但采樣技術正因為基于統計學原理，樣本規模的确定依賴于期望的可信度和已有經驗知識，很大程度上取決于系統分析師的主觀因素，和個人的經驗和能力，對系統分析師要求較高。
4、情節串聯闆
情節串聯闆通常就是一系列圖檔，分析人員通過這些圖檔來講故事。一般情況下啊，圖檔的順序與活動事件的順序一緻，通過一系列圖檔來說明會發生什麼。圖檔類型包括流程圖、互動圖、報表和記錄結構等。簡而言之，情節串聯闆技術就是使用工具向使用者說明（或示範）系統如何适合企業的需要，并表明系統将如何運轉。
【情節串聯闆的類型】
被動式、主動式和互動式，複雜程度依次遞增。
被動式是靜态圖檔，系統分析師充當系統的角色進行講解和示範；
主動式可以自動播放，描述系統典型場景等；
互動式可以讓使用者體驗系統的行為，可以是抛棄式原型等。
【情節串聯闆的制作】
情節串聯闆應該易于建立和修改，不要企圖做得太好太精美。情節串聯闆既不是原型，也不是真實事物的示範。
【情節串聯闆的優缺點】
優點是直覺，生動，使用者友好，互動性強，對使用者界面起了早期的評審作用。
缺點是花費時間很多，使需求擷取的速度大大降低。
5、聯合需求計劃
什麼是JRP?
聯合需求計劃（Joint Requirement Planning ,JRP）是一個通過高度組織的群體會議來分析企業内的問題，并擷取需求的過程。它是聯合應用開發（Joint Application Development，JAD）的一部分。
JAD以小組形式定義和建立系統，由企業主管部門經理、會議主持人、使用者、協調人員、IT人員、秘書等共同組成的專題讨論組，由這個讨論組來定義并詳細說明系統的需求和可選的技術方案。
JRP通過聯合各個關鍵使用者代表、系統分析師、開發團隊代表一起，通過有組織的會議來讨論需求。通常參會人數6 ~ 18人，時間1 ~ 5小時。
JRP的優點：
JRP相對來說成本較高，但是一種十分有效的一種需求擷取方法。
1）加快需求擷取進度，降低需求擷取成本，尤其對有歧義、最不清晰的領域十分有效
2）提升使用者參與積極性，提高開發效率
3）采用原型确認系統需求并擷取設計審批，具有原型化開發方法的優點
通過這次會議，JRP的這些優點，體會得十分真切。
JRP的原則：
JRP的主要意圖是收集需求，而不是對需求進行分析和驗證。實施JRP應把握以下主要原則：
1）事先制定議題
2）嚴格按照約定時間進行
3）對議題逐一進行讨論
4）會議記錄
5）避免術語
開發方避免使用專業術語，盡量通俗易懂，利于交流
6）（開發方）應有解決沖突的能力
極力避免與各方，尤其是甲方鬧不愉快。就事論事，目的在于解決問題。
7）中場休息
本次會議是一個上午，中午結束，并無中場休息
8）鼓勵取得一緻意見
9）保證大家遵守會議決議
即會後應有相關跟進，對作出的決議，産生的問題等及時處理。
JRP的一般步驟：
1）讓與會者互相認識，力求會議在輕松氣氛中進行
2）列舉問題，逐一讨論或按照議程，逐一進行
3）鼓勵大家對現有系統或現狀暢所欲言
4）鼓勵大家對新系統暢想，形成清單
5）對清單進行整理，明确優先級，評審，最後形成結論或結議。
當然今天的聯合需求計劃會議并沒有完全按照這樣的步驟，但精神是一緻的，那就是厘清需求，解決問題，形成結論，為下一步工作做好鋪墊。精神貫徹就行，具體做法可以加以裁剪。
三、需求記錄技術
由于需求擷取人員和需求分析人員可能不是同一個人，或者一個項目有多個系統分析師參與需求擷取，是以需要統一需求記錄工具，以便統一口徑。
常用的需求記錄工具有任務卡片、場景說明、使用者故事和Volere白卡等。
1、任務卡片
在各種需求記錄工具中，任務卡片是一種比較簡單的工具，特别适合對業務活動級的資訊收集與整理。
增強版任務卡片在基本任務卡片的基礎上，增加了問題點描述和解決方案提示。
2、場景說明
場景說明是使用者對其工作場景和過程的較長的描述。這些描述将在編寫測試用例和使用者教育訓練手冊中再次用到。
3、使用者故事
使用者故事描述了對使用者有價值的功能，包括三個方面的内容：書面描述（用于計劃和備忘）、交談（細化故事）和測試用例（驗證故事實作）。
4、Volere白卡
Volere白卡是一種類似于任務卡片的需求記錄工具。