• 1. 軟體架構體系
  • 1.1. 系統與子系統
  • 1.2. 模塊、組件、服務
  • 1.3. 軟體架構體系
• 2. 架構原則
  • 2.1. 解耦
  • 2.2. 分層
  • 2.3. 封裝
• 3. 架構的方法
  • 3.1 業務架構
  • 3.2 功能架構
  • 3.3 系統架構
  • 3.4 技術架構
  • 3.5 數據架構
  • 3.6 部署架構
• 4. 架構演進之路
  • 4.1. 單體架構
  • 4.2. 分散式架構
    • 4.2.1 應用集群
    • 4.2.2 分散式緩存
    • 4.3.3 業務拆分
    • 4.3.4 分庫分表和讀寫分離
    • 4.3.5 靜態化和CDN
    • 4.3.6 非同步解耦
  • 4.3. 微服務架構
• 5. 服務化
  • 5.1 為什麼需要服務化
  • 5.2 服務化的好處
  • 5.3 服務化的問題
• 6. 常見的需求問題
  • 6.1. 需求不明確
  • 6.2. 需求理解不一致
  • 6.3. 需求自身經常變動
• 7. 需求獲取
  • 7.1 需求來源
  • 7.2 需求分類
  • 7.3 獲取步驟
• 8. 需求要素
  • 8.1 角色、場景
  • 8.2 業務流程
  • 8.3 數據實體
  • 8.4 功能性需求
  • 8.5 非功能性需求
• 9. 案例：電商訂單系統
  • 9.1 概述
  • 9.2 角色
  • 9.3 場景(用例)
  • 9.4 功能
  • 9.5 實體
  • 9.6 流程

• 能夠掌握系統、子系統、模塊、組件、服務、框架、架構等概念的含義
• 能夠知道單體架構、分散式架構、微服務架構的適用場景、優勢和劣勢
• 能夠知道微服務架構常見技術框架
• 能夠瞭解組件化、服務化產生的原因、優勢和問題，初步具備中台概念
• 瞭解常見的需求問題
• 掌握一個需求包含的要素
• 掌握如何做需求分析

1. 軟體架構體系

1.1. 系統與子系統

系統：泛指由一群有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的工作的群體。

• 關聯：系統是由一群有關聯的個體組成的，沒有關聯的個體堆在一起不能成為一個系統。例如，把一個汽車發動機和一堆蘋果放在一起不能稱之為一個系統，把發動機、底盤、輪胎、車架組合起來才能成為一臺汽車，構成一個系統。
• 規則：系統內的個體需要按照指定的規則運作，而不是單個個體各自為政。規則規定了系統內個體分工和協作的方式。例如，汽車發動機負責產生動力，然後通過變速器和傳動軸，將動力輸出到車輪上，從而驅動汽車前進。
• 能力：系統能力與個體能力有本質的差別，系統能力不是個體能力之和，而是產生了新的能力。例如，汽車能夠載重前進，而發動機、變速器、傳動軸、車輪本身都不具備這樣的能力。

子系統：子系統也是由一群有關聯的個體所組成的系統，多半會是更大系統中的一部分。 子系統的定義和系統定義是一樣的，只是觀察的角度有差異，一個系統可能是另外一個更大系統的子系統。

以微信為例來做一個分析：

• 微信本身是一個系統，包含聊天、登錄、支付、朋友圈等子系統。
• 朋友圈這個系統又包括動態、評論、點贊等子系統。
• 評論這個系統可能又包括防刷子系統、審核子系統、發佈子系統、存儲子系統。
• 評論審核子系統不再包含業務意義上的子系統，而是包括各個模塊或者組件，這些模塊或者組件本身也是另外一個維度上的系統。例如，MySQL、Redis 等是存儲系統，但不是業務子系統

1.2. 模塊、組件、服務

• 模塊：是一套一致而互相有緊密關連的軟體組織。它分別包含了程式和數據結構兩部分。現代軟體開發往往使用模塊作為合成的單位
• 組件：自包含的、可編程的、可重用的、與語言無關的軟體單元，組件可以很容易被用於組裝應用程式中

模塊和組件都是系統的組成部分，只是從不同的角度拆分系統而已。例如：

