一、開篇

       本篇主將具體結合HRMS系統進行架構概要分析，按照上篇的理論指導，開展具體的架構分析過程實踐，通過分析找到關鍵功能、關鍵非功能性需求（關鍵質量及約束）等。

      在闡述具體的架構工作方法之前，請大家先檢視以下三方面的內容：

     1、HRMS系統的介紹？（涵蓋哪些功能？價值和作用是什麼？行業什麼情況？）

      2、本章分析的內容將圍繞4類企業代表的業務場景，（區分不同規模企業的關注點，規模將決定系統的設計方案）

      本篇將圍繞4類企業代表來闡述不同規模企業對於HRMS的需求及應用

•       A、100人以下的中小企業
•       B、500人以下的大中型企業
•       C、1000人以上的集團化大企業
•       D、全球型別的公司體系（幾萬人）

      3、架構師在設計該系統時的職責及具備的核心能力是什麼？

一、架構準備階段主要做什麼？

       架構準備階段主要是圍繞系統的全方位的需求分析來開展相關準備工作的，這裡的需求涵蓋功能性及非功能性2大類需求，非功能性需求又涵蓋質量屬性及約束兩項內容，我們在實際的分析過程中需要重點考慮業務功能、質量屬性及約束等內容，具體可採取表格方式進行梳理，藉助科學的方法找出來哪些是關鍵功能、哪些是關鍵質量需求、哪些是關鍵約束。

關鍵功能、關鍵質量屬性及關鍵約束等內容對於架構設計的實際影響有哪些呢？在這裡我們梳理成表格來呈現這樣大家有一個比較直觀的感受：

架構是圍繞需求來開展的，在對需求綜合分析的過程中，我們將需求劃分為3個層次：

業務級需求：包含客戶或出資者要達到的業務目標、預期投資、工期要求，以及要符合哪些標準、對哪些遺留系統進行整合等約束條件；

使用者級需求：使用者使用系統來輔助完成哪些工作。對質量要求如何。使用者群及所處的使用環境方面有何特殊要求。

開發級需求：開發人員需要實現什麼。開發期間、維護期間有何質量考慮。開發團隊的哪些情況會反過來影響架構。

　　對於此三類需求弄清楚之後，就可以形成一個初步的需求列表。

　　一方面為了滿足上述3類需求，同時還考慮到影響架構設計3個維度方面的內容，我們採取ADMEMS的需求型別及需求層次的二維矩陣表，來進行結構化的梳理，這樣更直觀也更清晰，我這裡先將考慮的維度放在這，後面關於HRMS系統的需求分析的過程中我將按照該方法進行整理：

我們瞭解了需求的層次、需求的型別，知道了他們對於架構的影響，也熟悉瞭解了他們之間的關聯關係，那接下來對我們來說最重要的就是理清思路，如何把需求全方位的陳列出來，利用需求層次及需求分類羅列整理。HRMS系統非常的複雜，功能較多，應用的場景及型別也比較繁多，所以最好的方式就是把需求列清晰：

通過需求的結構化整理，需要從這些需求中找到關鍵功能、關鍵質量及關鍵約束，並將關鍵質量、關鍵約束轉化為衍生的設計需求：

1、確定業務功能

關鍵的業務功能包含如下四個方面：1.核心功能；2.必做功能；3.高風險功能；4.獨特功能。

　　如何區別這四個方面，實際上是靠經驗和感覺。它們之間實際上是有重疊部分的。

核心功能：業務層介面所反映的功能。如，HRMS系統中，前面說的8大業務內容都屬於核心功能；

必做功能：必做功能實際上是以客戶為背景的，簡單來說就是願景；

高風險功能：顧名思義，哪些功能操作可能會涉及到安全和隱私等問題；

獨特功能：實際是上訴三個功能的補集，看看還有哪些沒有覆蓋到的，卻又很關鍵的功能。

　　架構師在設計階段要考慮到“關鍵功能”所佔有的比例，沒有明確的標準，一般遵循：功能少的系統比例高一些，功能多的系統比例少一些。

2、梳理非功能性需求涵蓋質量及約束需求，將這些質量及約束背後的衍生需求梳理清晰：

關於質量要求這塊的內容涵蓋的範圍非常的廣泛，涵蓋：1.效能  2. 安全性 3.持續可用性 4.可靠性 5.魯棒性 6.易用性 7.可測試性 8.可重用性 9.可維護性 10.可擴充套件性 11.可移植性 12 可互操作性等。我們在做HRMS系統架構設計時考慮的質量屬性裡面也不需要把每一個指標都做上去。這些指標之間是相互影響的。其影響關係如下（+表示促進  －表示影響  空白表示無明顯作用）：

