商業分析學習室個人學習空間
← 回到學習筆記

第一課｜從 PMP 到 BA：產品、需求與需求管理基礎

日期：2026-09-30
主軸：從熟悉的 PMP 視角，建立 BA 對產品、需求、價值與變更的思考方式。

30 秒複習

  1. Project 是有開始與結束的暫時性工作；Product 是被創造、交付、使用與持續演進的成果。
  2. Product Scope 看「產品要具備什麼功能與特性」；Project Scope 看「為了交付成果要完成哪些工作」。
  3. Business Requirement → Stakeholder Requirement → Solution Requirement 是由「為什麼」逐步走向「需要什麼能力」；Transition Requirement 則負責從目前狀態移轉到未來狀態。
  4. Traceability 不是過去／未來資料的方向，而是需求往上追「為什麼要做」，往下追「如何被設計、實作、測試與交付」。
  5. Implementation Dependency 看「沒有另一項需求，功能能不能做出來」；Benefit / Value Dependency 看「功能做出來了，價值能不能實現」。
  6. Impact Analysis 要同時看 value、risk、scope、data、downstream requirements、testing、schedule 與 cost。
  7. Prioritization 不是只看哪個功能最有價值，還要考慮 dependency、risk、effort、urgency 與 workaround。
  8. MVP 不是「功能最少」，而是「最少但仍能形成完整價值」的功能組合。
  9. Acceptance Criteria 要具體、可測試，回答「怎樣才算真的做到」。

---

一、Project、Product 與 Scope

Project vs Product

  • 專案結束，不代表產品生命週期結束。
  • 同一產品可以由多個專案逐步建立與擴充。
  • 「創造某一功能的工作」屬於 Project；「完成後留下並持續被使用的功能」屬於 Product 或 Product Component。

Product Scope vs Project Scope

  • Product Scope：產品或解決方案有哪些功能與特性。
  • Project Scope：為了交付該成果，要完成哪些工作。

燃油閥案例：

  • 「系統可預測未來 90 天需求」＝ Product Scope。
  • 「訪談輪機長、整理資料、開發、測試」＝ Project Scope。

---

二、需求的種類與關係

四類 Product Requirements

  • Business Requirement：為什麼要改？例如降低 Fuel Valve 緊急採購與庫存成本。
  • Stakeholder Requirement：誰需要什麼？例如輪機長需要知道下次補給前可能消耗多少、何時能補到。
  • Solution Requirement：產品必須做什麼／具備什麼品質？例如預測需求、顯示 ETA、計算 shortage risk。
  • Transition Requirement：怎麼從現在切換到未來？例如匯入歷史資料、訓練人員、平行運作。

Functional vs Nonfunctional

  • Functional Requirement：產品要做什麼。
  • Nonfunctional Requirement：做這件事時要達到什麼品質，例如效能、安全、可靠度、支援性。

例：

  • 「系統可以顯示需求預測」＝ Functional。
  • 「查詢結果必須在 2 秒內顯示」＝ Nonfunctional。

Product Requirement vs Project Requirement

  • Product Requirement：產品本身需要具備的能力或條件。
  • Project Requirement：專案執行要符合的條件，例如期限、契約、限制。
  • Transition Requirement 雖然是暫時性的，仍屬於 Product Requirements，不等於 Project Requirement。

---

三、先找 Need，再談 Solution

利害關係人常直接提出解法，例如：

  • 「我要 Dashboard」
  • 「我要 GPS」
  • 「跟廠商簽五年合約」

BA 要先追問：

你真正想解決什麼問題？

燃油閥案例中，輪機長真正需要的不是「AI 系統」本身，而是：

  1. 知道下一次補給前可能消耗多少。
  2. 知道備品預計何時送達。
  3. 因此能判斷補給到達前是否有 shortage risk。

需求應先描述 Need / Capability，再評估具體設計與方案。

---

四、Requirement Traceability

Backward Traceability

往上追：

為什麼需要這個功能？它支援哪個 Stakeholder Need？最後連回哪個 Business Objective？

如果某功能無法往回連到商業目標，就要重新檢查是否真的應該納入範疇。

Forward Traceability

往下追：

需求最後如何被設計、實作、測試與交付？

Bidirectional Traceability

理想狀態是雙向都能回答：

  • Why are we building this?
  • Did we actually deliver what the business needed?

今天修正的一個混淆：

  • Backward / Forward 不是歷史資料 vs 未來預測。
  • 它指的是需求關係的追溯方向。

---

五、Relationships & Dependencies

Subset

大需求拆成較細的子需求。

Implementation Dependency

如果沒有 B，A 根本無法被實作或正常運作。

例：

  • 沒有需求預測，就無法完成 shortage calculation。
  • 沒有 current inventory，就無法判斷補給前是否會缺料。

