在一个大规模复杂的系统中，通常需要采用某种方法来拆分客户的需求，对需要的拆分是撰写需求规范中必然遇到的一个问题，同时也是软件架构设计中必然遇到的一个问题。如何拆分需求，不仅仅影响目标系统的架构、性能，同时也影响项目管理中软件代码实现的时间。相同的用户需要，不同的拆分方法，导致软件开发的总的时间有可能会出现较大的差别，也会导致系统的故障的个数有较大的差别。本文将探讨拆分需求常见的原则与方法，这些原则和方法同时也适用于系统架构设计。需求的垂直切片，本质上是将大的需求纵向拆分成小但有价值的、可独立交付的小的需求。

第1章需求拆分的原则

1.1 理解需要背后的客户价值

在正式开始拆分需求之前，团队应该花一些时间梳理和确定工作目标，充分理解工作范围，比如涉及的利益相关者、需求验收标准等等。其中，明确需求价值是最为重要的。

将研发需求进一步的拆分，本质上是对交付增量做出的进一步细分。如果待拆分的需求没有明确的价值引导，那么研发工作就极有可能进入错误的方向或者「死胡同」，导致前功尽弃。

理解需求背后的客户价值和对组织的价值，是拆分需要的高阶思维。

1.2 参考：用户故事的定义方法

[需求管理-5]：需求分析 - 如何进行有潜在商业价值需求的帅选？用户故事的定义方法？_文火冰糖的硅基工坊的博客-CSDN博客

1.3 系统需求的层次

（1）功能性需求

（2）非功能性需求

1.4 需求拆分的INVEST原则：小而整

好的用户故事除了格式规范、要素完整外，还应该遵循INVEST原则：

自身角度：独立；
客户角度：可协商、有价值
管理角度：可评估
开发角度：足够小
测试角度：可测试

（1）Idependent（独立的）-- 用户故事自身的角度

要尽可能的让一个用户故事独立于其他的用户故事。

用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大小估算所涉及的范围更清晰，从而估算偏差更小。

（2）Negotiable（可协商的）-- 客户的角度

一个用户故事的内容要是可以协商的，用户故事不是合同。

一个用户故事只是对用户故事的一个简短的描述，不包括太多的细节；

具体的细节在沟通阶段产出。

一个用户故事带有了太多的细节，实际上限制了用户、团队的想法和沟通。

（3）Valuable（有价值的） -- 客户的角度

每个故事必须对客户具有价值（无论是用户、购买方还是公司内部角色）。

用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。

这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作对客户的价值。

（4）Estimatable（可评估）-- 项目管理的角度

计划会议里面一个很重要的环节，那就是故事点（工作量）的估计。

实际上就是对要开发的User Story进行一个粗量级的工作量的估算，以便于团队能够知道这个user story的复杂度（工作量）。

重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD(完成标准)来完成这个用户故事，如果不能完成，给出理由，由PO来决定是否拆分或者重新设计用户故事。

开发者难以估计故事的原因：对于业务领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

（5）Small（小的） -- 开发的角度

一个好的故事在工作量上要尽量短小。

最好不要超过10个理想人/天的工作量, 至少要确保的是在一个迭代中能够完成。

用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

备注：这里给出的10个人天，并不适合所有的场合，主要适合互联网的用户功能，在无线通信领域，只要一个10人的以内的小团队在一个迭代周期内能够完成，就可以认为已经足够小了。

（6）Testable（可测试的）-- 测试的角度

一个用户故事要是可以测试的，以便于用户确认它是可以完成的。

如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。

一个不可测试的用户故事例子：软件应该是易于使用的。

（7）补充：大小相等原则 -- 开发的角度

垂直拆分后的故事的开发工作量应该大致相等，确保开发团队能够平稳地开发软件需要。

1.5 需求拆分的三个准则：一个用户、完整价值、不依赖。

（1）一个用户

只包含一个用户，因为多个用户常常有细微的差别。

一般是典型的用户，常常有共同的某类需求。

（2）完整价值

完整地交付一个客户价值。

一个完整的用户故事意味着这个故事完成后，用户可以达成一个明确的、有意义的目标。

（3）不依赖

依赖性的三种常见类型是：重叠、顺序和包含。

重叠关系在故事之间功能点之间需要避免的；

顺序关系是现实存在，在多数情况下可以通过一些手段解决；

包含关系对复杂系统是有帮助的，利于把复杂功能分解成简单功能，但对排定发布和迭代计划的影响需要注意。

重叠依赖

重叠依赖是带来最多困扰的依赖形式，特别是多个用户故事包含多个不同的重叠部分时，很难找到一组用户故事可以代表该最小可行产品的功能集合，该集合应该包含且仅包含一次需要的功能。

重叠导致两个故事重复实现某种功能，容易导致边界混乱和不清晰。

解决方式：

将重叠部分单独剥离出来做为独立的用户故事；

合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的用户故事中；

使用Scrum开发模式。

顺序依赖

