關鍵字：需求分析 方法
需求獲取(requirement elicitation)是需求工程的主體。對于所建議的軟件產品，獲取需求是一個確定和理解不同用戶類的需要和限制的過程。獲取用戶需求位于軟件需求三個層次的中間一層。業務需求決定用戶需求，它描述了用戶利用系統需要完成的任務。從這些任務中，分析者能獲得用于描述系統活動的特定的軟件功能需求，這些系統活動有助于用戶執行他們的任務。 需求獲取是在問題及其最終解決方案之間架設橋梁的第一步。獲取需求的一個必不可少的結果是對項目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之后才能開始設計系統，否則，對需求定義的任何改進，設計上都必須大量的返工。把需求獲取集中在用戶任務上—而不是集中在用戶接口上—有助于防止開發組由于草率處理設計問題而造成的失誤。 需求獲取、分析、編寫需求規格說明和驗證并不遵循線性的順序，這些活動是相互隔開、增量和反復的。當你和客戶合作時，你就將會問一些問題，并且取得他們所提供的信息(需求獲取)。同時，你將處理這些信息以理解它們，并把它們分成不同的類別，還要把客戶需求同可能的軟件需求相聯系(分析)。然后，你可以使客戶信息結構化，并編寫成文檔和示意圖(說明)。下一步，就可以讓客戶代表評審文檔并糾正存在的錯誤(驗證)。這四個過程貫穿著需求分析的整個階段。 需求獲取可能是軟件開發中最困難、最關鍵、最易出錯及最需要交流的方面。需求獲取只有通過有效的客戶—開發者的合作才能成功。分析者必須建立一個對問題進行徹底探討的環境，而這些問題與產品有關。為了方便清晰地進行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對需求問題的全面考察需要一種技術，利用這種技術不但考慮了問題的功能需求方面，還可討論項目的非功能需求。確定用戶已經理解：對于某些功能的討論并不意味著即將在產品中實現它。對于想到的需求必須集中處理并設定優先級?，以避免一個不能帶來任何益處的無限大的項目。 需求獲取是一個需要高度合作的活動，而并不是客戶所說的需求的簡單謄本。作為一個分析者，你必須透過客戶所提出的表面需求理解他們的真正需求。詢問一個可擴充(open-ended)的問題有助于你更好地理解用戶目前的業務過程并且知道新系統如何幫助或改進他們的工作。調查用戶任務可能遇到的變更，或者用戶需要使用系統其它可能的方式。想像你自己在學習用戶的工作，你需要完成什么任務?你有什么問題?從這一角度來指導需求的開發和利用。
還有，探討例外的情況：什么會妨礙用戶順利完成任務?對系統錯誤情況的反映，用戶是如何想的?詢問問題時，以“還有什么能” ,”當?時，將會發生什么”“你有沒有曾經想過” ,“有沒有人曾經”為開頭。記下每一個需求的來源，這樣向下跟蹤直到發現特定的客戶。
有些時候，嘗試著問一些“愚蠢”的問題也有助于客戶打開話匣子。如果你直接要求客戶寫出業務是如何實現的，客戶十有八九無法完成。但是如果你嘗試著問一些實際的問題，例如：“以我的理解，你們收到訂單后，會...”�？蛻袅⒖叹蜁赋瞿愕腻e誤，并滔滔不絕的開始談論業務，而你，就在一邊仔細的聆聽吧。這一招就叫做“拋磚引玉”。
需求討論會上必須要使用筆記本電腦，還要指定一個打字熟練的人把所有的討論記錄下來，記錄的同時還要做一定的整理。如果不這樣做，那么你結束會議的時候就會發現，所有的討論只剩下一個模糊的印象，需求對你來說仍然是一件遙遠的事情。在座談討論之后，記下所討論的條目(item)，并請參與討論的用戶評論并更正。及早并經常進行座談討論是需求獲取成功的一個關鍵途徑，因為只有提供需求的人才能確定是否真正獲取需求。進行深入收集和分析以消除任何沖突或不一致性。
盡量把客戶所持的假設解釋清楚，特別是那些發生沖突的部分。從字里行間去理解以明確客戶沒有表達清楚但又想加入的特性或特征。Gause 和Weinberg(1989)提出使用“上下文無關問題”—這是一個高層次的問題，它可以獲取業務問題和可能的解決方案的全部信息�？蛻魧@些問題的回答諸如“產品要求怎樣的精確度”或“你能幫我解釋一下你為什么不同意某人的回答嗎?”這些回答可以更直接地認識問題，而這是封閉(close-end)問題所不能做到的。
需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟件解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發者和客戶之間采用了更多的交流方式(Kiel and Carmel 1995)。與單個客戶或潛在的用戶組一起座談，對于業務軟件包或信息管理系統(MIS)的應用來說是一種傳統的需求來源。直接聘請用戶進行獲取需求的過程是為項目獲得支持和買入(buy-in)的一種方式。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
