需求工程（RE）是在工程設計過程中定義、記錄和維護需求的過程。它在系統工程和軟件工程中很常見。

需求工程一詞的首次使用可能是在1964年的會議論文“維護，可維護性和系統需求工程”中，但直到1990年代末IEEE計算機協會出版后才開始使用。教程于1997年3月發布，并且建立了有關需求工程的會議系列，該系列會議已發展成為國際需求工程會議。

在瀑布模型中，需求工程是開發過程的xxx階段。后來的開發方法，包括用于軟件的Rational Unified Process（RUP），都假定需求工程將在系統的整個生命周期中持續進行。

需求管理是系統工程實踐的一個子功能，在國際系統工程理事會（INCOSE）手冊中也有索引。

需求工程中涉及的活動差異很大，這取決于所開發系統的類型和所涉及組織的特定實踐。這些可能包括：

1. 需求啟動或需求啟發–開發人員和利益相關者見面，詢問他們關于軟件產品的需求。
2. 需求分析和協商–確定需求（如果開發是迭代的，則包括新需求），并解決與利益相關者的沖突。書面工具和圖形工具（后者通常在設計階段都可以使用，但有些人在現階段也發現它們很有用）已成功地用作輔助工具。書面分析工具的示例：用例和用戶案例。圖形工具的示例：UML和LML。
3. 系統建模?–一些工程領域（或特定情況）要求在產品開始建造或制造之前對產品進行完整的設計和建模，因此必須提前執行設計階段。例如，在批準和簽署任何合同之前，必須詳細說明建筑物的藍圖。許多領域可能會使用生命周期建模語言來派生系統模型，而其他領域可能會使用UML。注意：在許多領域，例如軟件工程，大多數建模活動都被歸類為設計活動，而不是需求工程活動。
4. 需求規格說明–需求記錄在稱為需求規格說明（RS）的正式工件中，該工件僅在經過驗證后才成為正式文件。如果需要，RS可以包含書面和圖形（模型）信息。示例：軟件需求規范（SRS）。
5. 需求驗證–檢查記錄的需求和模型是否一致并滿足涉眾的需求。只有最終草案通過了驗證過程，RS才能成為正式文件。
6. 需求管理 –管理自需求開始以來與需求相關的所有活動，在系統開發過程中進行監督，甚至直到使用后（例如更改、擴展等）

這些有時被表示為按時間順序排列的階段，盡管在實踐中，這些活動之間存在相當大的交錯。

事實證明，需求工程顯然有助于軟件項目的成功。

在德國進行的一項有限研究提出了實施需求工程中可能存在的問題，并詢問受訪者是否同意這是實際問題。結果并未呈現為可推廣的結果，但表明主要的感知問題是需求不完整，目標移動和時間限制，較少的問題是溝通缺陷，缺乏可追溯性，術語問題和職責不明確。