• 從邏輯的角度來拆分系統後，得到的單元就是“模塊”；從物理的角度來拆分系統後，得到的單元就是“組件”。
• 劃分模塊的主要目的是職責分離；劃分組件的主要目的是單元復用。

例如我們要做一個學生信息管理系統，這個系統從邏輯的角度來拆分，可以分為：登錄註冊模塊、個人信息模塊、個人成績模塊；從物理的角度來拆分，可以拆分為應用程式、 Nginx、Web 伺服器、MySQL等

• 服務：服務和組件有某種相似之處：它們都將被外部的應用程式使用。兩者之間最大的差異在於：組件是在本地使用的（例如Jar文件）；而服務是運行起來的，要通過同步或非同步的遠程介面來遠程使用（例如RESTFul介面、web service、消息系統、RPC，或者socket）

服務是可以單獨運行，並且對外提供功能的一種形式。可以將一個複雜的項目分解成多個服務。當某一個服務掛掉時不會拖垮整個系統。如果沒有服務化，每當一個新的功能被添加到系統中就會影響到所有功能；如果採取服務化，每個服務只對其上下游的服務負責。

1.3. 軟體架構體系

2. 架構原則

2.1. 解耦

在軟體工程中，耦合指的就是對象之間的依賴性。對象之間的耦合度越高，維護成本越高。因此對象的設計應使類和構件之間的耦合最小。軟體設計中通常用耦合度和內聚度作為衡量模塊獨立程度的標準。劃分模塊的一個準則就是高內聚低耦合。

耦合性存在於各個領域，而非軟體設計中獨有的，理論上說絕對的零耦合是做不到的，但可以通過一些方法將耦合降至最低，降低耦合度即可理解為解耦，在設計上解耦的核心思想是【彼此獨立，互不依賴】。

2.2. 分層

分層結構是最為流行、應用最廣泛的應用軟體的設計方式。在應用了分層結構的系統中，各個子系統按照層次的形式組織起來，上層使用下層的各種服務，而下層對上層一無所知。每一層都對自己的上層隱藏其下層的細節。

經典三層架構：

在軟體架構中，經典三層架構自頂向下由用戶界面層、業務邏輯層、數據訪問層組成。在提出該分層架構的時代，多數系統往往較為簡單，本質上都是一個單體架構的資料庫管理系統。這種分層架構有效地隔離了業務邏輯與數據訪問邏輯，使得這兩個不同關註點能夠相對自由和獨立地演化。經典的三層架構如下所示：

分層的設計原則是：保證同一層的組件處於同一個抽象層次。即所謂的“單一抽象層次原則”。這一原則可以運用到分層架構中。比如下圖所示：

2.3. 封裝

假設我們有一個程式，它在邏輯上有一些不同的對象，並且這些對象彼此之間會相互交流。

在一個類中，當每個對象的狀態保持相對孤立，就實現了封裝。其餘的對象並不能觀察到這個對象的狀態。他們能做到的只有調用一些被稱作“方法”的通用功能。

因此，對象使用方法掌控著自己的狀態，除非明確允許，沒有其他人可以接觸到它。如果你想和某個對象交流，你需要使用提供的方法。但在預設情況下，你無法改變對象的狀態。

3. 架構的方法

架構圖是為了表示軟體系統的整體輪廓和各個組件之間的相互關係和約束邊界，以及軟體系統的物理部署和軟體系統的演進方向的整體視圖。要讓干係人理解、遵循架構決策，就需要把架構信息傳遞出去，架構圖就是一個很好的載體。不同的視角和角色，關註點也是不同的，看到的架構圖是不一樣的。

3.1 業務架構

使用者：CEO、CIO、CTO、產品總監

核心業務流程：

核心能力:

3.2 功能架構

使用者：產品總監、產品經理

示例：黑馬頭條功能架構圖

3.3 系統架構

使用者：系統架構師

3.4 技術架構

使用者：系統架構師

示例一：https://www.processon.com/view/link/636059870791295cf8db8006

示例二：冷鏈項目技術架構圖

3.5 數據架構

使用者：CTO、系統架構師、數據架構師

示例一：數據模型

示例二：大數據平臺架構

3.6 部署架構

使用者：運維架構師

示例一：https://www.processon.com/view/link/63648dfd637689059c421af8

示例二：冷鏈項目部署架構圖

4. 架構演進之路

4.1. 單體架構

