轉載本文需註明出處：微信公眾號EAWorld，違者必究。

需求是業務和技術的橋樑，是行業知識向數字化轉換的過程，業務是需求的輸入，需求是設計的輸入。即需求的關鍵元素必須從業務分析的元素演化而來，後續的高階設計需要從需求一脈相承，一以貫之，每個元素需要有完整的生命週期和演化鏈，這是一個有機的整體。以業務物件為例，在業務分析階段，業務客體是業務物件，在需求階段，業務客體演化為物件實體，在設計階段，物件演化成為資料庫物理模型中的表或者檢視。

需求內涵包括業務需求、管理需求、運維需求、外部服務需求四部分。

需求分析師的職責是依據業務分析輸出，根據業務邊界，界定需求邊界，根據業務參與者釐清使用者，根據業務用例深化使用用例，並衍生出管理用例、運維用例、系統用例、外部服務用例，根據業務規則，規定需求的約束和限制，根據業務流程，確定工作流程、頁面流、資料流，根據業務物件，定義物件實體和介面元素。

需求分析的目標已清晰，那我們如何正確開啟需求分析這個迷宮呢？需要一個好的方法論指導，我們採用的是Rational提出的基於面向物件的軟體工程RUP方法論，基於RUP方法論，對業務需求、管理需求、運維需求、外部服務需求和約束進行提取、組織、文件化，從而定義一份完美的需求。下面我們就像庖丁解牛一樣，朝著目標，沿著正確的路徑昂首前行。

在進入正題前，我們先解個惑，那就是業務和需求的差異究竟是什麼，為何資深需求分析師也會將二者混淆？

首先，內涵不同，業務是政府或者企業的運營內容，比如石油勘探開發業務，普查->詳查->精查->勘探鑽井->開發鑽井->輸油->煉化的全流程的業務通過全手工的方式同樣可以完成。而需求是資訊化領域概念，特指業務中能夠數字化、需要數字化的使用者要求，再比如勘探鑽井需要用鑽井平臺去實現，這個動作，資訊化是無法完成的，因此這個動作是無法進入資訊化需求的列表的。

其次，外延不同，業務的外延涵蓋組織的全部社會活動，但是需求的外延是可以數字化的組織工作。

最後，主體不同，業務分析的主體是甲方或者乙方組織的行業專家或者業務專家，可以完全沒有資訊化的知識背景。但是需求分析的主體是甲方或者乙方具備資訊化知識背景而且具備需求轉化能力的分析師。

一、如何界定需求邊界？

需求分析師是天才的轉換器和過濾器，依據業務邊界，將能夠數字化同時需要數字化的業務轉換為需求，而過濾掉不能數字化或者不需要數字化的線下過程。同時，無論在業務支撐還是業務重構、業務創新場景下，需求都肩負著對業務過程進行自動化和標準化的責任。

二、如何釐清使用者？

使用者是數字化系統的訪問主體，使用者分為使用使用者、運營管理使用者、運維使用者、系統內建使用者。

最佳實踐是，從業務分析中的業務參與者出發，參與業務執行、業務運營管理、業務決策的人員，將成為使用使用者，他們使用系統的服務功能，完成業務工作。

運營管理使用者、運維使用者是業務數字化過程中衍生的資訊系統的管理和運維人員，運營管理使用者負責管理、配置系統後端功能，涵蓋了應用系統管理人員。運維使用者負責定期巡查、應急處置系統故障、資料備份、安全管理等，涵蓋了IT運維人員。

系統內建使用者是根據業務自動化和外部服務的訴求從業務數字化過程中衍生出來的使用者，它負責系統自動執行的動作。

這裡需要強調的是，所謂使用者，是針對數字化系統而言的概念，不是針對業務而言的，即使用使用者指的是使用數字化系統的人，運營管理使用者指的是運營管理數字化系統的人。所以業務的運營管理和決策人員是使用使用者，不是運營管理使用者。

以保險系統為例，保險客戶、保險產品銷售、保險產品稽核人員、保險理賠人員、保險公司管理人員、保險公司領導等是保險系統的使用使用者，保險系統管理員是保險系統的管理使用者，保險系統的運維人員是運維使用者，保險系統的內建使用者是系統使用者。

順便說一句，釐清使用者的一項重要工作是對使用者進行分類，合理、精確的使用者分類是系統切分子系統以及系統安全控制的一項基礎工作，需要科學的劃分。

三、如何抽取用例？

用例定義的方法是範圍+級別+主體+前置條件+動作（場景）+觸發事件，用例是分層次的，高階用例允許包含多個低階用例。

範圍的核心是空間範圍、組織範圍和時間範圍。空間範圍是指網路空間和地理空間，組織範圍是指用例在哪些組織機構內執行，時間範圍是指用例的生命週期。比如中國人壽的產險產品，在北京、新疆的不同地域可能會存在不同的業務規則，在不同時間段保費可能存在不同的優惠價格，北京分公司和新疆分公司可能推出不同的特色地區小險種產品等。

級別主要針對用例的樹形層級，比如一級用例、二級用例等。高階用例通常抽像級別更好、更巨集觀。

主體是用例的執行者，前置條件是用例執行需要具備的條件或者狀態，是用例的必要前提。

動作是用例的行為，觸發條件則是用例的觸發時間或者觸發事件。

最佳實踐是，依據業務用例，深化出使用用例，它是使用使用者訪問數字化系統執行的業務工作，比如錄入保險訂單、稽核保險訂單、簽訂保險合同等。

