SPI E REQM P01 需求管理過程檔案

2021-08-04 06:46:32 字數 3477 閱讀 4061

編碼:xx-spi-e-reqm-p01

xx有限責任公司

需求管理過程檔案

更改控制頁

目錄1 目的 1

2 範圍 1

3 術語定義 1

4 職責 2

5 裁剪指南 2

6 過程 3

6.1 依據需求建立跟蹤矩陣 3

6.1.1 概要圖 3

6.1.2 啟動條件 4

6.1.3 輸入 4

6.1.4 活動 4

6.1.4.1 學習和理解「需求開發」階段的產生的需求文件 4

6.1.4.2 獲得對需求的承諾 5

6.1.4.3 建立需求跟蹤矩陣 5

6.1.5 輸出 5

6.1.6 關閉標準 5

6.2 需求不一致跟蹤 6

6.2.1 概要圖 6

6.2.2 啟動條件 7

6.2.3 輸入 7

6.2.4 活動 7

6.2.4.1 接收當前階段工作產品,維護矩陣 7

6.2.4.2 發現不一致 7

6.2.4.3 分析不一致、制定解決方案 8

6.2.4.4 執行糾正活動 8

6.2.4.5 需求管理的記錄 9

6.2.5 輸出 9

6.2.6 關閉標準 9

6.3 需求變更管理 10

6.3.1 概要圖 10

6.3.2 啟動條件 10

6.3.3 輸入 11

6.3.4 活動 11

6.3.4.1 收集需求變更請求 11

6.3.4.2 分析變更申請 11

6.3.4.3 評審變更請求及解決方案 11

6.3.4.4 獲得對變更的承諾 12

6.3.4.5 執行需求變更活動 13

6.3.4.6 記錄所有變更 14

6.3.5 輸出 14

6.3.6 關閉標準 14

7 審核 14

8 度量 14

9 技能要求 15

10 參照檔案 15

對需求進行管理、維護需求;

識別與專案計畫和工作產品之間的不一致之處;

確保把對需求的更改反映到專案計畫、活動和工作產品中。

確保專案經過確認的使用者需求,能被有效的管理、維護、跟蹤,並正確的實現,最終滿足使用者的需要。

從「需求開發」的「需求確認」結束開始,直到專案結束為止;有些專案可能只到通過「使用者驗收」為止。

epg:工程過程組,組織、執行、維護軟體過程改進的所有活動。

ccb:change control board變更控制委員會(專案經理、客戶、高階經理、技術專家等)。

ccb的參加範圍可以根據不同的情況而有所變更:當變更的影響非常小,對專案的階段性進度和階段內的各項活動的影響也非常小,甚至可以忽略不計時,ccb可由專案經理和客戶組成;當變更的影響仍非常小,對專案的階段性進度的影響也非常小,甚至可以忽略不計,但在階段內的活動需要有所變動時,投入的資源相對不發生變化時,ccb可以專案經理、專案組成員和客戶組成;其他的情況,ccb應由專案經理、專案內的主要成員、高階經理和客戶組成。

技術管理委員會:對有關技術問題進行評審、審查的組織,一般執行同行評審的活動。成員為專案經理、技術專家等,專案總監、技術副總可以以技術專家的身份參加技術管理委員會。

針對具體的專案時,客戶的技術專家也可以臨時加入這個組織。

需求跟蹤矩陣:用於維護專案實現客戶需求的跟蹤工具。

需求不一致:需求與專案計畫和工作產品之間的差異。

工作產品:用於指由過程產生的任何人工製品。這些人工製品包括文件、產品的一部分、服務、過程、規範等。

需求基線:需求開發結束時發布的與需求相關的一組工作產品。這組工作產品一般包括需求開發的全部工作產品(需求文件、評審記錄及參考文件)。是專案計畫以及其他附屬計畫的參考依據。

根據專案實際情況,包括需求明確程度、專案規模、工期、變更情況、專案經理可對本過程進行裁剪。

根據專案已定義的過程對需求管理的過程階段和工作產品進行裁剪。

需求小組(一般包括專案經理、系統分析員)依據經過「需求開發」而形成的需求文件,建立《需求跟蹤矩陣》。

