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

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

需求捕獲的一個關(guān)鍵元素是告知項目范圍。這包括提供被指定的軟件的描述，以及它的目的和交付的優(yōu)先級，以確?？蛻糇钪匾臉I(yè)務(wù)需求首先得到滿足。這最大限度地減少了需求專家花費時間來引出那些不重要的需求，或者那些在軟件交付時不再相關(guān)的需求的風(fēng)險。另一方面，描述必須是可伸縮的和可擴展的，以接受第一個正式列表中沒有表示的進(jìn)一步需求，并與遞歸方法中預(yù)想的前一個需求兼容。

3.1需求來源

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

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

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

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

業(yè)務(wù)規(guī)則。這些語句定義或約束業(yè)務(wù)本身的結(jié)構(gòu)或行為的某些方面。“如果還有一些未支付的學(xué)費，學(xué)生就不能注冊下學(xué)期的課程”這是一個商業(yè)規(guī)則的例子，它將成為大學(xué)課程注冊軟件的需求來源。

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

組織環(huán)境。通常需要軟件來支持業(yè)務(wù)過程，對業(yè)務(wù)過程的選擇可能受到組織的結(jié)構(gòu)、文化和內(nèi)部政治的制約。軟件工程師需要對這些敏感，因為一般來說，新軟件不應(yīng)該強制在業(yè)務(wù)過程中進(jìn)行計劃外的變更。

3.2啟發(fā)式技術(shù)

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

采訪。采訪利益攸關(guān)方是獲得需求的“傳統(tǒng)”方法。重要的是要了解訪談的優(yōu)勢和局限性以及應(yīng)該如何進(jìn)行。

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

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

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

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

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

其他技術(shù)。還有一系列其他技術(shù)支持提取需求信息，從分析競爭對手的產(chǎn)品到應(yīng)用數(shù)據(jù)挖掘技術(shù)，再到使用領(lǐng)域知識庫或客戶請求數(shù)據(jù)庫。

原文標(biāo)題：3.需求獲取

文章出處：【微信公眾號：汽車電子硬件設(shè)計】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq