SDD 缺的那一塊：系統分析
重點整理
SDD 不該只是做成「文件管理 + 追問」，而是要多一點系統分析的思維。那系統分析到底是什麼意思？
工具沒有幫 AI把注意力拆到每個分析點上。
- 連淺層的系統分析都不做（是多數）
- 現成工具只做了一部分（不夠絕對）
- 輕量 skill 幾乎不拆解（AI 不會自己分配注意力）
- 人類 Review 沒有施力點（看不出哪裡該檢查）
- 專案一複雜（幾乎動不了）
01｜系統分析有深淺之分
先把淺的做完，再去爭論深的要做到什麼程度。
淺層. 基本的分析點（多數人連這層都沒做）
深層. 見仁見智（例如狀態機分析）
跳過淺層直接談深層，是最常見的順序錯誤。
02｜讓工具著墨在資料關聯上
現成的規格工具有幫忙做一些分析，但做得不夠絕對。
・可以自己優化，讓它在實體關聯（ERM）這類分析上多花力氣
・關鍵是把分析點一個個拆出來，AI 才會分配注意力過去
沒拆解的 skill，等於沒有指定該看哪裡。
03｜驗收標準驅動
有人的流程是：規格寫完、驗收標準定義好，再和 user story 做連結。
・檢查有沒有奇怪的設計，或容易產生維護成本的高度客製化邏輯
・檢查完沒問題就開工
投資報酬率確實高——但瓶頸會落在「驗收標準很難定義」。
04｜分析結果可以變成測試計畫
系統分析的後階段，可以直接轉換成後端的 Test Plan。
這些思維都有辦法變成生產力，不是只停在文件。
很多資深工程師抗拒寫規格。
有時候不是方法不好，是他們在前一份工作被規格綁死過，留下了陰影。
行動清單
- [ ] 實體與關聯有沒有梳理（ERM）
- [ ] 狀態轉換有沒有列出（狀態機）
- [ ] 驗收標準定義了嗎（最難也最值得）
- [ ] 有沒有連回 user story（檢查一致）
- [ ] 高度客製化的邏輯標出來了嗎（維護成本）
- [ ] 分析結果有轉成測試計畫嗎（變生產力）
淺的都不做，專案一複雜就動不了。
