外觀
2026-07-13 資訊系統建置、需求分析與風險管理
📡 實習單位：內政部警政署刑事警察局 通訊監察科｜通訊監察科階段第一週。
本篇聚焦需求分析、風險管理與資訊安全的通用方法；特定機關的內部配置、帳號、資料與未經確認的業務細節均不納入公開內容。
今天先記住的四件事
使用者說出口的是「要求」，未必是系統該解決的問題。單位之間打架時，我後來會把業務效益、權限風險、資源與可行性攤開來比，而不是看誰講話大聲。「接受風險」是一個要留下理由、核准人和檢討時間的決定，不是把問題擱著。系統這邊我也重排了順序：算得對只是最低標，資料守不守得住、能不能在業務要的時間內吐出結果，一樣算在「可用」裡。
示意：把需求釐清、把殘餘風險管起來。此圖僅為概念示意，不代表任何實際系統或作業流程。
一、我先改掉「收到需求就列功能」的想法
使用者說出口的功能，常常只是他想到的解法，不等於需求。一開始就問「要做哪些按鈕、哪些欄位」，很容易在問題還沒清楚前把方案定死。
我後來會把順序倒過來：先確認誰會用、現行作業卡在哪、想改善什麼、改動後會影響誰，再檢查法規、權限、資料安全、技術與資源允不允許。
先問「為什麼需要」，再問「要做什麼」。
用「所有人都能查完整資料」來拆需求
假設使用者說希望所有人都能直接查完整資料。表面上是權限需求，真正的困擾也可能是申請流程太慢、耽誤工作。全面開放固然省掉等待，卻放大個資、權限與外洩風險。
路不只一條：縮短核准流程、依職務分級授權、替緊急案件開快速授權，再把查詢與下載紀錄留著。要解的是「等太久」，我不希望代價是整批資料曝險——使用者的話沒被否定，只是翻成另一種做法。
這段對我最有畫面。寫程式時我也常被「加個開關就好」帶著走，等那個開關長成沒人敢動的分支才發現，當初該問的是為什麼需要它。需求跟程式碼一樣，接住症狀就會越補越亂。
需求取捨要能說明理由
需求衝突很正常，我目前從四個方向比較：
- 業務效益：是否真的改善核心流程或處理時效？
- 權限與法遵：是否擴大資料可見範圍，或增加個資與稽核風險？
- 資源與可行性：人力、預算、資料品質與技術條件是否足夠？
- 替代方案：有沒有侵害較小、成本較低或更容易維護的作法？
這四項不會自動給答案，但至少讓「為什麼先做、為什麼不做」留下依據。
二、風險的四種處理方式
風險不可能歸零。評估機率與影響之後，處理方式大致就四種。避免是不進行風險過高或缺乏依據的活動，例如取消沒有法律依據的資料蒐集功能；降低是加入控制措施，把發生機率或損害壓下來，像身分驗證、分級權限、備份與操作紀錄都算。
移轉是以保險或契約分擔部分損失與責任，例如投保，或在契約中釐清廠商責任；接受則是評估後承擔剩餘風險並持續列管，用在影響低、機率低，且改善成本明顯過高的風險上。我自己的第一反應多半是降低，加驗證、加日誌、加權限，但那也是成本最容易被低估的一種。
我原本容易把「接受風險」聽成「先不處理」。差別很清楚：接受要知道自己接受了什麼、控制夠不夠、誰核准、何時重看；忽略則沒做完這些判斷。
所以風險管理停不在填完一張表。系統上線後權限使用、異常紀錄與業務條件都會變，原本合理的決定也要再檢討一次。
三、資料正確之外還要顧什麼
資訊安全這段讓我把「正確」拆成兩層。
- 完整性關心資料是否正確、完整，且沒有被未授權地新增、刪除或修改。帳號異動、案件內容修改與系統日誌都應留下可追溯紀錄。
- 可用性關心經授權的人員能否在需要時正常使用系統與資料。
- 效能與即時性關心系統能否在業務要求的時間內完成處理。結果就算正確，回應太慢錯過時機，一樣沒有價值。
機密性補的是最後一塊：哪些人因職務需要，可以看見、下載或處理這些資料。三者是底線，效能與即時性再決定這套系統對業務有沒有用。這些我想在需求還在紙上時就問完，等系統做完再加防護只補得到外圍。
從系統設計看，它們會互相拉扯：權限切得越細，查詢路徑越繞；日誌留得越完整，儲存和寫入成本越高。與其說是四個目標，不如說是四條要一起調的旋鈕，而預算通常只夠調兩條——先調哪兩條是治理決定，不是技術決定。
四、我對系統承辦人角色的新理解
承辦人夾在業務、技術、資安與管理中間做翻譯：一邊把模糊的抱怨整理成能做的需求，一邊把技術限制、維運成本和剩餘風險講回去給業務單位聽懂。轉交需求給廠商只是最表面的一層。
難的是追問：這功能到底解決什麼問題？不做會怎樣？做了多出哪些權限和維運責任？這三句不好問，問了通常會拖慢進度。
這一天的分層結構
從使用者說出口的那句話，一路疊到「算不算可用」的標準：
text
第 0 層 使用者說出口的要求
問什麼：他要的是哪個功能、哪些欄位、哪個按鈕
產出：一句原話，形式像規格，內容多半是他想到的解法
↓ 解法不等於問題，先問為什麼需要
第 1 層 問題定義與影響範圍
問什麼：誰會用、現行作業卡在哪、想改善什麼、改動後影響誰
產出：翻成問題的敘述、關係人清單、法規權限與資源的限制條件
↓ 問題講清楚了，需求開始互相打架
第 2 層 需求取捨
問什麼：這條需求換得到什麼、擴大了誰的可見範圍、有沒有更小的做法
產出：四個方向的比較結果，以及先做與不做的書面依據
↓ 選定做法，剩下的風險還在
第 3 層 風險處理
問什麼：這個風險要避免、降低、移轉，還是接受
產出：處理方式的選擇，加上理由、核准人、重新檢討的時間
↓ 東西做出來了，怎麼算「可用」
第 4 層 完整性與可用性
問什麼：資料守不守得住、授權的人拿不拿得到、來不來得及
產出：可追溯的異動紀錄、權限與日誌設計、業務要求的回應時間門檻
圖示對應上方五層，只是概念示意，不代表任何實際系統或作業流程。
**重點：**這一天從使用者說出口的那句話，疊到「算不算可用」。第 0 層要把原話當原話收著，別把「要求」直接當「需求」；第 1 層把要求翻回問題，問誰會用、卡在哪、改動後影響誰；第 2 層用業務效益、權限法遵、資源可行性、替代方案四個方向讓砍掉的需求留下依據；第 3 層認清「接受」是要講出核准人與重看時間的決定，不是把問題擱著。最明顯的拉扯是第 3 層壓在第 4 層：降低風險的直覺是加驗證、加日誌、加權限，可是權限越細查詢越繞、日誌越完整成本越高，把可用性與即時性吃掉。四條旋鈕的預算通常只夠調兩條，先調哪兩條是治理決定；我會先把核准人與重看時間定下來，再談控制加到多密。
往下追問：「接受風險」的核准人與重看時間，實務上由誰定，為什麼常常沒人定？四條旋鈕先調哪兩條該由業務端還是技術端拍板，會在哪一刻發現調錯了？
我的反思
《資通安全管理法》第 3 條 把機密性、完整性與可用性寫成定義，我原本以為只是名詞解釋。把需求分析走一遍才發現這三個詞更像驗收清單：功能一旦開出去，最後都會落成某個人的權限、某份資料的保存、某個人的維運責任。功能清單留不住這些。
第 13 條 要求公務機關訂資通安全維護計畫。照那四項比較回想一遍，最難填的是「剩餘風險由誰承擔」。技術上誰負責很清楚，但業務單位願意接受到什麼程度、多久重看一次，我還沒想清楚該由誰定，也不確定實務上真的有人在定。
要把今天留下來，我想記五件事：問題怎麼被定義、哪些需求被砍掉、依據是什麼、剩餘風險誰扛、什麼時候重新評估。不用長，但比一句「使用者需要」更能解釋一套系統為什麼長成這樣。
本日對應主題
- 通訊保障與資料治理：把需求與風險放回資料、程序及治理的完整控制鏈。
- 警政資訊系統與資安概念：接續系統治理、韌性與委外管理觀念。
法規與官方來源
- 法規與官方來源索引：回查資通安全治理與資料保護的官方依據。