1. 需求管理(Requirements Management，REQM)

Requirements management is the process of documenting，analyzing，tracing，prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders。It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.
需求管理是記錄，分析，跟蹤，確定優先級，就需求達成一致的過程，然后控制變更和與相關的干系人進行溝通的過程。它是一個貫穿整個項目的連續過程。需求是項目(產品或服務)成果應符合一種能力。

“需求”指的是由項目接受的或項目產生的產品和產品構件需求，包括由組織征集的對項目的需求。這種需求既有技術性的，也有非技術性的。

需求工程分為需求獲取、需求分析、需求定義和需求驗證。或：分為5個獨立的階段：需求獲取、需求建模、形成需求規格、需求驗證和需求管理。

需求管理(Requirements Management，REQM)目的：

需求開發的目的是通過調查與分析，獲取用戶需求并定義產品需求。軟件項目需求開發的結果應該有項目視圖和范圍文檔、用例文檔、軟件需求規格說明及相關分析模型，需求基線是團隊成員已經承諾將在某一特定產品版本中實現的功能性和非功能性需求的一組集合，經評審批準，這些文檔就定義了開發工作的需求基線，這個基線在客戶和開發人員之間就構筑了計劃產品功能需求和非功能需求的一個約定。

• 確保各方對需求的一致理解；
• 管理和控制需求的變更；
• 從需求到最終產品的雙向跟蹤，維護需求并且確保能把對需求的更改反映到項目計劃、活動和工作產品中。

2. 需求開發

需求開發分為需求獲取、需求分析、需求定義和需求驗證。

2.1. 需求獲取

積極的與用戶進行交流，捕捉、分析和修正用戶對目標系統的需求，并提煉出符合解決問題的用戶需求，產生《用戶需求說明書》。

collecting requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
收集需求是確定、記錄和管理干系人的需求和要求以滿足項目目標的過程。

2.2. 需求分析

需求分析的目的是對各種需求信息進行分析并抽象描述，為目標系統建立一個概念模型。

2.2.1. 需求分析的方法

需求分析的方法主要有三種：結構化分析方法、面向對象分析方法和面向問題域的分析方法。

2.2.1.1. 結構化分析方法

結構化分析方法的實質是著眼于數據流，自頂向下，逐層分解，建立系統的處理流程，以數據流圖和數據字典為主要工具，建立系統的邏輯模型。所以面向數據流分析方法屬于結構化分析方法的范疇。

2.3. 需求定義

需求定義的目標是根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生《需求規格說明書》。系統設計人員將依據《需求規格說明書》開展系統設計工作。

2.4. 需求驗證

需求驗證是指開發方和用戶共同對需求文檔評審，經雙方對需求達成共識后做出書面承諾，使需求文檔具有商業合同效果。

“需求管理”與“需求開發”密切合作；
“需求開發”涉及到把項目關系人的需要轉換成產品需求和決定如何在各個產品構件之間安排或分配需求。
在“需求管理”中，要收集需求的變更和變更的理由，并且維持對原有需求和所有產品及產品構件需求的雙向跟蹤。在軟件成熟度模型集成(CMMI)中，“需求開發”對應“需求開發”過程域，“需求管理”對應“需求管理”過程域。

3. 需求管理流程

需求管理流程主要包括6大部分：制訂需求管理計劃、求得對需求的理解、求得對需求的承諾、管理需求變更、維護對需求的雙向跟蹤性、識別項目工作與需求之間的不一致性。另外，與此流程相關的還有：關于組織的總體方針和需求管理模板。

3.1. 制訂需求管理計劃

需求管理計劃的主要內容包括確定需求管理軟硬件資源、需求跟蹤性矩陣、需求變更請求表等。由項目經理審批該計劃。制訂需求管理計劃，以便于需求管理人員按計劃地開展需求管理工作，并保持需求管理工作的一致性。

3.2. 求得對需求的理解

設法理解需求提供者提出的這些需求的含義，實際就是我們平常所說的“確認需求”活動。

隨著項目的成熟和各項需求的派生，所有各項活動或工程學科都要接受相應的需求。為了避免這些需求漫無邊際地外延或“遺漏”，要建立一些準則，以便指明接受需求的適當的渠道或正式來源。接受需求的活動應該與需求提供者的需求分析活動一起進行，以確保對需求的含義達成共識。分析和對話的結果是達成一致的需求集合。

3.3. 求得對需求的承諾

這個特定實踐實現從各個項目參加者處求得對需求的承諾。

即使某個實踐以前實現過與需求提供者對需求的共識，但是現在實施這個實踐時，還是要在那些必須進行各項為實現這些需求所需的活動人員之間達成一致和建立承諾。在整個項目推進中，特別是在“需求開發”過程域的各項活動的進程中，需求可能會演變。隨著需求的演變，要求在所有項目干系人之間對己批準的現行需求重新建立承諾，并且對項目計劃、活動和工作產品中的后續變更做出承諾。

3.4. 管理需求變更

這個特定實踐實現各項需求在項目推進期間發生演變的同時，對需求的變更進行管理。

在項目推進期間，需求會由于各種各樣原因而發生變更。隨著原來的需要發生變化和工作的推進，將會產生一些附加的需求，因此必然要對現行的需求做出相應的變更。有效地管理這些需求和需求變更相當重要。有必要了解每個需求的來源，并且做出變更理由的文件。項目經理可能希望跟蹤相應的需求變化度量數據，以便判斷是否需要采取新的控制措施或對已有的控制做出調整。

3.5. 維護對需求的雙向跟蹤性

這個特定實踐維護在需求與項目計劃和工作產品之間的雙向跟蹤性。

這個特定實踐的目的在于維護對每個產品分解層的雙向跟蹤性。如果需求管理得好，就可以建立起從來源需求到它的較低層次需求的跟蹤性，和從較低層次的需求到它們的來源需求的跟蹤性。這種雙向跟蹤性有助于確定是否所有來源需求都完全得到處理，是否所有的低層需求都可以跟蹤到有效的來源。需求的跟蹤性還可以覆蓋與其他實體的關系，例如與產品、設計文檔的變更、測試計劃、驗證、確認以及工作任務等的關系。跟蹤性應該覆蓋橫向和縱向(例如接口兩邊)的關系。在評估需求變更對項目計劃、活動，以及工作產品的影響時，尤其需要跟蹤性。

3.6. 識別項目工作與需求之間的不一致

這個特定實踐識別項目計劃和工作產品與需求之間的不一致之處。

雖然通過這項活動產生的一些工作產品將成為經過更新的項目計劃、活動和工作產品，但是，這些工作產品屬于“項目策劃”過程的產品，而不是“需求管理”的。這個特定實踐旨在發現需求與項目計劃和工作產品之間的不一致，并且啟動糾正措施。

關于需求管理的描述，正確的是()。
A.需求管理包括在產品生存周期中維持需求一致性和精確性的所有活動
B.從測試用例和測試報告可得描述中追蹤到用戶原始需求的過程是正向追蹤
C.需求文件之間的跟蹤用于檢查需求分解中可能出現的錯誤或遺漏
D.需求跟蹤矩陣中可以不體現測試策略和測試場景的跟蹤結果

需求管理包括在產品開發過程中維持需求一致性和精確性的所有活動；
從測試用例和測試報告可得描述中追蹤到用戶原始需求的過程是反向追蹤；
需求跟蹤矩陣中可以體現測試策略和測試場景的跟蹤結果。

轉載/整理：
希賽教育的試題解釋：https://www.educity.cn/

總結

以上是生活随笔為你收集整理的笔记-项目范围管理-需求工程-需求管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。