需求管理研究報告-資料下載頁
2025-04-26 08:11本頁面
【正文】 9 需求跟蹤 目的? 將系統(tǒng)設計、編程、測試等階段的工作成果與需求文檔進行比較，建立與維護“需求文檔－設計文檔－代碼－測試用例”之間的一致性，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。 角色與職責? 項目經(jīng)理跟蹤需求。 啟動準則? 需求文檔已經(jīng)通過正式評審并獲得了承諾。? 系統(tǒng)設計、編程、測試等階段的工作成果如設計文檔、代碼、測試用例已經(jīng)產(chǎn)生。 輸入? 需求文檔? 設計文檔、代碼、測試用例等 主要步驟[Step1] 建立與維護需求跟蹤矩陣? 正向跟蹤。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應點。? 逆向跟蹤。檢查設計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。? 正向跟蹤和逆向跟蹤合稱為“雙向跟蹤” 。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格） 。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應關系。矩陣單元之間的可能存在“一對一” 、 “一對多”或“多對多”的關系。由于對應關系比較復雜，最好在表格中加必要的文字解釋。表 81 為簡單的需求跟蹤矩陣格式。? 當需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。＃ 需求文檔（版本，日期）設計文檔（版本，日期）代碼（版本，日期）測試用例（版本，日期）1 標題或標識符，說明 標題或標識符，說明 代碼名稱，說明 測試用例名稱，說明6 / 92 … … … …表 81 簡單的需求跟蹤矩陣格式[Step2] 查找不一致? 使用需求跟蹤矩陣的優(yōu)點是很容易發(fā)現(xiàn)需求文檔與后續(xù)工作成果之間的不一致之處，例如：? 后續(xù)工作成果沒有實現(xiàn)需求文檔中的某些需求；? 后續(xù)工作成果實現(xiàn)了需求文檔中的不存在的需求；? 后續(xù)工作成果沒有正確實現(xiàn)需求文檔中的的需求； ? 項目經(jīng)理將發(fā)現(xiàn)的“不一致性”記錄在《需求跟蹤報告》之中，并通報給相關責任人（工作成果的開發(fā)者） 。[Step3] 消除不一致? 相關責任人給出消除“不一致”的措施和計劃，項目經(jīng)理將該措施和計劃記錄到《需求跟蹤報告》之中。? 相關責任人消除“不一致性”之后，項目經(jīng)理更新“需求跟蹤矩陣” 。 輸出? 《需求跟蹤報告》 結束準則? 每個開發(fā)階段的“需求跟蹤矩陣”都已經(jīng)建立。? 已經(jīng)消除了需求文檔與后續(xù)工作成果之間的不一致性。 度量? 項目經(jīng)理統(tǒng)計工作量和上述文檔的規(guī)模。7 / 9 需求變更控制 目的? 修改“原需求文檔”中不正確的內(nèi)容，產(chǎn)生新的需求文檔。? 控制需求文檔的變更，防止發(fā)生混亂。補充說明：本規(guī)程中的 “原需求文檔 ”是指已經(jīng)通過了評審并獲得書面承諾的需求文檔。 角色與職責? 開發(fā)方負責人（項目經(jīng)理）和客戶共同控制需求變更。 啟動準則? 某人（來自開發(fā)方或客戶方）提出變更“原需求文檔”的申請。 輸入? “原需求文檔” 主要步驟[Step1] 需求變更 申請? 需求變更申請人撰寫“需求變更申請書” ，遞交給項目經(jīng)理或客戶方負責人。? “需求變更申請書”必須闡述：（1）變更原因；（2）變更的內(nèi)容；（3）此變更對項目造成的影響。[Step2] 審批需求變更申請開發(fā)方負責人（項目經(jīng)理）和客戶共同審批“需求變更申請書”：? 如果任何一方不同意變更，則退回變更請求，項目按照“原需求文檔”執(zhí)行。? 如果雙方都同意變更，轉(zhuǎn)向 [Step3]。[Step3] 更改需求文檔? 需求分析員根據(jù) [Step1] 和 [Step2] 更改“原需求文檔 ”，產(chǎn)生新的需求文檔。8 / 9[Step4] 重新進行需求確認? 重新進行需求評審，參見需求確認規(guī)程中的 [Step2]。? 重新獲取書面的需求承諾，參見需求確認規(guī)程中的 [Step3]。 輸出? 《需求變更控制報告》 結束準則? 新的需求文檔已經(jīng)被確認。 度量? 項目經(jīng)理統(tǒng)計工作量。 實施建議? 先對項目經(jīng)理和客戶進行培訓，讓他們掌握必要的需求管理知識。? 對需求管理過程域產(chǎn)生的所有有價值的文檔進行配置管理。? 對于非合同項目，本規(guī)范中有關客戶的活動可以被裁減掉。
規(guī)章制度相關推薦
鄂ICP備17016276號-1