公司發展的初期，資金少、用戶少，需要的軟體產品的數據和併發量都比較小，這個時期大多數的軟體系統只需要單一伺服器就可以滿足需求，所有的業務邏輯都在單一應用系統，單應用、單資料庫。資料庫部署在和應用相同的虛擬機或伺服器上，或者放置在另外一臺機器上。此時的架構圖如下：

或

• 操作系統：windows、linux
• 應用伺服器：tomcat、jetty、jboos、apache、weblogic、websphere...
• 資料庫：mysql、oracle、db2...
• 應用系統：可以用java、php、asp等各種語言開發

這種架構模式優點很明顯：

• 節省伺服器資源，投入少
• 管理簡單：上線、部署、監控、問題排查等都比較簡單
• 開發簡單：軟體系統功能整合在一起，不需要考慮太多服務依賴等問題，代碼管理也比較簡單明瞭。
• 測試簡單

隨著公司和業務進入快速發展時期，軟體系統面臨來自多方面的考驗：

單體架構的缺點也越發的凸顯出來：

• 可用性差： 應用和資料庫都是單點，無論應用還是資料庫出現問題，整個系統的就會不可用了
• 穩定性差： 系統耦合度高，新增或者修改任何一個功能，哪怕只是一行代碼，也需要重啟伺服器，此時系統是不可用的
• 性能差：單一的應用伺服器和資料庫伺服器，性能總會有上限的，當用戶變多或者準確的說相同時刻併發訪問多時，系統就容易掛掉了

4.2. 分散式架構

單體架構有著明顯的缺陷，隨著系統訪問量的增多，這些缺陷越來越凸顯，為瞭解決這些缺陷，架構升級了，變成了分散式架構。分散式，就是多個實例提供服務。下麵我們來簡單介紹下常見的一些解決方案。

4.2.1 應用集群

• 反向代理伺服器：把用戶請求反向路由到應用伺服器，常見的反向代理伺服器是Nginx或HAProxy
• 應用伺服器：集群化部署
• 資料庫伺服器：主從部署

架構優點：

• 可用性高：代理伺服器、應用伺服器、資料庫伺服器都是做了集群，當某台機器掛掉後，其他機器能夠幾乎無感的接替下任務
• 性能比單體架構高： 用戶的請求分發到多個應用伺服器上，整體性能接近單體結構的三倍
• 安全性高： 外網用戶訪問的是反向代理伺服器，應用和資料庫隔離在內網中

4.2.2 分散式緩存

緩存分為多級緩存，比如本地緩存（JVM中），分散式緩存伺服器（Redis集群等）。本地緩存的訪問速度更快一些，但是受應用伺服器記憶體限制，其緩存數據量有限，而且會出現和應用程式爭用記憶體的情況。遠程分散式緩存可以使用集群的方式，部署大記憶體的伺服器作為專門的緩存伺服器，可以在理論上做到不受記憶體容量限制的緩存服務。常見緩存伺服器包括Redis、Memcached等。使用緩存後，數據訪問壓力得到有效緩解。

4.3.3 業務拆分

業務進一步發展，用戶越來越多，系統又出現了瓶頸，此時整個電商系統可以做系統拆分了，系統拆分分為水平拆分和垂直拆分。

水平拆分：

拆分成商品、訂單、交易、用戶、支付等多個系統，每個系統都都是多台伺服器構成的集群。

垂直拆分：

將一些公共業務和服務，如用戶中心拆分成註冊登錄中心和用戶中心，簡訊、文件、消息等各種公共服務，從業務系統中拆分剝離出來。

這種架構的優勢也比較明顯，一方面，應用系統增加了，能夠響應用戶的請求也會變多，另一方面公共服務能夠提供給所有的應用使用，達到服務復用的效果。但是大家需要註意的是資料庫有可能只是一個，而單一資料庫伺服器的處理能力必然是有限的，隨著用戶併發量的持續增多，資料庫將會是系統的瓶頸。

4.3.4 分庫分表和讀寫分離

讀寫分離：

在網站的用戶達到一定規模後，資料庫因為負載壓力過高而成為網站的瓶頸。目前大部分的主流資料庫都提供主從熱備功能，通過配置資料庫的主從關係，可以將一臺資料庫伺服器的數據更新同步到另外的資料庫伺服器上。網站利用資料庫的這一功能，實現資料庫讀寫分離，從而改善資料庫負載壓力。