需求開發活動已經執行,並得出《系統需求規格說明書》。

《使用者需求說明書》

《系統需求規格說明書》

「專案已定義的軟體過程」

需求小組在「需求開發」階段產出了「需求文件」,《使用者需求說明書》一般是經過組織、提煉、概括後的使用者提出的需求;《系統需求規格說明書》是經過轉化後形成的可供操作的、可開發的系統需求說明,一般能滿足所有的使用者需求。

需求小組對「需求文件」的內容進行講解,被講解人一般為專案經理、後續階段活動的專案組成員(例如:系統設計階段的系統設計員,開發階段的編碼人員,測試階段的測試人員,實施過程的實施人員和驗收人員等)。在這一過程中一定要達到被講解人能夠完全理解「需求」的內容。

專案經理認為必要時可組織專案組成員對需求進行反講,加深對需求的了解。

系統分析員與專案經理組成需求小組,當系統分析員完成需求開發、系統分析工作後離開專案組時,專案經理必須有能力對需求進行維護,專案經理必須在系統分析員的幫助下熟知需求、系統分析的內容、任務等。

在專案執行過程中,當需求發生變更後,重新進行「需求開發」後產生新的「需求文件」時,系統分析員應對需求的變化情況以及變化產生的影響進行講解。

需求小組與客戶、各個專案參與者達成共識,確保專案的各個階段的參與者能夠對當前的「需求」做出承諾。每個專案參與者都在理解了需求的基礎之上,做出對「需求」的承諾。

需求小組維護對於需求變更後的重新「需求開發」階段之後的所有專案相關人員的重新確認、重新承諾的過程。

需求小組獲得「需求開發」的後續階段的各個參與者對「需求」的確認和承諾,確保「需求」的連續性,一致性,完整性。

需求小組組織簽訂、維護有「需求承諾」的《使用者需求說明書》、《系統需求規格說明書》文件。

需求小組依據最初的經過「需求開發」階段得到的被確認的「需求文件」、「專案已定義的軟體過程」來建立《需求跟蹤矩陣》。確定跟蹤的時間、頻率、間 (隔等。

需求小組從「需求文件」中識別出各個需求專案,並按「需求文件」中定義好的需求項編號或需求項名稱,一一填寫在《需求跟蹤矩陣》中。

需求小組將《需求跟蹤矩陣》作為「需求管理安排計畫」列入專案計畫的從屬計畫,參與專案計畫的評審。需求管理安排的時間一般是里程碑或周這樣的階段性時間。

《需求跟蹤矩陣》

需求小組建立了《需求跟蹤矩陣》;並將需求講解給專案組,至少「專案策劃」階段的專案組成員已經理解了需求。

需求小組跟蹤在專案執行過程中需求的狀態、工作產品與需求之間的不一致等內容。並且採取措施維護工作產品與需求的一致性。

01 需求調研記錄

氣象監測與災害預警工程 低溫冷害預報預警系統 需求調研記錄 北京中軟國際資訊科技 二o一三年十月 目錄第一章測試 1 1.1 測試 1 1.1.1 測試 1 1.1.1.1 測試 1 第二章測試 6 第三章測試 7 第四章圖表目錄 8 本模板適用於大客戶部所有文件的編寫,對外提價的文件 對內提交的文...

01期刊管理系統需求分析

1.2.1系統任務概述 1.2.2功能需求3 1.2.3資料流圖3 1.2.4資料字典6 1.2.5e r圖6 1.2.6效能要求7 1.2.7執行環境7 一 期刊管理系統需求分析 1.2.1系統任務概述 人類社會已經進入了乙個以資訊科技為中心的時代。人類傳遞資訊 獲取資訊 交流資訊的方式發生了前所...

01銷售人員培訓需求分析報告範本

人力資源部對公司銷售人員進行了培訓需求問卷調查,收到有效問卷103份。經過對問卷進行統計分析,撰寫此分析報告,以作為2008年度開展銷售培訓的參考和依據。一 銷售人員總體概況 1.銷售人員調查資料分析 從學歷上看,本公司銷售人員主要由大專畢業人員組成,約佔公司銷售人員的79.6 從男女比例來看,公司...