CMMI需求管理說明及相關(guān)文檔模板

1、0 數(shù)據(jù)庫變更管理數(shù)據(jù)庫變更管理.1 目的.1 角色與職責(zé).1 啟動準則.1 輸入.1 主要步驟.1 step1 數(shù)據(jù)庫設(shè)計變更申請.1 step2 審批數(shù)據(jù)庫設(shè)計變更申請.1 step3 更改數(shù)據(jù)庫設(shè)計文檔.2 step4 重新進行數(shù)據(jù)庫設(shè)計確認.2 輸出.2 結(jié)束準則.2 度量.2 1 數(shù)據(jù)庫變更管理數(shù)據(jù)庫變更管理 目的目的 鐵路客票安全系統(tǒng)的數(shù)據(jù)庫由設(shè)計部委派專人負責(zé)管理，以防止出現(xiàn)混亂。 修改“原數(shù)據(jù)庫設(shè)計文檔”中不正確的內(nèi)容，產(chǎn)生新的數(shù)據(jù)庫文檔。 控制數(shù)據(jù)庫文檔和腳本的變更，防止發(fā)生混亂。 補充說明：本規(guī)程中的“原數(shù)據(jù)庫設(shè)計文檔”是指已經(jīng)通過了評審并獲得書面承諾的數(shù)據(jù)庫 設(shè)計文檔。

2、角色與職責(zé)角色與職責(zé) 設(shè)計部委派專人負責(zé)管理數(shù)據(jù)庫，目前數(shù)據(jù)庫管理項目的負責(zé)人為王雪暉 啟動準則啟動準則 某人（來自項目開發(fā)組或客戶方）提出變更“原數(shù)據(jù)庫設(shè)計”的申請。 輸入輸入 “原數(shù)據(jù)庫設(shè)計文檔” 主要步驟主要步驟 step1 數(shù)據(jù)庫設(shè)計變更申請數(shù)據(jù)庫設(shè)計變更申請 數(shù)據(jù)庫設(shè)計變更申請人撰寫“數(shù)據(jù)庫設(shè)計申請書” ，遞交給項目經(jīng)理或客戶方負責(zé)人。 “數(shù)據(jù)庫設(shè)計申請書”必須闡述：（1）變更原因；（2）變更的內(nèi)容；（3）此變更對 項目造成的影響。 step2 審批數(shù)據(jù)庫設(shè)計變更申請審批數(shù)據(jù)庫設(shè)計變更申請 設(shè)計部、變更提出者的開發(fā)方負責(zé)人（項目經(jīng)理）和數(shù)據(jù)庫管理項目負責(zé)人共同審批 “數(shù)據(jù)庫設(shè)計變更申

3、請書”： 如果任何一方不同意變更，則退回變更請求，項目按照“原數(shù)據(jù)庫設(shè)計文檔”執(zhí)行。 如果雙方都同意變更，轉(zhuǎn)向 step3。 2 step3 更改數(shù)據(jù)庫設(shè)計文檔更改數(shù)據(jù)庫設(shè)計文檔 數(shù)據(jù)庫管理員根據(jù) step1 和和 step2 更改“原數(shù)據(jù)庫設(shè)計文檔”和 sql 腳本，產(chǎn)生 新的數(shù)據(jù)庫設(shè)計文檔和 sql 腳本。 step4 重新進行數(shù)據(jù)庫設(shè)計確認重新進行數(shù)據(jù)庫設(shè)計確認 重新進行數(shù)據(jù)庫設(shè)計評審，參見數(shù)據(jù)庫設(shè)計確認規(guī)程中的 step2。 重新獲取書面的數(shù)據(jù)庫設(shè)計承諾，參見需求確認規(guī)程中的 step3。 輸出輸出 數(shù)據(jù)庫設(shè)計變更控制報告 新的數(shù)據(jù)庫設(shè)計文檔 新的 sql 腳本 結(jié)束準則結(jié)束準則 新的

4、數(shù)據(jù)庫設(shè)計文檔已經(jīng)被確認。 度量度量 數(shù)據(jù)庫管理項目經(jīng)理統(tǒng)計工作量。 3 第第 8 章章 需求管理需求管理.2 8.1 介紹介紹.2 8.2 需求確認需求確認.3 8.2.1 目的.3 8.2.2 角色與職責(zé).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 結(jié)束準則.4 8.2.8 度量.4 8.3 需求跟蹤需求跟蹤.5 8.3.1 目的.5 3.3.2 角色與職責(zé).5 3.3.3 啟動準則.5 3.3.4 輸入.5 3.3.5 主要步驟.