為支撐和保障使用用例的執行，數字化系統衍生出管理用例、運維用例和系統用例、外部服務用例。

管理用例是數字化系統建成後，管理員對數字化系統的管理工作，比如，身份管理、組織管理等。

運維用例是數字化系統建成後，運維人員對數字化系統進行的執行維護工作，比如模擬登入、資料備份等。

系統用例是自動執行的動作，由系統內建使用者作為用例的使用者。比如自動審批流轉、自動預警等。

外部服務用例通常從需求邊界衍生而來，是系統與外部系統整合的服務介面，將系統與外部系統在業務流程或者資料層面整合為一個整體。

用例定義的難點是，業務用例是閉環的，需求用例同樣要求閉環。但是，由於業務用例中的手工動作或者線下動作不包含在需求用例中，那麼需求用例如何保證業務的閉環呢？最佳實踐是，將由於手工或者線下中斷的不同業務環節封裝在不同的子系統中，子系統間通過整合實現完整的業務閉環。或者在系統內，將上個環節的執行結果作為下個環節的輸入資訊，延續業務流程。

強調一點，需求分析中必須包含運維需求。因為，數字化系統的價值體現在系統執行產生的效益，那麼前提是系統能穩定執行並在故障時能快速恢復，所以，系統是否能良好運維，直接關係到系統的價值是否能充分體現。比如，如果系統中的業務鏈複雜，系統執行故障時，需要跟蹤整個業務鏈才能定位系統故障點，那麼為了快速解決故障，運維需求需要包括在業務鏈中每個業務動作包含一個唯一的traceID，通過traceID能夠跟蹤業務鏈中每個業務動作執行的結果，通過日誌確定哪個業務動作結果是失敗，即可快速定位故障的程式點，從而快速排障。

四、如何抽取約束和限制？

約束和限制是用例執行的過程規則，包括業務主體、客體的空間和時限限制、效能和可靠性指標約束、環境限制、安全保密約束、使用者體驗約束等。

業務主體、客體、時限限制是指特定型別的主體在特定的空間和特定時限能對特定客體進行特定操作。

指標約束包含（使用者量、資料量、效能指標、可靠性指標）等，以保險業務為例，要求使用者訪問保險訂單時響應時間2ms，系統24*7穩定執行等。

環境限制包括系統空間限制、行政區劃限制等。安全保密約束包括使用者訪問採用加密方式，系統資料必須加密儲存等。使用者體驗約束包括使用者訪問3次點選即可完成等類似需求。

最佳實踐是細化和分解業務規則，作為需求的約束和限制。以保險業務為例，產險的代理機構領導在公司內網中上班時間才允許稽核本代理機構的產險經紀人銷售的產險訂單。這個約束，要求特定主體（保險代理機構領導）在特定環境（公司內網）在特定時限（上班時間）對特定客體（產險訂單）進行稽核。

五、如何定義流程？

流程是具有確定的開始節點、確定的環節、確定的環節轉換邏輯、確定的結束節點的一個時間或者邏輯序列。

流程圖需要包括使用者、活動、次序、輸入、輸出等關鍵元素。那麼定義流程需要先定義業務任務，分解業務任務為多個過程，將過程定位為環節，明確環節輸入和輸出，並確定環節間的並行或者序列次序，即可完成流程定義。

最佳實踐是，從業務流程細化業務執行的工作流程。然後，依據工作流程結合功能設計，確定頁面流和資料流向，定義資料流。

需要強調的是，流程定義需要涵蓋正向流程、反向流程、異常流程。正向流程是業務正常開展的走向，而反向流程是環節出現逆向動作，比如A提交申請，B稽核通過，C稽核通過，此時，A撤銷申請，或者C稽核駁回，流程需要逆向返回A。異常流程是在流程執行過程中，在某環節出現異常結果，流程如何提供異常出口，而不是讓流程停滯在該環節等。

更重要的是，流程定義，需要從高層流程向細化流程層層深入，先抓樹幹，再抓枝葉，最後深入毛細。

六、如何定義物件？

物件是數字化系統中的資訊載體，物件的內涵包含了業務主體、業務客體、事件、過程等。

如何表達物件呢？ER圖。ER圖即物件關係圖是指以物件實體、關係、屬性三個基本概念概括物件實體的資料基本結構，從而描述靜態資料結構的概念模式。

最佳實踐是，根據業務物件抽象出物件實體和物件元素，作為系統的資料概念模型。根據物件元素，設計介面上的屬性。

物件定義中的關鍵點是分析物件關係，物件間的依賴、繼承、擴充套件等關係是物件定義中保證系統資料的完整性和可用性的根本保證。

簡單而言，需求分析是說明誰（使用者）對誰（物件）按照什麼樣的規則（約束和限制）在數字化系統中以什麼樣的順序（流程）做什麼事（用例）。如果以正確的方式開啟需求分析，需求分析將是一個令人愉悅的過程，前提是，您一定要上接業務，下銜設計，讓需求分析成為一個業務到技術的完美轉身。


關於作者：郭崑山，中國第一代Java程式設計師，擁有20年IT研發和管理經歷，曾在中科軟事業部任副總經理，曾組織、規劃、設計、研發、落地推廣中國排名前三的Saas石油勘探雲，曾管理一個40人的事業部從年度虧損400萬扭虧至600萬利潤。


關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享。長