顺序依赖是指要使某用户故事完成，另外的一个或多个用户故事必须在它之前完成。

顺序依赖通常是无害的，在现实软件开发是也是常见的现象。从敏捷开发的角度，整个系统是从初始的最小可行产品逐步演化为强大的产品，后面的每一步是建立在前面的基础之上的。

但从另外的角度，不必要的顺序依赖使得排列和调整优先级变的比较困难，进而影响制定发布和迭代计划，也使得用户故事的大小估算更难以把握。（顺序依赖主要影响项目管理）

解决方式：

一个迭代内的用户故事尽量做到没有内在依赖；

保持迭代之间只有单向依赖，在时间上只有后面迭代的故事对前面迭代故事的单向依赖（前向依赖）；

剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求混在一个故事里。

尽可能把可以独立的故事独立出来。

包含依赖（自顶向下、自底向上）

包含依赖是指在组织用户故事时使用分层级的管理，比如常见的特性－故事两级管理，一个特性包含多个用户故事，这样就构成了特性对其属下故事的包含依赖。

解决方式：

用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划，特性一级可以用来做发布计划；

特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去；

遵从最小可行产品的理念，一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。

第2章 9 种常见的垂直切分模式

聚合：使一个简单的功能组合、聚合、叠加成一个越来越复杂的功能。

分解：把一个复杂的功能分解无数个越来越简单的功能。

切分的本质，就是对用户不同维度的行为进行分类，或按照时间维度或按照空间维度：

（1）根据操作的行为分类

（2）操作操作的数据分类

（3）根据操作的步骤分类

2.1 按工作流程不同的操作步骤来切分（一个用户操作入口、多个不同的操作步骤）

工作流程是指工作事项的活动流向顺序。工作流程包括实际工作过程中的工作环节、步骤和程序。

完整的工作流程可能会非常长，考虑的异常情况也可能很多，当开发完整的工作流程所需要的工作量很大的时候，就需要对工作流程进行拆分。

依照工作流程的步骤顺序，将大需求拆分成一个个逻辑连续的、有独立价值的用户故事是最常见的拆分模式。如何把一个工作流程拆分成多个子流程呢？

（1）方法1：分段法

把一段流程的M个步骤，均匀的拆分成n个段，每个端的步骤 L = M/n。

这种方法的优点：简单。

但这种方法有一个缺点：每一段只是完整流程的一小段，无法构成端到端的用户业务，无法为用户提供端到端的服务。只有全部分段都完成时，才能为用户提供服务。

（2）方法2：主流程闭环，即 Happy Path法。

这是参考如何构建一个完善的、周全的工作流程的角度来看，如何拆分完善的、周全的工作流程。

这种方法：先找出完整流程的头尾环节，逐步加入更多的中间流程和异常处理子流程；

一头一尾步骤，为用户提供了开始和结束的完整流程，有了完整的框架，只是中间过程不完善而已。为了使得整个流程更加的丰满和完善，可以逐步加入更多的中间流程和更多的异常处理子流程。根据二八定律指出，最有价值的流程往往只占 20%，其余的 80% 通常是次要的。因此，遵循先抓取最重要的工作流程，然后再逐步扩大和丰富需求，增加新的故事集。

如下图所示：

（1）先创建主流程的User Story

（2）逐步把中间流程转变成新的User Story

（3）逐步把异常处理流程转变成新的User Story

这样一个大的业务流程，就可以分解成无数个User Story集合。或者说，通过丰富User Story集合，就可以丰富大的业务流程，使得一个业务流程越来越复杂。

2.2 按用户不同的操作类型切分（用户多个不同的操作类型）

当一个大的功能需求与「管理」或「配置」等描述词相关时，可以将其按照不同的用户操作切分成更小的故事。常见的用户操作有：增、删、减、查、更新等。如下图所示：

每个独立的操作，都可以拆成一个独立的用户故事和用户功能需要。

2.3 按不同的业务规则拆分

业务规则是指对业务定义和约束的描述，用于维持业务结构或控制和影响业务的行为。不同的规则，控制目标系统的不同行为。

业务规则技术的基本思想是将系统处理的业务逻辑从程序代码中抽取出来，将其转变为简单的业务规则，以结构化的业务规则数据来表示和控制业务行为，采用类自然语言来描述，并集中存储在规则库中。业务规则由业务人员创建、实时更新和调试，业务规则之间的复杂逻辑关系由规则引擎处理。业务规则技术改变了传统的、以过程形式处理业务逻辑的方式。

比如Linux IP table就是基于业务规则来工作的，电影院卖票系统也可以定义各种规则。

此时，就可以按照业务规则来切分复杂的功能需要，每个规则就可以是一个User Story。

例如，在线售票系统的购票流程通常隐含对数量限制、排他性等规则，研发团队可以先实现没有限制条件的购票流程，再进一步实现不同约束规则相关的用户故事，每个约束条件，就可以定义成一个用户故事。如下图所示：