系統分析師的經驗分享(SA)：在技術與需求間搭建橋樑

Published in

spyua

24 min readAug 26, 2024

作為一位在軟體系統領域有多年經驗的工作者，我的職涯涵蓋了軟體開發、架構設計、需求釐清與整體架構評估等多個方面。目前，我在國泰擔任Cloud PG的角色，但其實有點跨職能，常常協助PM進行需求釐清、技術實現以及時程控管，這讓我在實務上也扮演了SA的角色。另外，和專業的PM一起工作過程中，我不僅建立了SA的職能，還從這位PM身上學到了不少專案管理的技巧。不過，由於我的工作也跨及到SD（系統設計）、SQA（軟體品質保證）與MA（維護分析師），甚至還涉及到一些PG（軟體開發者）的職責，這與我原本進入公司的開發初衷有些不同。因此，本文將主要聚焦於SA職能的建立與整理。

我多麼想要有一個大神直接帶我飛上天…

目前工作內容與職責

我的工作內容涵蓋了Cloud PG、SA、SD，甚至還包含一些PM的職責，例如與PM共同制定技術審核與時程控管。作為SA，我的主要職責包括：

與業務單位（BU）溝通，釐清技術解決方案
跨部門協調，確保系統服務的介接順暢
審核各類技術文件，如SRS、SDD等
根據需求進行系統架構與雲端架構的設計
執行使用者分析與系統分析
必要時協助開發

在過去的專案中，我參與了兩個主要較大的案例：一個是我目前負責的雲端服務項目，另一個是我在中冠時期負責的鋼廠程控項目。最近，我也參與了一個海外統一推播服務系統的開發。由於沒有專業的SA帶領我，所以如果有任何遺漏或觀念不正確的地方，還請不吝留言指正。

SA工作內容與職責

根據我累積的經驗和與其他人的交流，SA的核心職責如下：

蒐集和確認專案資訊 : 進行資料收集、分析與驗證，並產出《資料分析報告》或《資料驗證報告》。
了解客戶需求 : 透過與客戶的面談來確認需求，並設計系統原型，產出《需求訪談紀錄》和《系統原型設計文件》。
與團隊討論可行性：與團隊討論需求的可行性、優先順序和替代方案，對應的文件包括《需求可行性評估報告》和《替代方案建議書》。
撰寫系統規劃文件：將需求分析結果詳細記錄成文件，包括《系統需求規格書》和《系統設計文件》。有些SA同時具備PG職能，還會進一步產出《程式設計規格書》、《軟體套件清單》和《系統運維手冊》。
協助測試規劃 : 協助制定測試策略和測試計畫，確保測試範圍與需求相符，產出《測試計劃書》或《測試策略文件》。這一部分跟QA會不太一樣，SA的主要目的是確保系統設計與客戶需求相符，他們主要關注的是系統功能是否符合設計目標和客戶需求。QA的主要目的是確保軟體的品質，這包括功能性、性能、安全性等各方面。QA更關注如何有效地測試系統，找到潛在的缺陷和問題，並確保系統符合質量標準。
持續優化系統：在開發過程中不斷與客戶確認需求，並進行調整，對應文件包括《需求變更紀錄》和《系統優化報告》。

以上五點是主要項目，接著是進階項目，資深SA會針對細節再去做深入

系統架構設計：在系統規劃階段，設計整體系統架構，包括定義主要組件、它們之間的關係，以及如何整合到現有IT環境中，並產出《系統架構設計文件》。儘管這部分屬於SD範疇，但許多SA也具備SD的能力，能與專業SD討論技術細節。
風險評估與管理：具備技術背景的資深SA需要識別潛在的項目風險，並提出緩解策略，這通常會體現在《系統需求規格書》中，特別針對異常處理和服務暫停等風險進行規劃。
測試策略制定：雖然詳細的測試計劃通常由專業的QA團隊制定，但SA往往需要協助制定測試策略，以確保技術方案的完整性。

根據不同的Domain，SA還會涉及一些特定的文件，例如金融業的交易性能規格或電子商務中的用戶行為報告分析。雖然這些任務有些跨職能，但SA通常會具備基本能力來處理這些需求。

