需求工程

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

需求工程(Requirements Engineering，RE)

　　需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特征的一門學科。需求工程通過合適的工具和記號系統地描述待開發系統及其行為特征和相關約束，形成需求文檔，並對用戶不斷變化的需求演進給予支持。

　　需求工程是隨著電腦的發展而發展的，在電腦發展的初期，軟體規模不大，軟體開發所關註的是代碼編寫，需求分析很少受到重視。後來軟體開發引入了生命周期的概念，需求分析成為其第一階段。隨著軟體系統規模的擴大，需求分析與定義在整個軟體開發與維護過程中越來越重要，直接關係到軟體的成功與否。人們逐漸認識到需求分析活動不再僅限於軟體開發的最初階段，它貫穿於系統開發的整個生命周期。80年代中期，形成了軟體工程的子領域——需求工程(requirement engineering,RE)。進入90年代以來，需求工程成為研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《Requirements Engineering》。一些關於需求工程的工作小組也相繼成立，如歐洲的RENOIR(Requirements Engineering Network of International Cooperating Research Groups)，並開始開展工作。

　　需求分析是介於系統分析和軟體設計階段之間的橋梁。一方面，需求分析以系統規格說明和項目規劃作為分析活動的基本出發點，並從軟體角度對它們進行檢查與調整；另一方面，需求規格說明又是軟體設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或儘早剔除早期錯誤，從而提高軟體生產率，降低開發成本，改進軟體質量。

　　需求工程(RE)可分為

　　1.系統需求工程（如果是針對由軟硬體共同組成的整個系統）

　　2.軟體需求工程（如果僅是專門針對純軟體部分）。

　　軟體需求工程是一門分析並記錄軟體需求的學科，它把系統需求分解成一些主要的子系統和任務，把這些子系統或任務分配給軟體，並通過一系列重覆的分析、設計、比較研究、原型開發過程把這些系統需求轉換成軟體的需求描述和一些性能參數。

　　需求工程是一個不斷反覆的需求定義、文檔記錄、需求演進的過程，並最終在驗證的基礎上凍結需求。80年代，HerbKrasner定義了需求工程的五階段生命周期：需求定義和分析、需求決策、形成需求規格、需求實現與驗證、需求演進管理。近來，MatthiasJarke和KlausPohl提出了三階段周期的說法：獲取、表示和驗證。

　　綜合了幾種觀點，可以把需求工程的活動劃分為以下5個獨立的階段：

　　（1）需求獲取：通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；

　　（2）需求建模：為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述，並儘可能多的捕獲現實世界的語義；

　　（3）形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；

　　（4）需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性；

　　（5）需求管理：支持系統的需求演進，如需求變化和可跟蹤性問題。

　　需求工程無疑是當前軟體工程中的關鍵問題，從美國於1995年開始的一項調查結果就足以看出這一點。在這項調查中，他們對全國範圍內的8000個軟體項目進行跟蹤調查，結果表明，有1/3的項目沒能完成，而在完成的2/3的項目中，又有1/2的項目沒有成功實施。他們仔細分析失敗的原因後發現，與需求過程相關的原因占了45%，而其中缺乏最終用戶的參與以及不完整的需求又是兩大首要原因，各占13%和12%。

　　需求工程又是軟體工程中最複雜的過程之一，其複雜性來自於客觀和主觀兩個方面。從客觀意義上說，需求工程面對的問題幾乎是沒有範圍的。由於應用領域的廣泛性，它的實施無疑與各個應用行業的特征密切相關。其客觀上的難度還體現在非功能性需求及其與功能性需求的錯綜複雜的聯繫上，當前對非功能性需求分析建模技術的缺乏大大增加了需求工程的複雜性。從主觀意義上說，需求工程需要方方面面人員的參與（如領域專家、領域用戶、系統投資人、系統分析員、需求分析員等等），各方面人員有不同的著眼點和不同的知識背景，溝通上的困難給需求工程的實施增加了人為的難度。

　　最初，需求工程僅僅是軟體工程的一個組成部分，是軟體生命周期的第一個階段。雖然大家也都知道需求工程對軟體整個生命周期的重要性，但對它的研究遠遠沒有對軟體工程的其他部分的研究那麼深入。

　　在傳統軟體工程生命周期中，涉及需求的階段稱作需求分析。一般來說，需求分析的作用是：

• 系統工程師說明軟體的功能和性能，指明軟體和其他系統成分的介面，並定義軟體必須滿足的約束；

