编辑导读：针对业务流程而设定的办理方案并不是万能的，在系统有限的范畴内，产物设计需要对界线举办了确定。本文作者从界线的观念出发，对此展开了梳理和说明，与各人分享。

业务场景与行业的团结往往是最切实际的约束条件，同样是电子商务网站，有些商品可以线上生意业务，而有些大宗商品却无法打破付出与信任的限制，也许普通商品的电子商务网站无需对用户的信用体系做审查，可是大宗商品的生意业务网站就要负起审查的职责。

大宗商品如棉花、钢铁等，交易的最小单元是批次、规格等，牵涉的金额在百万甚至千万不等，条约以及订单的履约风险是用户较量存眷的环境。譬喻棉花商品的信息与实际条约如下图所示。

从通用的角度来看，针对业务流程而设定的办理方案老是有约束的，系统的范畴老是有限的；在需求界说阶段，对系统的范畴举办界定是十分重要的。

如何确定需求的界线，推荐的 *** 是通过上下文干系图，实际上是数据流图中的顶层图。相关的思路就是将整个待开拓系统领略成一个黑盒，然后标识出外部的参加者和系统的交互干系。

而在实际的操纵中，上下文干系图的应用有两个问题：一个是系统太大，不容易一下子梳理出来。

01 范畴 vs 界线

范畴和界线需要区分隔来，范畴是指系统涉及哪些内容，而界线则是系统与人的职责界线。针对这个问题，《把握需求进程》一书中有个出色的例子，如下图

首先来看看这张数据流图。

这是一个产物销售公司的销售进程示意图；

顾主需要买对象时就会打 *** 给公司销售人员，公司销售人员按照供给商的促销数据向顾主报价，并按照当前库存量来判定可否响应该顾主的订单；

假如顾主接管了这个价值，而且也有足够的库存量，销售人员就会认为该订单是有效的，并将其转给信用核查员；

信用核查员按照顾主的汗青生意业务数据以其信用卡的环境来抉择该订单是否是安详的，然后将审核的功效返还给销售人员；

假如审核的功效暗示订单是安详的，那么销售人员就将订单记录下来

而其他环节（诸如收款、物流）将按照这里的订单记录来举办相应的处理惩罚

假如该企业规划投资20万–30万开拓一个完成包围进、销、存打点的软件系统（这个业务流程是一定涉及个中的），

那么该如何选择系统的界线，譬喻选择2号界线，可能选择2号界线，并将与信用卡公司的交互成果去掉。假如你选择的是2号界线，但用户要求实现3号界线，你将如何应对？

02 确定界线

许多时候软件设计者思量的过于全面，总想做一个大而全的系统，然而许多时候我们是按照项目标投入和资源来限制界线范畴的，假如没有项目本钱与时间的限制，那么确定界线的意义就失去了许多。

假如系统只是实现“记录订单”的成果，那么实际上意味着用户必需手动完成接订单和信用核查的事情，系统只是起到了一个电子化的成果，换句话说，通过某种形式的Excel也能记录大部门的数据。

这样的系统显然不是一个投入20万-30万的系统所应该回收的界线，或者在开拓一个通用性的进销存产物（订价在几百元）时就会将界线界说在这里。

那么2号界线呢，这时系统不只实现了记录订单成果，还将自动按照该顾主的汗青生意业务记录、提供的信用卡举办信用查抄，这里实现的成果显然与用户的投入相匹配的。只不外信用卡查抄大概会存在一些变数。

再来看看3号界线，也就是实现订单吸收的自动化，大概的要领有呼唤中心、Web网站等。这些成果固然很公道，但它是超出系统预算的，因此不该该将其纳入系统的界线内。

03 成果的取舍

没有免费的软件成果，必然的项目时间与本钱节制下，肯定需要对软件成果举办取舍，上面的例子，用户将界线从2号移到3号，也就意味着你需要开拓电子商务网站或呼唤中心；那么紧接着的是一系列的思考：

成立呼唤中心后，需要不绝的按照产物信息更新语音流程，这需要付出很高的本钱；并且数字中继、设备的维护本钱也较量高。

呼唤中心对比于人工处事其友好性更差，大概会低落用户满足度；这样客户大概会转回人工台，并不会低落本钱。

电子商务网站的建树本钱只是一部门，维护本钱更是大块，她包罗 *** 带宽用度、主机托管用度，并且安详机能保障越发重要。

你的顾主群中电子商务网站的利用率是否高，投入产出比是否符合。

你地址的行业假如是大宗商品的生意业务又当如何，思量 *** 款金额庞大，是否需要先签署条约。

04 创新界线

创新界线的问题，凡是是把顾主、顾主行为习惯纳入了系统的范畴。譬喻把购置机票后的值机处事延伸到了机场之外，而不是从达到机场后才开始。