我稍微統整一下我認知SA有的三大能力，

優秀的溝通能力

理解並準確捕捉用戶需求
將技術概念轉化為非技術人員能理解的語言
與開發團隊有效溝通，確保設計意圖得到準確實現

2. 需求轉化為流程和架構圖的能力

能夠將抽象的需求轉化為具體的流程和架構圖

3. 深厚的技術底子

評估需求的技術可行性
制定對開發友好的規格
在設計解決方案時考慮到性能、安全性、可擴展性等技術因素

優秀的溝通能力

在我的經驗中，大多遇到的問題不是技術解的問題，大多的問題都是溝通上的認知差異及技術差異化認知的問題，因此卓越的溝通能力是SA須先具備的，尤其在客戶溝通和跨部門協作中尤為關鍵。

除了需擅長主動傾聽，能夠準確捕捉客戶的明確和潛在需求。在表達複雜概念時，避開技術面，使用客戶易於理解的語言。通過運用開放式問題和視覺化工具，引導客戶深入思考需求，並更好地理解proposed解決方案。

而在跨部門溝通中，SA扮演著橋樑的角色。需在技術團隊和非技術團隊之間建立共同語言，深入分析各方相關者的目標和關注點。面對意見分歧時，須尋找平衡點與雙方可接受的方案。我覺得這點蠻重要的，因為就算你站在技術對的立場，很常遇到對方部門的歷史因緣而不再探討出一個妥協的方案。

所以耐心和引導能力是系統分析師的另一大特質。除了能夠將複雜的概念分解成易於理解的小部分，重點需不厭其煩地重複關鍵信息。能識別並適當回應各方的情緒和顧慮。通過引導式提問和場景假設，幫助需求提出者和團隊成員梳理思路，逐步完善需求和解決方案。

需求轉化為流程和架構圖的能力

在進行各種分析和設計任務時，我常用的工具有

Draw.io：線上繪圖工具，適合創建各種圖表（例如流程圖、UML圖、網路圖等）。
Mermaid：用於生成圖表和流程圖，我通常用來畫API Sequence Flow。
Miro：線上白板平台，適合團隊協作，通常用來繪製心智圖以釐清事項。

身為一個SA，你必須針對需求情境設計出不同的圖表

1. Mind Map

在項目初期釐清需求時，我經常使用心智圖來展開項目，分析大項目間的依賴關係，並確定大項目能展開哪些小項目。心智圖可以協助系統分析師（SA）組織並視覺化複雜的項目。簡而言之，它有助於團隊成員理解項目的範圍和關鍵元素，是項目初期規劃的有力工具。

分享一下之前繪製的設備控制模組心智圖，用以釐清項目需求。當初在部門規劃設備套件模組時，我們針對控制模組去釐清有哪些控制單元，常見的為PLC控制器與PC，接著再針對各控制單元進行進一步的展開和分類。

透過心智圖，我可以迅速勾勒出各控制器的套件規劃可能性，並能在討論過程中同步繪圖。這種方法使我們能夠規劃出涵蓋從底層硬件控制到上層用戶界面的各個方面。它不僅有助於開發團隊理解系統架構，還為進一步的開發和維護提供了良好的指導。

2.Use Case Diagram

一般我會用Use Case Diagram定義使用者與系統服務之間的使用關係，其重要性在於初步框出系統邊界和各元素間的關係。值得注意的是，許多人常將 Use Case Diagram 與 User Flow Chart 混淆。Use Case Diagram 的重點在於展示系統提供哪些功能，而非詳述如何實現這些功能。

以線上購物系統的功能為例，如圖一所示，它展示了”瀏覽商品”、”搜索商品”、”加入購物車”和”結帳”等功能，但並不說明如何執行這些操作。此外，從圖中您也可以看出系統的邊界關係：支付系統與庫存系統屬於外部系統，不在線上購物系統本身的服務範疇內。

3. User Flow Chart

