需求范圍定義的工作重點在于明確項目的目標和范圍，通過三步走的方法，界定了需求范圍以后，就可以以業務事件列表和報表列表為線索，進行進一步的需求分析需求分析和需求業務建模提供架構基礎。

一、需求范圍定義

我們在做項目的時候，進行需求工程分析項目，為了能給需求分析與需求建模提供有效的支持，避免出現“上梁不正下梁歪”的情況，我們在立項階段的需求范圍定義就顯得尤為重要。而需求范圍的定義應該放在項目的啟動立項階段，對整個項目的宏觀業務需求，起到指引的作用。

一句話說就是：明確項目的目標和范圍。

那么需求范圍定義的應該怎么做？結合筆者的經驗，三步可以概括：

1. 劃分主題域，進而畫出構件圖，即摸清楚結構性框架；
2. 繪制上下文關系圖，找到主題域承擔的責任，即找到每個板塊的業務范圍；
3. 標識業務事件和報表，輸出需求大綱。

劃分主題域顧名思義就是劃分板塊，但是劃分的方法，維度，參考的標識應該是什么呢？我們可以通過兩個方法來識別：

• 以“事”為線索劃分主題域，通過業務事件找到業務流信息；
• 對于復雜的聯機處理業務系統，單單以一條線劃分主題域還不夠，結合職責劃分主題域會有更好的效果。

二、案例：商旅平臺系統

（1）確定主題域

通過典型的業務職責，將系統分為：銷售、生產、售后三部分。

• 銷售職責區塊：由于產品特性，商旅針對的B端用戶是組織和企業。所以這里的客戶是企業。銷售這個業務職責就是對客戶企業的管理，服務跟蹤，運營數據數據分析等，這里把這個主題域命名為客戶管理子系統，也是通常說的CRM
• 生產職責區塊：這個職責區塊就是為企業用戶提供全面的商旅業務（包括機票，酒店，用車等），也就是商旅業務就是他的核心生產業務。因此可以把這個業務區塊主題域稱為“商旅業務系統”，但是由于業務相當復雜，以及服務業的特性，光是一級主題域還不夠，商旅業務子系統下，平臺內部還應該劃分更細的業務職責以及協同職責，這里才是整個平臺高效運轉的核心，也是我們劃分主題域的核心工作，所以這個案例的重點是把業務系統下的二級主題域劃分清楚。
• 售后職責區塊：這個區塊，為企業提供售后的支持的主題域，主要是財務上的，和C端的旅游不同，商旅很多是企業和平臺月結的，而平臺和供應商一般也是周期結算。所以售后這個區塊一是平臺和企業的按照周期結算對賬，二是平臺和供應商的結算。這個主題域叫做結算系統。

下面我們來進一步二級主題域的劃分。

在業務子系統內部，由于業務的特殊性和復雜性。我們進一步進行職責劃分：生產、支持、服務三個職責區塊。

• 生產職責區塊：商旅平臺在本質上屬于電商平臺，只不過商品不是實物產品，他只是一個平臺代理商，所以它的核心業務應該是屬于電商：查詢、下單、支付、發貨這個完整的業務流程。這個主題域我們把它叫成：生產系統。業務要走的通，除了業務，還應有資金。支付方式如果支持多種：月結、現結、預存，那么還應該有支付系統，或者第三方提供支付服務，提供支付接口，或者提供記賬的虛擬支付系統。
• 支持職責區塊：由于業務的復雜特性（以機票為例：各種政策投放，優惠，里程兌換，行程單報銷，短信通知），質量風控，投訴質檢等。需要大量的運營人員以及系統對業務的支持。這里把所有的業務支持的東西都放在一起，叫業務支持主題域。生產上即業務支持子系統
• 服務職責區塊：由于服務行業7*24服務業的特性，在這個職責區塊上，為了給客服中心提供有效的協同支持，還應該有工單子系統，呼叫子系統。

第二步：繪制構件圖

完成了主題域劃分以后，可以用一個構件圖，標識出各主域題之間的關系，即找到各主題域之間的接口，把整個系統聯系起來，搭建出整個業務框架。

在前面我們已經標識出了一級主題域有：“客戶關系管理系統”、“商旅業務系統”、“結算系統”，現在我們先來梳理一下一級主題域之間的關系。

客戶關系管理子系統和商旅業務系統：以商旅機票服務為例，只有企業賬戶已經開通，企業下的用戶才能在業務系統下單，所以在用戶下單時候，需客戶關系管理系統提供相應的用戶數據，企業信息給業務系統。而為了分析企業的商旅出行的數據等，業務系統還應該把訂單數據回傳給客戶關系管理系統，以為生成各類運營報表提供基礎。所以這兩個主題域之間的接口應該是：CRM提供查詢客戶資料的接口供業務系統查詢，業務系統提供同步訂單數據的接口給CRM。

客觀關系管理系統和結算系統：企業當月使用多少票量，應該月結金額多少錢，企業是否按時還款，這塊數據應該由結算系統同步給給客戶關系管理系統。所以這兩個主題域之間的接口應該是：結算系統提供數據給CRM生成報表。