當出現多個質量屬性出現互斥的時候，必須要權衡以哪個為主，那相應的另外一個質量屬性就會弱化。

在架構設計中，對非功能性需求的重視程度，也會影響架構設計的好與劣；但也要平衡過渡設計和適可而止的關係。

二、如何找出關鍵的功能性、非功能性需求、關鍵約束？

1、找到系統的關鍵功能（系統具體是做什麼的？）

我們可以採取職責鏈模式來梳理關鍵功能：

模擬不同型別的使用者如何通過系統實現業務需求的過程，藉助系統化的思維模擬跟蹤各環節，梳理清晰後即可得出清晰的職責鏈，這樣便可以找出各鏈上的關鍵功能點，這些關鍵點即是關鍵功能。藉助職責鏈模式來梳理核心功能，確認系統中存在必要功能、HRMS系統中的8大業務模組，這裡再強調下：

上面8項屬於核心功能。除此之外，還應該會有流程管理、許可權管理等功能，輔助及支撐系統執行的基礎功能。

2、確定關鍵質量的5大原則（找出關鍵質量屬性）

• Ø分類合適+必要擴充

       針對質量分類進行細化及分解

• Ø考慮多方涉眾

       使用者不僅關注功能，同時也需要質量，使用者關注的質量可能包括易用性、效能、持續可用性、魯棒性等，客戶不一定是終端使用者，比如超市銷售系統的客戶是超市老闆，但終端使用者可能是收銀員或上貨員，他們所關注的質量屬性可能不一致。

• Ø檢查性思維

       隨時檢查各個質量屬性，看看每一項是否確實算不上“關鍵質量”，從而防止遺漏關鍵需求。

• Ø識別矛盾+劃定優先順序

       確定這些質量屬性之間的矛盾關係，明確以哪些質量屬性為主。

• Ø嚴格程度符合領域與規模特點

       嚴格程度符合領域與規模特點

       關鍵質量屬性個數根據專案、產品、平臺不同而不一樣

       諸如：銀行專案（注重安全性、易用性）;網際網路服務專案（注重持續可用性、易用性、效能、可靠性等）

3、找出關鍵約束並將這些約束轉化為功能或質量需求

首先，按照4類約束進行羅列（儘可能全面）

其次、分析約束面向的功能、質量方面的轉化

最後、確定這些約束轉化後的功能、質量是否重要

4、•第1步：需求結構化；•第2步：分析約束影響；•第3步：確定關鍵質量；•第4步：確定關鍵功能

三、HRMS系統的關鍵功能、關鍵質量指標及約束

無論介紹的，還是本篇前面介紹的內容基本上都是理論偏多一些，當然其中有一些具體的原則及操作方法，可能大家還不清楚具體的如何下手，如果真來一個專案，我該怎麼循序漸進、由淺入深呢？下面我們就以HRMS為例來簡單說明，我們來具體實際操作一下大家就會有比較清晰的認識了，希望大家能夠掌握其中的精髓。需要多實踐和總結。

3.1、梳理出需求層次及需求型別（形成表格）

在前面我們描述了4類企業類別，在梳理需求前，我這邊根據實際情況將企業劃分為4類：

•       A、100人以下的中小企業
•       B、500人以下的大中型企業
•       C、1000人以上的集團化大企業
•       D、全球型別的公司體系（幾萬人）

我們可直觀看出上述按照企業的規模、人員數量來進行的劃分，因為我們都知道在系統架構設計時，一般來說規模及數量對於架構的影響是決定性的，所以這裡先基於這個維度來對企業分類。

3.1.1 業務級需求

       前面我們羅列的HRMS系統的功能，我這裡不在重複羅列，我認為這8項是基礎業務級需求，上述的4類企業都需要提供這些功能。（具體請參考上面的HRMS系統功能圖）

       同時為了區分不同規模、人員數量企業的差異性，我這邊又整理了幾方面的需求內容，模擬甲方提出：

       注意事項：（前面規模較小的公司個性化的功能，後面規模較大的企業預設會有這些功能，所以很多內容我沒有重複列出）

   A、100人以下的中小企業（單個企業內部使用）