User Flow Chart 描述使用者的操作流程。它有助於開發團隊理解用戶如何操作系統的細節，對優化用戶體驗和界面設計很有幫助。在我最初繪製這個 Chart 時，容易將它與 Business Flow Chart 和 System Flow Chart 混淆。我會在介紹完這兩張 Chart 後再做一次比較。

4. Business Flow Chart（業務流程圖）

這是一般常見的業務流程圖，描述不同角色在系統中互動的流程與決策點。這張圖是系統設計與業務需求對應的關鍵圖。

5. System Flow Chart (系統流程圖)

這張圖將業務流程轉化為技術實現，通常描述一些技術細節，例如數據流向、API 調用及處理邏輯、錯誤處理等。

介紹完 3、4、5 三張圖的用途後，我們來做一個簡單的比較。以前面提到的 Use Case Diagram 中的線上購物系統為例，我們選取單一功能（瀏覽商品）來說明，如圖二所示：

User Flow Chart 展示用戶在瀏覽商品時可能遇到的具體步驟和決策點，如使用篩選（過濾器）、查看產品詳情等。
Business Flow Chart 詳細說明了系統如何處理用戶請求，包括根據用戶登錄狀態載入不同設置，以及應用業務規則進行數據處理。
System Flow Chart 深入展示了技術實現細節，例如使用 Redis 緩存來優化性能，以及如何處理數據庫查詢和響應生成。

另外需要注意的是，System Flow Chart 可以有多種不同的展開方式，通常會根據具體需求而略有差異。例如：

資料流程圖：描述資料在系統中的流動路徑（通常基於服務架構圖來繪製資料流）
時序圖：展示操作的時間順序和服務間的訊息傳遞（常見的如 API Sequence Flow）
狀態圖：描述處理請求過程中的不同狀態

以上所述基本涵蓋了 SA（系統分析師）專注的業務與系統資料流之間的對應釐清。我認為上述提到的範例相對簡單。如果要更專業一些，我建議可以參考下面這篇文章：《System Flowchart: Definition, Application, Benefits, Symbols and Examples》。這篇文章不僅簡要解釋了 UML Component（統一建模語言元件圖），而且給出的例子也更專業，更貼近實際應用場景。

以下內容已經接近 SD（系統設計）的範疇了。但在實際工作中，我經常遇到被要求產出這一塊的情況，所以特別記錄一下這部分。

6. System Architecture (系統架構圖)

系統架構圖從較高層次的角度釐清系統間的依賴關係。通常包含以下要素：

系統的各個模組和服務
數據流或控制流（如前述提到的System Flow Chart），描述服務之間的互動方式
技術選擇，如資料庫架構、緩存（Cache）架構、通訊方式等
系統與外部系統或使用者的互動方式

這裡我們直接用.NET的經典範例eShopOnContainers的架構圖作為示例，如圖三所示。該圖展示了整個系統的核心部分，包括客戶端、API Gateway、微服務、資料庫和事件總線等。圖中將不同的服務進行了模組化，每個服務在系統中的職責定位很清晰，充分體現了此微服務架構的組織方式。

此外，圖中還展示了具體的技術選擇，如Docker Host、SQL Server、RabbitMQ、Redis等。箭頭和線條則展示了系統內部各部分之間的數據流動與控制流，有助於理解服務之間的關係與依賴性。

7. API Sequence Diagram（API序列圖）

API Sequence Flow 是一種流程圖，用於表示系統中不同服務實體（通常是應用程式、伺服器或服務）之間通過 API 進行互動的過程。這種圖表描述了這些服務實體之間的請求與響應流程，通常會與 API 規格文檔（API Specification）一同呈現。

這張API Sequence Flow圖展示了一個典型的用戶登錄流程,涉及四個主要組件:Client(客戶端)、API Gateway(API網關)、Auth Service(認證服務)和Database(數據庫)。流程如下:

客戶端發起登錄: Client向API Gateway發送POST /login請求,包含用戶名和密碼。
驗證憑證: API Gateway將憑證轉發給Auth Service進行驗證。
查詢用戶數據: Auth Service向Database查詢用戶數據。
返回用戶數據: Database將用戶數據返回給Auth Service。
驗證成功: Auth Service驗證成功後,生成session token並返回給API Gateway。
響應客戶端: API Gateway將session token作為200 OK響應返回給Client。