應用伺服器在寫數據的時候，訪問主資料庫，主資料庫通過主從複製機制將數據更新同步到從資料庫，這樣當應用伺服器讀數據的時候，就可以通過從資料庫獲得數據。

分庫分表：

隨著資料庫中的數據量越來越大，相應的，查詢所需要的時間也越來越多，這個時候，相當於數據的處理遇到了瓶頸，另一方面單庫發生意外的時候，需要修複的是所有的數據，而多庫中的一個庫發生意外的時候，只需要修複一個庫。基於此，分庫分表就成了必然。分庫分表的策略很多，如按照用戶、訂單、交易、商品等進行分庫，不同的資料庫中按照時間進行分表。

分庫分錶帶來性能上的顯著提升，但相應的管理和維護成本也比較高，比如資料庫伺服器的維護、分表策略的維護。為了便於應用程式訪問分庫分表、讀寫分離後的資料庫，通常在應用伺服器端使用專門的數據訪問模塊，使資料庫的分庫分表和讀寫分離對應用透明。

4.3.5 靜態化和CDN

隨著網站業務不斷發展，用戶規模越來越大，和中國複雜的網路環境，不同地區的用戶訪問網站時，速度差別也極大。為了提供更好的用戶體驗，留住用戶，網站需要加速網站訪問速度。主要手段有使用頁面的靜態化和CDN。

操作方式上把一些頁面，比如某些商品的詳情信息，在發佈商品時將頁面靜態化，靜態化頁面和靜態資源可以放在CDN伺服器，部署在網路服務提供商的機房，用戶在訪問靜態資源時，可以很好的利用CDN的優點，從距離自己最近的網路提供商機房獲取數據。

4.3.6 非同步解耦

應用之間的服務存在互相調用的情況，但有些場景下，並不需要同步調用，比如某個業務完成後，需要簡訊通知對方，而簡訊接收的時間晚幾秒鐘都是可以接受的，此時就不需要同步處理了，我們可以使用消息隊列，把發送簡訊的內容扔到消息隊列中，達到非同步處理的效果，從而增強業務系統的性能，此時對於服務之間也達到瞭解耦的功能，服務之間的依賴減少了。

4.3. 微服務架構

微服務架構是分散式架構的深化，分散式架構偏向於部署和環境，比如上邊提到的應用、資料庫、緩存等，在多台機器上進行部署，就屬於分散式。微服務架構通過業務拆分實現服務組件化，通過組件組合快速開發系統，業務單一的服務組件又可以獨立部署，使得整個系統變得清晰靈活。

大量的分散式服務又使得架構實現面臨問題，如服務註冊發現，服務統一接入和許可權控制，服務的負載均衡，服務配置的集中管理，服務熔斷，服務監控等。

所以微服務架構是由這些基礎的服務組件和業務微服務組件共同組成：

• 服務註冊發現組件： 進行服務治理
• 服務網關組件：提供統一入口和許可權控制
• 負載均衡組件：提供客戶端或伺服器端的負載均衡
• 集中配置組件：提供服務集中管理
• 熔斷器組件：提供服務熔斷
• 服務追蹤組件：提供服務監控

採用微服務架構後，項目可以快速迭代與持續交付。但是也帶了一些弊端，開發人員除了需要關註業務邏輯實現外還需要考慮業務的一系列問題，比如服務註冊，服務發現，服務通訊，負載均衡，服務熔斷，服務超時等，這些是非常重要的。大多數時候，我們需要依賴第三方庫或者組件來提供這些服務，例如Hystrix，Eureka、Zookeeper等組件，在其服務組織中起到了廣泛的應用。

5. 服務化

5.1 為什麼需要服務化

傳統企業或者很多企業的軟體，大多不止一套系統，都是各個獨立大系統的堆砌。整體存在的問題是：

• 擴展性差
• 可靠性不高
• 維護成本還很大
• 重覆輪子很多

非常容易能夠想到，解決這些問題的方法是：組件化、服務化。

微服務架構，將各個組件或者模塊分散到各個服務中，對整個系統實現解耦。那微服務架構強調的重中之重就是業務系統需要完善的組件化和服務化。什麼是組件化？

