需求范围定义的工作重点在于明确项目的目标和范围，通过三步走的方法，界定了需求范围以后，就可以以业务事件列表和报表列表为线索，进行进一步的需求分析需求分析和需求业务建模提供架构基础。

一、需求范围定义

我们在做项目的时候，进行需求工程分析项目，为了能给需求分析与需求建模提供有效的支持，避免出现“上梁不正下梁歪”的情况，我们在立项阶段的需求范围定义就显得尤为重要。而需求范围的定义应该放在项目的启动立项阶段，对整个项目的宏观业务需求，起到指引的作用。

一句话说就是：明确项目的目标和范围。

那么需求范围定义的应该怎么做？结合笔者的经验，三步可以概括：

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 协议