「我需要一個報表系統。」——你的第一反應如果是「用什麼報表框架」，你就跳過了最重要的那一層。
先講結論
SA 的核心工作是翻譯：把使用者的人話翻成開發者能實作的結構。翻譯之所以難，是因為使用者不知道自己要什麼、工程師會假設太多、需求永遠在變但結構不能每次翻新。
五個思維層次
系統分析不是一個步驟，是五層思考，每層回答不同的問題。
1. 問題域：到底要解決什麼
最常見的錯誤是跳過這層。
使用者說「要報表系統」——先問：他為什麼要報表？想看什麼？做什麼決策？現在沒報表他怎麼做？真的需要「報表系統」嗎，還是一個 dashboard 就夠了？
核心技巧：5 Whys。 不斷追問為什麼，直到碰到真正的問題根源。表面需求跟真正需求往往差很遠。
2. 需求域：需要什麼能力
功能性需求大家都會列。坑在非功能性需求和商業規則——「同時 1000 人結帳不能掛」「折扣不能疊加超過兩層」，不問就不知道。
3. 資料域：管理什麼資料
SA 最具體的產出之一：Entity-Relationship 模型。
不用畫完美的 ER Diagram，但你要能回答：核心實體有哪些？關係是什麼？生命週期是什麼？哪些資料是衍生的（訂單總金額 = 商品金額 x 數量 - 折扣）？
先想資料結構，再想功能。 資料模型錯了，上面蓋的功能全部要重來。
4. 行為域：資料怎麼流動
兩個核心工具：資料流圖（資料從哪來、經過什麼處理、到哪去）和狀態圖（物件有哪些狀態、怎麼轉換）。
大部分的 bug 不是「功能寫錯」，而是**「狀態轉換沒處理好」**。已付款的訂單可以直接刪除嗎？已出貨的可以退款嗎？這些在這一層就要想清楚。
5. 介面域：對外長什麼樣
API 設計、UI wireframe、系統整合介面。
如果前四層做得扎實，這層幾乎水到渠成。如果你發現 API 設計很糾結，通常是前面的資料模型或狀態流沒想清楚。
一個人做 SA 的最小流程
以前 SA 是專職角色。現在小團隊或個人專案，用最少成本取得 SA 思維的好處：
- 寫一頁 Problem Statement：什麼問題、誰遇到、現在怎麼處理（三句話）
- 列核心實體和關係：不用畫圖，文字就好（User has many Orders, Order has many Items）
- 畫一張狀態圖：只畫最核心的實體（通常是 Order、Ticket 之類的）
- 定義 API happy path：主要 3-5 個 endpoint，只寫 request/response 形狀
- 列出你「不確定」的地方：這些就是風險點
AI 可以幫你生成初版 ER diagram、狀態圖、API 規格。但你要有能力判斷哪裡不對、哪裡缺了。
延伸閱讀
- 系統規劃方法論 — 偏重時程和資源面
- UML 統一塑模語言 — SA 產出物的標準表達方式
- API 設計與認證機制 — 介面域的具體實踐
- IT 角色演進 — SA 角色的定位變化
你上次開始寫 code 前有想過資料模型嗎？還是邊寫邊加欄位？——如果是後者，不要怪後來的人看不懂你的 schema。