Benefit / Value Dependency

A 已經可以正常運作，但沒有 B，就無法實現預期商業價值。

例：

  • 預測系統正常，但 Procurement 不使用結果做採購決策，緊急採購仍不會下降。
  • 系統成功發出 shortage alert，但沒有建立後續處理流程，仍可能無法及時補給。

今天修正：

  • 「警報成功，但機務沒有處理流程」屬於 Benefit / Value Dependency，不是 Implementation Dependency。

---

六、Impact Analysis

變更需求時，不只問「能不能改」，還要問整體影響。

案例：

Forecast 從 90 天延長至 180 天，並加入 Engine Load Profile。

應檢查：

  • Business Value：更長規劃期是否真的改善補給決策？
  • Forecast Risk：預測區間越長，誤差是否放大？
  • Data Impact：每艘船是否都有可用且一致的 Load Profile？
  • Downstream Requirements：Shortage Alert、Fleet Forecast、採購規劃是否都要調整？
  • Testing：90 天與 180 天的 accuracy 是否都要重新驗證？
  • Schedule / Cost：新增資料介面、模型與測試會增加多少工作？

BA 的任務是把影響整理完整，支援 decision maker 決定：

  • Approve
  • Defer
  • Reject
  • Request more information

---

七、Requirement Prioritization

MoSCoW

  • Must：缺少就無法達成 solution success。
  • Should：很重要，但可以暫時沒有或有 workaround。
  • Could：有價值，但拿掉不影響核心成功。
  • Won't：本次 release 不做，不代表永遠不做。

燃油閥第一版：

  • Current Inventory：Must。
  • 90-day Forecast：Must。
  • Replenishment ETA：依是否有 workaround，可能 Should / Could / Must。
  • Shortage Alert：依使用者是否能有效人工監控，可能 Should / Must。
  • 180-day Advanced Forecast：Could。
  • GPS Animation：若無法 trace 回 Business Objective，Won't for this release。

Priority ≠ Sequence

R4 Shortage Alert 可能價值很高，但若它依賴 R1、R2、R3，仍不能跳過 dependency 先做。

---

八、MVP

MVP 的核心不是「功能最少」，而是：

最少但仍然能形成完整價值的能力組合。

在本次案例中，一個合理的第一版候選是：

  1. Current Inventory
  2. 90-day Forecast
  3. Replenishment ETA

這三項已能讓使用者判斷「補給前會不會缺料」。

若第二版只能再做一項，今天選擇 Shortage Alert，理由是：

  • 已知目前真正的瓶頸是 Superintendent 無法逐船檢查。
  • Alert 能快速縮小人工判斷範圍。
  • 相較於 180-day Forecast，它更直接解決現況問題，且 effort / risk 較低。

---

九、Acceptance Criteria

Requirement：

系統要能發出 Shortage Alert。

Acceptance Criteria 要進一步定義：

  • 什麼條件一定要發？
  • 什麼條件不應該發？
  • 警報要顯示哪些資訊？
  • 哪些誤報可以接受？漏報風險如何控制？

今天提出的警報資訊至少應包含：

  • 目前庫存
  • 預測需求
  • 已提出但尚未到貨的數量
  • 預計到貨時間
  • 預估 shortage date / shortage quantity
  • 警報原因，例如未提出申請、到貨晚於需求、可用量不足

也發現可將異常拆成不同類型：

  • Shortage Risk
  • Missing Requisition
  • Late Replenishment

下一步要把這些描述進一步量化成可測試的 Acceptance Criteria。

---

今天修正的三個重要誤解

  1. Backward / Forward Traceability 不是過去與未來資料。
  2. 功能正常但價值沒實現，是 Value Dependency，不是 Implementation Dependency。
  3. 沒有發出警報不代表預測一定更準。仍需留意 False Negative（漏報）與 False Positive（誤報）。

---

下一次建議銜接

正式學習位置仍在 01.5 需求的種類與相互關係，下一輪可先把：

  • Functional vs Nonfunctional
  • Product vs Project vs Quality Requirement

再鞏固一次。

之後可接：

  • 01.6 Product Information
  • 07.4 Acceptance Criteria
  • 07.5 Verify Requirements vs 07.6 Validate Requirements

---

教材對照

本筆記為個人學習整理，主要對照：

  • 1.1.7.4 Product Requirements
  • 1.2.1 Relationship Between Products and Projects
  • 1.2.3 How Business Analysis Supports Portfolio, Program, and Project Management
  • 7.4 Define Acceptance Criteria
  • 7.7 Prioritize Requirements and Other Product Information
  • 8.2 Establish Relationships and Dependencies
  • 8.4 Manage Changes to Requirements and Other Product Information

未重製原書圖表或大段原文。