需求確認概要

需求確認是確保所實現的產品與客戶需求一致。

確認需求的必要性

1. 需求傳遞

2. 確認需求
□ 是一系列活動，確保所實現的產品與客戶需求一致
□ 是文檔化的證據，可以據此實現預期的功能及質量
□ 我們是否實現了客戶所需要的需求

定義范圍

1. 產品范圍
□ 某項產品、服務或成果，所具有的特性和功能

2. 項目范圍
□ 為交付具有規定特性與功能的產品、服務或成果，而必須完成的工作

3. 項目范圍說明書-項目成功的關鍵因素
□ 產品范圍描述
□ 產品驗收標準
□ 項目可交付成果
□ 項目除外責任
□ 項目制約因素
□ 項目假設條件

項目范圍說明書

1. 項目范圍說明書的主要作用
□ 確定范圍：描述可交付成果和所要完成的工作
□ 溝通基礎：在項目干系人之間，建立對項目范圍的共識
□ 規劃和控制依據：指導未來項目的規劃和執行
□ 變更基礎：提供變更請求的評估基準

2. 在詳細的項目范圍說明書的基礎上，其他項目計劃也將被逐步開發出來。

工作任務分解

1. 工作分解結構創建WBS
□ 創建工作分解結構WBS是把項目可交付成果和項目工作分解成較小的、更易于管理的組成部分的過程
□ 工作包是工作分解結構的底層，是能夠可靠地估算和管理工作成本和活動持續時間的位置
□ 為工作包建立控制賬戶，并根據賬戶編碼分配標志號，是創建工作分解結構的最后步驟

2. 創建WBS分解原則
□ 包含原則：又稱100%規則，WBS整體包含了項目，所需要完成的全部工作
□ 不可再分原則：WBS的最底層必須有相對獨立的屬性，即不可再分
□ 信息透明原則：分解到可以充分估算，完成該工作包所需的時間、費用、資源的層次為止
□ 80小時原則：最底層工作包可以在80個小時內完成，使得工作績效至少可以2周更新一次，以便監控
□ 獨立責任原則：分解到可以安排給一個責任者（個人或團隊）負責
□ 滾動分解原則：信息暫時不足的，可暫時不分解，等信息充分后繼續分解

3. 創建WBS的作用
□ 項目規劃和預算編制，關注項目目標，澄清職責
□ 建立項目團隊
□ 確定具體的工作包，以便估算工作量和分配工作
□ 為進度計劃制定、成本估算、績效測量等提供了一個堅實的基礎

驗證需求

1. 驗證需求有兩個層面的工作
□ 內部驗證需求是否已正確實現
□ 與客戶驗收項目范圍

2. 驗證需求工作應定義在下列計劃中
□ 需求管理計劃RMP
□ 項目文檔管理計劃
□ 項目配置管理計劃

內部驗證需求方法

內部驗證需求方法是由評審和測試組成，在關鍵時間點或重要里程碑進行需求評審，總結出評審報告供后續活動參考，可以進行正式同行評審或非正式研討。

1. 需求評審
□ 由設計人員、開發人員、客戶或第三方驗證人員發起
□ 跟蹤需求與產品設計、測試用例、用戶手冊等文檔的一致性
□ 確保正在開發的產品是需求所要求的
□ 確保產品滿足接收條件

2. 評審原則
□ 確立評審目標
□ 預先定義評審流程。
□ 獨立的評審員達成一致意見
□ 評審活動遵循統一的評審流程
□ 評審標準可度量

3. 評審目的
□ 相互學習，加深團隊對需求的理解
□ 建立團隊內部信任
□ 檢查、驗證需求，確保所開發的產品是需求所要求的

產品測試

1. 測試過程
□ 根據需求設計測試用例
□ 對測試用例進行評審
□ 根據測試用例測試需求

2. 測試與評審互為補充。

3. 測試方法取決于所屬行業及產品特點。

4. 可以由內部測試人員進行測試或聘請第三方人員進行測試。

外部驗收范圍

1. 驗收范圍主要關注對項目可交付成果的驗收
一般在項目或項目階段末進行，由客戶或項目發起人進行。
□ 核實范圍通過 -> 正式簽字確認
□ 核實范圍不通過 -> 變更請求（缺陷補救）

2. 驗收范圍不通過的原因
□ 最初SOW不完整，理解錯誤
□ 定義范圍時有遺漏
□ 定義范圍和制定驗收標準時，未讓重要干系人參與，也未得到干系人的批準