供應商主題域：在確定最終的主題域之前，我們還需要結合最終的目標來考察這些主題域。從目標范圍的角度來說，商旅平臺，只是作為一個代理商，他沒有真正的產品。剛才我們分析的都是對內的關系，還應分析對外的關系，即平臺是通過整合其他渠道或者代預定的方式來提供服務的。所以考慮他的產品從哪里來，就會自然想到其供應商，這里統一叫成：供應商主題域。當然從機票的業務來講，可能有：黑屏，航司官網，其他OTA等等。從其他平臺有交易，有業務就有資金。所以還應該有對供應商的支付體系。

第一級主題域的構件圖畫好了，標識出服務接口：

如下：

下面來確定第二級主題域的構件圖：

首先確定二級主題域之間的關系：生產系統、供應商業務系統、供應商支付系統、業務支持系統、工單系統、外呼系統。

生產系統和供應商系統：以機票為例，來找這兩個主題域之間的關系。我們以“事”為線索，從業務事件，找到業務流程，最終推演業務活動。機票下單首先航班信息這些不是憑空變出來的，都是從供應商那里獲取到的，包括航班信息，艙位信息，運價，座位的查詢，部分退票改簽政策等應該由供應商提供。如果用戶下單，那么平臺還應該去供應商那里自動創單，所以還應該對接供應商業務系統的下單接口，供應商提供的支付接口。

生產系統和業務支持系統：

• 由于業務的特殊性，對于大客戶企業，航空公司會有三方或者兩方協議政策提供優惠，每種艙位折扣的優惠力度，又由于每個時間段折扣不同，航線不同折扣不同，高管白名單等。這些都應該維護在業務系統中給生產系統出票提供支持。
• 退票改簽的政策也各個航空公司有差異，每年都在變，甚至每個季度都在變，這些應由運營人員根據航空公司，企業大客戶政策，航班艙位多個角度實時更新并給生產提供支持。
• 作為平臺來講，會有一套自己獨有的出票邏輯體系，供應商出票優先級，政策投放規則以實 現盈利，所以業務支持系統維護出票配置，供應規則等給生產系統，當然這部分也可以放在生產系統本身當中，這里不詳細介紹。

生產系統和工單系統：電商訂單無時無刻不在產生，對于7*24小時的人工服務，客服人員隨時在處理訂單的問題，也需要其他業務組，或者部門來處理的，甚至是需要技術人員處理（如退款失敗，需要人工退款），要實現高效的輸出，團隊協作必不可少。而其他業務人員想要快速實現高效協作，工單系統中的訂單信息必不可少，應該由生產系統通過服務接口提供給工單系統

生產系統和外呼系統：對于人工出票，客戶致電后為了能實現智能接聽，快速識別出客戶個人信息，已預訂的訂單信息，應該由生產系統提供信息給外呼系統。

通過各個二級主題域之間的分析，找到了二級主題域之間的服務接口，繪制成構建圖后如下：

通過我們對系統整體進行主題域劃分之后，并且標識出各主題域之間的關系，即服務接口以后，系統整體的架構就一個雛形了（案例只是標識了部分業務接口，具體還有很多其他業務接口，技術上的功能接口未標出）。下面一步就是進一步對各主題域內部進行細節梳理。

（2）繪制上下文關系圖

什么是上下文關系圖？

當把系統的范圍縮小到一個主題域時候，涉及的內容就大大減少了。這個時候我們針對每個主題域來分析，分析其所要承擔的業務責任。

我們以二級主題域，業務最復雜的生產系統為例來繪制上下午關系圖，通過三個步驟來抽絲剝繭，分析出細節脈絡。

a. 將整個系統看成一個盒子

b. 找到系統中所有的customer（客戶）和worker(工作人員)

c. 分析customer和worker主動發起的事件

首先把這個生產系統看成一個黑盒子，用矩形表示；接著思考這些主題域需要哪些外部的customer，內部的worker？

很顯然，這里的customer最重要的商旅用戶。他發起出差肯定會提交出差申請，不管是事前出差申請，還是訂票中提出差申請。那么會有他的領導來審核，對于生產系統來說也是屬于customer。

申請通過以后就會進行在生產系統訂票，生產系統這個時候需要到外部供應商那里去購票，這個時候，企業的業務協同就開始了，所以供應商，結算系統，業務支持系統對于生產系統來說都是屬于外部的worker。結算系統負責資金流，業務系統提供業務支持，供應商系統負責提供票務。

用戶除了訂票還會有什么獨立的行為呢？可能會因為天氣原因，個人原因臨時改變行程，發生改簽或者退票。這是一個獨立的，不是必然發生的事情。首先應該由customer提出申請，然后由平臺客服運營人員進行審核后提交給航空公司或者供應商處

如果退改簽的審核通過，則會進行相應的收取手續費或者退款，因此將這兩個信息添加到上下文關系圖中，這時候就會得到。

