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