這個流程展示了一個安全的、分層的身份驗證過程。API Gateway作為中間層,隔離了客戶端與核心服務,增強了系統安全性。Auth Service專門處理認證邏輯,而Database存儲用戶信息,體現了職責分離的原則。

使用session token而不是直接返回用戶數據,也體現了安全性考慮,避免敏感信息直接暴露給客戶端。

這種圖表對於理解系統間的交互、API設計以及安全流程非常有幫助,尤其是在微服務架構中。

8. ERD (Entity-Relationship Diagram)（實體關係圖）

圖形化的方式描述數據庫的邏輯結構，描述系統中的實體類型、它們的屬性，以及實體之間的關係。這張圖可以幫助設計與開發者了解數據間的相依性。

ERD 的主要組成部分包括：

實體（Entities）：對應現實世界中的對象或概念，例如「用戶」、「產品」等。
屬性（Attributes）：描述實體的特徵，如用戶的「姓名」、「電子郵件」等。
關係（Relationships）：表示實體之間的聯繫，如「用戶購買產品」。
基數（Cardinality）：指定實體間關係的數量約束，如一對一、一對多、多對多。

下圖五舉一個簡易例子，

實體（Entities） :

CUSTOMER（客戶）
ORDER（訂單）
PRODUCT（產品）
ORDER_ITEM（訂單項目）

2. 屬性（Attributes） : 如 CUSTOMER id、name 和 email …

3. 關係（Relationships） :

CUSTOMER 和 ORDER 之間是一對多關係（一個客戶可以下多個訂單）
ORDER 和 ORDER_ITEM 之間是一對多關係（一個訂單可以包含多個訂單項目）
PRODUCT 和 ORDER_ITEM 之間是一對多關係（一個產品可以出現在多個訂單項目中）

