軟體需求獲取

出自 MBA智库百科(https://wiki.mbalib.com/)

軟體需求獲取(Software Requirement Elicitation)

　　軟體需求獲取是需求工程的主體。對於所建立的軟體產品來說，獲取需求是一個確定和理解不同用戶類的需要和限制的過程。獲取需求的一個必不可少的結果是對項目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之後才能開始設計系統，否則，對需求定義的任何改進，設計上都必須大量的返工。

　　需求獲取是在問題及其最終解決方案之間架設橋梁的第一步。獲取需求的一個必不可少的結果是對項目中描述的客戶需求的普遍理解，一旦理解了需求，分析者、開發者和客戶就能探索出描述這些需求的多種解決方案。

　　需求包括業務需求、用戶需求和功能需求以及非功能需求，在需求開發之前，需要先定義好需求開發的過程，形成文檔，內容包括：需求開發的步驟，每一個步驟如何實現，如何處理意外情況，如何規劃開發資源等。需求獲取就是進行需求收集的一個活動，它從人員、資料和環境中得到系統開發所需要的相關信息。

　　需求獲取是一個需要高度合作的活動，並不是客戶所說的需求的簡單謄本。作為一個分析者，你必須透過客戶所提出的錶面需求理解他們的真正需求。需求獲取不是一個簡單地進行知識轉移的活動，為了能夠解決需求獲取中普遍存在的問題，獲取活動至少要做到：確定待獲取信息的內容；確定待獲取信息的來源；確定應採取的獲取方法；執行獲取；記錄獲取成果。

　　需求獲取可能是軟體開發中最困難、最關鍵、最易出錯及最需要交流的方面。需求獲取只有通過有效的客戶一開發者的合作才能成功。

　　在需求分析的初期，分析人員對問題知之甚少，用戶對問題的描述、對目標軟體的要求通常也是相當零亂和模糊的。更為嚴重的是，分析人員與用戶的知識領域不同，從而造成相互理解方面的困難。因此，在需求分析過程中，為了能夠獲得系統真正的需求，往往需要進行需求捕獲，也就是去尋找需要與軟體系統開發有關的系統信息。

　　對需求問題的全面考察需要一些相關的技術和方法，這些技術和方法不但考慮了問題的功能需求方面，還可通過討論獲得項目的非功能需求。

　　常用的需求獲取方法包括以下幾種：

　　1、用戶訪談

　　用戶訪談是一種最基本的需求獲取手段，它是指分析人員以個別訪談或小組會議的形式與用戶進行初步的溝通。用戶訪談的形式包括結構化和非結構化兩種，結構化是指分析人員按照一定准則事先準備好一系列問題，通過用戶對問題的回答來獲取有關目標軟體方面的內容；非結構化則是只列出一個粗糙的想法，根據訪談的具體情況來進行發揮。

　　2、用戶調查

　　在進行用戶訪談時，由於很多關鍵人員的時間有限，不易安排過多的時間或者項目涉及的客戶面較廣，不可能一一訪談。因此，就需要藉助用戶調查的方法，通過精心設計要問的問題，然後下發到相關的人員手中，讓他們填寫，再從所填寫的內容中獲取系統的需求信息，這樣就可以剋服上述的問題。

　　用戶調查最大的不足就是缺乏靈活性，而且可能存在受調查人員不能很好表述自己想法的限制。

　　3、現場觀摩

　　俗話說，百聞不如一見，對於許多較為複雜的流程和系統而言，是很難用自然語言表達清楚的。因此，為了能夠對系統的需求獲得全面的瞭解，實際觀察用戶的操作過程就是一種行之有效的方法。現場觀摩就是走到客戶的工作場所，一邊觀察，一邊聽客戶講解，甚至可以安排人員跟隨客戶一起工作一段時間。這樣就可以使得分析人員對客戶的需求有更加直觀的理解。但是，在現場觀摩過程中必須切記：建造軟體系統不僅僅只是為了模擬客戶的手工操作過程，還必須將最好的經濟效益、最快的處理速度、最合理的操作流程和最友好的用戶界面等作為軟體設計的目標。

　　4、文檔考古

　　文檔考古是指對歷史存在的一些文檔進行研究，從帶有數據的文件、表單、報表等文檔中獲取所需信息的過程。對於一些數據流程比較複雜的、工作表單較多的項目來說，就可以應用這種方法。

　　5、建立聯合分析小組

　　在系統開發時，系統分析員和用戶之間由於知識結構的差異，難免存在難逾越的交流鴻溝。

　　用戶提供的需求信息，在系統分析員看來可能是零散和片面甚至無法理解的。因此，為了能夠減少交流上的問題，就需要一個領域專家來幫助進行溝通，即可以建立一個由用戶、系統分析員和領域專家參加的聯合分析小組來共同完成需求的獲取。

　　6、原型法

　　原型是在軟體開發中被廣泛使用的一種工具，在軟體系統的很多開發階段都起著非常重要的作用。原型法就是儘可能快地建造一個粗糙的系統，這系統實現了目標系統的某些或全部功能，但是這個系統可能在可靠性、界面的友好性或其他方面上存在缺陷。建造這樣一個系統的目的是為了考察某一方面的可行性，如演算法的可行性，技術的可行性，或考察是否滿足用戶的需求等。原型是在最終系統產生之前的一個局部真實表現，可以讓人們能夠對一些具體問題進行基於實物的有效溝通，從而幫助人們儘早解決軟體開發中存在的各種不確定性。

　　原型主要有三種類型：探索型，實驗型，進化型。探索型的目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性，實驗型是用於大規模開發和實現前，考核方案是否合適，規約說明是否可靠；進化型的目的不在於改進規約說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。

　　對於原型法的使用也有兩種不同的策略：廢棄策略和追加策略。廢棄策略是指先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反覆進行修改，形成比較好的思想，據此設計出較完整、準確、一致、可靠的最終系統，系統構造完成後，原來的模型系統就被廢棄不用。探索型和實驗型屬於這種策略。追加策略則與之不同，它是指在原模型的基礎之上不斷增加和修改，最終產生實用的系統。

　　在需求模糊的不確定性較大的情況下，使用原型方法來進行需求信息的獲取尤其有效。

　　7、模型驅動

　　前面的面談、原型、觀察以及文檔審查等方法可以通過執行一些具體的獲取行為來對系統需求進行認知和理解。但是大多數軟體系統，尤其是對於複雜的系統而言，它們的需求獲取任務絕不是可以通過一兩次這樣簡單的獲取行為就能夠完成的。為了能夠使得獲取行為相互配合、減少不必要的精力耗費和防止出現獲取信息的遺漏，可以採用模型驅動的方法。

　　模型驅動方法是一類以定義明確的模型為理論基礎，依據模型指導和組織活動開展的需求獲取方法。這些方法的模型定義確定了所要收集的信息類型，模型的建立和完善的過程就是進行需求獲取的過程。常見的模型驅動方法有面向目標的方法(Goal—Oriented Methods)、基於場景的方法(Scenario—Based Methods)和基於用例模型的方法(Use Case—Based Methods)。

　　這裡主要討論一下基於用例模型的方法。建立用例模型是一種需求獲取的有效方法，其簡潔清晰的描述方式容易被軟體人員和用戶共同理解和接受。在用例模型中，角色和用例是兩個基本概念，分別代表著系統外部的執行者和系統應包含的功能，因此，建立用例模型的主要工作是確定角色、確定用例和描述用例。用例模型以用戶和任務為中心，將整個工作的焦點集中在從用戶的角度說明系統能夠乾什麼，完全不考慮具體的實現細節，從而達到準確地理解客戶需求的目的。這種方法已經在許多大型系統的開發中取得成效，實踐證明它能有效地解決用戶參與的問題。

　　8、基於上下文的方法

　　軟體系統是作為一個整體存在的，它通過和環境的交互來解決用戶的問題，滿足用戶的需求。軟體系統中的每項功能都是依存於一定的背景和上下文環境，因此，要正確地理解系統的功能就必須要正確地理解它的背景和上下文知識。基於上下文的方法就是註重於系統的環境、開發組織的業務背景、涉眾的特征以及目標等。與前面的方法相比，它更加註重用戶在一定環境下表現出來的行為，通過分析用戶的行為得到信息。

• 李彤，王煒，鬱湧編著,軟體工程概論,科學出版社,2012.02,第42頁