第8章 需求管理1
第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 第8章 需求管理 需求管理（Requirement Management, RM）的目的在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其他工作成果的一 致性，并控制需求的變更。 需求管理過程域是SPP模型的重要組成部分。本規(guī)范闡述了需求管理過程域的三個主 要規(guī)程： ← 需求確認 [SPP-PROC-RM-VALIDATE] ← 需求跟蹤 [SPP-PROC-RM-TRACKING] ← 需求變更控制 [SPP-PROC-RM-CHANGE] 上述每個規(guī)程的“目標”、“角色與職責”、“啟動準則”、“輸入”、“主要步驟”、“輸出 ”、“完成準則”和“度量”均已定義。 本規(guī)范適用于國內IT企業(yè)的軟件研發(fā)項目。建議用戶根據(jù)自身情況（如商業(yè)目標、研 發(fā)實力等）適當?shù)匦薷谋疽?guī)范，然后推廣使用。 8.1 介紹 我們把所有與需求相關的活動通稱為需求工程。需求工程中的活動可分為兩大類，一 類屬于需求開發(fā)，另一類屬于需求管理。圖8-1為需求工程的結構圖（流程見圖9- 1）。 圖8-1 需求工程結構圖 需求管理過程域主要有3個規(guī)程：需求確認、需求跟蹤與需求變更控制。 一、需求確認 需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書 面承諾，使需求文檔具有商業(yè)合同效果。 二、需求跟蹤 需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應關系，建立與維護“需求 跟蹤矩陣”，確保產品依據(jù)需求文檔進行開發(fā)。 三、需求變更控制 需求變更控制是指依據(jù)“變更申請－審批－更改－重新確認”的流程處理需求的變更， 確保需求的變更不會失去控制而導致項目發(fā)生混亂。 需求管理過程域產生的主要文檔有： ← 《需求評審報告》，同技術評審報告的模板 [SPP-TEMP-TR-REPORT]。 ← 《需求跟蹤報告》，模板見 [SPP-TEMP-RM-TRACKING]。 ← 《需求變更控制報告》，模板見 [SPP-TEMP-RM-CHANGE]。 8.2 需求確認 8.2.1 目的 o 開發(fā)方和客戶對需求文檔如《用戶需求說明書》和《產品需求規(guī)格說明書》進行評審，并作 書面承諾。 補充說明：《用戶需求說明書》和《產品需求規(guī)格說明書》可以分開也可以放在一起進行需 求確認，視項目的具體情況而定。 8.2.2 角色與職責 o 開發(fā)方和客戶共同組織人員對需求文檔如《用戶需求說明書》和《產品需求規(guī)格說明書》 進行評審。 o 開發(fā)方負責人（項目經理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。 8.2.3 啟動準則 o 需求文檔如《用戶需求說明書》和《產品需求規(guī)格說明書》已經完成。 8.2.4 輸入 o 需求文檔如《用戶需求說明書》和《產品需求規(guī)格說明書》。 8.2.5 主要步驟 [Step1] 非正式需求評審 o 項目經理先在項目內部組織人員進行非正式的需求評審，以消除明顯的錯誤和分歧。非 正式的需求評審方式請參考技術評審過程域的對應規(guī)程[SPP-PROC-TR-ITR]。 [Step2] 正式需求評審 o 項目經理邀請同行專家和用戶（包括客戶和最終用戶）一起評審需求文檔，盡最大努力 使需求文檔能夠正確無誤地反映用戶的真實意愿。正式需求評審方式請參考技術評審 過程域的對應規(guī)程[SPP-PROC-TR-FTR]。 [Step3] 獲取需求承諾 當需求文檔通過正式的評審之后，開發(fā)方負責人（項目經理）和客戶對需求文檔作書面 承諾，使之具有商業(yè)合同效果。示例如下： 本需求文檔建立在雙方對需求的共同理解基礎之上，我同意后續(xù)的開發(fā)工作根據(jù)該需求 文檔開展。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。我明白需求的變 更將導致雙方重新協(xié)商成本、資源和進度等。 甲方負責人簽字 乙方負責人簽字 8.2.6 輸出 o 《需求評審報告》 o 書面的需求承諾 8.2.7 結束準則 o 需求文檔通過了正式評審，并且獲得開發(fā)方和客戶的書面承諾。 8.2.8 度量 o 項目經理統(tǒng)計工作量和上述文檔的規(guī)模 8.3 需求跟蹤 8.3.1 目的 o 將系統(tǒng)設計、編程、測試等階段的工作成果與需求文檔進行比較，建立與維護“需求文 檔－設計文檔－代碼－測試用例”之間的一致性，確保產品依據(jù)需求文檔進行開發(fā)。 3.3.2 角色與職責 o 項目經理跟蹤需求。 3.3.3 啟動準則 o 需求文檔已經通過正式評審并獲得了承諾。 o 系統(tǒng)設計、編程、測試等階段的工作成果如設計文檔、代碼、測試用例已經產生。 3.3.4 輸入 o 需求文檔 o 設計文檔、代碼、測試用例等 3.3.5 主要步驟 [Step1] 建立與維護需求跟蹤矩陣 o 正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應點。 o 逆向跟蹤。檢查設計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處 。 o 正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求 跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應關系。矩陣單 元之間的可能存在“一對一”、“一對多”或“多對多”的關系。由于對應關系比較復雜， 最好在表格中加必要的文字解釋。表8-1為簡單的需求跟蹤矩陣格式。 o 當需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。 |＃|需求文檔 |設計文檔 |代碼 |測試用例 | | |（版本，日期） |（版本，日期） |（版本，日期）|（版本，日期） | |1 |標題或標識符，說|標題或標識符， |代碼名稱，說明|測試用例名稱，說| | |明 |說明 | |明 | |2 |… |… |… |… | | | | | | | 表8-1 簡單的需求跟蹤矩陣格式 [Step2] 查找不一致 o 使用需求跟蹤矩陣的優(yōu)點是很容易發(fā)現(xiàn)需求文檔與后續(xù)工作成果之間的不一致之處，例 如： ← 后續(xù)工作成果沒有實現(xiàn)需求文檔中的某些需求； ← 后續(xù)工作成果實現(xiàn)了需求文檔中的不存在的需求； ← 后續(xù)工作成果沒有正確實現(xiàn)需求文檔中的的需求； o 項目經理將發(fā)現(xiàn)的“不一致性”記錄在《需求跟蹤報告》之中，并通報給相關責任人（工作 成果的開發(fā)者）。 [Step3] 消除不一致 o 相關責任人給出消除“不一致”的措施和計劃，項目經理將該措施和計劃記錄到《需求跟 蹤報告》之中。 o 相關責任人消除“不一致性”之后，項目經理更新“需求跟蹤矩陣”。 8.3.6 輸出 o 《需求跟蹤報告》 8.3.7 結束準則 o 每個開發(fā)階段的“需求跟蹤矩陣”都已經建立。 o 已經消除了需求文檔與后續(xù)工作成果之間的不一致性。 8.3.8 度量 o 項目經理統(tǒng)計工作量和上述文檔的規(guī)模。 8.4 需求變更控制 8.4.1 目的 o 修改“原需求文檔”中不正確的內容，產生新的需求文檔。 o 控制需求文檔的變更，防止發(fā)生混亂。 補充說明：本規(guī)程中的“原需求文檔”是指已經通過了評審并獲得書面承諾的需求文檔。 8.4.2 角色與職責 o 開發(fā)方負責人（項目經理）和客戶共同控制需求變更。 8.4.3 啟動準則 o 某人（來自開發(fā)方或客戶方）提出變更“原需求文檔”的申請。 8.4.4 輸入 o “原需求文檔” 8.4.5 主要步驟 [Step1] 需求變更申請 o 需求變更申請人撰寫“需求變更申請書”，遞交給項目經理或客戶方負責人。 o “需求變更申請書”必須闡述：（1）變更原因；（2）變更的內容；（3）此變更對項目 造成的影響。 [Step2] 審批需求變更申請 開發(fā)方負責人（項目經理）和客戶共同審批“需求變更申請書”： o 如果任何一方不同意變更，則退回變更請求，項目按照“原需求文檔”執(zhí)行。 o 如果雙方都同意變更，轉向 [Step3]。 [Step3] 更改需求文檔 o 需求分析員根據(jù) [Step1] 和 [Step2] 更改“原需求文檔”，產生新的需求文檔。 [Step4] 重新進行需求確認 o 重新進行需求評審，參見需求確認規(guī)程中的 [Step2]。 o 重新獲取書面的需求承諾，參見需求確認規(guī)程中的 [Step3]。 8.4.6 輸出 o 《需求變更控制報告》 8.4.7 結束準則 o 新的需求文檔已經被確認。 8.4.8 度量 o 項目經理統(tǒng)計工作量。 8.5 實施建議 o 先對項目經理和客戶進行培訓，讓他們掌握必要的需求管理知識。 o 對需求管理過程域產生的所有有價值的文檔進行配置管理。 o 對于非合同項目，本規(guī)范中有關客戶的活動可以被裁減掉。 ----------------------- 需求跟蹤 需求變更控制 需求工程 需求開發(fā) 需求調查 需求定義 需求分析 需求管理 需求確認
第8章 需求管理1