組件化，即將一個大系統，按照一定的業務或者技術維度，拆分成獨立的組件。目的是為了分而治之，為了可重用，為了減少耦合度。比如按照技術維度：文件上傳下載組件、簡訊發送組件、搜索組件、緩存組件；按照業務維度：用戶中心、商品中心、支付中心等。

阿裡巴巴提出 大中台，小前臺戰略，就是把組件化、插件化、服務化解決方案到極致。通過產品線公共業務或者技術下沉，形成各種技術中台或者業務中台。

5.2 服務化的好處

• 調用簡單
• 代碼復用
• 業務隔離
• 資料庫解耦

5.3 服務化的問題

有利必有弊，服務化也會面臨很多問題：

• 本身不大的系統，業務不複雜的系統也不需要微服務架構
• 多個模塊資料庫，分散式事務是一個挑戰
• 增加了測試、運維等事務的複雜性

6. 常見的需求問題

6.1. 需求不明確

• 盲人摸象，各階段人員只掌握了一段
• 初期階段，業務還在摸索
• 各部門目標和kpi不一致，需求有衝突

6.2. 需求理解不一致

客戶：我家有三個小孩，我須要一個能三個人用的鞦韆。它是由一繩子弔在我園子里的樹上。

項目經理：鞦韆這東西太簡單了，就是一塊板子，兩邊用繩子吊起來，掛在樹上的兩個枝子上。

設計師：這個無知的項目經理，兩個樹枝上掛上鞦韆哪還能蕩漾起來嗎？除非是把樹從中截斷再支起來，這樣就滿足要求了。

項目最重要的階段是進行需求分析，明白真正的需求。項目需求指的是用戶真正需要什麼，而不是供應商假設用戶需要什麼和供應商能夠供應什麼。需求的準確定位就是要按用戶要求，對目標系統提出完整、準確、清晰、具體要求。這對一個項目的成功來說非常重要，需求分析做得不好，就會造成需求不斷變更，從而影響進度、費用，甚至會導致項目失敗。

6.3. 需求自身經常變動

• 儘可能地分析清楚哪些是穩定的需求，哪些是易變的需求。以便在進行系統設計時，將軟體的核心建築在穩定的需求上，否則將會吃盡苦頭。
• 在合同中一定要說清楚“做什麼”和“不做什麼”。如果合同含含糊糊，日後扯皮的事情就多。

7. 需求獲取

7.1 需求來源

干係人

干係人（Stake holder）：對於系統有利益關係的個人，團隊、組織和其他系統。

項目干係人包括但不限於：

• 投資方：系統的投資方
• 主管方：批准/管理系統的
• 最終用戶：用戶/系統受益方
• 操作方：操作/維護系統的
• 監管方：認證系統的
• 測試方：負責系統驗收

示例：XX信貸管理系統

投資方：     資金部
主管方：  	 信息化部
用戶代表：   市場部
最終用戶：   營業員
監管方：     審計部
測試方：     信息化部
操作方：     信息化部

7.2 需求分類

軟體需求的三個層次：

1. 業務需求

描述組織或客戶的高層次目標，通常問題定義本身就是業務需求。業務需求就是系統目標，它必須是業務導向、可度量、合理、可行的。這類需求通常來自於高層，例如項目投資人、實際用戶的管理者、市場營銷部門或產品策劃部門。

業務需求從總體上描述了為什麼要開發系統（why），希望達到什麼目標。比如“希望實施CRM後公司的客戶滿意度達到80％以上”。

業務需求對之後的用戶需求和功能需求起了限定作用，任何用戶和功能需求都必須符合業務需求。

2. 用戶需求

用戶需求是指描述用戶使用產品必須要完成什麼任務，怎麼完成需求，通常是進行用戶訪談、調查，對用戶使用的場景進行整理，從而建立從用戶角度的需求。

用戶需求必須能夠體現軟體系統將給用戶帶來的業務價值 ，也就是說用戶需求描述了用戶能使用系統來做些什麼（what），這個層次的需求是非常重要的。

用戶需求可細分為：

• 基本型需求：產品功能必須滿足的用戶需求。例如社交產品的加友功能；音樂產品的聽歌功能。

• 期望型需求：用戶滿意度隨著此類需求的滿足程度而線性提升或下降。當此類型需求越得到滿足則用戶滿意度越高，反之則用戶滿意度越低。例如，音樂類產品的歌曲越多越好。