5、5 step1 建立與維護需求跟蹤矩陣.5 step2 查找不一致.6 step3 消除不一致.6 8.3.6 輸出.6 8.3.7 結(jié)束準則.6 8.3.8 度量.6 8.4 需求變更控制需求變更控制.7 8.4.1 目的.7 8.4.2 角色與職責(zé).7 8.4.3 啟動準則.7 8.4.4 輸入.7 8.4.5 主要步驟.7 step1 需求變更申請.7 step2 審批需求變更申請.7 step3 更改需求文檔.7 step4 重新進行需求確認.8 4 8.4.6 輸出.8 8.4.7 結(jié)束準則.8 8.4.8 度量.8 8.5 實施建議實施建議.8 5 第第 8 章章 需求管理需求管理

6、 需求管理（requirement management, rm）的目的在客戶與開發(fā)方之間建立對需求的共 同理解，維護需求與其他工作成果的一致性，并控制需求的變更。 需求管理過程域是 spp 模型的重要組成部分。本規(guī)范闡述了需求管理過程域的三個主要 規(guī)程： 需求確認 spp-proc-rm-validate 需求跟蹤 spp-proc-rm-tracking 需求變更控制 spp-proc-rm-change 上述每個規(guī)程的“目標(biāo)” 、 “角色與職責(zé)” 、 “啟動準則” 、 “輸入” 、 “主要步驟” 、 “輸出” 、 “完成準則”和“度量”均已定義。 本規(guī)范適用于國內(nèi) it 企業(yè)的軟件研發(fā)項

7、目。建議用戶根據(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ī)程：需求確認、需求跟蹤與需求變更控制。 一、需求確認一、需求確認 需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面 承諾，使需求文檔具有商業(yè)合同效果。 二、需求跟蹤二、需求跟蹤 需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與

8、維護“需求跟 需求工程 需求開發(fā) 需求變更控制 需求管理 需求確認 需求跟蹤 需求調(diào)查 需求分析 需求定義 6 蹤矩陣” ，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。 三、需求變更控制三、需求變更控制 需求變更控制是指依據(jù)“變更申請審批更改重新確認”的流程處理需求的變更， 確保需求的變更不會失去控制而導(dǎo)致項目發(fā)生混亂。 需求管理過程域產(chǎn)生的主要文檔有： 需求評審報告 ，同技術(shù)評審報告的模板 spp-temp-tr-report。 需求跟蹤報告 ，模板見 spp-temp-rm-tracking。 需求變更控制報告 ，模板見 spp-temp-rm-change。 8.2 需求確認需求確認 8.2.1 目的

9、目的 開發(fā)方和客戶對需求文檔如用戶需求說明書和產(chǎn)品需求規(guī)格說明書進行評審， 并作書面承諾。 補充說明：用戶需求說明書和產(chǎn)品需求規(guī)格說明書可以分開也可以放在一起進行需 求確認，視項目的具體情況而定。 8.2.2 角色與職責(zé)角色與職責(zé) 開發(fā)方和客戶共同組織人員對需求文檔如用戶需求說明書和產(chǎn)品需求規(guī)格說明書 進行評審。 開發(fā)方負責(zé)人（項目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。 8.2.3 啟動準則啟動準則 需求文檔如用戶需求說明書和產(chǎn)品需求規(guī)格說明書已經(jīng)完成。 8.2.4 輸入輸入 需求文檔如用戶需求說明書和產(chǎn)品需求規(guī)格說明書 。 7 8.2.5 主要步驟主要步驟 step1 非正

10、式需求評審非正式需求評審 項目經(jīng)理先在項目內(nèi)部組織人員進行非正式的需求評審，以消除明顯的錯誤和分歧。非 正式的需求評審方式請參考技術(shù)評審過程域的對應(yīng)規(guī)程spp-proc-tr-itr。 step2 正式需求評審正式需求評審 項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審需求文檔，盡最大努力盡最大努力 使需求文檔能夠正確無誤地反映用戶的真實意愿。使需求文檔能夠正確無誤地反映用戶的真實意愿。正式需求評審方式請參考技術(shù)評審過 程域的對應(yīng)規(guī)程spp-proc-tr-ftr。 step3 獲取需求承諾獲取需求承諾 當(dāng)需求文檔通過正式的評審之后，開發(fā)方負責(zé)人（項目經(jīng)理）和客戶對需求文檔作書面 承

