需求獲取

需求獲取，屬於軟體工程中的一部分，包括需求來源和獲取需求的技術。它是軟體設計的第一階段，其本質主要是人的活動，涉及軟體設計人員如何與客戶建立有效的溝通。也稱為“需求發現”、“需求獲得”。
需求獲取(requirement elicitation)是需求工程的主體。對於所建議的軟體產品，獲取需求是一個確定和理解不同用戶類的需要和限制的過程。獲取用戶需求位於軟體需求三個層次的中間一層。業務需求決定用戶需求，它描述了用戶利用系統需要完成的任務。從這些任務中，分析者能獲得用於描述系統活動的特定的軟體功能需求，這些系統活動有助於用戶執行他們的任務。需求獲取和分析包括對原始需求變更控制，版本控制，從需求到產品和模組的可追溯性，成品交付和產品的狀態跟蹤。
需求獲取是在問題及其最終解決方案之間架設橋樑的第一步。獲取需求的一個必不可少的結果是對項目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之後才能開始設計系統，否則，對需求定義的任何改進，設計上都必須大量的返工。把需求獲取集中在用戶任務上—而不是集中在用戶接口上—有助於防止開發組由於草率處理設計問題而造成的失誤。
需求獲取、分析、編寫需求規格說明和驗證並不遵循線性的順序，這些活動是相互隔開、增量和反覆的。當你和客戶合作時，你就將會問一些問題，並且取得他們所提供的信息（需求獲取）。同時，你將處理這些信息以理解它們，並把它們分成不同的類別，還要把客戶需求同可能的軟體需求相聯繫（分析）。然後，你可以使客戶信息結構化，並編寫成文檔和示意圖（說明）。下一步，就可以讓客戶代表評審文檔並糾正存在的錯誤（驗證）。這四個過程貫穿著需求分析的整個階段。 需求獲取可能是軟體開發中最困難、最關鍵、最易出錯及最需要交流的方面。需求獲取只有通過有效的客戶—開發者的合作才能成功。分析者必須建立一個對問題進行徹底探討的環境，而這些問題與產品有關。為了方便清晰地進行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對需求問題的全面考察需要一種技術，利用這種技術不但考慮了問題的功能需求方面，還可討論項目的非功能需求。確定用戶已經理解：對於某些功能的討論並不意味著即將在產品中實現它。對於想到的需求必須集中處理並設定優先權，以避免一個不能帶來任何益處的無限大的項目。
需求獲取是一個需要高度合作的活動，而並不是客戶所說的需求的簡單謄本。作為一個分析者，你必須透過客戶所提出的表面需求理解他們的真正需求。詢問一個可擴充（open-ended）的問題有助於你更好地理解用戶目前的業務過程並且知道新系統如何幫助或改進他們的工作。調查用戶任務可能遇到的變更，或者用戶需要使用系統其它可能的方式。想像你自己在學習用戶的工作，你需要完成什麼任務？你有什麼問題？從這一角度來指導需求的開發和利用。
還有，探討例外的情況：什麼會妨礙用戶順利完成任務？對系統錯誤情況的反映，用戶是如何想的？詢問問題時，以“還有什麼能” ,”當?時，將會發生什麼”“你有沒有曾經想過” ,“有沒有人曾經”為開頭。記下每一個需求的來源，這樣向下跟蹤直到發現特定的客戶。
有些時候，嘗試著問一些“愚蠢”的問題也有助於客戶打開話匣子。如果你直接要求客戶寫出業務是如何實現的，客戶十有八九無法完成。但是如果你嘗試著問一些實際的問題，例如：“以我的理解，你們收到訂單後，會...”。客戶立刻就會指出你的錯誤，並滔滔不絕的開始談論業務，而你，就在一邊仔細的聆聽吧。這一招就叫做“拋磚引玉”。
需求討論會上必須要使用筆記本電腦，還要指定一個打字熟練的人把所有的討論記錄下來，記錄的同時還要做一定的整理。如果不這樣做，那么你結束會議的時候就會發現，所有的討論只剩下一個模糊的印象，需求對你來說仍然是一件遙遠的事情。在座談討論之後，記下所討論的條目(item)，並請參與討論的用戶評論並更正。及早並經常進行座談討論是需求獲取成功的一個關鍵途徑，因為只有提供需求的人才能確定是否真正獲取需求。進行深入收集和分析以消除任何衝突或不一致性。
儘量把客戶所持的假設解釋清楚，特別是那些發生衝突的部分。從字裡行間去理解以明確客戶沒有表達清楚但又想加入的特性或特徵。Gause 和Weinberg（1989）提出使用“上下文無關問題”—這是一個高層次的問題，它可以獲取業務問題和可能的解決方案的全部信息。客戶對這些問題的回答諸如“產品要求怎樣的精確度”或“你能幫我解釋一下你為什麼不同意某人的回答嗎？”這些回答可以更直接地認識問題，而這是封閉（close-end）問題所不能做到的。
需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟體解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發者和客戶之間採用了更多的交流方式（Kiel and Carmel 1995）。與單個客戶或潛在的用戶組一起座談，對於業務軟體包或信息管理系統（MIS）的套用來說是一種傳統的需求來源。直接聘請用戶進行獲取需求的過程是為項目獲得支持和買入（buy-in）的一種方式。
儘量理解用戶用於表述他們需求的思維過程。充分研究用戶執行任務時作出決策的過程，並提取出潛在的邏輯關係。流程圖和決策樹是描述這些邏輯決策途徑的好方法。
在需求獲取的過程中，你可能會發現對項目範圍的定義存在誤差，不是太大就是太小。如果範圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業務和客戶的值，此時獲取過程將會拖延。如果項目範圍太小，那么客戶將會提出很重要的但又在當前產品範圍之外的需求。當前的範圍太小，以致不能提供一個令人滿意的產品。需求的獲取將導致修改項目的範圍和任務，但作出這樣具有深遠影響的改變，一定要小心謹慎。
正如經常所說的，需求主要是關於系統做什麼，而解決方案如何實現是屬於設計的範圍。這樣說雖然很簡潔，但似乎過於簡單化。需求的獲取應該把重點放在“做什麼”上，但在分析和設計之間還是存在一定的距離。你可以使用假設“怎么做”來分類並改善你對用戶需求的理解。在需求的獲取過程中，分析模型、螢幕圖形和原型可以使概念表達得更加清楚，然後提供一個尋找錯誤和遺漏的辦法。把你在需求開發階段所形成的模型和螢幕效果看成是方便高效交流的概念性建議，而不應該看成是對設計者選擇的一種限制。
需求獲取討論會中如果參與者過多，就會減慢進度。人數大致控制在5到7人是最好的。這些人包括客戶、系統設計者、開發者和可視化設計者等主要工程角色。相反地，從極少的代表那裡收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將導致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數用戶的需要。最好的權衡在於選擇一些授權為他們的用戶類發言的產品代表者，他們也被同組用戶類的其它代表所支持。
沒有一個簡單、清楚的信號暗示你什麼時候已完成需求獲取。當客戶和開發者與他們的同事聊天、閱讀工業和商業上的文獻及在早上沐浴時思考時，他們都將對潛在產品產生新的構思。你不可能全面收集需求，但是下列的提示將會暗示你在需求獲取的過程中的返回點。
1. 如果用戶不能想出更多的使用實例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來確定使用實例的。
2. 如果用戶提出新的使用實例，但你可以從其它使用實例的相關功能需求中獲得這些新的使用實例，這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的其它使用實例的可選過程。
3. 如果用戶開始重複原先討論過的問題，此時，也許你就完成了收集需求的工作。
4. 如果所提出的新需求比你已確定的需求的優先權都低時，也許你就完成了收集需求的工作。
5. 如果用戶提出對將來產品的要求，而不是現在我們討論的特定產品，也許你就完成了收集需求的工作。
以上知識大致上討論需求分析應該如何做，實際上對於需求分析的方法有很多很多，已經形成了一定的理論，當然這種理論比較偏向與方法學，而方法學的套用主要還是要靠個人。所以，大家在實際套用的時候，不妨結合自己的實際，有選擇性的採用一些方法，那你就是成功的。
多年來，分析者總是利用情節或經歷來描述用戶和軟體系統的互動方式，從而獲取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把這種看法系統地闡述成用例（用例）的方法進行需求獲取和建模。雖然用例來源於面向對象的開發環境，但是它也能套用在具有許多開發方法的項目中，因為用戶並不關心你是怎樣開發你的軟體。而最重要的，用例的觀點和思維過程帶給需求開發的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統做什麼遠遠強於詢問用戶希望系統為他們做什麼這一傳統方法。
用例的重要功能是用畫用例圖的功能來鑑別和劃分系統功能。它把系統分成角色（actor）和用例（用例）。角色(actor)表示系統用戶能扮演的角色（role）。這些用戶可能是人，可能是其他的計算機一些硬體或者甚至是其它軟體系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外。它們必須能刺激系統部分並接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文本描述。它描述了觸發用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統應採取的補救措施。
這樣說可能會非常複雜，其實一個用例描述了系統和一個角色（actor）的互動順序。用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。用例可以:
· 用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。
· 用例由角色激活，並提供確切的值給角色。
· 用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。在UML中，用例表示為一個橢圓。
角色是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可能有許多角色實例（例如有很多個銷售員），但就該系統而言，他們均起著同一種作用，扮演著相同的角色，所以用一個角色表示。一個用戶也可以扮演多種角色。例如，一個高級行銷人員既可以是貿易經理，也可以是普通的行銷人員；一個行銷人員也可以是售貨員。在處理角色時，應考慮其作用，而不是人或工作名稱，這一點是很重要的。
我們使用不帶箭頭的線段將角色與用例連線到一起，表示兩者之間交換信息，稱之為通信聯繫。角色觸發用例，並與用例進行信息交換。單個角色可與多個用例聯繫；反過來，一個用例可與多個角色聯繫。對同一個用例而言，不同角色有著不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，儘管執行的，但角色未必是人。例如，角色也可以是一個外界系統，該外界系統可能需要從當前系統中獲取信息，與當前系統有進行互動。
一個用例可能包括完成某項任務的許多邏輯相關任務和互動順序。因此，一個用例是相關的用法說明的集合，並且一個說明（scenario）是用例的實例。這種關係就像是類和對象的關係。在用例中，一個說明被視為事件的普通過程(normal course)，也叫作主過程，基本過程，普通流，或“滿意之路” (happy path)。在描述普通過程時列出執行者和系統之間相互互動或對話的順序。當這種互動結束時，執行者也達到了預期的目的。
在用例中的其它說明可以描述為可選過程(alternative coruse)。可選過程也可促進成功地完成任務，但它們代表了任務的細節或用於完成任務的途徑的變化部分。在互動序列中，普通過程可以在一些決策點上分解成可選過程，然後再重新匯成一個普通過程。