• 興奮型需求：是一種完全出乎用戶意料的屬性或功能。例如微信的搖一搖。

• 無差異型需求：這類需求無論滿足與否，用戶滿意度都不會受其影響，用戶對此因素並不在意。例如產品的簡介。

• 反向型需求：用戶沒有此需求，提供後滿意度適得其反。例如產品付費功能。

3. 功能需求

功能需求描述的是開發人員需要實現什麼，是需求的主體，它描述的是開發人員如何設計具體的解決方案來實現這些需求（how），其數量往往比用戶需求高一個數量級。

這些需求記錄在軟體需求規格說明（Software Requirments Specification）中。 SRS完整地描述了軟體系統的預期特性。開發、測試、質量保證、項目管理和其他相關的項目功能都要用到 SRS。

7.3 獲取步驟

我們必須知道獲取需求的具體步驟

1. 標識項目干係人： 干係人列表
2. 與項目干係人交流：溝通計劃
3. 收集需求： 需求溝通紀要
4. 重要性排序：需求優先順序
5. 選擇需求： 根據資源和約束，選擇實現的需求
6. 記錄需求：編寫文檔

軟體研發是一個團隊性工作，各個角色協同工作，共同把項目完成。每個階段和角色的產出，又是下一階段和角色的輸入。比如作為架構師，會根據產品經理編寫的功能需求說明書，進行整體系統架構設計，而開發人員，也會根據產品經理的需求說明書和架構師的概要設計，做詳細的設計和開發。

8. 需求要素

8.1 角色、場景

一般來說每個業務活動是對用戶使用場景的抽象（例如電商購物活動），每個業務活動可能包含多個場景（例如商品瀏覽、購物車、下單、支付），分析使用場景時應按照業務活動為主線逐個進行分析，每個業務活動分析時應包含如下內容：

1.明確活動執行角色

2.明確活動執行的前置條件

3.明確不同場景：

一個業務活動可能包含正常的使用場景、備選使用場景和異常使用場景

4.明確每個場景的執行步驟

5.業務規則和約束：

明確在每個業務活動下應遵循的業務規則和約束，這裡一般是與業務流程相關的行為規則，或與數據實體相關的數據規則（比如某個欄位的長度）

8.2 業務流程

針對流程類需求必須進行業務流程分析。需求人員進行流程分析應遵循如下方法：

（1）業務流程確認

一個流程為一個業務事件，一般是外部角色發起或系統內部主動發起（比如時間事件或狀態事件），發起後會觸發一系列業務活動。

（2）角色及業務活動確認

流程圖中的每個泳道都必須對應到角色，每個角色對應多個業務活動。需求人員在確認業務活動時一定要保證活動的粒度，一個業務活動一定是由一個角色完成且每個業務活動都是有價值的。

（3）業務活動間關係及數據確認

確定所有業務活動的前後關係，並明確流程間傳遞的數據實體。

（4）流程整體瓶頸分析

一般若某個角色業務活動工作量較大，或流程涉及高級領導，一般都會造成瓶頸，這種情況需求人員應想辦法分散工作量提出流程優化建議。

8.3 數據實體

針對流程類需求需要分析各業務活動傳遞的數據實體，統計分析類需求需要分析統計查詢條件數據實體和展現數據實體，介面類需求需要分析介面傳遞數據實體，具體分析包含如下內容：

1.明確數據實體

確認需要分析的所有數據實體，明確哪些為系統原有實體、哪些為新增實體、哪些為改造實體。

2.明確所有數據實體間關係

實體間關係包含（1對1、1對多、多對多），另外需要分析數據實體變更是否需要保留版本，實體刪除（邏輯刪除、物理刪除）是否影響其它數據實體。

3.明確數據實體欄位

針對新增數據或改造數據實體需要明確新增欄位的名稱、欄位類型、是否必填、欄位取值方式（人工輸入、系統自動繼承自其它數據實體、系統自動計算需要明確計算公式）。

4.數據許可權分析

需要分析不同角色在數據許可權方面的差異，若涉及縱向多級用戶，要說明對於集團/省/地市用戶的數據隔離。

8.4 功能性需求

系統功能分析是結合系統現狀和上述分析進一步明確實現相應用戶場景的系統功能，主要還包含內容如下：

1.功能列表

