需求獲取，屬於軟體工程中的一部分，包括需求來源和獲取需求的技術。它是軟體設計的第一階段，其本質主要是人的活動，涉及軟體設計人員如何與客戶建立有效的溝通。
基本介紹
- 中文名：需求獲取
- 外文名：requirement elicitation
- 目標：提高開發者與用戶之間溝通的能力
- 方法：用戶面談等
- 套用：軟體開發等
- 學科：軟體工程用戶面談
簡述,步驟,方法,
簡述
當軟體項目以招標方式確定開發單位時，“標書”往往可以作為初步的需求陳述。用戶需求陳述可能由用戶單方面寫出。也可能由系統分析員配合用戶共同寫出。需求陳述的內容包括問題範圍、功能需求、套用環境及假設條件等。此外。對採用的軟體工程標準、模組構造準則、將來可能做的擴充及可維護性要求等方面的內容，也都要做適當描述。總之，需求陳述應該闡明“做什麼”而不是“怎樣做”。它應該描述用戶需求而不是提出解決問題的方法；應該指出哪些是系統必要的屬性，哪些是可選的屬性；應該避免對設計策略施加過多的約束；也不要描述系統的內部結構，否則會限制系統實現的靈活性。
需求獲取是開發者、用戶之間為了定義新系統而進行的交流。需求獲取是需求分析的前提，需求獲取是獲得系統必要的特徵，或者是獲得用戶能接受的、系統必須滿足的約束。由於用戶是其各自領域的專家，對開發的系統應該如何做，已經有了總體考慮，但這些用戶通常不具備軟體開發方面的技術和經驗。而與此相對，開發者在軟體開發方面具有豐富的經驗，但了解用戶和用戶的領域相關知識較少。如果雙方所理解的領域內容在系統分析、設計過程出現問題，通常在開發過程的後期才會被發現，將會使整個系統交付延遲，或上線的系統無法或難以使用，最終所開發的系統以失敗告終，導致出現嚴重的軟體危機。例如，遺漏的需求(丟失了系統必須支持的功能)或錯誤的需求(不正確的功能描述或不可用的用戶界面)。需求獲取的目標，就是為了提高開發者與用戶之間溝通的能力，進而構造套用系統的領域模型。
在面向對象的方法中，開發者選擇用戶易於理解的表達方式，通常使用用例來獲取軟體的需求。用例通過描述“參與者”和“系統”之間的互動來描述系統的行為。用例方法最主要的優點在於它是用戶導向的，用戶可根據自己所對應的用例來不斷細化自己的需求。此外，使用用例還可方便地得到系統功能的測試用例。
步驟
對於不同規模及不同類型的項目，需求獲取的過程不會完全一樣。下面給出需求獲取過程的參考步驟。
1．開發高層的業務模型
所謂套用領域，即目標系統的套用環境，如銀行、電信公司等。如果系統分析員對該領域有了充分了解，就可以建立一個業務模型，描述用戶的業務過程，確定用戶的初始需求。然後通過疊代，更深入地了解套用領域，之後再對業模型進行改進。
2．定義項目範圍和高層需求
在項目開始之前，應當在所有利益相關方面建立一個共同的願景，即定義項目範圍和高層需求。項目范同描述系統的邊界以眨與外部事物(包括組織、人、硬體設備、其他軟體等)的關係。高層需求不涉及過多的細節，主要表示系統需求的概貌。
3．識別用戶類和用戶代表
需求獲取的主要目標是理解用戶需求，因而客戶的參與是生產出優質軟體的關鍵因素。因此，首先確定目標系統的不同用戶類型；然後挑選出每一類用戶和其他利益相關方的代表，並與他們一起工作；最後確定誰是項目需求的決策者。
用戶類可以是人，也可以是與系統打交道的其他應用程式或硬體部件。如果是其他應用程式或硬體部件，則需要以熟悉這此系統或硬體的人員作為用戶代表。
4．獲取具體的需求
確定了項目範圍和高層需求，並確定了用戶類及用戶代表後，就需要獲取更具體、完整和詳細的需求。
5．確定目標系統的業務工作流
具體到當前待開發的套用系統，確定系統的業務工作流和主要的業務規則。採取需求調研的方法獲取所需的信息。例如，針對信息系統的需求調研方法如下。
(1)調研用戶的組織結構、崗位設定、職責定義，從功能上區分有多少個子系統，劃分系統的大致範圍，明確係統的目標。
(3)時凋研內容事先準備，針對不同管理層次的用戶詢問不同的問題，列出問題清單。將操作層、管理層、決策層的需求既聯繫又區分開來，形成一個需求的層次。
6．需求整理與總結
必須對上面步驟取得的需求資料進行整理和總結，確定對軟體系統的綜合要求，即軟體的需求。並提出這些需求實現條件，以及需求應達到的標準。這些需求包括功能需求、性能需求、環境需求、可靠性需求、安全保密需求、用戶界面需求、資源使用需求、軟體成本消耗與開發進度需求等。
方法
1．用戶面談
這是一種理解商業功能和商業規則的最有效方法。面談過程需要認真的計畫和準備。其基本要點如下。
(1)面談之前：確立面談目的；確定要包括的相關用戶；確定參加會議的項目小組成員；建立要討論的問題和要點列表；複查有關文檔和資料；確立時間和地點；通知所有參加者有關會議的目的、時間和地點。
(2)進行面談時：衣著得體；準時到達、尋找異常和錯誤情況；深入調查細節；詳細記錄；指出和記錄下未回答條目和未解決問題。
(3)面談之後：複查筆記的準確性、完整性和可理解性；把所收集的信息轉化為適當的模型和文檔；確定需要進一步澄清的問題域；適當的時候向參加會議的每一個人發一封感謝信。
2．需求專題討論會
需求專題討論會也許是需求獲取的一種最有力的技術。項目主要風險承擔人在短暫而緊湊的時間段內集中在一起，一般為一或兩天，與會者可以在套用需求上達成共識、對操作過程儘快取得統一意見。參加會議的人員包括主持人、用戶、技術人員、項目組人員。
專題討論會具有以下優點。
(1)協助建立一支高效的團隊，圍繞項目成功的目標；
(2)所有的風險承擔人都暢所欲言；
(3)促進風險承擔人和開發閉隊之間達成共識；
(4)揭露和解決那些妨礙項同成功的行政問題；
(5)能夠很快地產生初步的系統定義。
3．問卷調查
可用於確認假設和收集統計傾向數據，問卷需要快速叫答，允許匿名方式。存在問題的是：相關的問題不能事先決定；問題背後的假設對答案造成偏頗。如“這符合你的期望嗎?”難以探索一些新領域：難以繼續用戶的模糊回響。在完成最初的面談和分析後，問卷調查可作為一項協作技術收到良好的效果。
4．現場觀察
掌握用戶如何實際使用一個系統以及到底用戶需要哪些信息，最好的辦法是親自觀察用戶是如何完成實際工作的。 一般方法如下。
(1)對辦公室進行快速瀏覽，了解布局、設備要求和使用、工作流總體情況；
(2)安排幾個小時觀察用戶是如何。實際完成他們的工作的，理解用戶實際使用計算機系統和處理事務的細節；
(3)像用戶一樣接受訓練和做實際工作，發現關鍵問題和瓶頸。
5．原型化方法
一個軟體原型是所提出的新產品的部分實現，幫助開發人員、用戶以及客戶更好地理解系統的需求，它比開發人員常用的技術術語更易於理解。建立原型可以解決在產品開發的早期階段需求不確定的問題，用戶、經理和其他非技術項目風險承擔者發現在確定和開發產品時，原型可以使他們的想像更具體化，如建立基於Web的套用系統原理，使用HTML進行界而設計。
6．基於用例的方法
隨著面向對象技術的發展，基於用例的方法任需求獲取和建模方面套用越來越廣泛。用例建模是以任務和用戶為中心的，開發和描述用戶需要系統做什麼。另外，用例幫助於開發人員理解用戶的、業務和套用領域，並可以運用面向對象分析和設計方法將用例轉化為對象模型。
用例建模的基本步驟入下。
(1)確定系統的參與者：參與者是與系統互動的外部實體，它既可以是人員也可以是外部系統或硬體設備。
(2)確定場景：場景是對人們利用計算機系統過程做了什麼和體驗了什麼的敘述性描述，它從單個參與者的角度觀察系統特性的具體化和非正式的描述。
(3)確定系統用例：用例描述了一個完整的系統事件流程，其重點在於參與者與系統之間的互動而不是內在的系統活動，並對參與者產生存價值的可觀測結果。
(4)確定用例之間的關係：在確定出每一個參與者的用例之後，需要將參與者和特定的用例聯繫起來，最終繪製出系統的用例圖。
(5)編寫用例描述文檔：單純使用用例圖並不能提供用例所具有的全部信息，因此需要使用文字描述那些不能反映在網形上的信息。用例描述是關於角色與系統如何互動的規格說明，要求清晰明確，沒有二義性。在描述用例時，應該只注重外部能力，不涉及內部細節。
