需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行爲特徵和相關約束，形成需求文檔，並對用戶不斷變化的需求演進給予支持。
軟件需求是指用戶對目標軟件系統在功能、行爲、性能、設計約束等方面的期望。通過對應問題及其環境的理解與分析，爲問題涉及的信息、功能及系統行爲建立模型，將用戶需求精確化、完全化，最終形成需求規格說明，這一系列的活動即構成軟件開發生命週期的需求分析階段。
需求分析是介於系統分析和軟件設計階段之間的橋樑。一方面，需求分析以系統規格說明和項目規劃作爲分析活動的基本出發點，並從軟件角度對它們進行檢查與調整；另一方面，需求規格說明又是軟件設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或儘早剔除早期錯誤，從而提高軟件生產率，降低開發成本，改進軟件質量。
需求工程是隨着計算機的發展而發展的，在計算機發展的初期，軟件規模不大，軟件開發所關注的是代碼編寫，需求分析很少受到重視。後來軟件開發引入了生命週期的概念，需求分析成爲其第一階段。隨着軟件系統規模的擴大，需求分析與定義在整個軟件開發與維護過程中越來越重要，直接關係到軟件的成功與否。人們逐漸認識到需求分析活動不再僅限於軟件開發的最初階段，它貫穿於系統開發的整個生命週期。80年代中期，形成了軟件工程的子領域——需求工程(requirementengineering,RE)。進入90年代以來，需求工程成爲研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《RequirementsEngineering》。一些關於需求工程的工作小組也相繼成立，如歐洲的RENOIR(RequirementsEngineeringNetworkofInternationalCOOPeratingRESearchGroups)，並開始開展工作。
需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行爲特徵和相關約束，形成需求文檔，並對用戶不斷變化的需求演進給予支持。RE可分爲系統需求工程（如果是針對由軟硬件共同組成的整個系統）和軟件需求工程（如果僅是專門針對純軟件部分）。軟件需求工程是一門分析並記錄軟件需求的學科，它把系統需求分解成一些主要的子系統和任務，把這些子系統或任務分配給軟件，並通過一系列重複的分析、設計、比較研究、原型開發過程把這些系統需求轉換成軟件的需求描述和一些性能參數。
需求工程是一個不斷反覆的需求定義、文檔記錄、需求演進的過程，並最終在驗證的基礎上凍結需求。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等。其主要原理包括分類繼承層次、信息隱藏、彙集關係等。形式化方法從廣義上說，是應用離散數學的手段來設計、模擬和分析，得到像數學公式那樣精確的表示。從狹義上說，就是使用一種形式語言進行語言公式的形式推理，用於檢查語法的良構性並證明某些屬性。形式化方法一般用於一致性檢查、類型檢查、有效性驗證、行爲預測以及設計求精驗證。引入形式化機制的目的是：
●減少二義性，提高精確性；
●爲驗證打下基礎；
●允許對需求進行推理；
●允許執行需求。
但是人們常常不用形式化手段，因爲：
●形式化涉及太多細節，分析的級別較低；
●形式化的核心問題是一致性和完整性，而不是獲取需求；
●沒有合適的工具；
●要求更多的代價。
傳遞需求的主要任務是書寫軟件需求規格說明，其目的是：
●傳達對需求的理解；
●作爲軟件開發項目的一份契約；
●作爲評價後續工作的基線；
●作爲控制需求進化的基線。
對需求規格說明感興趣的羣體包括：用戶、客戶；系統分析員、需求分析員；軟件開發者、程序員；測試員；項目管理者。
認可需求就是讓上述人員對需求規格說明達成一致，其主要任務是衝突求解，包括定義衝突和衝突求解兩方面。常用的衝突求解方法有：協商、競爭、仲裁、強制、教育等，其中有些只能用人的因素去控制。
進化需求的必要性是明顯的，因爲客戶的需要總是不斷（連續）增長的，但是一般的軟件開發又總是落後於客戶需求的增長，如何管理需求的進化（變化）就成爲軟件進化的首要問題。對傳統的變化管理過程來說，其基本成分包括軟件配置、軟件基線和變化審查小組。當前的發展是軟件家族法，即產品線方法。多視點方法也是管理需求變化的一種新方法，它可以用於管理不一致性並進行關於變化的推理。
二、需求工程推薦方法
需求工程包括需求開發和管理，而需求開發又包括這幾個過程：需求獲取，需求分析，需求規格說明和需求驗證。在需求開發之前，還需要有一個知識培訓的過程，需求工程也是一個項目工程，因此也包括了項目的管理。對於這些過程，有以下方法可以採用。
·知識培訓
需求分析員培訓：需求分析員應該具有良好的交流溝通能力，同時理解產品，並掌握了需求工程的技能。
用戶培訓：用戶也應該接受需求工程知識的培訓，讓他們理解需求的重要性，知道如何準確的描述需求，需求的風險性等。
開發人員培訓：開發人員應該對用戶的應用領域有一個基礎的瞭解，明白客戶的業務活動，術語，產品目標等
·需求獲取
需求包括業務需求，用戶需求和功能需求以及非功能需求，在需求開發之前，我們需要先定義好需求開發的過程，形成文檔，內容包括：需求開發的步驟，每一個步驟如何實現，如何處理意外情況，如何規劃開發資源等
需求獲取包括以下方法和技能：
項目範圍確定：開需求開發前期，我們應該獲取用戶的業務需求，定義好項目的範圍，使得所有的涉衆對項目有一個共同的理解。
用戶確定：確定用戶羣和分類，對用戶組進行詳細描述，包括使用產品頻率，所使用的功能，優先級別，熟練程度等等。對每一個用戶組確定用戶的代言人。對於大型項目，我們需要先確定中心客戶組，中心客戶組的需求具有高級別的優先級，需要先實現的核心功能。
用例確定：與用戶代表溝通，瞭解他們需要完成的任務，得到用例模型。同時根據用例導出功能需求。用例描述應該採用標準模板。
系統事件和響應：業務事件可能觸發用例，系統事件包括系統內部的事件以及從外部接受到信息，數據等等，或者一個突發的任務。
獲取方法：召開需求討論會議，觀察用戶的工作過程，採用問答式對話，採用誘發式需求誘導等等。檢查完善：問題報告和補充需求建議
·需求分析
需求分析是對用戶的需求獲取之後的一個粗加工過程，需要對需求進行推敲和潤色以使所有涉衆都能準確理解需求。分析過程首先需要對需求進行檢查，以保證需求的正確性和完備性，然後將高層需求分解成具體的細節，創建開發原型，完成需求從需求獲取人員到開發人員的過渡。
繪製關聯圖：關聯圖確定系統和外部的交互。劃分了系統的範圍和界限，構建了系統對外的接口。
原型開發：對於敏捷方法，推薦完成一個界面的原型，一個初步的系統實現，通過原型，讓所有涉衆對開發的項目有了一個初步的映像，同時可以提供對需求的檢驗。
需求優先級別：採用分析的方法確定產品的功能，用例和單項需求的優先級別，以優先級爲基礎，確定各項功能和需求都包括在哪個版本中，在項目開發過程中，需求的優先級別根據實際情況進行調整。
需求建模：圖形分析模型對需求描述更加抽象。主要可以採用UML的建模分析。
數據字典創建：建立系統中所用到的數據項和結構的定義，數據字典可以使參與項目開發的每一個人都使用統一的定義。
子系統：建立系統的結構，同時將需求分配到各個子系統和模塊中。
·規格說明
SRS應該是一個作爲涉衆對系統的統一理解。
採用SRS模板：定義一種標準模板