分析得出實現上述業務活動對應的功能/介面列表，並明確新增功能、改造功能；

2.功能/介面關聯影響分析

實現某個業務活動需要新增或改造的功能對其它關聯功能/介面的影響分析。比如改造請購池受理功能，可能會影響採購項目創建功能；採購項目創建功能修改一個欄位取值範圍，會影響項目統計分析和同步ES系統介面。

3.系統交互原型分析

需求人員應遵循界面規範，並與研發溝通確定系統交互原型，幫助研發或用戶更好的理解需求場景。

在交互原型中應包含如下內容：

• 原型界面的名稱、入口，原型間關聯關係和使用角色
• 頁面內容、格式及排序方法
• 操作要點：比如交互的信息提示、界面規則和約束（比如界面以不同顏色顯示不同的校驗結果）。

4.演算法分析：

在系統功能交互時涉及比較複雜的演算法，需要單獨對演算法進行分析。

8.5 非功能性需求

包含需求的可行性分析、健壯性分析、可擴展性分析、執行效率分析，可行性分析從以下幾個方面進行：

1.技術可行性 系統交互實現方式與研發確認是否可行，需求人員在與研發溝通過程中需要不斷積累哪些功能實現在技術層面很難支撐。

2.時間可行性 根據用戶的上線時間要求分析是否可滿足要求。

3.合法合規可行性 分析用戶需求是否滿足國家法規或公司法規要求。

4.數據安全性分析 用戶需求是否滿足信息系統安全要求。

9. 案例：電商訂單系統

9.1 概述

電商所有模塊中，訂單系統是非常核心的一個子系統，決定了整個流程能不能順暢的執行，起著承上啟下的作用，其他模塊都是圍繞訂單系統進行構建的。訂單系統出問題，或者功能流程設計不完善、不准確，將會造成整個電商系統整體或局部業務流轉不順暢，甚至導致項目的失敗。

訂單系統的作用是：管理訂單類型、訂單狀態，收集關於商品、優惠、用戶、收貨信息、支付信息等一系列的訂單實時數據，進行庫存更新、訂單下發等一系列動作。訂單系統業務的基本模型涉及用戶、商品（庫存）、訂單、付款。訂單基本流程是下訂單-->減庫存，這兩步必須同時完成，不能下了訂單不減庫存（超賣），或者減了庫存沒有生成訂單（少賣）。

下麵我們從需求分析的角度，來看一看B2C電商中先款後貨模式下的訂單系統設計的過程。

9.2 角色

一個訂單系統，涉及到的角色包括：

實體角色：

• C端用戶
• B端商戶
• 電商平臺
• 配送商
• 第三方平臺

系統關係：

9.3 場景(用例)

從用戶的角度，我們看到的用戶場景如下：

用例圖：

9.4 功能

訂單系統業務架構：

（1）訂單服務

該模塊的主要功能是用戶日常使用的服務和頁面，主要有訂單列表、訂單詳情、線上下單等，還包括為公共業務模塊提供的多維度訂單數據服務。

（2）訂單邏輯

訂單系統的核心，起著至關重要的作用，在訂單系統負責管理訂單創建、訂單支付、訂單生產、訂單確認、訂單完成、取消訂單等訂單流程。還涉及到複雜的訂單狀態規則、訂單金額計算規則以及增減庫存規則等。在4節核心功能設計中會重點來說。

（3）底層服務

信息化建設達到一定程度的企業，一般會將公司公共服務模塊化，比如：產品，會構建對應的產品系統，代碼、資料庫，介面等相對獨立。但是，這也帶來了一個問題，比如：訂單創建的場景下需要獲取的信息分散在各個系統。

如果需要從各個公共服務系統調用：一是會花費大量時間，二是代碼的維護成本非常高。因此，訂單系統接入所需的公共服務模塊介面，在訂單系統即可完成對接公共系統的服務。

9.5 實體

9.6 流程

流程是指從平臺角度出發，將訂單從創建到完成的整個流轉過程進行抽象，從而形成了一套標準流程規則。每個流程觸發的條件又可分為系統觸發和人工觸發兩種場景。

下麵以一個通用B2C商城的訂單系統為例，根據其實際業務場景，其訂單流程可抽象為5大步驟：訂單創建>訂單支付>訂單生產>訂單確認>訂單完成。 如下圖：