• 軟體工程師求精軟體的配置，建立數據模型、功能模型和行為模型；

• 為軟體設計者提供可用於轉換為數據設計、體繫結構設計、界面設計和過程設計的模型；

• 提供開發人員和客戶需求規格說明，用於作為評估軟體質量的依據。

但從當前的研究現狀來看，需求工程的內容遠不止這些。需求工程是系統工程和軟體工程的一個交叉分支，涉及到軟體系統的目標、軟體系統提供的服務、軟體系統的約束和軟體系統運行的環境。它還涉及這些因素和系統的精確規格說明以及系統進化之間的關係。它也提供現實需要和軟體能力之間的橋梁。

　　需求工程的基本活動包括：

• 抽取需求；

• 模擬和分析需求；

• 傳遞需求；

• 認可需求；

• 進化需求。

　　每個活動都有它基本的動機、任務和結果，也有各自的困難所在。

　　首先，開始一個項目是因為要對現行系統進行改造。要改造一個系統是因為現行系統存在需要解決的問題。如：現行系統與當前情況不符合、出現新的商機或者可能節省時間、資金和資源等，這就是抽取需求的動機。在這個階段，需求工程師的任務是認識問題之所在，獲取足夠多的知識，最後成為問題領域的專家。需求工程師常採用W6H方法去認識問題領域，即6個以W打頭的問題，一個以H打頭的問題，如表1所示。

　　需求抽取是非常困難的，其主要原因有：

• 缺乏領域知識，應用領域的問題常常是模糊的、不精確的；

• 存在預設的知識，即難以描述的日常知識（常識問題）；

• 存在多個知識源，而且多知識源之間可能有衝突；

• 面對的客戶可能有偏見，如不能提供你需要瞭解什麼或不想告知你需要瞭解的事情。

　　需求抽取的方法一般有問卷法、面談法、數據採集法、用況法、情景實例法、組織會議法以及基於目標的方法等，還有知識工程方法，如：場記分析法、卡片分類法、分類表格技術和基於模型的知識獲取等。

　　需求工程的第二個階段是模擬和分析需求，目前有許多工作都以此為目標進行。需求分析和模擬的出發點在於：

• 指導抽取；

• 幫助需求工程師瞭解進展；

• 幫助發現問題；

• 幫助檢查對問題的理解。

　　需求分析和模擬又包含三個層次的工作。首先是需求建模。需求模型的表現形式有自然語言、半形式化（如圖、表、結構化英語等）和形式化表示等三種。自然語言形式具有表達能力強的特點，但它不利於捕獲模型的語義，一般只用於需求抽取或標記模型。半形式化表示可以捕獲結構和一定的語義，也可以實施一定的推理和一致性檢查。形式化表示具有精確的語義和推理能力，但要構造一個完整的形式化模型，需要較長時間和對問題領域的深層次理解。對需求概念模型的要求包括：

• 實現的獨立性:不模擬數據的表示和內部組織等；

• 足夠抽象：只抽取關於問題的本質方面；

• 足夠形式化：語法無二義性，並具有豐富的語義；

• 可構造性：簡單的模型塊，能應付不同複雜程度和規模的描述；

• 利於分析：能支持二義性、不完整性和不一致性分析；

• 可追蹤性:支持橫向交叉索引並能與設計或實現等建立關聯；

• 可執行性：可以動態模擬，利於與現實相比較；

• 最小性：沒有冗餘的概念。

　　需求模擬技術又分為企業模擬、功能需求模擬和非功能需求模擬等。

　　企業模擬是一種軟系統方法，涉及整個組織，從各個不同的視點分析問題，包括目標、組織結構、活動、過程等。有的企業模擬還建立可執行的領域模型。採用企業模擬方法產生的不僅僅是規格說明，還可以得到許多關於企業運作的狀況分析。目前代表性的工作包括：信息模擬、組織模擬和目標模擬等。

　　功能需求模擬從不同視點為模擬軟體提供服務，包括結構視點和行為視點等，主要方法有：結構化分析、面向對象分析和形式化方法。結構化分析是一種面向數據的方法，以數據流為中心。其核心概念包括：進程、數據流、數據存儲、外部實體、數據組和數據元素。有代表性的模擬工具有：數據流圖、數據字典、原始進程規格說明。面向對象分析以對象及其服務作為建模標準，比較自然，對象也具有相對的穩定性。主要模擬的元素有：對象、類、屬性、關係、方法、消息傳遞、UseCases等。其主要原理包括分類繼承層次、信息隱藏、彙集關係等。形式化方法從廣義上說，是應用離散數學的手段來設計、模擬和分析，得到像數學公式那樣精確的表示。從狹義上說，就是使用一種形式語言進行語言公式的形式推理，用於檢查語法的良構性並證明某些屬性。形式化方法一般用於一致性檢查、類型檢查、有效性驗證、行為預測以及設計求精驗證。引入形式化機制的目的是：

