系統設計在決定什麼？委外開發業主要參與的五個決定與設計文件

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

委外做系統的報價單或時程表上，常常有一行寫著「系統分析與設計」，後面排了好幾週。這段時間看不到畫面，也看不到功能。很多業主都會冒出同一個問題：這幾週到底在做什麼？能不能跳過，直接開始寫？

先講答案：系統設計不是畫圖，也不是寫一本沒人看的文件，它是在做一連串「之後很難改」的決定。 這些決定裡，有幾個只有出錢的人答得出來。你不在場，工程師就只能替你猜。

這篇寫給要委外開發系統的企業主和專案窗口。如果你是在準備工程師面試的 System Design，那是同一個詞的另一種用法，這篇幫不上忙。

系統設計是「決定怎麼做」的階段：排在需求確認之後、寫程式之前

一句話定義：系統設計是把已經確認的需求，變成「這套系統要怎麼蓋」的階段——切成哪幾塊、資料放在哪裡、每一塊之間怎麼傳資料、出問題時怎麼處理。

拿開餐廳來比。你想賣什麼、客人是誰、一天要出幾份餐，這是需求。廚房放前面還是後面、冰箱要幾台、出餐口朝哪一邊，這是設計。師傅進場施工，才是開發。

實務上，設計通常分兩層。先做架構設計，決定系統切成哪幾大塊、彼此怎麼連；再做細部設計，把每一塊裡面的資料欄位、介面格式、處理步驟寫清楚。業主要參與的決定，幾乎都落在架構設計這一層。

放回整條開發流程，順序大致是：需求、系統分析、系統設計、開發、測試、上線。六個階段各自在做什麼，可以讀系統開發生命週期那一篇。這裡只打開「設計」這一格。

系統設計跟系統分析、系統架構圖、規格書差在哪

這四個詞常被混著講，開會時各說各話。先分開：

• 規格書：你要達成什麼、做到什麼程度算完成
• 系統分析：把現在的流程、資料、角色弄清楚
• 系統設計：決定怎麼做，以及選了這個就放棄什麼
• 系統架構圖：把設計的結果畫出來給人看

報價單上的「SA／SD」，就是系統分析（System Analysis）加系統設計（System Design）：分析是把問題弄清楚，設計是決定解法。

要留意的是，有架構圖不等於做過系統設計。 圖只是設計的一種表達方式，一張畫得很漂亮的圖，可能沒有回答任何一個取捨。圖有哪些種類、怎麼看，系統架構圖那一篇有完整說明。

規格書是你的話，設計是對那些話的回答。 規格寫「兩間分店的庫存要同步」，設計要回答的是：多久同步一次、以哪一邊為準、斷線的時候怎麼辦。

系統設計真正在做的事：先定「之後很難改」的那幾個決定

談軟體架構的人，很愛引用 Ralph Johnson 的一個講法。Martin Fowler 的軟體架構指南轉述過：架構就是「你希望在專案早期就做對的那些決定」。

哪些決定算這一種？微軟的架構文件在談架構決策紀錄時給了一個可以操作的標準：只需要記錄會影響系統結構、關鍵品質，或是難以反悔的選擇。

回到餐廳。店開在哪一條街、廚房的瓦斯和排煙走哪裡，開張之後要改，等於重新裝潢一次。菜單、桌椅怎麼擺、牆面什麼顏色，下個月想換就換。

系統也一樣。有一個不用懂技術就能用的判斷法：

問一句「這個決定之後要改，會不會動到已經存進去的資料，或是動到別的系統？」會，就是難改的，設計階段要定下來；不會，就先不用追求一次到位。

之後很難改（設計階段要定）	之後好改（不必一開始就完美）
客戶、訂單這類資料存成什麼結構、以哪裡為準	畫面的配色與版面
跟會計、金流、ERP 怎麼對接	欄位顯示的名稱、報表格式
多間分店或多個品牌共用一套，還是各一套	通知信和簡訊的文案
帳號權限分幾層、誰看得到誰的資料	列表預設的排序方式

委外專案最常見的兩種浪費，剛好是這張表的兩邊：左邊的事沒有人做決定，右邊的事卻開了三次會。

