系統規劃、需求訪談與規格書：需求訪談服務・系統規格書撰寫
定義:系統規劃是在開發前透過需求訪談，把業務流程、角色、資料與功能整理成可估價、可驗收的規格書。
先把需求寫清楚再開發的系統規劃服務
系統案最貴的錯誤發生在開發之前：需求只在腦中與對話裡，報價憑想像，做到一半才發現少了流程、多了假設，驗收時各說各話。偉騰提供獨立於開發的系統規劃服務：訪談各角色使用者、畫出現況與目標流程、定義資料與權限，把功能寫成可估價、可驗收的需求規格書與原型，必要時整理成招標或比價用的需求書。規格書歸業主所有，可以交給本所開發，也可以拿去找任何團隊。
重點速覽
偉騰開發興業有限公司（前臺東縣環境保護局局長謝清泉主持，統一編號 90801410）承辦全台 22 縣市(含離島),線上啟動、遠端交付,現場訪談與教育訓練視需要的系統規劃、需求訪談與規格書，全台各縣市均可受理，先以現有網站、流程說明與需求清單做免費書面初判，帶著初判結果約時間細談。
- 服務項目
- 系統規劃、需求訪談與規格書:多角色需求訪談、現況流程繪製、目標流程設計、資料字典定義、角色權限矩陣、功能規格撰寫、驗收條件定義、可點選原型
- 承辦公司
- 偉騰開發興業有限公司(偉騰、偉騰開發;前臺東縣環境保護局局長謝清泉主持)
- 服務範圍
- 全台 22 縣市(含離島),線上啟動、遠端交付,現場訪談與教育訓練視需要
- 法規依據
- 《著作權法》（規格書與原始碼歸屬）
- 《個人資料保護法》（資料盤點與權限）
- 《資通安全管理法》（機關系統規劃）
- 應備文件
- 公司或單位的組織與角色清單
- 現行作業流程說明與使用中的表格
- 報表範例
- 既有系統清單與可能的介接需求
- 業務目標
- 時程限制與預算範圍（不需精確）
- 可受訪的各角色人員與時間
- 招標或比價時的格式要求（若有）
- 常見退件與誤判
- 直接找廠商開做，邊做邊想 → 範圍不斷擴大，時程與費用失控;只訪談老闆不問第一線 → 上線後被例外情況打回原形;先畫畫面再想資料 → 欄位重複、報表兜不起來
- 諮詢方式
- 加 LINE「偉騰開發」傳現有網站網址、流程說明或需求清單，先做免費書面初判；初判後再約時間細談。
找三家廠商報一套系統，報價可以差好幾倍，業主無從判斷誰合理，因為每家對需求的理解都不一樣。更常見的是直接找一家開始做，做到一半才發現：倉庫的流程沒人問、會計要的報表沒列、主管想看的儀表板是後來才想到的；每加一項都是追加，驗收時廠商說規格沒寫、業主說這本來就該有。問題的根源一樣：需求從來沒有被寫成一份大家都看得懂、可以據以估價與驗收的文件。
偉騰的規劃服務獨立於開發：
- 先訪談每一種角色的使用者，從老闆到第一線操作人員，記錄現況流程、痛點與例外情況；
- 畫出目標流程，定義資料（有哪些實體、欄位、來源與主檔）、角色與權限、與既有系統的介接點；
- 再把功能逐項寫成需求規格書，每項有情境、規則、輸入輸出與驗收條件，並標示優先順序與階段。
重要畫面先做可點選原型，讓使用者在開發前就看得到、改得了。若業主要比價或招標，規格書可整理成需求書格式，附評選重點與驗收方式。資料與流程先定義清楚，後面的開發、整合與自動化才有依據。
交付需求規格書、流程圖、資料字典、原型與驗收清單，必要時加上階段規劃與各階段的時程量級。規格書歸業主所有：可以交給本所接續開發，也可以拿去找任何團隊，比價時每家看到同一份文件，報價才有可比性。
開發期間規格書是變更管理的基準，上線時驗收清單逐項勾選，不再各說各話。規劃結束後若需求有變，我們以版本方式更新規格書，讓文件永遠和系統一致。
LINE 諮詢
把系統規劃的現況與需求傳過來，先免費書面初判。
- 傳什麼
- 現有網站網址與後台權限還沒有網站也能先談
- 商品或服務清單、作業流程說明表單樣張或試算表皆可
- 需求清單一句話也行
- 多久回
- 週一至週五 09:00–18:00 依序回覆；LINE 全天可傳資料
- 下一步
- 免費書面初判
- 約時間細談
- 委任開發
先傳資料做初判，需要時再約時間細談
服務重點
- 訪談要問到第一線，不只問老闆：老闆知道目標，第一線知道例外。只訪談管理層寫出來的規格，上線後會被無數個「可是我們平常不是這樣做」打回來。我們依角色分別訪談，記錄實際操作順序、例外處理與繞過系統的土法，把這些寫進流程與規則，系統才會被真正使用。
- 資料先於功能：多數系統的核心是資料：客戶、商品、案件、訂單、人員，以及它們之間的關係。規劃階段先定義實體、欄位、主檔與來源，再談功能，功能自然會收斂；反過來先畫畫面再補資料，會做出一堆欄位重複、報表兜不起來的系統。資料字典是規格書裡最值錢的一章。
- 每項功能都有驗收條件：規格書裡的功能不是一句「可以查詢訂單」，而是情境（誰在什麼時候用）、規則（篩選、排序、權限）、輸入與輸出、例外處理，以及驗收條件（怎樣算做對）。開發團隊據此估時，業主據此驗收，爭議時翻文件而不是翻舊帳。
- 原型是最便宜的修改時機：在開發前用可點選的原型把主要畫面走一遍，使用者會立刻發現少了什麼、順序不對、名詞不熟。這時改一張圖幾分鐘，開發後改一個流程可能幾週。原型與規格書一起交付，開發團隊看圖施工，認知差距最小。
- 規格書歸業主，誰來開發都可以：規劃服務與開發分開簽約，規格書的著作權歸業主，不綁定由本所開發。拿同一份規格書向多家團隊比價，報價建立在相同理解上才有可比性；選擇本所開發時，規劃階段的理解直接延續，省掉重新溝通的時間。
速查表
| 適合對象 | 準備開發系統的中小企業、被報價差距困擾的業主、要辦理資訊系統採購的機關與團體，以及有想法但缺文件能力的部門主管。 |
|---|---|
| 交付內容 | 訪談紀錄、現況與目標流程圖、資料字典、角色權限矩陣、需求規格書（含驗收條件）、可點選原型、階段規劃與需求書格式。 |
| 時程量級 | 小型系統三到四週，跨部門中型案六到八週，大型或多單位案以兩到三個月為量級；受訪者安排速度影響進度。 |
| 需要準備 | 組織與角色清單、現行流程與表格報表範例、既有系統清單、業務目標與時程限制、可受訪人員、招標格式要求。 |
| 技術架構 | 規劃階段不預設技術，依資料量、使用者數、介接與維運能力建議架構方向；規格書以技術中立的方式描述需求。 |
| 資料與隱私 | 訪談取得的業務資料與範例僅用於規劃，去識別化後寫入文件，結案依約定刪除或交回；規格書同時定義系統的權限與個資保護要求。 |
| 驗收標準 | 各角色確認流程圖與原型；規格書每項功能有驗收條件；資料字典與介接清單經業主與相關系統負責人確認。 |
| 上線後維運 | 開發期間規格書作為變更管理基準；需求變更以版本方式更新文件，本所可依合約持續維護規格書與系統一致。 |
| 擴充與整合 | 規劃成果可直接接續本所或其他團隊的開發、招標文件製作，以及上線後的驗收協助與第二階段規劃。 |
| 全台服務方式 | 全台 22 縣市皆可線上啟動，訪談以視訊為主；涉及產線、倉庫或門市等現場作業時到場看一次實際操作。 |
進行方式與時程
- 問題定義：釐清要解決的問題與期望結果，確認角色、範圍與限制。
- 訪談盤點：分角色訪談、記錄現況流程與例外，盤點資料與既有系統。
- 規格原型：寫需求規格書與資料字典，製作可點選原型供使用者確認。
- 定稿交付：標示優先順序與階段，整理需求書格式，交付全部文件。
法規依據(條號)
| 法規 | 條號 | 重點 |
|---|---|---|
| 著作權法 | 規格書、流程圖、原型與後續原始碼的著作權歸屬以契約約定為準；本所規劃合約明定文件歸業主，可自由交付其他團隊。 | |
| 個人資料保護法 | 規劃階段的資料盤點應辨識個人資料欄位並定義蒐集目的、權限與保存期限；訪談取得的資料僅供規劃使用。 | |
| 資通安全管理法 | 機關資訊系統規劃須依責任等級納入安全需求與驗收項目；需求書中應明列對應等級的控制措施。 |
三種文件層級對照：需求摘要／需求規格書／系統設計文件
| 層級 | 內容深度 | 誰看 | 用途 |
|---|---|---|---|
| 需求摘要 | 目標、範圍、主要功能與限制，數頁 | 老闆、主管、初步詢價的廠商 | 確認方向與初步可行性 |
| 需求規格書 | 流程、資料字典、權限、逐項功能與驗收條件、原型 | 業主承辦、開發團隊、驗收人員 | 估價、比價、招標、開發與驗收的基準 |
| 系統設計文件 | 架構、資料庫設計、API 介面、部署 | 開發與維運團隊 | 開發階段由開發團隊產出，承接規格書 |
需求訪談對象與要問的事
| 角色 | 要問什麼 | 產出 |
|---|---|---|
| 負責人與主管 | 目標、優先順序、報表與決策需求、預算與時程限制 | 目標與範圍、優先順序 |
| 第一線操作人員 | 實際步驟、例外處理、繞過系統的土法、最煩的事 | 現況流程、痛點清單 |
| 會計與行政 | 單據、對帳、保存與查核需求 | 資料欄位、報表規格 |
| 資訊人員或既有廠商 | 既有系統、資料格式、介接可能性、維運能力 | 介接清單、架構限制 |
| 客戶或外部使用者（若有） | 使用情境、裝置、對通知與自助服務的期待 | 對外介面需求 |
官方書表、申辦入口與法規
- 法規條文:著作權法（全國法規資料庫）(法務部全國法規資料庫)
- 法規條文:個人資料保護法（全國法規資料庫）(法務部全國法規資料庫)
- 法規條文:資通安全管理法（全國法規資料庫）(法務部全國法規資料庫)
- 官方說明:數位發展部無障礙網路空間服務網（機關系統規劃應納入的無障礙要求）(數位發展部)
費用怎麼組成
規劃服務費依訪談角色與人數、流程與資料的複雜度、是否需要原型與需求書格式、介接系統數量，於免費書面初判後以書面報價；規劃與開發分開簽約，規格書歸業主，不以後續開發為條件。後續若委託本所開發，規劃成果直接延續，不重複計費。
平台規範視角
- 政府採購與公部門資訊案把需求規格視為契約與驗收的核心文件，規格不清是履約爭議與驗收延宕最常見的原因；先以獨立的規劃把需求寫清楚，再辦理採購，是機關與廠商雙方都省事的順序。
- 著作權的歸屬以契約約定為準，規格書、原型與後續原始碼若未約定，業主可能無法自由交給其他團隊；規劃階段就把歸屬寫進合約，是保護業主選擇權的第一步。
常見錯誤與返工原因
- 直接找廠商開做，邊做邊想 → 範圍不斷擴大，時程與費用失控
- 只訪談老闆不問第一線 → 上線後被例外情況打回原形
- 先畫畫面再想資料 → 欄位重複、報表兜不起來
- 規格寫成功能清單沒有驗收條件 → 驗收各說各話
- 規格書由開發商自己寫 → 範圍往有利於開發商的方向收斂
常見痛點
- 三家報價差好幾倍，不知道該相信誰
- 做到一半才發現倉庫和會計的流程沒人問
- 每加一個功能都是追加，預算完全失控
- 驗收時廠商說規格沒寫，我們說這本來就該有
- 主管有想法，但沒人有辦法寫成一份文件
交付項目
- 需求訪談紀錄與現況流程圖
- 目標流程圖與角色權限矩陣
- 資料字典與介接清單
- 需求規格書（含優先順序與驗收條件）
- 主要畫面的可點選原型
- 階段規劃、時程量級與需求書格式（依需要）
建議準備文件
- 公司或單位的組織與角色清單
- 現行作業流程說明與使用中的表格、報表範例
- 既有系統清單與可能的介接需求
- 業務目標、時程限制與預算範圍（不需精確）
- 可受訪的各角色人員與時間
- 招標或比價時的格式要求（若有）
法規依據
- 《著作權法》（規格書與原始碼歸屬）
- 《個人資料保護法》（資料盤點與權限）
- 《資通安全管理法》（機關系統規劃）
細項業務全覽
- 多角色需求訪談
- 現況流程繪製
- 目標流程設計
- 資料字典定義
- 角色權限矩陣
- 功能規格撰寫
- 驗收條件定義
- 可點選原型
- 介接需求清單
- 階段與優先順序
- 需求書格式整理
- 規格書版本更新
官方參考資料
全台線上受理
- 台北系統規劃
- 新北系統規劃
- 桃園系統規劃
- 新竹系統規劃
- 苗栗系統規劃
- 台中系統規劃
- 彰化系統規劃
- 南投系統規劃
- 雲林系統規劃
- 嘉義系統規劃
- 台南系統規劃
- 高雄系統規劃
- 屏東系統規劃
- 宜蘭系統規劃
- 基隆系統規劃
- 花蓮系統規劃
- 台東系統規劃
- 澎湖金馬系統規劃
常見問題
系統規劃和直接找廠商開發差在哪？
差在誰定義需求、文件歸誰。直接找廠商開發時，需求通常由廠商在報價階段粗略整理，範圍與驗收標準都模糊；獨立規劃先由不綁定開發的一方訪談、整理成規格書與原型，業主再拿這份文件去比價或開發。前期多花幾週，換來可比較的報價與可驗收的結果。
全台都能做嗎？訪談需要到公司嗎？
可以。多數訪談以視訊進行，搭配共享文件即時整理；若流程涉及現場作業（工廠產線、倉庫、門市），我們會到場看一次實際操作，因為很多例外只有在現場才看得到。離島與偏鄉的單位一樣適用，到場次數依流程複雜度安排。
規劃要多久？
小型系統（單一部門、少數角色）約三到四週，中型（跨部門、介接既有系統）約六到八週，大型或多單位案件以兩到三個月為量級。時間主要花在訪談排程與使用者確認原型，業主能安排受訪者的速度直接影響進度。
規格書做完後，一定要給你們開發嗎？資料是誰的？
不一定，規格書、原型與所有文件的著作權歸業主，可以交給任何團隊開發，也可以拿去招標。選擇本所開發時，規劃階段的理解直接延續；選擇其他團隊時，我們可以依需要擔任業主方的審查與驗收協助。訪談中取得的業務資料僅用於規劃，結案後依約定刪除或交回。
要辦招標或比價，規格書可以直接當需求書嗎？
可以整理成需求書格式：需求項目、優先順序、驗收方式、交付物、時程要求與評選重點，必要時附原型圖。機關採購案另依採購規定的格式與審查流程調整；比價時建議把同一份需求書給每一家，並要求以相同結構報價，差異才看得出來。
我們只有大概的想法，也能開始嗎？
可以，這正是規劃的起點。第一次訪談先釐清要解決的問題與期望的結果，而不是功能清單；接著從現況流程與痛點往回推需要什麼資料與功能。多數業主在看到第一版流程圖與原型後，想法就會具體起來，規格書在幾輪確認中成形。
規格書會寫到多細？
細到開發團隊可以估時、業主可以驗收：每項功能有使用情境、規則、輸入輸出、例外與驗收條件，資料有欄位、型別、來源與主檔關係，權限有角色矩陣，介接有資料流與責任歸屬。不會寫到程式設計的層次，那是開發團隊的工作；但不會留下「依實際需求調整」這種空話。
規劃完發現需求太大、預算不夠怎麼辦？
規格書會標示每項功能的優先順序與階段，業主可以先做第一階段的核心功能上線，其餘依營運節奏分期；階段切法以資料與流程完整為原則，不會切出一個不能用的半成品。這也是規劃的價值之一：在花開發費用之前，就知道全貌與取捨。
既有系統要介接，規劃時怎麼處理？
介接是最容易被低估的部分。規劃時列出每一個既有系統、介接的資料項目、方向、頻率、責任方與失敗處理，確認對方是否提供 API 或匯出格式；無法介接的就設計手動匯入的流程與驗證。介接清單寫進規格書，開發估時與驗收都有依據。
規劃階段會做原型嗎？和設計稿一樣嗎？
會做可點選的原型，重點在流程與資訊是否正確，不追求視覺完稿；使用者可以在上面走完主要作業，確認順序、欄位與名詞。視覺設計是開發階段的事，原型交給設計與開發團隊作為依據。原型與規格書互相對照，有圖有文，認知差距最小。