4. 基數（Cardinality）: 使用 crow’s foot 符號表示，例如 || — o{ 表示「一對多」關係

ERD 表示出實體之間的關係和每個實體的主要屬性，使得數據庫結構一目了然。這對於設計數據庫結構、進行系統分析以及與團隊成員溝通都非常有幫助。

9. Software Architecture（軟件架構）

表示軟體系統的高層次結構設計。描述了系統的基本組件、這些組件之間的關係，以及它們如何一起工作來達成系統的需求。他與系統架構不同，他會針對某一個系統服務項目展開內部軟體架構，細到使用哪個軟體套件都能看得清楚。

以下圖六為之前我稍微初步設計的設備通用軟體架構，主要層次為Application Context、Device Interface、Service Layer、Infrastructure Layer。每一層負責不同的業務邏輯和操作，並且有明確的功能劃分與角色定義。

Application Context（應用程式上下文）: 這一層是應用程式的最高層級，負責管理整體的應用流程和執行邏輯。在這個上下文中，與設備的交互由Device Interface來處理，而所有服務邏輯的調用都經過Service Layer。

Device Interface（設備接口層）：該層負責與實體設備的具體互動，包含了針對不同設備類型（如ModbusTCP協議控制的設備、手持控制裝置、機器人、馬達、感測器等）的具體實現。每個設備都有自己的具體邏輯處理模組，如：

Device Concrete (ModbusTCP)：處理基於ModbusTCP協議的設備通訊。
Device Concrete (Module)：模組化的設備控制邏輯，對應不同的硬體裝置。
Action Combo Table：針對設備控制所需的操作組合表，管理製造過程中的動作數據庫。
Service Layer（服務層）：服務層提供應用程式的業務邏輯，通過API接口與外部通信。該層將設備操作抽象化，並提供對外的API來支持高層次應用與設備控制的交互。這一層負責處理業務邏輯與數據的整合，調用Device Interface進行實際的設備操作。
API Interface：服務層中的API接口，提供標準化的設備控制和數據管理功能，供其他應用或外部系統使用。
Infrastructure Layer（基礎設施層）：基礎設施層負責系統的底層實作，包含了資料庫、檔案系統、以及與硬體控制相關的實際操作。在這一層，你定義了多種基礎設施模組，如硬體控制（HW Control）、資料管理（Data Manager）以及與用戶界面相關的模組。
HW Control Package：負責對實體硬體（如相機、機器人、馬達、感測器等）的控制，基於C++或其他低階API進行硬體驅動與控制。
Data Manager Package：負責數據的持久化與管理，涉及資料庫操作和檔案系統（例如使用Entity Framework來操作資料庫、管理設備資料和操作日誌）。
View Package：提供用戶界面的控制，包括登入視圖和日誌視圖。

上述設備控制軟體系統架構圖簡明扼要地展示了從基礎設施層到應用層的詳細結構。圖中清晰呈現了所有組件、其功能以及使用的具體技術。這個架構設計著重於模組化、可擴展性與系統穩定性，為設備控制系統提供了一個全面的軟體解決方案。

此架構幫助開發團隊明確各模組的職責與依賴關係，減少設計混亂。通過分層和模組化的設計，它促進了代碼的一致性與可測試性。這不僅提高了系統的可維護性和擴展性，也為開發流程提供了標準化的依據。因此，它降低了開發風險和錯誤的可能性，最終提升了整體的開發效率與系統質量。

10. Class Diagram（類圖）

軟體架構圖是系統的高層次視圖，主要展示軟體系統的模組、層次結構、組件之間的關係，以及它們如何交互來完成系統的整體功能。而物件類別圖是對系統內部的Class、Class的屬性、方法以及它們之間的關係（如繼承、關聯等）進行詳細說明。它更關注於軟體的具體實現，展示物件導向的設計結構。

這邊以電子商務系統針對訂單功能舉例一個簡易的類別物件圖，圖中有四個主要類別：Order（訂單）、Customer（客戶）、OrderItem（訂單項目）和Product（產品）。每個類別都用一個矩形表示，矩形分為三個部分：類別名稱、屬性和方法。

屬性（Attributes）:

每個類別都有自己的屬性，用 “-” 符號表示私有屬性。
例如，Order 類別有 orderId、orderDate、customer 和 items 屬性。
屬性定義了類別所包含的數據。

方法（Methods）:

類別中的方法用 “+” 符號表示公共方法。
例如，Order 類別有 calculateTotal() 和 addItem() 方法。
方法定義了類別可以執行的操作。

關係（Relationships）:

類別之間的線條表示它們之間的關係。
“Order “1” — “1..*” OrderItem” 表示一個 Order 包含一個或多個 OrderItem（一對多關係）。
“Order “1” — “1” Customer” 表示一個 Order 對應一個 Customer（一對一關係）。
“OrderItem “1” — “1” Product” 表示一個 OrderItem 對應一個 Product（一對一關係）。

上述類別圖展示實現訂單處理系統的核心功能。定義系統程式面主要Instance、它們的屬性和行為，以及它們之間的關係，為後續的詳細設計和編碼工作奠定了基礎。依照上述類別圖直接設計出相對應程式碼

using System;
using System.Collections.Generic;
using System.Linq;

public class Product
{
    public int ProductId { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    public int Stock { get; set; }
    public void UpdateStock(int quantity)
    {
        Stock += quantity;
    }
}
public class Customer
{
    public int CustomerId { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public void UpdateProfile(string name = null, string email = null)
    {
        if (name != null) Name = name;
        if (email != null) Email = email;
    }
}
public class OrderItem
{
    public int ItemId { get; set; }
    public Product Product { get; set; }
    public int Quantity { get; set; }
    public decimal CalculateSubtotal()
    {
        return Product.Price * Quantity;
    }
}
public class Order
{
    public int OrderId { get; set; }
    public DateTime OrderDate { get; set; }
    public Customer Customer { get; set; }
    public List<OrderItem> Items { get; set; } = new List<OrderItem>();
    public void AddItem(OrderItem item)
    {
        Items.Add(item);
    }
    public decimal CalculateTotal()
    {
        return Items.Sum(item => item.CalculateSubtotal());
    }
}
public class Program
{
    public static void Main()
    {
        // 創建產品
        var product1 = new Product { ProductId = 1, Name = "筆記本電腦", Price = 1000m, Stock = 10 };
        var product2 = new Product { ProductId = 2, Name = "滑鼠", Price = 20m, Stock = 50 };
        // 創建客戶
        var customer = new Customer { CustomerId = 1, Name = "張三", Email = "zhangsan@example.com" };
        // 創建訂單
        var order = new Order { OrderId = 1, OrderDate = DateTime.Now, Customer = customer };
        // 添加訂單項目
        order.AddItem(new OrderItem { ItemId = 1, Product = product1, Quantity = 1 });
        order.AddItem(new OrderItem { ItemId = 2, Product = product2, Quantity = 2 });
        // 計算訂單總額
        decimal total = order.CalculateTotal();
        Console.WriteLine($"訂單總額: ${total:F2}");
        // 更新庫存
        product1.UpdateStock(-1);
        product2.UpdateStock(-2);
        // 更新客戶資料
        customer.UpdateProfile(email: "zhangsan_new@example.com");
        Console.WriteLine($"客戶 {customer.Name} 的新郵箱: {customer.Email}");
        Console.WriteLine($"產品 '{product1.Name}' 的剩餘庫存: {product1.Stock}");
        Console.WriteLine($"產品 '{product2.Name}' 的剩餘庫存: {product2.Stock}");
    }
}

圖表用途總整理

以下針對上述提到流程與架構圖類型做一個總整理。

深厚的技術底子

雖然大部分人的認知，SA不需要具備太高的技術職能，但在我的經驗深厚技術底子反而是SA專業能力的核心支柱。如下圖八，

底層：技術支柱

技術支柱是系統分析師的核心競爭力，決定了SA能否在開發過程中能準確地提供技術指導與支持。特別是在涉及大型系統的時候，對於架構的掌握、資料庫的設計優化以及API的設計與安全性管理尤為重要。這些技術能力確保系統能夠穩定運行並具備良好的擴展性和安全性。

中層：系統設計與分析

當技術能力已成為基礎，SA的工作重心上升至系統設計與分析層面。這一層涵蓋需求分析、系統架構設計、資料流設計等，並包含User Story、功能模組的劃分與系統流程圖的繪製。

系統設計與分析不僅要求SA理解技術，更需要能夠將技術應用於滿足業務需求。SA需要參與與使用者和其他利害關係人的討論，並依據業務需求設計出具備可行性的技術解決方案。優質的系統設計能夠減少開發與運維中的風險，並提高系統的可維護性與可擴展性。

上層：業務理解與決策

SA不僅僅是技術專家，他們還需要有深刻的業務理解。這一層著重於需求訪談、風險評估、系統持續優化等內容，並涉及到如何將技術解決方案轉化為業務價值。

業務理解與決策層對SA提出了更高的要求，特別是當系統的設計需要考慮到業務流程的改變時，SA必須具備充分的靈活性與適應性。系統分析師在這一階段不僅僅是設計者，更是決策者，需要在技術可行性與業務需求之間尋找最佳平衡。

頂層：戰略規劃與合作

金字塔的頂層代表的是系統分析師的最高境界 — — 戰略規劃與跨部門合作。這一層的重點在於技術落地，並通過與業務單位的合作推動整體戰略實施。

在這個層次，SA不僅需要具備技術洞察力，還需要在企業內部推動技術的應用，以支持企業的長期戰略目標。這一角色要求系統分析師能夠跨越技術和業務之間的鴻溝，從全局的視角出發，將技術解決方案與企業戰略緊密結合，從而實現長遠的成功。

這邊做個小總結，SA的工作不僅僅局限於技術領域，同時需要具備卓越的溝通能力，能夠將抽象的需求轉化為具體的系統設計，並且擁有深厚的技術背景來確保方案的可行性、性能、安全性與可擴展性。除此之外，SA還必須在專案管理、跨部門協作、系統優化等領域發揮核心作用，從而在技術與業務需求之間取得平衡，並推動企業的長期戰略落地。

最後我的好友Feedback這篇的內容思維，比較偏瀑布式開發SA職責內容。如果是敏捷開發呢? 這算是蠻有趣的思維，就留給各位思考吧。