商業分析實務指南(PMI) Business Analysis for Practitioners: A Practice Guide CH4 需求導出和分析 (Requirements Elicitation And Analysis) 4.11 - 4.15

1. Business Analysis
商業分析實務指南 (PMI)
四、需求導出和分析 (3/3)
Moris, CBAP, PMP, PMI-PBA
PMI-PBA 商業分析讀書會
2015.09.10

2. 商業分析實務指南
TopicTopic PagePage DateDate LinkLink
Ch1 商業分析概論 10 8/6
Ch2 需要評估 26 8/13
Ch3 商業分析規劃 32 8/20
Ch4 需求導出和分析 (4.1-9) 20/68 8/27
Ch4 需求導出和分析 (4.10) 29/68 9/3
Ch4 需求導出和分析 (4.11-15) 19/68 9/10
Ch5 追蹤與監控 20 9/17
Ch6 解決方案評價 20 9/24
商業分析者之家 商業分析智囊團
CBAP/PBA TaiwanCBAP/PBA 商業分析
CBAP/PBA Taiwan
改變．價值．解決方案

3. Aylan Kurdi

4. World War II

5. 4 需求導出和分析
 文件化方案需求
 確認需求 (Validate RQ)
 驗證需求 (Verify RQ)
 核准會議
 解決需求衝突

6. 4.11 文件化方案需求
 為什麼文件重要
 企業需求文件 (BRD)
 解決方案文件
 需求規格
 撰寫需求的指導原則
 排序需求
 技術性需求規格
 透過用例 (UC) 和使用者故事製作文件
 待辦項目 (Backlog Items)

7. 4.11 文件化方案需求
 在分析過導出的資訊後 , 商業分析師要依照組織 ,
專案需要 , 和專案生命週期 , 將需求記錄成文件
 商業分析師要準備需求文件包給開發團隊

8. 4.11 文件化方案需求
 為什麼文件重要
 確認需求的基準 (Baseline)
 企業問題或機會的定義
 設計 , 開發 , 測試 , 品保的主要輸入 (Input)
 使用手冊或其他文件的基礎
 支援合約的細節 (SOW, RFP 的輸入 )
 解決方案發展的起點
 重用性的基礎
 產業規範稽核的標準 , 或高風險專案必要的需求紀錄

9. 4.11 文件化方案需求
 企業需求文件 (BRD)
 包含目標 , 目的 , 高階需要 , 和新專案的合理性
 識別什麼對企業是關鍵的 , 及為何關鍵
 放在企業需求規格 , 或存放所有需求的大型文件
 若用試算表整理 , 建立以企業需求為起點的階層架構
 用需求管理工具 , 企業需求會以分類或屬性作群組

10. 4.11 文件化方案需求
 解決方案文件 (SD)
 包含產品或服務的特性 , 功能 , 特徵的文件
 用以建立符合企業需求或關係人需求的產品或服務
 方案開發團隊視為建立產品的藍圖
 解決方案文件的格式在商業分析規劃時作定義
 主要的格式包含需求文件 , 使用者故事 , 用例 , 待辦
清單
 產品需求會以不同類型的詳細程度來撰寫 , 如企業需
求 , 關係人需求 , 方案需求 , 和過渡需求
 方案需求則進一步分成功能性和非功能性需求
 需求的分類則可以幫助文件建立群組和結構

11. 4.11 文件化方案需求
 需求規格 (Requirement Specification)
 說明發生在解決方案的狀況 , 條件 , 動作 , 反應 , 結
果 , 和錯誤條件
 跟隨開發團隊建立解決方案所製作的手冊 (manual)
 泛指所有需求的文件 , 包含高階的 , 企業導向的期望
或需要 , 到產品或服務的詳細規格
 敏捷 , 精實 , 或混和方法專案 , 需求規格反而非常輕
量