11、諾，使之具有商業(yè)合同效果。示例如下： 本需求文檔建立在雙方對需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作根據(jù)該需求 文檔開展。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。我明白需求的變更將導(dǎo) 致雙方重新協(xié)商成本、資源和進度等。 甲方負責(zé)人簽字 乙方負責(zé)人簽字 8.2.6 輸出輸出 需求評審報告 書面的需求承諾 8.2.7 結(jié)束準則結(jié)束準則 需求文檔通過了正式評審，并且獲得開發(fā)方和客戶的書面承諾。 8.2.8 度量度量 項目經(jīng)理統(tǒng)計工作量和上述文檔的規(guī)模 8 8.3 需求跟蹤需求跟蹤 8.3.1 目的目的 將系統(tǒng)設(shè)計、編程、測試等階段的工作成果與需求文檔進行比較，建立與維護“需求文 檔

12、設(shè)計文檔代碼測試用例”之間的一致性，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。 3.3.2 角色與職責(zé)角色與職責(zé) 項目經(jīng)理跟蹤需求。 3.3.3 啟動準則啟動準則 需求文檔已經(jīng)通過正式評審并獲得了承諾。 系統(tǒng)設(shè)計、編程、測試等階段的工作成果如設(shè)計文檔、代碼、測試用例已經(jīng)產(chǎn)生。 3.3.4 輸入輸入 需求文檔 設(shè)計文檔、代碼、測試用例等 3.3.5 主要步驟主要步驟 step1 建立與維護需求跟蹤矩陣建立與維護需求跟蹤矩陣 正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應(yīng)點。 逆向跟蹤。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。 正向跟蹤和逆向跟蹤合稱為“雙向跟蹤

13、” 。不論采用何種跟蹤方式，都要建立與維護需 求跟蹤矩陣（即表格） 。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應(yīng)關(guān)系。矩陣單 元之間的可能存在“一對一” 、 “一對多”或“多對多”的關(guān)系。由于對應(yīng)關(guān)系比較復(fù)雜， 最好在表格中加必要的文字解釋。表 8-1 為簡單的需求跟蹤矩陣格式。 當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。 需求文檔 （版本，日期） 設(shè)計文檔 （版本，日期） 代碼 （版本，日期） 測試用例 （版本，日期） 1標(biāo)題或標(biāo)識符，說明標(biāo)題或標(biāo)識符，說明代碼名稱，說明測試用例名稱，說明 9 2 表 8-1 簡單的需求跟蹤矩陣格式 step2 查找不一致查找不一致 使用需

14、求跟蹤矩陣的優(yōu)點是很容易發(fā)現(xiàn)需求文檔與后續(xù)工作成果之間的不一致之處，例 如： 后續(xù)工作成果沒有實現(xiàn)需求文檔中的某些需求； 后續(xù)工作成果實現(xiàn)了需求文檔中的不存在的需求； 后續(xù)工作成果沒有正確實現(xiàn)需求文檔中的的需求； 項目經(jīng)理將發(fā)現(xiàn)的“不一致性”記錄在需求跟蹤報告之中，并通報給相關(guān)責(zé)任人 （工作成果的開發(fā)者） 。 step3 消除不一致消除不一致 相關(guān)責(zé)任人給出消除“不一致”的措施和計劃，項目經(jīng)理將該措施和計劃記錄到需求 跟蹤報告之中。 相關(guān)責(zé)任人消除“不一致性”之后，項目經(jīng)理更新“需求跟蹤矩陣” 。 8.3.6 輸出輸出 需求跟蹤報告 8.3.7 結(jié)束準則結(jié)束準則 每個開發(fā)階段的“需求跟蹤矩陣”

