同样的流程和操作，由于输入的数据业务规则不同，因此进行数据处理时采用的方式也不同。对于这样的情况，我们可以把功能按照业务规则来进行拆分。

典型的例子是搜索引擎，比如Google。在Google中，输入框只有一个，但Google会根据你所输入的数据规则的不同，来进行不同的处理操作。看下面几种情况：

在Google搜索框中输入一个关键字，得到这个关键字相关的搜索结果

在Google搜索框中输入一个算式，如“ 1+1=”，得到算式的结果

在Google搜索矿中输入“ThoughtWorks site:”，得到在这个站点中出现ThoughtWorks的页面

…

对于这样的情况，我们可以把每一个业务规则都单独拆分成一个用户故事。当然，虽然这些用户故事看起来很相似，但是大部分情况下，这些规则的优先级是截然不同的。总会有一簇最高优先级的用户故事以及围绕在外围的用户故事。比如在这个例子中，对于Google来说，支持关键字搜索一定是最高优先级的，需要在产品设计的一开始就要实现，而能够计算算式的，可能很多年之后，才开始考虑加这样一个功能。

第二种情况，是对同样一个流程，在终端接不同的网关或渠道。最典型的例子是在线支付。比如，我在京东上买了一盒磁力橡皮泥，提交订单进入支付流程，在支付页面可以选择微信支付、京东支付、银行卡支付等等。

第一次实现支付的功能，可能会比较复杂，但后面如果从一种扩充到多种支付方式，就相对比较简单。而且最先需要支持什么样的支付方式，你可能在一开始也拿不定主意。这个时候，我们不妨将支付功能拆成2张卡，形如

会员可以使用微信支付/京东支付/网银支付中的一种进行支付

会员可以使用微信支付/京东支付/网银支付三种渠道进行支付

使用这种拆分方法，atv，可以延迟决策-我们需要最先支持哪种支付方式，同时合理的评估项目的工作量。

对于有的系统，业务模型可能会非常复杂，比如一个房产交易平台中的房产信息，可能包含户型信息、中介信息、地理位置信息、价格及购买相关的税率信息、展示图、效果动画等等，当我们需要在系统中引入这样一个业务模型时，如果一上来就要考虑清楚这个业务模型的方方面面，是个性价比很低的事情——做了很多功课，但没有给客户带来真正的业务价值。

这个时候，我们需要将业务模型，按照我们实际需要提供的功能进行拆分。比如，我们要做一个中介搜索系统，可以仅取出模型中的中介信息，而不需要处理其它部分。即使我们需要整个业务模型去做一些事情，也可以把其拆成一个个子模型，根据子模型的业务价值及优先级去设计相应的功能。

比如在这个例子中，我们需要对房产的信息做展示

对于户型信息，需要有户型图，户型相关的文案展示

对于中介信息，可以看到中介人的头像、联系方式，可以使用多种方式在线联系中介代理

对于地理信息，我可以在Google Map上查看其地理位置，并能够从我的位置导航过去

对于展示的图片和动画，我需要像幻灯片一样，可以在页面上播放

……

那么，如果我们一开始就着手于解析这个房产业务模型，那可能浪费了很多时间，而没有交付对用户有价值的业务功能。这个时候，我们需要区分哪些信息是核心信息，是对用户来说最有价值的，把这些信息从业务模型中提取出来，而后设计相应的更小的业务功能，切忌一蹴而就。

需求拆分是没有银弹的，要根据具体的场景、限制来选择合适的拆分方法。在遇到使用某个拆分方法，不能满足当前业务需求时，看看是不是可以换个思路，换个方法。

当然，在选择拆分方法时，也有一些技巧，如

基于80/20法则，选择那些可以拆出低优先级卡片（或者可以被扔掉的卡片）的拆卡法。

选择可以把卡片拆的大小差不多的方法，未来在发布计划中更容易做需求置换

选择开发团队更容易理解和实现的方式