概念釐清
許多開發者在專案文件撰寫時，容易混淆「程式流程圖」與「業務流程圖」。兩者雖同屬流程圖範疇，但關注層次、受眾與繪製細節截然不同。
業務流程圖
- 關注點：企業/組織的業務邏輯、角色職責、資料流向、決策節點。
- 受眾：專案經理、業務分析師、客戶、測試人員等非技術利害關係人。
- 符號規範：BPMN 2.0 標準符號（泳道、事件、閘道、活動等）。
- 顆粒度：宏觀，不涉及程式碼細節，例如「使用者下單 → 系統驗證庫存 → 財務開立發票 → 倉庫出貨」。
程式流程圖
- 關注點：單一功能/模組的演算法邏輯、控制結構（if/else、for/while、try/catch）、函式呼叫關係、資料結構變化。
- 受眾：開發人員、代碼審查者、維護工程師。
- 符號規範：傳統流程圖符號（開始/終止橢圓、判斷菱形、處理矩形、流向箭頭）。
- 顆粒度：微觀，可精確到程式碼區塊層級，例如「讀取變數 A → 判斷 A > 0 → 是：呼叫 FuncX() → 否：拋出異常」。
對比總結表
| 維度 | 業務流程圖 | 程式流程圖 |
|---|
| 抽象層級 | 高（業務邏輯） | 低（實作邏輯） |
| 主要目的 | 溝通需求、確認範圍 | 指導編碼、輔助除錯 |
| 是否包含技術細節 | 否 | 是 |
| 常用工具 | Visio、ProcessOn、Bizagi | Visio、Draw.io、IDE 內建圖表 |
實務建議
- 專案啟動階段先產出業務流程圖，確認業務邏輯無誤。
- 詳細設計階段，針對複雜演算法、核心交易流程繪製程式流程圖。
- 兩者可透過「業務步驟 → 對應程式模組」的追溯矩陣建立關聯，確保設計完整性。
清晰區分兩者定位，能有效降低溝通成本，讓文件真正發揮價值。