15、都已經(jīng)建立。 已經(jīng)消除了需求文檔與后續(xù)工作成果之間的不一致性。 8.3.8 度量度量 項目經(jīng)理統(tǒng)計工作量和上述文檔的規(guī)模。 10 8.4 需求變更控制需求變更控制 8.4.1 目的目的 修改“原需求文檔”中不正確的內(nèi)容，產(chǎn)生新的需求文檔。 控制需求文檔的變更，防止發(fā)生混亂。 補充說明：本規(guī)程中的“原需求文檔”是指已經(jīng)通過了評審并獲得書面承諾的需求文檔。 8.4.2 角色與職責(zé)角色與職責(zé) 開發(fā)方負責(zé)人（項目經(jīng)理）和客戶共同控制需求變更。 8.4.3 啟動準則啟動準則 某人（來自開發(fā)方或客戶方）提出變更“原需求文檔”的申請。 8.4.4 輸入輸入 “原需求文檔” 8.4.5 主要步驟主要步驟 st

16、ep1 需求變更需求變更申請申請 需求變更申請人撰寫“需求變更申請書” ，遞交給項目經(jīng)理或客戶方負責(zé)人。 “需求變更申請書”必須闡述：（1）變更原因；（2）變更的內(nèi)容；（3）此變更對項 目造成的影響。 step2 審批需求變更申請審批需求變更申請 開發(fā)方負責(zé)人（項目經(jīng)理）和客戶共同審批“需求變更申請書”： 如果任何一方不同意變更，則退回變更請求，項目按照“原需求文檔”執(zhí)行。 如果雙方都同意變更，轉(zhuǎn)向 step3。 step3 更改更改需求文檔需求文檔 需求分析員根據(jù) step1 和和 step2 更改“原需求文檔” ，產(chǎn)生新的需求文檔。 11 step4 重新進行需求確認重新進行需求確認 重新

17、進行需求評審，參見需求確認規(guī)程中的 step2。 重新獲取書面的需求承諾，參見需求確認規(guī)程中的 step3。 8.4.6 輸出輸出 需求變更控制報告 8.4.7 結(jié)束準則結(jié)束準則 新的需求文檔已經(jīng)被確認。 8.4.8 度量度量 項目經(jīng)理統(tǒng)計工作量。 8.5 實施建議實施建議 先對項目經(jīng)理和客戶進行培訓(xùn)，讓他們掌握必要的需求管理知識。 對需求管理過程域產(chǎn)生的所有有價值的文檔進行配置管理。 對于非合同項目，本規(guī)范中有關(guān)客戶的活動可以被裁減掉。 12 需求跟蹤報告 1. 需求跟蹤矩陣需求跟蹤矩陣 提示：提示：正向跟蹤和逆向跟蹤合稱為“雙向跟蹤” 。不論采用何種跟蹤方式，都要建立與維護 需求跟蹤矩陣（

18、即表格） 。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應(yīng)關(guān)系。矩陣單元 之間的可能存在“一對一” 、 “一對多”或“多對多”的關(guān)系。由于對應(yīng)關(guān)系比較復(fù)雜，最好 在表格中加必要的文字解釋。當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤 矩陣。 需求文檔 （版本，日期） 設(shè)計文檔 （版本，日期） 代碼 （版本，日期） 測試用例 （版本，日期） 1標(biāo)題或標(biāo)識符，說明標(biāo)題或標(biāo)識符，說明代碼名稱，說明測試用例名稱，說明 2 2. 需求問題處理需求問題處理 提示：提示：查找工作成果與需求文檔之間的不一致性，分析原因，給出解決措施 問題描述識別人、日期解決措施結(jié)果 1 2 13 數(shù)據(jù)庫設(shè)計數(shù)據(jù)庫設(shè)計變更控制報告 數(shù)據(jù)庫設(shè)計數(shù)據(jù)庫設(shè)計變更申請變更申請 申請變更的 數(shù)據(jù)庫設(shè)計文檔 輸入名稱，版本，日期等信息 變更的內(nèi)容 及其理由 評估數(shù)據(jù)庫設(shè)計變更將 對 項目造成的影響 申請人簽字 變更申請的審批意見變更申請的審批意見 變更申請方 項目經(jīng)理簽字 審批意見： 簽字，日期 設(shè)計部簽字 審批意見： 簽字，日期 更改需求文檔更改需求文檔 變更后的 數(shù)據(jù)庫設(shè)計文檔 輸入名稱，版本，完成日期等信息 更改人簽字 14 重新評審重新評審數(shù)據(jù)庫設(shè)計數(shù)據(jù)庫設(shè)計文檔文檔 數(shù)據(jù)庫設(shè)計評審小組簽