• 減少二義性，提高精確性；

• 為驗證打下基礎；

• 允許對需求進行推理；

• 允許執行需求。

　　但是人們常常不用形式化手段，因為：

• 形式化涉及太多細節，分析的級別較低；

• 形式化的核心問題是一致性和完整性，而不是獲取需求；

• 沒有合適的工具；

• 要求更多的代價。

　　傳遞需求的主要任務是書寫軟體需求規格說明，其目的是：

• 傳達對需求的理解；

• 作為軟體開發項目的一份契約；

• 作為評價後續工作的基線；

• 作為控制需求進化的基線。

　　對需求規格說明感興趣的群體包括：用戶、客戶；系統分析員、需求分析員；軟體開發者、程式員；測試員；項目管理者。

　　認可需求就是讓上述人員對需求規格說明達成一致，其主要任務是衝突求解，包括定義衝突和衝突求解兩方面。常用的衝突求解方法有：協商、競爭、仲裁、強制、教育等，其中有些只能用人的因素去控制。

　　進化需求的必要性是明顯的，因為客戶的需要總是不斷（連續）增長的，但是一般的軟體開發又總是落後於客戶需求的增長，如何管理需求的進化（變化）就成為軟體進化的首要問題。對傳統的變化管理過程來說，其基本成分包括軟體配置、軟體基線和變化審查小組。當前的發展是軟體家族法，即產品線方法。多視點方法也是管理需求變化的一種新方法，它可以用於管理不一致性併進行關於變化的推理。

　　需求工程包括需求開發和管理，而需求開發又包括這幾個過程：需求獲取，需求分析，需求規格說明和需求驗證。在需求開發之前，還需要有一個知識培訓的過程，需求工程也是一個項目工程，因此也包括了項目的管理。對於這些過程，有以下方法可以採用。

　　1.知識培訓

　　需求分析員培訓：需求分析員應該具有良好的交流溝通能力，同時理解產品，並掌握了需求工程的技能。

　　用戶培訓：用戶也應該接受需求工程知識的培訓，讓他們理解需求的重要性，知道如何準確的描述需求，需求的風險性等。

　　開發人員培訓：開發人員應該對用戶的應用領域有一個基礎的瞭解，明白客戶的業務活動，術語，產品目標等

　　2.需求獲取

　　需求包括業務需求，用戶需求和功能需求以及非功能需求，在需求開發之前，我們需要先定義好需求開發的過程，形成文檔，內容包括：需求開發的步驟，每一個步驟如何實現，如何處理意外情況，如何規劃開發資源等

　　需求獲取包括以下方法和技能：

　　項目範圍確定：開需求開發前期，我們應該獲取用戶的業務需求，定義好項目的範圍，使得所有的涉眾對項目有一個共同的理解。

　　用戶確定：確定用戶群和分類，對用戶組進行詳細描述，包括使用產品頻率，所使用的功能，優先順序別，熟練程度等等。對每一個用戶組確定用戶的代言人。對於大型項目，我們需要先確定中心客戶組，中心客戶組的需求具有高級別的優先順序，需要先實現的核心功能。

　　用例確定：與用戶代表溝通，瞭解他們需要完成的任務，得到用例模型。同時根據用例導出功能需求。用例描述應該採用標準模板。

　　系統事件和響應：業務事件可能觸發用例，系統事件包括系統內部的事件以及從外部接受到信息，數據等等，或者一個突發的任務。

　　獲取方法：召開需求討論會議，觀察用戶的工作過程，採用問答式對話，採用誘髮式需求誘導等等。檢查完善：問題報告和補充需求建議

　　3.需求分析

　　需求分析是對用戶的需求獲取之後的一個粗加工過程，需要對需求進行推敲和潤色以使所有涉眾都能準確理解需求。分析過程首先需要對需求進行檢查，以保證需求的正確性和完備性，然後將高層需求分解成具體的細節，創建開發原型，完成需求從需求獲取人員到開發人員的過渡。