設計階段的目標不是一次全部做對，而是難改的先想清楚，其餘的保持好改。

系統設計階段業主要參與的五個決定

我最常聽到客戶說的一句話是：「我知道我需要一個系統，但我說不清楚要做什麼。」需求說不清楚沒有關係，那本來就要一起拆。下面這五題不一樣。這五個決定表面上是技術問題，答案卻在你的公司裡，不在工程師的腦袋裡。

決定一：每一種資料的正本放在哪裡、往哪裡流

同一位客戶的電話，業務的 Excel 有一份，會計系統有一份，LINE 官方帳號的後台又有一份。客戶換了號碼，哪一份算數？

這就是「正本」的問題。每一種重要資料，都要指定一個地方當正本，其他地方只能來抄，不能自己改。就像餐廳的訂位只記在一本簿子上，櫃檯和外場看的是同一本。

假設有一家做團購的公司，訂單從官網、LINE 和電話三個地方進來，庫存記在倉庫的 Excel。設計階段要回答的是：三個來源的訂單最後匯到哪裡？庫存以倉庫那份為準，還是以系統為準？

這些問題工程師答不出來，因為它們問的其實是：哪個部門對哪一份資料負責、誰可以改、改了之後要通知誰。 這是公司的分工，不是程式的寫法。有一個簡單的檢查：同一份資料如果有兩個地方都可以改，遲早會對不起來。

正本和流向定好之後，才輪到資料表怎麼拆、欄位怎麼設計，那一層的細節可以看資料庫設計怎麼做才不會後患無窮。

決定二：功能切成哪幾個模組，邊界跟哪個部門對齊

模組就是把系統切成幾個各管各的區塊。餐廳有廚房、外場、櫃檯，各做各的事，只在出餐口和結帳台交接。交接的地方越少、越清楚，出錯就越好找。

有一條很有名的觀察，叫康威定律。Melvin Conway 在 1968 年提出：一個組織設計出來的系統，結構會長得像這個組織自己的溝通結構。

翻成業主的話：系統的模組邊界，最後多半會長得跟你公司的部門邊界一樣。 業務部和倉管部之間，誰負責出貨通知講不清楚，系統裡訂單模組和庫存模組的交接也會講不清楚。

這一題你要回答的是：哪些事一定是同一批人在處理，可以綁在一起？哪些事之後可能交給別的部門或換別家廠商，要先切開？至於中小企業的第一版系統，通常先在一套系統裡把模組分清楚就夠，不必一開始就拆成好幾套。

決定三：系統要撐到多大，哪些現在做、哪些只留接口

這一題有兩種常見的錯。一種是做太小，半年後要加一間分店，發現整個帳號結構要重來。另一種是做太大，為了想像中的十萬會員，先付了一大筆現在用不到的錢。

第二種錯，Martin Fowler 介紹的 Yagni 原則（You Aren’t Gonna Need It，你用不到的）講得很清楚：推測未來才需要的能力，不要現在就做，因為預先做的功能除了要花錢做，還會拖慢其他功能、增加維護負擔，猜錯了還得回頭修。同一篇文章也講了例外：這條原則不適用在「讓軟體容易修改」的投入上。

這就是「留接口」和「先做好」的差別。假設你現在只有一間店，一兩年內很可能開第二間。先做好，是現在就把多分店的報表、調貨、權限全部做完。留接口，是資料結構裡先有「分店」這個欄位，功能等真的開店再做。前者是在為猜測付錢，後者是在為不重做付錢。

你要帶去會議的答案是：未來一到兩年，最可能發生的三件事是什麼？這三件事，就是該留接口的地方。

決定四：跟既有系統怎麼對接，對方出問題時怎麼辦

很少有系統是孤零零一套。它要接金流、物流、電子發票、LINE，還可能要接公司用了十年的會計系統。這類對接多半透過 API，API 是什麼、串接有哪些風險可以先看那一篇。

每一個對接點，設計階段都要講定四件事：誰主動找誰要資料、多久同步一次、對方沒回應或重複送來時怎麼處理、兩邊數字對不起來時以誰為準。

