需求捕獲與軟件需求的來源以及軟件工程師如何收集它們有關。這是建立對軟件需要解決的問題的理解的第一個階段。它基本上是一種人工活動，是確定利益攸關方并在開發團隊和客戶之間建立關系的地方。它被稱為“需求捕獲”、“需求發現”和“需求獲取”。

一個好的需求捕獲過程的基本原則之一是在各個利益攸關方之間進行有效的溝通。在整個軟件開發生命周期(軟件開發生命周期)過程中，在不同的時間點與不同的利益攸關方進行這種交流。在開發開始之前，需求專家可能會形成這種溝通的渠道。他們必須在軟件用戶(和其他利益攸關方)的領域和軟件工程師的技術世界之間進行協調。在不同抽象層面上的一組內部一致的模型促進了軟件用戶/利益攸關方和軟件工程師之間的通信。

需求捕獲的一個關鍵元素是告知項目范圍。這包括提供被指定的軟件的描述，以及它的目的和交付的優先級，以確保客戶最重要的業務需求首先得到滿足。這最大限度地減少了需求專家花費時間來引出那些不重要的需求，或者那些在軟件交付時不再相關的需求的風險。另一方面，描述必須是可伸縮的和可擴展的，以接受第一個正式列表中沒有表示的進一步需求，并與遞歸方法中預想的前一個需求兼容。

3.1需求來源

在典型的軟件中，需求有許多來源，識別和評估所有潛在的來源是至關重要的。本主題旨在提高人們對軟件需求的各種來源以及管理這些需求的框架的認識。主要內容如下:

目標。術語“目標”(有時稱為“業務關注”或“關鍵成功因素”)指的是軟件的總體、高層次的目標。目標提供了開發軟件的動機，但通常是模糊的表述。軟件工程師需要特別注意評估目標的價值(相對于優先級)和成本?？尚行匝芯渴且环N成本相對較低的方法。

領域知識。軟件工程師需要獲得或擁有有關應用程序領域的可用知識。領域知識提供了背景，所有引出的需求知識必須在此基礎上設置，以便理解它。在知識領域中模擬本體論方法是一個很好的實踐。應該確定應用領域內相關概念之間的關系。

利益攸關方(見第2.2節，過程參與者)。許多軟件被證明是不令人滿意的，因為它強調了一組利益相關方的需求而犧牲了其他的利益相關方。因此，交付的軟件很難使用，或者顛覆了客戶組織的文化或政治結構。軟件工程師需要識別、表示和管理許多不同類型的利益攸關方的“觀點”。

業務規則。這些語句定義或約束業務本身的結構或行為的某些方面?！叭绻€有一些未支付的學費，學生就不能注冊下學期的課程”這是一個商業規則的例子，它將成為大學課程注冊軟件的需求來源。

操作環境。需求將來自執行軟件的環境。例如，這些可能是實時軟件中的時間約束或操作環境中的性能約束。這些必須積極地尋求，因為它們會極大地影響軟件的可行性和成本，并限制設計選擇。

組織環境。通常需要軟件來支持業務過程，對業務過程的選擇可能受到組織的結構、文化和內部政治的制約。軟件工程師需要對這些敏感，因為一般來說，新軟件不應該強制在業務過程中進行計劃外的變更。

3.2啟發式技術

一旦確定了需求源，軟件工程師就可以開始從它們中提取需求信息。請注意，需求很少是現成的。相反，軟件工程師從這些信息中獲取信息來制定需求。本主題集中于讓人類利益攸關方表達需求相關信息的技術。這是一項非常困難的任務，軟件工程師需要敏感地認識到這樣一個事實，即(例如)用戶可能難以描述他們的任務，可能會遺漏重要的信息，或者可能不愿意或不能合作。特別重要的是要明白，啟發式抽取不是一種被動的活動，即使有合作的、善于表達的利益攸關方可用，軟件工程師也必須努力工作來引出正確的信息。許多業務或技術需求都是默認的或尚未從最終用戶獲得的反饋。計劃、驗證和確認在需求捕獲中的重要性怎么強調都不過分。有許多技術可以用于提取需求;最主要的是:

采訪。采訪利益攸關方是獲得需求的“傳統”方法。重要的是要了解訪談的優勢和局限性以及應該如何進行。

場景。場景為引出用戶需求提供了一種有價值的方法。它們允許軟件工程師提出“如果”和“如何完成”的問題，從而為有關用戶任務的問題提供框架。最常見的場景類型是用例描述。這里有一個主題4.2(概念建模)的鏈接，因為場景符號，例如用例圖，在建模軟件中很常見。

原型。對于澄清不明確的需求，該技術是一種有價值的工具。它們可以以與場景類似的方式進行操作，為用戶提供一個環境，用戶可以在其中更好地理解需要提供哪些信息。原型技術的范圍很廣——從屏幕設計的紙質模型到軟件產品的beta測試版本——它們在需求捕獲和需求驗證方面的不同用途有很大的重疊(見6.2節，原型)。低保真度原型通常是為了避免利益相關方“錨定”在一個高質量原型的次要的、偶然的特征上，這些特征會以意想不到的方式限制設計的靈活性。

促進會議。這些會議的目的是試圖達到一種總結性的效果，通過這種效果，一組人可以對他們的軟件需求帶來比單獨工作更多的見解。他們可以集思廣益，提煉那些通過評審難以表達出來的想法。另一個優點是沖突的需求很早就出現了，可以讓利益攸關方識別這些需求發生的位置。當它工作得很好時，這種技術可能會導致比其他方法更豐富、更一致的需求集。然而,會議需要謹慎處理(因此需要主持人),以防止情況的關鍵能力的團隊正在侵蝕組織忠誠,或在需求反映了一些直接的擔憂(也許高級)人青睞的損害他人。

觀察。在組織環境中軟件環境的重要性導致了觀察技術的適應，例如需求捕獲的民族志。軟件工程師通過將自己沉浸在環境中來學習用戶任務，并觀察用戶如何通過相互交互以及軟件工具和其他資源來執行他們的任務。這些技術相對昂貴，但也很有指導意義，因為它們說明了許多用戶任務和業務過程太過微妙和復雜，以至于參與者很難描述它們。

用戶故事。這種技術通常用于自適應方法中(參見軟件工程模型和方法知識領域中的敏捷方法)，并引用了用客戶術語表達的所需功能的簡短、高層次的描述。典型的用戶故事有這樣的形式:“As A ， I want<目標/愿望>，則<效益>。一個用戶故事應該包含足夠的信息，以便開發人員能夠對實現它所付出的努力做出合理的估計。這樣做的目的是為了避免在項目中經常發生的一些浪費，在這些項目中，詳細的需求在工作開始之前就被收集起來了，但是這些需求在工作開始之前就變得無效了。在實現用戶故事之前，客戶必須編寫一個適當的驗收過程，以確定用戶故事的目標是否已經實現。

其他技術。還有一系列其他技術支持提取需求信息，從分析競爭對手的產品到應用數據挖掘技術，再到使用領域知識庫或客戶請求數據庫。

原文標題：3.需求獲取

文章出處：【微信公眾號：汽車電子硬件設計】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq