先講結論
SA/SD 文件體系不是官僚，是在特定時代用來解決特定問題的工具。大多數文件的存在有合理的原因，但那個原因在現代開發環境裡有些已經消失了。
理解每份文件為什麼存在，比知道格式更重要。這樣你才能判斷哪些該做、哪些可以用更輕量的方式取代。
為什麼這些文件會出現
時代背景：電腦很貴，錯不起
1960–70 年代，大型主機的運算時間按小時計費。在寫任何一行程式前，需求和設計必須先搞清楚——因為錯了的代價是重做整個流程。這催生了「在寫程式前把事情想清楚的人」，也就是 SA 的原型。
翻譯問題：業務人員看不懂程式
開發者稀缺，讓他們去跟業務溝通是浪費。需要一個懂業務又懂系統的人把「我要一個可以查庫存的功能」翻譯成「資料庫這樣設計、API 這樣切」。SA 本質上是翻譯官。
政府採購：文件是驗收依據
美國國防部 1970 年代開始要求軟體承包商提交標準化文件（DoD-STD-2167）。文件從此變成「合約上的交付物」，而不只是內部工作產出。這套規格後來擴散到所有大型政府和企業採購。
IBM 把這套帶進亞洲
IBM 在 1970–80 年代把這套方法論賣給日本大企業。日本 SI 公司把它變成超級精細的流程規範，台灣 IT 從日本和 IBM 兩條線繼承了同樣的結構。
文件體系全覽
按專案流程排列，每份文件解決的問題：
需求階段
BRD（Business Requirements Document） 業務要什麼、為什麼要做、成功指標。這份文件的讀者是業務主管和出錢的人，不是工程師。
FRD（Functional Requirements Document） 系統要做什麼、功能清單、邏輯規則。這是 SA 最核心的產出，也是開發的主要依據。詳細寫法見 FRD 寫作指南。
SRS（Software Requirements Specification） FRD 的正式版，加上非功能性需求（效能、安全、可靠性）。通常只有政府採購或金融業才嚴格要求 SRS 格式。
Use Case Document 誰在什麼情境下做什麼事，包含主流程和例外流程。現代 Agile 開發用 User Story + Acceptance Criteria 取代，但 Use Case 仍然是一種把「情境」想清楚的有用工具。
分析階段
DFD（Data Flow Diagram） 資料怎麼在系統間流動。注意 DFD 不屬於 UML 標準，它來自更早的結構化分析方法論（1970 年代），但幾乎每個 SA 都在畫。
ERD（Entity Relationship Diagram） 資料實體與關聯，Table Schema 的前身。ERD 是 Peter Chen 1976 年提出的，也不屬於 UML。現代工具：dbdiagram.io、Mermaid ER Diagram。詳細見 ERD 設計與資料庫正規化。
流程圖（Flowchart） AS-IS（現況流程）和 TO-BE（未來流程）。ISO 5807 是標準，但大多數人畫的是非標準的白板版本。
設計階段
SDD（System Design Document） 系統架構、模組切分、技術選型。現代替代方案：ADR（Architecture Decision Record），用短篇決策記錄取代長篇設計文件。
資料庫設計文件 Table Schema、Index 設計、關聯、命名規則。現代工具直接用 DBML 或 Prisma Schema 取代 Word 文件。
API Specification 端點、參數、回傳格式。2015 年後大多改用 Swagger/OpenAPI YAML。見 OpenAPI 規格範本。
Sequence Diagram 跨系統、跨服務的呼叫順序。UML 標準的一部分，也是現代微服務架構裡最常用的設計圖。見 Sequence Diagram 實戰範本。
測試與上線階段
Test Plan / Test Case 測試範圍、策略、具體步驟和預期結果。見 Test Case 寫作指南。
Deployment Document / Operation Manual 部署步驟、環境設定、rollback 計畫、操作說明。現代用 Runbook 取代，通常放在 wiki 或 Notion。
哪些在現代開發裡還有價值
SA/SD 文件存在的三個前提，在現代開發環境裡有些已經改變：
| 原始前提 | 現代情況 | 影響 |
|---|---|---|
| 需求變更代價高 | Agile 接受需求會變 | 不需要在寫程式前把所有需求鎖死 |
| 開發者不懂業務 | Senior Engineer 普遍具備業務理解 | 翻譯角色不再那麼必要 |
| 文件是驗收依據 | Working software 才是驗收依據 | 文件回到輔助角色 |
還有明確價值的：
- FRD / 功能規格：避免需求理解偏差，特別是跨團隊溝通時
- ERD：資料庫設計的必要工具，資料模型錯了全部都要改
- Sequence Diagram：微服務架構裡的標準溝通語言
- API Spec（OpenAPI）：前後端契約，可自動生成 SDK 和 mock
可以輕量化或省略的：
- SRS → 用 FRD + 效能需求備忘錄取代
- BRD → PR/FAQ（Amazon 格式）或 1-pager 足夠
- Flowchart → 短會議 + 白板照片對多數場景足夠
- Operation Manual → Runbook + Slack 記錄
現代替代方案對照
| 傳統產出 | 現代替代 |
|---|---|
| Word API Spec | OpenAPI YAML（Swagger） |
| Visio ERD | dbdiagram.io / Mermaid ER |
| Word SDD | ADR（Architecture Decision Record） |
| Use Case Document | User Story + Acceptance Criteria |
| Test Case Document | BDD Gherkin（Cucumber 格式） |
實戰建議
如果你在傳統 SI 或大型企業 IT 工作，文件要求是合約規定，無法省略。這時候重點是：做最小夠用的版本，不要把文件當目的本身。
如果你在 Agile 團隊，選擇性地借用 SA 文件的思維：
- 功能複雜的需求 → 寫 FRD（即使格式簡化）
- 跨服務設計 → 畫 Sequence Diagram
- 資料模型設計 → 一定畫 ERD
- 技術決策 → 寫 ADR