　　繪製關聯圖：關聯圖確定系統和外部的交互。劃分了系統的範圍和界限，構建了系統對外的介面。

　　原型開發：對於敏捷方法，推薦完成一個界面的原型，一個初步的系統實現，通過原型，讓所有涉眾對開發的項目有了一個初步的映像，同時可以提供對需求的檢驗。

　　需求優先順序別：採用分析的方法確定產品的功能，用例和單項需求的優先順序別，以優先順序為基礎，確定各項功能和需求都包括在哪個版本中，在項目開發過程中，需求的優先順序別根據實際情況進行調整。

　　需求建模：圖形分析模型對需求描述更加抽象。主要可以採用UML的建模分析。

　　數據字典創建：建立系統中所用到的數據項和結構的定義，數據字典可以使參與項目開發的每一個人都使用統一的定義。

　　子系統：建立系統的結構，同時將需求分配到各個子系統和模塊中。

　　4.規格說明

　　SRS應該是一個作為涉眾對系統的統一理解。

　　採用SRS模板：定義一種標準模板。

　　1.過程能力評估

　　通過比較現有需求工程過程與過程參考模型之間的差別，可以評估現有過程的能力水平。具體而言，首先以調查表、面談等方式收集組織中需求相關實踐的執行情況；然後，與過程參考模型中的實踐進行映射和比較，統計各能力等級下實踐的執行情況；根據統計結果判定當前所處的能力等級。

　　需求工程過程參考模型，當“已執行級”的基礎實踐被全部規範執行時，需求工程過程達到“已執行”能力等級，否則，需求過程處在“不完整”能力等級；當執行了全部的“已管理級”實踐時，需求工程過程達到“已管理”能力等級；當執行了全部的“已定義級”實踐時，需求開發工程達到“已定義”能力等級。

　　2.過程改進策略

　　確定了組織需求過程所處的能力水平後，可以通過引入新實踐或提高已有實踐的性能，實現過程的改進。首先要明確過程改進的目標；然後分析組織的資源條件，確定過程改進的主要內容和手段。要遵循漸進的過程改進策略。一般來說，按照“由低到高”、“先規範後引入”的順序逐提高過程能力，即先改進低能力等級的實踐再改進高能力等級的，先規範已有實踐再引入新實踐，這樣可以降低組織進行需求工程過程改進的風險。

　　需求分析階段的工作結果是開發軟體系統的重要基礎，大量統計數字表明，軟體系統中15%的錯誤起源與錯誤的需求。因此，軟體需求規格說明書完成以後，需要認真進行技術評審和修改。作為需求分析階段工作的複查手段，在需求分析的最後一步，應該對功能的正確性、完整性和清晰性，以及其他需求給予評價，可按以下準則評價和驗證。

　　1.正確性：正確性是最基本的要求之一，一般是指雜需求規格說明書中對於待開發系統的功能、行為、性能的描述必須與用戶對目標軟體產品的期望相吻合，正確性是相對與用戶的應用需求而言的，由於具體應用的千差萬別，需求規格說明書的正確性的判斷標準也應各不相同。正確性檢查屬於技術問題，它並不能說明需求模型是否完全表達了用戶需求。評價正確性時，可以按照建模規則去檢查，或使用軟體工具(如CASE)自動檢查。當然，也可以請其他不參與該項目的同行校對，發現錯誤及時更正。

　　2.完整性：完整性是指需求模型中是否包含了用戶所需的所有功能，這是最基本的要求，若不能滿足，其它任何質量問題都無從談起。因為需求分析的不完全，即使後面的設計與實現再好，也不能滿足用戶的要求。並且，在系統開發後期增加或更改用戶需求，將會成倍地增加開發代價。因此，完整性評價是需求工程質量的關鍵。改進需求分析的完整性將有助於提高軟體開發的生產率，但評價完全性問題卻很難。因為用戶有時不能完全表達其所有需求，開發者又沒有預見，致使軟體完成後才發現，維護代價相當大。為了及時發現問題，開發者最好跟班作業，對用戶的業務進行深入地瞭解，從而對需求模型的完全性作出評價。具體評價方法可採用用戶審閱、樣例分析、業務規則驗證、進程映像等方法。

　　3.實現性：實現性是指需求模型可以在規定的時間、經費預算和項目的技術約束下完成整個軟體開發。這就要求我們在需求模型中不要出現這樣或那樣的假設，不要忽略各種實際因素，特別是技術和經費，以免到開發後期追悔莫及。評價可實現性主要應用下麵兩種方法:

　　（1）應用開發人員審閱。他們會重點審查系統實現的一些潛在問題，從技術和經濟角度分析系統實現的可行性，發現問題可及早修改。

　　（2）開發代價估計。這是對需求模型的實現性進行定量測量的方法，通常質量越好代價越大，降低代價就要犧牲質量。只有權衡兩者的關係，才能使系統的可實現性達到最佳。

　　總之，實現性是需求工程質量的最重要因素之一，實現可能性極小的需求模型，其它質量因素再好也無用。

　　4.適應性：適應性可以看作需求模型與用戶的獨立性，即當用戶需求發生變化時，需求模型可以不做修改或只進行微小調整。

　　適應性是需求工程質量評價的最關鍵因素之一，但在實際系統開發中往往不被重視。很多需求分析人員就事論事，以完成系統的基本功能為目標，而忽略了其功能擴充或改變的可能性，這將會給系統維護造成困難。適應性評價要分析哪些需求將來可能改變、它們出現的可能性及其對需求模型的影響。由於系統未來可能發生的變化很難預測，所以適應性評價有一定困難。具體評價可採用如下方法:

　　（1）高層管理者評審。因為適應性評價涉及組織發展的戰略目標，一般的業務工作人員無能為力，只有高層決策者才能把握企業未來的發展方向。

　　（2）行業專家評審。這些行業專家應該是業務咨詢或學術專家，他們能更好地把握企業的發展方向，能夠對潛在的市場變化及其可能性作出預測分析。

　　（3）技術專家評審。有經驗的需求分析專家可以基於系統結構對系統的適應性作出評估，雖然他們並不一定熟悉企業的業務，但是可以從需求分析的技術角度評價系統的適應性。

　　5.集成性：在一個大的企業信息系統開發中，通常包括多個應用子系統，這些子系統之間的數據一致性問題顯得格外重要。集成性就是指某個應用子系統與企業信息系統中其它應用系統之間的數據一致性，以減少應用系統之間的數據衝突。由於在某些項目開發中，各應用子系統的需求分析是相對獨立的，這就不可避免地造成數據重覆、系統之間介面複雜等問題。要防止出現類似情況，應儘可能地重覆利用已有的數據資源或者進行適當的擴充，以適應新系統的要求。其次，對數據項的定義要保持命名和格式上的一致。

　　特別強調的是要用全局的觀點看待數據，使需求模型具有通用性。

　　集成性的評價可採用如下幾種方法:

　　（1）通過局部應用與全局應用模型的比較，發現數據衝突和結構衝突。

　　（2）將數據項向已有的數據源做映像，查看是否存在數據共用和重用的可能。

　　（3）讓該應用系統以外的其它業務部門審閱，檢查數據定義是否具有共性。

　　6.一致性：需求規格說明書的一致性要求：系統中不存在顯式的或隱含的矛盾，也就是說，需求規格說明書中各個需求的描述必須不能相互矛盾，矛盾主要為：術語使用方面的衝突，功能衝突，以及時序方面的前後不一致等。一致性的評價可採用如下幾種方法:

　　（1）同一意思要用相同的術語來表達。

　　（2）需求規格說明書中的各個部分的產品功能不得相互矛盾。

　　7.理解性：顧名思義，理解性是指需求模型的結構和描述易於理解。只有通俗易懂，才能更好地同用戶交流。如果用戶很難理解需求分析結果，他們就不可能檢驗需求模型是否完全準確地表達了他們的需求內容。另外，應用開發人員對需求模型的理解也至關重要，因為他們負責系統的設計與實現，不充分理解系統的需求，會使軟體系統的實現結果同用戶要求出現偏差，造成軟體生產率下降。評價理解性常可採用以下方法:

　　（1）用戶審閱。這是最常用的一種方法，檢驗需求模型的可理解性。但這種方法有一個缺點，用戶可能只關心他們所熟悉的業務操作，而沒有充分理解模型所表達的含義。

　　（2）樣例分析。更有效的方法是讓用戶去使用這個模型，分析一個業務樣例，來檢驗他們對模型的理解程度。

　　（3）應用開發人員審閱。雖然系統設計和編程人員不像需求分析人員那樣熟悉用戶的業務要求，但他們能有針對性地找出哪些地方描述得不清楚。同時，這一步也是應用開發人員認識需求模型的過程，有利於他們即將進行的設計工作，保證整個系統開發階段的平穩過渡。