• 不同的使用者看到的內容不同、可以單獨管理各自內部的事宜
• 業務審批流程，支援自定義
• 與郵件系統、OA、財務系統等整合
• LInux環境、java語言、內外網均可使用
• 需要提供app與pc端服務接入
• 資料統計及分析

    B、500人以下的大中型企業（多個公司內使用）

• 支援多分公司管理模式（不同分公司看到的模組及資料不同，相互隔離，總部能看到）
• 各分公司主要是作為業務拓展，按照總部的管理流程及制度來執行
• 功能優化及升級，由總部統一規劃及實施，各地可以提需求
• 硬體及軟體環境由總部統一管理及維護
• 採取雲端部署模式，部署前需各地提出相關需求
• 支援wap、微信等服務接入
• 大資料跟蹤（指導各部門的人力資源及管理優化）

     C、1000人以上的集團化大企業（業務拆分模式的集團化公司）

• 大集團公司下設多個小集團公司，各集團公司的業務不同和垂直化分公司的管理模式不同，需要系統支援該型別的配置管理
• 資訊流轉及上報的業務線需要跨多個公司及職級，業務線不能亂。
• 各集團子公司自定義內部的管理體系，總公司制定統一工作要求並給予指導
• 總公司及各子公司均有資訊中心，各自建設內部的資訊化，最終通過總公司資訊中心進行統籌
• 科學決策及指導（人才戰略）

     D、全球型別的公司體系（幾萬人）（跨國公司）

• 不同國家分公司的內部管理系統的功能模組不同
• 系統支援各地國家當地的語言
• 總部、分公司及下屬部門間的資訊聯動及共享支援，可按層級設定彙報線及審批流
• HRMS系統接入的第三方系統略有不同（OA、ERP等）,根據不同國家的公司情況，各公司統籌，對於總公司統籌的服務，各分公司按要求使用
• 企業指揮艙（內部+外部）

3.1.2 質量屬性

A、開發期質量

       一般來說，甲方不會是專業的軟體公司，如果是預設甲方會內部自主提出相應的需求提出具體的設計規劃方案，這其中便會考慮系統的質量要求，對於開發過程中的質量要求一般需要在架構設計時主動考慮，提供相應的問題來諮詢或為甲方提供專業的建議及諮詢。對於甲方確認的內容可重點關注，對於甲方沒有主動提出的，需要我們根據行業經驗做好判斷來落實。

基於前面模擬提出的個性化的需求，我們來綜合梳理下開發期的質量要求：

基於上面的分析，我們已基本確認了不同規模的企業的HRMS系統需要考慮的質量屬性略有不同。

B、執行期質量

針對執行期的質量考慮，主要是基於使用者使用過程中的各類場景來展開進行分析，提取出上述幾類質量屬性方面的要點：

相對於開發期的質量屬性來說，執行期的質量屬性更多、更復雜、更重要，所以我們需要特別重視。

3.1.3 系統約束

基於前面列出的應用需求，我們綜合4類企業的約束，形成統一的約束清單：

       上面我們系統化的梳理了系統的業務功能、質量屬性及約束內容，下面我們採取需求層次-需求型別二維矩陣來找出關鍵功能、關鍵質量屬性及關鍵約束。

3.2、確定關鍵功能、關鍵質量屬性及關鍵約束

      在確定關鍵功能、質量屬性及約束之前，我想再限定和說明個前提，以便大家更好的理解，我們需要開發一個SaaS版本的系統，全方位的支援上述4類企業的需求，過程中我們作為一個企業，需要考慮成本、商業模式、企業未來的戰略及盈利等方面的內容。

       所以基於這些約束及現狀，我們可以梳理得出以下的關鍵功能及質量、約束的表格。作為後續我們做概要架構的前提和基礎。

上表的具體的推演過程如下：

A、確定組織級的功能、質量、約束等內容

B、確定使用者級的功能、質量、約束等內容

C、確定開發級的質量及約束等

D、將約束衍生為質量屬性及功能、將質量屬性衍生為功能

將關鍵約束衍生為功能：

根據功能提煉出非功能性需求：

E、形成統一的二維表（形成關鍵結果）

（如上表）

F、總結

       通過上述的幾個環節，我們把不同型別的約束轉化為質量屬性及功能需求，最終我們形成了最終的需求二維矩陣，這將為我們的架構指明方向，後續我們再做架構的設計及規劃的時候就能夠做到有的放矢，不會走錯方向。

四、更多資訊

關於更多的系統架構方面的知識，我已建立了交流群，相關資料會第一時間在群裡分享，歡迎大家入群互相學習交流：

微信群：（掃碼入群-名額有限）