解構數位藍圖：系統分析的核心五大步驟

發表於 分類於

在我們日常生活中，從預訂一張電影票的 App，到公司內部複雜的 ERP 系統，背後都隱藏著一個共同的起點——系統分析。

可以把系統分析想像成替一座數位建築繪製藍圖的過程。如果沒有這份精準的藍圖，直接動工蓋大樓，後果將不堪設想，同樣的，沒有經過紮實的系統分析就開始寫程式，專案也很可能走向混亂與失敗。

這份「數位藍圖」究竟是如何誕生的呢？讓我們一步步揭開系統分析的神秘面紗，探索其最核心的五大步驟。

步驟一：問題識別與初步調查 (Problem Identification & Preliminary Investigation)

這是整個旅程的起點。在這個階段，我們的首要任務不是思考「解決方案」，而是深刻理解「問題」本身。

  • 目標： 確認專案的必要性與基本方向。
  • 核心活動：
    • 訪談利害關係人 (Stakeholders)： 與提出需求的客戶、未來的使用者、管理層進行溝通，了解他們遇到了什麼困難？期望達到什麼目標？
    • 定義問題： 將模糊的抱怨（例如：「我們系統好慢」）轉化為具體的、可衡量的問題（例如：「在尖峰時段，訂單處理時間超過 5 分鐘，導致客戶流失率增加 15%。」）。
    • 界定範疇 (Scope)： 畫出專案的邊界。要解決什麼？同樣重要的是，我們不解決什麼？ 明確的範疇可以防止專案無限擴大，導致失控。

這個階段就像建築師第一次與屋主會面，傾聽他們對未來「家」的夢想與需求，並勘查建地的基本狀況。

步驟二：可行性分析 (Feasibility Analysis)

當我們初步了解問題後，下一步就是評估：「這個專案，我們真的做得起來嗎？」這需要從三個關鍵角度進行理性評估：

這一步是專案的「健康檢查」，確保不是在打造一座空中樓閣。

  1. 技術可行性 (Technical Feasibility)： 以現有的技術、工具和團隊的技能，有能力開發出這個系統嗎？
  2. 經濟可行性 (Economic Feasibility)： 投入的成本（人力、時間、硬體）是否能被未來的效益（提升效率、增加營收、降低成本）所覆蓋？簡單來說，這筆投資划算嗎？
  3. 操作可行性 (Operational Feasibility)： 系統完成後，公司或使用者是否有能力、有意願去操作它？它能否順利融入現有的工作流程？

如果任何一項評估結果為「不可行」，就需要回到上一步重新思考問題的定義，或者果斷中止專案，避免更大的損失。

步驟三：需求分析與定義 (Requirements Analysis & Definition)

這是系統分析中最核心、也最耗時的環節。要將前兩個步驟收集到的模糊需求，轉化為清晰、完整、無歧義的規格。這份規格將成為後續設計與開發團隊的唯一聖經。

  • 目標： 產出一份詳盡的「系統需求規格書 (SRS)」。
  • 核心活動：
    • 需求收集： 運用訪談、問卷、使用者觀察、腦力激盪等方法，全面挖掘使用者需要系統「做什麼」。
    • 需求分類：
      • 功能性需求 (Functional Requirements)： 系統必須具備的功能。例如：「使用者必須能夠使用電子郵件和密碼登入。」
      • 非功能性需求 (Non-functional Requirements)： 系統運行的品質與限制。例如：「網頁回應時間不得超過 2 秒」、「系統必須能同時支援 1000 人上線」。
    • 需求驗證： 與利害關係人再次確認，確保理解的需求與他們的期望完全一致。

這個階段，建築師會畫出詳細的平面圖，標明每個房間的大小、功能、門窗位置，並與屋主反覆確認，直到每個細節都符合期待。

步驟四：系統建模 (System Modeling)

文字描述往往存在模糊空間，為了更精準地表達系統的結構與行為，會使用圖形化的模型來輔助說明。這就是「建模」。

  • 目標： 將抽象的需求轉化為視覺化的、結構化的模型。
  • 常用模型工具：
    • 使用案例圖 (Use Case Diagram)： 描述使用者（Actor）如何與系統互動以完成特定目標。
    • 資料流程圖 (Data Flow Diagram, DFD)： 描繪資料在系統中的流動、處理與儲存過程。
    • 實體關係圖 (Entity-Relationship Diagram, ERD)： 展現系統需要儲存的資料（實體）以及它們之間的關聯。
    • 活動圖 (Activity Diagram) / 循序圖 (Sequence Diagram)： 表現特定業務流程的步驟或物件之間的互動順序。

這些圖表就是藍圖中的結構圖、水電管線圖和立面圖。它們讓開發團隊能從不同視角清楚地理解系統的內部運作邏輯。

步驟五：系統規格書撰寫與審查 (Specification & Review)

最後，將前面所有步驟的成果——問題定義、可行性分析、需求列表、系統模型——全部彙整成一份正式的、結構化的文件，這就是**「系統規格書 (System Specification)」**。

這份文件是系統分析階段的最終產出，也是連結「分析」與「設計」兩個階段的關鍵橋樑。它將交付給：

  • 專案經理： 用於規劃時程與資源。
  • 系統設計師/架構師： 作為架構設計的依據。
  • 開發工程師： 了解功能細節。
  • 測試工程師： 編寫測試案例的基礎。

文件完成後，還需要召開一次正式的審查會議，邀請所有利害關係人共同檢視，確保無誤後簽署確認。一旦確認，這份藍圖就正式定稿，準備交給施工團隊（設計與開發人員）動工了！

結論

系統分析從來就不只是一門純粹的技術工作，它更是一門溝通、同理與結構化思考的藝術。它是一座橋樑，穩固地連結著使用者的真實需求與最終的技術實現。

下次當使用一個順暢好用的軟體時，不妨想一想，在這背後，一定有一位或一群系統分析師，曾經像偵探一樣細心探詢、像建築師一樣精心規劃，才繪製出那份無可取代的數位藍圖。