「從產品做出原型到研發程式設計實現，中間有一條鴻溝。需求越複雜，這條鴻溝就越大。」如何彌補這個「鴻溝」呢？我們需要進行兩個工作：系統分析與架構設計。本篇 chat 先講其中的系統分析。
系統分析強調對問題的調查，要解決的是系統必須做什麼的問題。
此次交流以乙個零售企業的實際專案為例，講述如何進行系統分析。內容包括：
軟體系統分析全過程
定義系統的目標和範圍
分析系統流程
需求規格描述
系統分析能力是架構師必備的，希望通過本次交流，為學員成為系統架構師打好專業基礎。
移動支付的使用已經非常廣泛。不管是線上的電商平台，還是線下的實體零售，都支援多種支付方式，這就給企業財務人員的核賬工作帶來極大的挑戰。拿實體零售來說，沒有移動支付前，只能付現金，財務人員只要核對實收現金和營業額。如今，支付方式繁多，每一種支付都需要財務人員去核對。以我們公司為例，我們有 400+ 實體店，每天是幾十萬的支付流水，而乙個運作良好的電商平台，每天會產生上百萬的支付流水。面對巨量的支付資料，財務人員依賴於手工核賬顯然是不行的，不光工作量大，還容易出錯。這時，財務部門會要求建立對賬系統，由系統來完成核賬。
在業務部門或者產品經理(網際網路公司設有產品崗，一般需求來自產品經理) 提出需求之後，我們首先要分析業務邏輯抓住核心需求，理清系統的邊界，知道系統能做什麼，不能做什麼。然後，才能設計出滿足業務方要求的系統。一種常見的情況是，職場新人拿到需求就開始設計資料表結構，寫**了，想到哪寫到哪。另一種情況是，一些有工作經驗的人，憑著自己的經驗去設計，要麼是考慮不周，要麼就是漏掉一些功能。這都是設計系統之前缺少系統分析而造成的問題。
下面我們通過零售企業的對賬系統，介紹系統設計前如何做好系統分析。
需求分析的目的是確定系統目標和範圍。有了清晰的目標和範圍，我們才知道系統要建成什麼樣，成功與否的衡量標準是什麼。社交平台上，經常看到有人說學習靜不下心，沒看幾頁書心就不知道飄到哪去了。這就是典型的沒有目標的學習，學到什麼程度可以結束沒有清晰的界定。
首先是定義系統目標，就是說我們為什麼要建立這個系統？系統目標最好用一句話能描述清楚，對賬系統的目標可以這樣描述：
幫助財務人員提高對賬效率，保障資金安全
確定了目標，就有了方向。再來看如何理清系統範圍。系統範圍指的就是我們要開發的那些功能，理解核心流程（對賬業務的流程）或者企業最為關注的事件，可以幫助我們理清系統範圍。
1. 對賬業務流程
企業內部有各種各樣的流程，我們只要關注跟系統有關的業務流程。我們的對賬系統跟對賬有關，對賬業務一般是這樣的：
業務用例描述：
業務用例名稱
簡述對賬
財務人員核對支付資料，找出問題資料進行處理
2. 分析業務流程
圈出了系統將參與的業務流程（對賬）後，就來分析它的工作流程，看看在流程內部的一連串工作，哪些工作是人工操作的，哪些工作是可以資訊化的，可資訊化的工作專案將作為系統的服務專案，也就是系統的功能。
讀者朋友可能已經發現了，我們分析業務流程，其目的就是為了定義出系統用例。所以會有一套切分工作專案的準則：
現在來看一下對賬業務流程，財務人員首先是拿到外部平台的對賬單和公司內部業務支付資料，然後調整資料格式，最後進行資料比對，找出問題。這一連串的工作，我們可以用活**來表示。
3. 定義系統範圍
活**中的每乙個動作，都可能成為系統用例。系統用例是我們需要開發的功能，它們構成了系統的範圍。前面我們說過，可以資訊化的動作將作為系統用例。
我們來看一下每個動作，資料接入、資料轉換和資料核對一定是可以資訊化的，它們是對賬系統要解決的核心問題，而差錯處理目前是人工操作的，不可以資訊化，它不能作為系統用例。但在系統上線後可以有系統報警，以郵件或簡訊的形式通知財務人員。對應的，就可以用 "傳送報警郵件" 或 "傳送報警簡訊" 作為系統用例。
下面用 「定時啟動者」 作為用例的啟動者，是因為對賬系統上線後是定時自動執行的。
系統用例名稱
簡述1）資料接入
系統每日於約定時間主動從外部系統拉取對賬單
2）資料轉換
系統把對賬單以統一的格式進行轉換
3）資料儲存
系統將轉換過格式的資料儲存到對賬資料池中
系統用例名稱
簡述1）資料對比
系統對雙方的每條資料依次進行比對
2）差異記錄
記錄比對過程中發現的問題資料
系統用例名稱
簡述1）二次核對
系統對差錯記錄中的資料會進行二次核對，避免由於日切的原因造成問題錯報
2）系統報警
對不能自動修復的問題資料，通知手工處理
至此，我們已經確定了系統的範圍。就是說，我們已經知道對賬系統將會有哪些功能了。
4. 分析系統流程
就像分析業務流程一樣，得到系統用例後，我們還需要分析每個系統用例的細節和規則，最後編寫成用例敘述文件，這份文件作為正式需求分析檔案，也可以作為業務人員與開發人員之間的溝通檔案。
乙份用例敘述格式裡包含很多字段，實踐中常用的字段有這些：
用例基本資料
執行流程
條件及規則
我們以 「拉取資料」 為例，其他用例類似。
用例名稱
拉取資料
用例編號
suc001
用例簡述
系統每日於約定時間主動從外部系統拉取資料
用例圖《略》
參考畫面
《無》主要流程
1) 時間一到，系統自動通過外部系統的 api 拉取對賬單。 2）呼叫資料轉換服務
例外流程
1a) [網路異常]請求超時，3秒後重試。
業務規則
《無》5. 建立領域模型
編寫好系統用例敘述後，需求分析的工作就完成了。
建立領域模型可以放在系統設計時去做，通常分析階段輸出的模型圖，系統（架構）設計師會再進行調整以便開發人員參照編寫**。我們的對賬業務比較簡單，這裡提供一下思路，讀者朋友可以試著挑戰一下。需要注意的是一定要理清業務的概念，使用統一語言，這是進一步溝通的基礎。
我們是從企業流程分析開始的，從 use case 的敘述中去尋找概念，然後再將這些概念合起來組成概念 (類) 圖。也可以從領域概念分析著手，找出概念及關係，然後拿比較關鍵的 use case 來檢驗看看這些類別是否能正確支撐 use case，若是無法通過檢驗，就逐步修正類別或其關係。
這兩種方式哪種好，是見仁見智的。若是能讓它們相輔相成是最理想的。其實，很多年前 james rumbaugh 就提出了 two-prong 系統分析方法，將領域分析和 use case 結合起來，首先是捕捉領域知識來建立領域模型；然後針對特定應用系統的 use cases 加以檢驗，來建立應用模型。
最後，我們再來回顧一下需求分析的過程，首先我們要找到跟系統有關的業務流程，換句話說，就是企業關心的事件；接著，我們就要分析流程內部的工作專案，哪些是手工操作，哪些是可以資訊化的，可以資訊化的將作為系統用例，用來定義系統的範圍；確定了系統的範圍之後，就要仔細的分析業務細則，最後編寫系統用例敘述，形成正式的需求分析文件。
閱讀全文:
資訊系統分析方法
一 為業務分層 資訊系統顧名思義就是管理資料的系統，而資料就是企業業務辦理過程中產生的，所以信 息系統的建立必須圍繞企業的業務展開。企業的業務數不勝數，如何來組織？答案就是 根據業務的重要性，劃分業務層次。一般情況下，四層就足夠了，分別為 a基本業務 企業最核心的業務 b重要業務 c一般業務 d延伸...
系統分析師下午題 案例分析
考是考完了，反正沒複習完，感覺都對吧，錄入一波筆記，明年可以用咯，明年專攻案例分析與 標出問題要點，作為主要線索進行分析和思考 對照問題要點仔細閱讀正文 通過定性分析或定量估算，構思答案要點 簡練語言寫出答案 在2019年的本次考試中 必答題考了pert圖 1 判斷說法正確，並給出解釋 2 計算關鍵...
PO PO系列 請購單系統分析（案例）
2014 07 01 created by baoxinjian 一 摘要 請購單管理 匯入請購單時時pr單一塊重要內容，因為只有當其他模組由物料需求時，才會讓採購部門進行採購，所以大多數請購單都是通過其他模組匯入，如mrp，wip和inventory等 所以之後會進行各個模組進行物料匯入的案例詳解...