12. 4.11 文件化方案需求
 撰寫需求的指導原則
 資訊必須轉錄為高品質 , 格式良好的需求
 撰寫良好的需求對開發人員與專案團隊有極大價值
 需求的撰寫 , 文件化 , 和指導原則依賴專案生命週期
 格式良好的需求應包含的要素
 條件 , 主題 , 命令式 , 主動動詞 , 對象 , 商業規則 ( 選 ), 結
果 ( 選 )
 高品質的需求應具備下列特徵
 不模糊 , 精確 , 一致 , 正確 , 完整 , 可衡量 , 可行 , 可追蹤 ,
可測試

13. 4.11 文件化方案需求
 排序需求
 需求的排序定義在商業分析計畫
 需求導出和分析時 , 引導關係人作優先序的決策
 排序技術 : MoSCoW, 複式投票 , 時間盒 , 加權評分
 技術性需求規格
 專案需要詳細的技術文件 , 以支援開發的工作
 這些需求會紀錄在技術性需求規格
 技術規格要素 : 線框圖 , 畫面樣式 , 資料模型 , 詳細
流程 , 詳細需求

14. 4.11 文件化方案需求
 透過用例 (UC) 和使用者故事製作文件
 用例常用於功能需求規格或代替功能需求的文件
 使用者故事常作為解決方案需求的高階版本
 待辦項目 (Backlog Items)
 產品需求和交付物的優先序清單
 通常撰寫成故事 , 並經過業務排序
 用來管理和組織專案的工作

15. 4.12 確認需求 (Validate RQ)
 確認是要確保需求能解決問題
 確保產品 , 服務 , 或系統符合顧客或關係人需要
 確保需求精確反映關係人的意向 , 符合他們的期
待
 需求確認的要點
 持續確認 (Continual Confirmation)
 需求演練 (RQ Walkthrough)

16. 4.12 確認需求 (Validate RQ)
 持續確認 (Continual Confirmation)
 需求確認可能發生在撰寫需求文件或需求研討會
 需求確認不是只有在需求流程結束才執行
 確認是獲取關係人同意 , 開發中的方案可以完成目標
 需求演練 (RQ Walkthrough)
 與關係人共同審查 , 確認需求是否有效
 讓關係人足夠時間做準備 , 和閱讀材料
 關係人提出問題 , 獲得理解 , 和表達憂慮的機會

17. 4.13 驗證需求 (Verify RQ)
 驗證是審查需求錯誤和品質的程序
 驗證可能發生在確認 (Validate) 之前或之後
 驗證由解決方案團隊執行
 確保需求或交付物符合品質標準
 兩種驗證流程
 同儕審查 (Peer Review)
 檢驗 (Inspection)

18. 4.13 驗證需求 (Verify RQ)
 同儕審查 (Peer Review)
 需求流程中的任意時間點皆可執行
 正式或非正式的審查需求
 參與人員 : 商業分析師 , 品保人員 , 測試人員
 檢驗 (Inspection)
 檢驗是比同儕審查更嚴謹的方式
 可用於審查任意事物的精確性 , 完整性 , 和相關性
 參與人員 : 建立需求文件者 , 接收需求文件者
 需求檢驗的查檢表 (Checklist)

19. 4.14 核准會議
 核准會議與確認會議分開進行
 方案經過確認後 , BA 須獲得關係人對需求的簽署
 簽署可以正式或非正式 , 由商業分析規劃決定
 三個必要的簽署
 業務負責人
 解決方案團隊
 商業分析師

20. 4.15 解決需求衝突
 衝突可能發生在商業分析流程的任意點
 商業分析師負責調解衝突的情況
 商業分析師須具備協商和獲取共識的軟性技能
 排除主觀和情緒的技術
 德爾菲法 (Delphi)
 複合投票 (Multivoting)
 加權評分 (Weighted Ranking)

21. 4.15 解決需求衝突
 德爾菲法 (Delphi)
 幫助專家們對主題達成共識
 複式投票 (Multivoting)
 透過投票將多個選項縮減到可以做決策的數量
 加權評分 (Weighted Ranking)
 方案選項評分與需求優先順序也使用同樣方式

22. 感謝您的參與