AWS 的可靠性指引談到對接的系統出問題時該怎麼辦，特別寫了一句：這既是技術討論，也是業務討論。它舉的例子是，電商首頁同時顯示推薦商品、熱門排行和訂單狀態，其中一個來源掛了，其他部分照樣顯示，比整頁出錯好；處理付款的系統則可能相反，寧可暫時不能用，也要先顧帳對得起來。

系統遇到異常時要怎麼反應，是設計階段就要定下來的，不是出事了才臨場決定。

你要回答的有兩類。一類是業務上的輕重：哪些流程斷線時可以晚一點再補，哪些一秒都不能等。 月報表晚一小時沒有人會發現，刷卡付款卡住十秒客人就走了。另一類是現實條件：既有系統的廠商願不願意開介面讓別人接、要不要另外收費。這些事工程師查不到，只有你問得到。

決定五：可靠、速度、成本、安全互相衝突時先顧哪一個

「又快、又穩、又便宜、又安全」每一份需求都會寫，但這四件事會互相打架。

微軟的架構框架替每一項系統品質都寫了一頁「權衡」。以可靠性的權衡為例：想要更穩，就要多備幾份；備份越多，花的錢越多，要保護的地方也越多，維運越複雜，資料寫入還會慢一點。

Google 的網站可靠性工程團隊講得更直白，在 SRE 一書談風險的章節裡寫道：百分之百多半不是對的可靠性目標；使用者通常分不出「很穩」和「極度穩」的差別；可靠性每往上一級，成本不是等比例增加，下一級可能是前一級的一百倍。

算一筆帳就有感覺。一年有 8,760 個小時。可用性（系統正常可用的時間比例）99.9%，代表一年最多可以停大約 8.8 小時；99.99%，一年只能停大約 53 分鐘。

多那一個 9，對內部請假系統來說，可能是多花一大筆錢去買沒有人感覺得到的 8 小時；對線上收款來說，可能就值得。

這個判斷只有業主做得出來，所以你要回答三個問題：系統停一小時會損失什麼？資料最多可以掉多久，是昨天的，還是五分鐘前的？哪些資料外流會出大事？答案出來之後，記得寫進規格的非功能性需求，也就是「要做得多好」的那一半，才驗收得到。

至於用哪一種程式語言、哪一套框架、哪個牌子的資料庫，可以放心交給工程團隊。你只要確認兩件事：選擇的理由有沒有寫下來，以及換一個團隊接不接得起來。

系統設計階段會留下哪些文件：設計文件、架構圖與決策紀錄

設計做完，不該只留在工程師的腦袋裡。常見的交付文件有五種：系統設計文件、系統架構圖、資料結構說明、介面規格，還有架構決策紀錄。業主不必每一份都讀懂，但有兩個地方一定要看。

第一個是設計文件裡的「不做什麼」。Malte Ubl 在介紹 Google 設計文件的文章裡提到，設計文件的重點是記下做決定時考慮過的取捨，其中有一節叫「非目標」，也就是本來可以做、但明確決定不做的事。先看這一節，確認裡面沒有你以為會有的東西。

第二個是架構決策紀錄，英文縮寫 ADR。它的格式最早來自 Michael Nygard 在 2011 年的一篇文章：每個重要決定寫成一到兩頁，固定五欄，標題、背景、決定、狀態、後果。他點出的問題很真實：新加入專案的人看到一個過去的決定，如果找不到理由，只剩兩條路，盲目接受，或是盲目改掉。微軟的文件再補一點：排除掉的選項也要記。

這件事已經不只是工程師圈子裡的習慣。英國政府在 2025 年 11 月發布了架構決策紀錄框架，給公部門的技術團隊一套記錄架構決定的共同做法，欄位還多了一欄「諮詢過哪些利害關係人」。那是英國公部門的規範，不是台灣的規定，但方向很清楚：重要的技術決定要留下紀錄，而且要記下問過誰。

一頁決策紀錄大概長這樣（示意，不是真實案例）：

