商業分析知識體系(BABOK 2.0) Techniques 技術交流 需求管理相關技術 9.30 結構化演練 基準(Baselining) 簽核(Signoff) 涵蓋矩陣(Coverage Matrix) 需求文件(Requirements Documentation) 選商需求(Requirements for Vendor Selection)

1. Business Analysis
商業分析知識體系 (IIBA)
需求管理相關技術
Moris, CBAP, PMP, PMI-PBA
Techniques 技術交流 (BABOK 2.0)
2015.11.19

2. 商業分析知識體系
TopicTopic PagePage DateDate LinkLink
需求分析相關技術 (1) na 10/08
需求分析相關技術 (2) na 10/15
企業分析相關技術 na 10/22
商業分析規劃相關技術 na 10/29
需求導出相關技術 (1) na 11/05
需求導出相關技術 (2) na 11/12
需求管理相關技術 na 11/19
解決方案評估相關技術 na 11/26
商業分析者之家 商業分析智囊團
CBAP/PBA TaiwanCBAP/PBA 商業分析
CBAP/PBA Taiwan
改變．價值．解決方案
http://line.me/R/ti/g/1LBjwhaMop

3. Pray for Paris
Wallnicki

4. 4.1 管理方案範疇和需求
 問題追蹤 (9.20)
 基準 (Baselining)
 簽核 (Signoff)

5. 4.1 管理方案範疇和需求
 基準 (Baselining)
 需求經核准後即建立基準 , 所有功能變更都需紀錄和
追蹤 , 以及現狀會與基準做比較
 建立基準後 , 後續對需求修改須遵循必更管理流程
 變更核准後 , 需求管理計畫會要需求基準版做維護
 額外的資訊也會維護進去 , 如變更的描述 , 變更的人
員 , 和變更的理由

6. 4.1 管理方案範疇和需求
 簽核 (Signoff)
 需求簽核是將關係人的協定正式化 , 代表需求文件的
內容和呈現精確和完整
 正式簽核應依據組織標準和法令規範的要求進行
 獲取簽核應舉辦面對面的最終審查 , 邀請有權限核准
需求的關係人參加
 若關係人僅有權限簽核部分需求 , 應建立明確清單哪
些需求已經關係人核准 , 及補充清單哪些需求尚未核
准
 在此情況 , 商業分析師要確保每個需求至少有一個具
權限的關係人核准

7. 4.2 管理需求追蹤
 涵蓋矩陣 (Coverage Matrix)
 涵蓋矩陣是一張用來管理追蹤的資料表或電子表格 ( 如
Excel 工作表 )
 通常用於較少的需求 , 或是追蹤有限的高階需求

8. 4.3 管理需求重用
 N/A

9. 4.4 準備需求文件包
 需求文件 (Requirements Documentation)
 選商需求 (Requirements for Vendor Selection)

10. 4.4 準備需求文件包
 需求文件
 需求的獲取通常作為正式文件
 需求有許多的範本被廣泛運用
 範本和文件的選擇是依據商業分析方法
 常見的需求文件類型
 企業需求文件 (BRD)
 產品藍圖 (Product Roadmap)
 軟體 / 系統需求規格
 補充性需求規格
 願景文件 (Vision Document)

11. 4.4 準備需求文件包
 選商需求
 若外部單位有潛在的解決方案 , 商業分析師會獲取需
求作成 RFI, RFQ, RFP 的格式
 RFI 是發包組織開放一定數量的替代方案 , 尋求資訊來評價可能的選
項
 RFQ 和 RFP 則是發包組織對方案選項有所了解 , 尋求能夠實施選項
的廠商 , RFP 會較 RFQ 正式
 RFP 內容 : 企業 / 關係人需求 , 企業策略 / 企業架構 , 技術環境限制
, 法令 / 規範 / 政府要求
 供應商資訊 : 方案成本 / 總持有成本 , 企業策略校準 , 方案架構 / 績
效 / 品質 / 支援 , 方案擴展 / 整合 , 方案持續 / 供應商剖析
 商業分析師會基於企業需求發展評價標準
 成本 : 實施成本 , 總持有成本
 目標衡量 : 建議方案符合需求的程度

12. 4.5 溝通需求
 需求研討會 (9.23)
 結構化演練 (9.30)

13. 技術介紹
 9.30 結構化演練

14. 9.30 結構化演練
 執行結構化演練來溝通 , 驗證 , 與確認需求
 邀請參與者審查和討論需求的工作會議
 參與者要題出問題 , 並做評論和建議
 有些議題會在會議中被識別出來
 所有問題 , 評論 , 考量 , 和建議會被記錄
 演練的結果可能是改版的需求 , 並發佈需求調查
 演練也可稱作需求審查
 與檢驗類似 , 遵循更正式的流程並使用查檢表等工具

15. 9.30 結構化演練
 前提條件
 完整的需求文件包 , 審查人員清單 , 會議載體
 處理過程
 審查範疇 , 組織和排程審查 , 執行審查 , 編寫審查紀
錄和結果 , 必要時重新審查
 角色 : 需求寫作人員 (Author), 記錄人員 (Scribe) , 主
持人員 (Moderator), 同業人員 (Peer), 審查人員
(Reviewer)
 審查期間遵循的規則
 主持人員確保所有參與者遵守規則
 商業分析師決定哪些關係人參與

16. 9.30 結構化演練
 優點
 促進關係人對需求的討論
 有效識別可能模糊和不了解的領域
 缺點
 若變更未善盡管理 , 審查會議可能導致重複改版
 改版和審查周期的長度 , 導致漫長的核准流程

17. 感謝您的參與
危機女王 Our Brand Is Crisis