分析完了customer主動發起的事件后，我們來繼續分析worker主動發起的事件。從生產系統customer以外的都是worker，包括供應商，協作系統，財務系統等。

下面我們來分析幾個例子：

• 航空變動：天氣原因，原航班有延誤，取消等通知需要通知給用戶，通過業務支持系統中的短信模塊來發送短信通知用戶（如果出票有短信服務也會通知）；
• 企業余額不足：企業在商旅系統上余額不足，不足以支付后，將會通知給用戶；
• 航旅個人報告：個人的商旅航分析報告，主動推送給用戶。

其他例子不詳細說明。

我們再加上這些后，上下文關系圖變得更加豐富和清晰：

到現在我們就通過以生產系統為例，從customer和worker的業務事件分析起。繪制出了生產系統的上下文關系圖

（3）標識業務事件和報表，輸出需求大綱

對于聯機業務處理的系統而言，業務事件（業務流程）是核心線索，對于管理信息系統而言，report（包括各種查詢，分析，統計）是核心線索，而在此案例中，商旅平臺屬于復雜的聯機處理事務系統。

首先我們來對業務事件做個解析

業務事件是梳理業務系統需求的一個很重要的線索，因為一個企業或組織存在的核心價值在于接受外部用戶的請求，通過響應請求讓用戶滿意的同時也創造了相應的價值。

業務事件是業務流程的觸發點，標識出業務事件能夠幫助我們識別出業務流程；而業務流程是為了響應業務事件而觸發的一系列業務活動，它通常是由不同部門、不同崗位協作完成的。因此業務流程的信息是掌握在中層管理人員手里的，它屬于脈絡信息。

結合我們的案例商旅系統，在我們分析上下文關系圖的時候就是按照業務事件分析的，標注出業務事件后如下：

舉一個業務事件例子：由用戶提出出差申請（業務事件），于是產生審批流程（業務流程），需要相關人員進行審批（業務步驟），提出出差申請是業務事件，即觸發整個流程的行為，也是直接作用于系統的行為。通過這個事件，我們可以找到一系列的活動和相關部門。

解析出報表：

在此基礎上我們來分析潛在的報表。需求定義階段主要是識別出報表的類型以及為什么要這些報表，他們的使用場景。這里由于和企業需要結算對賬，就需要進行業務賬和資金賬的核對。

根據分類可以分析出以下報表：

當然，報表不一定完全，還要根據管理層的意圖，需求，進行訪談，增加報表類型等。

輸出需求大綱，產出需求范圍規格文檔。

下面就是我們的最后一步，把剛才的分析匯總成需求大綱，輸出需求規格的邊界，從主題域開始，一個一個小節列出來，闡述業務事件（包括整個流程），列表需求。搭建出了整體的系統框架。為具體的后期業務建模需求說明提供了參考。

下面是我輸出的需求大綱作為參考

Word版的文檔需求大綱：

XXX商旅平臺系統需求規格說明書：

1.文檔概述

（略）

2.任務概述

2.1業務需求

• 為大型企業提供一站式商旅解決方案，包括審批，預訂，出行，報銷全流程服務
• （其余略）

2.2用戶人群分析

（略）

3.業務模型分析

本系統由客戶關系管理系統，商旅業務系統，結算系統，將從業務的銷售，生產，售后等范圍進行提供支持，其范圍如下：

主題域劃分示意圖

3.1客戶關系管理系統

本主題域主要對客戶關系管理提供支持，主要對企業信息管理，用戶信息管理，消費統計等分析，其范圍如下：……

（略）

3.2商旅業務系統

本主題域主要為企業提供整體的商旅業務。在此主題域下又劃分為：生產系統，供應商業務系統，供應商支付系統，業務支持系統，工單系統，外呼系統主題域。其關系如下：

3.2.1生產系統

生產系統是整個業務生產的核心系統，是連接各個二級主題域的中樞，下面是生產系統的上下文關系圖，標識出了生產系統范圍。

3.2.1.1業務事件

• 提交出差申請
• 撤銷出差申請
• 預訂出票
• 申請改簽
• 申請退票
• …

3.2.1.2服務接口

• 獲取企業信息
• 獲取用戶信息
• 獲取訂單信息
• 下單接口
• 支付接口
• 退票接口
• 退款接口
• 改簽支付接口
• …

3.2.1.3報表

• 出票周期統計報表
• 改簽周期統計報表
• 退票周期統計報表
• 航旅分析統計報表
• …

3.2.2結算系統

（略）

…

4.具體需求

4.1生產系統

4.2結算系統

4.3呼叫系統

4.4工單系統

…

三、總結

需求范圍定義的工作重點在于明確項目的目標和范圍，通過三步走的方法，界定了需求范圍以后，就可以以業務事件列表和報表列表為線索，進行進一步的需求分析需求分析和需求業務建模提供架構基礎。

以上便是筆者的工作總結以及方法論復盤，歡迎指正和交流。

本文由 @謝君翊 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議