• 決定：訂單資料以訂單系統為正本，會計系統每天晚上同步一次
• 背景：會計系統是既有的套裝軟體，只能每天整批匯入，沒辦法即時接收
• 考慮過的選項：即時同步、每晚同步、每週人工匯出
• 後果：會計看到的是前一天的數字；之後如果要即時，需要更換會計系統或加購介面
• 問過誰：財務主管、會計系統廠商

一頁寫得好的決策紀錄，業主應該讀得懂每一個字。

系統設計沒做好，後面會付出哪些代價

設計出問題，最常見的情況不是決定錯了，而是沒有人做決定。業主以為工程師會決定，工程師寫到那裡順手選了一個，沒有人寫下來。微軟那份文件提醒，做了卻沒有記錄的決定多半會被忘掉，接著就是同一件事重複吵，或是後來的修改不知不覺違背了原本的用意。

決定錯了，至少有紀錄可以回頭檢討；沒有紀錄的決定，連要改的時候會撞到什麼都不知道。

怎麼知道設計階段是不是被跳過了？有三個訊號：時程表上沒有設計階段，或只有一行帶過；設計階段交出來的只有畫面稿；問「為什麼這樣做」，得到的回答是「通常都這樣」。三個訊號中了兩個，就值得停下來，把前面那五個決定重新問一遍。

設計沒做好的系統，通常會出現這幾種症狀：

• 改一個地方，壞三個地方。模組邊界沒有切清楚，功能互相糾纏
• 同一筆資料，兩邊對不起來。沒有指定正本，每個系統各改各的
• 不是撐不住，就是白花錢。容量和可靠性沒有討論過，全憑感覺
• 換人或換廠商就接不起來。決定都在某個人的腦袋裡

麻煩的是，這些症狀驗收那天看不出來，通常要等資料變多、功能要加、人要換的時候才浮現。設計階段省下來的時間不會消失，只會換一個比較貴的時間點出現。

台灣的公部門對這件事有正式的要求。行政院公共工程委員會在 111 年 9 月發過一份函，針對資訊服務採購常見的履約爭議，要求機關「反覆檢視需求訪談結果，確認符合需要再允許廠商進行程式開發」，並且「開發過程依各階段查核點進行查核」。這是對政府機關辦採購的要求，民間專案不適用，但做法可以直接借用：設計做完，要有一個你點頭才能往下走的關卡。

小專案與敏捷開發也需要系統設計嗎？份量跟著風險走

需要，但不是每個專案都要寫厚厚一本。

Malte Ubl 在同一篇文章裡講得很實際：要解決的問題並不模糊時，寫設計文件的價值就不大；小幅度的改動，一到三頁就夠。

判斷要做多少，可以回到前面那個判斷法：這個專案裡，有幾個難改的決定？

一頁式的活動網頁、純介紹的形象官網，幾乎沒有難改的決定，一頁清單講定就可以開工。只要碰到金流、會員資料，或是要跟其他系統對接，難改的決定就出現了，設計就不能省。

敏捷開發也一樣。每兩週交付一次，不代表不用設計，而是把設計也拆成小塊：難改的那幾個決定先定，其餘的邊做邊調。敏捷省掉的是一次把所有細節寫完，不是省掉做決定。

開系統設計會議前，業主先準備好這五組答案

把前面的內容收成一張清單。開設計會議之前照著準備，會議時間就能花在選項的代價上，而不是花在回公司問人。

• 資料正本與流向：每種重要資料由哪個部門負責、誰可以改
• 模組怎麼切：哪些事同一批人處理、哪些之後可能獨立出去
• 要撐到多大：未來一到兩年最可能發生的三件事
• 跟誰對接：既有系統清單、廠商配合度、哪些流程不能斷
• 品質怎麼排優先：停一小時的損失、資料最多可以掉多久

系統設計聽起來很技術，但走到最後，都是在回答「這家公司怎麼運作」。 工程師懂系統，你懂公司，設計階段就是把這兩邊對起來的時間。

如果你手上正好有一套系統要委外，卻不確定這五題該怎麼回答，瞻新資訊可以先陪你把需求和既有系統盤一遍，再來談怎麼設計。

常見問題