第8章需求管理 2
8.1 介紹 2
8.2 需求確認 3
8.2.1 目的 3
8.2.2 角色與職責 3
8.2.3 啟動準則 3
8.2.4 輸入 3
8.2.5 主要步驟 4
[step1] 非正式需求評審 4
[step2] 正式需求評審 4
[step3] 獲取需求承諾 4
8.2.6 輸出 4
8.2.7 結束準則 4
8.2.8 度量 4
8.3 需求跟蹤 5
8.3.1 目的 5
3.3.2 角色與職責 5
3.3.3 啟動準則 5
3.3.4 輸入 5
3.3.5 主要步驟 5
[step1] 建立與維護需求跟蹤矩陣 5
[step2] 查詢不一致 6
[step3] 消除不一致 6
8.3.6 輸出 6
8.3.7 結束準則 6
8.3.8 度量 6
8.4 需求變更控制 7
8.4.1 目的 7
8.4.2 角色與職責 7
8.4.3 啟動準則 7
8.4.4 輸入 7
8.4.5 主要步驟 7
[step1] 需求變更申請 7
[step2] 審批需求變更申請 7
[step3] 更改需求文件 7
[step4] 重新進行需求確認 8
8.4.6 輸出 8
8.4.7 結束準則 8
8.4.8 度量 8
8.5 實施建議 8
需求管理（requirement management, rm）的目的在客戶與開發方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，並控制需求的變更。
需求管理過程域是spp模型的重要組成部分。本規範闡述了需求管理過程域的三個主要規程：
需求確認 [spp-proc-rm-validate]
需求跟蹤 [spp-proc-rm-tracking]
需求變更控制 [spp-proc-rm-change]
上述每個規程的「目標」、「角色與職責」、「啟動準則」、「輸入」、「主要步驟」、「輸出」、「完成準則」和「度量」均已定義。
本規範適用於國內it企業的軟體研發專案。建議使用者根據自身情況（如商業目標、研發實力等）適當地修改本規範，然後推廣使用。
我們把所有與需求相關的活動通稱為需求工程。需求工程中的活動可分為兩大類，一類屬於需求開發，另一類屬於需求管理。圖8-1為需求工程的結構圖（流程見圖9-1）。
圖8-1 需求工程結構圖
需求管理過程域主要有3個規程：需求確認、需求跟蹤與需求變更控制。
一、需求確認
需求確認是指開發方和客戶共同對需求文件進行評審，雙方對需求達成共識後作出書面承諾，使需求文件具有商業合同效果。
二、需求跟蹤
需求跟蹤是指通過比較需求文件與後續工作成果之間的對應關係，建立與維護「需求跟蹤矩陣」，確保產品依據需求文件進行開發。
三、需求變更控制
需求變更控制是指依據「變更申請－審批－更改－重新確認」的流程處理需求的變更，確保需求的變更不會失去控制而導致專案發生混亂。
需求管理過程域產生的主要文件有：
《需求評審報告》，同技術評審報告的模板 [spp-temp-tr-report]。
《需求跟蹤報告》，模板見 [spp-temp-rm-tracking]。
《需求變更控制報告》，模板見 [spp-temp-rm-change]。
● 開發方和客戶對需求文件如《使用者需求說明書》和《產品需求規格說明書》進行評審，並作書面承諾。
補充說明：《使用者需求說明書》和《產品需求規格說明書》可以分開也可以放在一起進行需求確認，視專案的具體情況而定。
● 開發方和客戶共同組織人員對需求文件如《使用者需求說明書》和《產品需求規格說明書》進行評審。
● 開發方負責人（專案經理）和客戶對需求文件作書面承諾，使之具有商業合同效果。
● 需求文件如《使用者需求說明書》和《產品需求規格說明書》已經完成。
● 需求文件如《使用者需求說明書》和《產品需求規格說明書》。
● 專案經理先在專案內部組織人員進行非正式的需求評審，以消除明顯的錯誤和分歧。非正式的需求評審方式請參考技術評審過程域的對應規程[spp-proc-tr-itr]。
● 專案經理邀請同行專家和使用者（包括客戶和終端使用者）一起評審需求文件，盡最大努力使需求文件能夠正確無誤地反映使用者的真實意願。正式需求評審方式請參考技術評審過程域的對應規程[spp-proc-tr-ftr]。
當需求文件通過正式的評審之後，開發方負責人（專案經理）和客戶對需求文件作書面承諾，使之具有商業合同效果。示例如下：
本需求文件建立在雙方對需求的共同理解基礎之上，我同意後續的開發工作根據該需求文件開展。如果需求發生變化，我們將按照「需求變更控制規程」執行。我明白需求的變更將導致雙方重新協商成本、資源和進度等。
甲方負責人簽字
乙方負責人簽字
● 《需求評審報告》
● 書面的需求承諾
● 需求文件通過了正式評審，並且獲得開發方和客戶的書面承諾。
● 專案經理統計工作量和上述文件的規模
● 將系統設計、程式設計、測試等階段的工作成果與需求文件進行比較，建立與維護「需求文件－設計文件－**－測試用例」之間的一致性，確保產品依據需求文件進行開發。
● 專案經理跟蹤需求。
● 需求文件已經通過正式評審並獲得了承諾。
● 系統設計、程式設計、測試等階段的工作成果如設計文件、**、測試用例已經產生。
● 需求文件
● 設計文件、**、測試用例等
● 正向跟蹤。檢查需求文件中的每個需求是否都能在後續工作成果中找到對應點。
● 逆向跟蹤。檢查設計文件、**、測試用例等工作成果是否都能在需求文件中找到出處。
● 正向跟蹤和逆向跟蹤合稱為「雙向跟蹤」。不論採用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即**）。需求跟蹤矩陣儲存了需求與後續工作成果的對應關係。
矩陣單元之間的可能存在「一對一」、「一對多」或「多對多」的關係。由於對應關係比較複雜，最好在**中加必要的文字解釋。表8-1為簡單的需求跟蹤矩陣格式。
● 當需求文件或後續工作成果發生變更時，要及時更新需求跟蹤矩陣。
表8-1 簡單的需求跟蹤矩陣格式
● 使用需求跟蹤矩陣的優點是很容易發現需求文件與後續工作成果之間的不一致之處，例如：
後續工作成果沒有實現需求文件中的某些需求；
後續工作成果實現了需求文件中的不存在的需求；
後續工作成果沒有正確實現需求文件中的的需求；
● 專案經理將發現的「不一致性」記錄在《需求跟蹤報告》之中，並通報給相關責任人（工作成果的開發者）。
● 相關責任人給出消除「不一致」的措施和計畫，專案經理將該措施和計畫記錄到《需求跟蹤報告》之中。
● 相關責任人消除「不一致性」之後，專案經理更新「需求跟蹤矩陣」。
● 《需求跟蹤報告》
● 每個開發階段的「需求跟蹤矩陣」都已經建立。
● 已經消除了需求文件與後續工作成果之間的不一致性。
● 專案經理統計工作量和上述文件的規模。
● 修改「原需求文件」中不正確的內容，產生新的需求文件。
● 控制需求文件的變更，防止發生混亂。
補充說明：本規程中的「原需求文件」是指已經通過了評審並獲得書面承諾的需求文件。
第8章需求管理
第8章需求管理 2 8.1 介紹 2 8.2 需求確認 3 8.2.1 目的 3 8.2.2 角色與職責 3 8.2.3 啟動準則 3 8.2.4 輸入 3 8.2.5 主要步驟 4 step1 非正式需求評審 4 step2 正式需求評審 4 step3 獲取需求承諾 4 8.2.6 輸出 4 8...
第4章需求開發與需求管理
目錄第4章需求開發與需求管理 3 4.1 什麼是需求 4 4.1.1 基本概念 4 4.1.2 需求案例 4 4.2 了解使用者 6 4.3 需求工程 7 4.3.1 基本概念 7 4.3.2 一些感悟 8 4.4 需求開發的主要困難與對策 9 4.4.1 知識技能問題 9 4.4.2 態度問題 1...
第8章專案進度管理
8.1專案進度管理概述 1 何謂專案管理 每乙個專案都有乙個進度要求，專案進度管理就是保證專案的所有工作都在乙個指定的時間內完成。2 專案進度管理涉及的主要過程 專案進度管理包括6個管理過程，其體內容如下。l 活動定義 確認一些特定的工作，通過完成這些活動就完成了工程專案的各專案細目。2 活動排序 ...