Terry Yao's Blog

[methodology] 系統分析與設計 — SA 的思維框架

閱讀時間約 10 分鐘

cover

系統分析與設計 — SA 的思維框架

SA 做的事，本質上是翻譯——把人話翻成系統能理解的結構。

SA 到底在做什麼

很多人以為 SA 就是「畫 UML 圖的人」或「寫規格文件的人」。這就像說廚師就是「切菜的人」。

SA 的核心工作是 在需求和實作之間建立橋樑：

使用者說的話 → [SA 的翻譯] → 開發者能實作的結構
「我要一個購物車」      →      資料模型、狀態流、API 介面、例外處理

翻譯之所以難，是因為：

  • 使用者不知道自己要什麼（他們描述的是症狀，不是需求）
  • 工程師會假設太多（他們直接跳到實作，跳過結構設計）
  • 需求永遠在變（但結構不能每次都翻新）

SA 的五個思維層次

系統分析不是一個步驟，而是五個層次的思考，每一層回答不同的問題：

graph TD
    A[1. 問題域<br/>到底要解決什麼問題？] --> B[2. 需求域<br/>需要什麼能力來解決？]
    B --> C[3. 資料域<br/>需要管理哪些資料？關係是什麼？]
    C --> D[4. 行為域<br/>資料怎麼流動？狀態怎麼轉換？]
    D --> E[5. 介面域<br/>系統對外長什麼樣子？]

    style A fill:#E91E63,color:#fff
    style B fill:#9C27B0,color:#fff
    style C fill:#2196F3,color:#fff
    style D fill:#4CAF50,color:#fff
    style E fill:#FF9800,color:#fff

1. 問題域：到底要解決什麼問題？

最常見的錯誤是直接跳過這層。

使用者說「我需要一個報表系統」——你的第一反應不該是「用什麼報表框架」，而是：

  • 他為什麼需要報表？想看什麼？做什麼決策？
  • 現在沒有報表他怎麼做？痛點在哪？
  • 真的需要「報表系統」嗎？還是一個 dashboard 就夠了？

核心技巧：5 Whys（五個為什麼）

不斷追問「為什麼」，直到碰到真正的問題根源。表面需求和真正需求往往差很遠。

2. 需求域：需要什麼能力？

確認問題後，把它拆成系統需要具備的「能力」：

需求類型範例容易被忽略嗎？
功能性需求使用者可以新增商品到購物車不會，大家都會寫
非功能性需求頁面載入時間 < 2 秒經常被忽略
約束條件必須在現有的 PostgreSQL 上運行有時被忽略
商業規則折扣不能疊加超過兩層最容易被忽略

非功能性需求和商業規則才是真正的坑。 功能性需求大家都會列，但「同時 1000 人結帳不能掛」和「VIP 客戶的折扣規則」這種東西不問就不知道。

3. 資料域：需要管理什麼資料？

這是 SA 最具體的產出之一：Entity-Relationship 模型。

不需要畫完美的 ER Diagram，但你要能回答：

  • 有哪些核心實體？（User、Product、Order、Cart…）
  • 它們之間的關係是什麼？（一對多、多對多）
  • 每個實體的生命週期是什麼？（建立 → 修改 → 刪除？還是建立 → 歸檔？）
  • 哪些資料是衍生的？（訂單總金額 = Σ 商品金額 × 數量 - 折扣）
[User] 1──N [Order] N──N [Product]
   │                       │
   └── 1──N [Cart] ──N ────┘

思維重點： 先想資料結構，再想功能。資料模型錯了，上面蓋的功能全部要重來。

4. 行為域：資料怎麼流動？

兩個核心工具：

資料流圖 (DFD) — 回答「資料從哪來、經過什麼處理、到哪去」

使用者 → [提交訂單] → 訂單系統 → [計算金額] → 支付閘道
                         ↓
                    [更新庫存] → 庫存系統

狀態圖 — 回答「這個東西有哪些狀態、怎麼轉換」

[草稿] → 提交 → [待審核] → 核准 → [進行中] → 完成 → [已結案]
                    ↓
                  退回 → [草稿]

為什麼這很重要： 大部分的 bug 不是「功能寫錯」，而是「狀態轉換沒處理好」。一個訂單從「待付款」可以變成「已取消」嗎？已出貨的訂單可以退款嗎？這些問題在這一層就要想清楚。

5. 介面域：對外長什麼樣？

最後一層才是大家最熟悉的：API 設計、UI wireframe、系統整合介面。

這一層的產出：

  • API 端點清單（對應 API 設計）
  • UI 的資訊架構（每個頁面顯示什麼資料、能做什麼操作）
  • 外部系統整合介面（支付、物流、第三方 API）

重點： 如果前四層做得扎實，這一層幾乎是自然而然的。如果你發現 API 設計很糾結，通常是前面的資料模型或狀態流沒想清楚。

SA 產出物一覽

不是每個專案都需要全部的文件，但你應該知道有哪些工具可以用：

產出物解決什麼問題什麼時候必要
需求規格書 (SRS)記錄「系統要做什麼」的完整描述外包、大型專案、合約型開發
資料字典定義每個欄位的型別、範圍、來源多人開發、資料密集型系統
ER Diagram資料模型的視覺化幾乎所有後端專案
DFD 資料流圖資料在系統中怎麼流動複雜業務邏輯、多系統整合
狀態圖核心物件的狀態轉換有複雜生命週期的實體（訂單、工單、審批流）
Use Case 圖誰可以對系統做什麼權限設計、多角色系統
系統架構圖模組之間的關係和部署結構所有專案都值得畫

一個人做 SA 的現實

以前 SA 是一個專職角色，需要大量訪談和文件撰寫。現在如果你是自己做專案或小團隊，怎麼用最少的成本得到 SA 思維的好處？

最小可行的 SA 流程：

  1. 寫一頁 Problem Statement — 用三句話描述：什麼問題、誰遇到、現在怎麼處理
  2. 列出核心實體和關係 — 不需要畫圖，用文字列就好（User has many Orders, Order has many Items）
  3. 畫一張狀態圖 — 只畫最核心的那個實體（通常是 Order、Ticket、Request 之類的）
  4. 定義 API 的 happy path — 主要的 3-5 個 endpoint，只寫 request/response 的形狀
  5. 列出你「不確定」的地方 — 這些就是你需要去確認的風險點

AI 在這裡的角色： 你可以把模糊的需求丟給 AI，讓它幫你生成初版的 ER diagram、狀態圖、API 規格。但你要有能力判斷：它生成的東西哪裡不對、哪裡缺了。

反思問題

  1. 你上次開始寫 code 之前，有想過資料模型嗎？ 還是邊寫邊加欄位？
  2. 你的系統裡，核心實體有幾種狀態？每種狀態的轉換條件你說得出來嗎？
  3. 如果明天來了一個新需求，你的資料模型撐得住嗎？ 如果不確定，可能當初的 SA 沒做到位。
  4. 你能不能在 10 分鐘內，把一個新功能的資料流畫出來？ 這是 SA 思維內化的指標。

延伸閱讀

關係圖譜

反向連結