需求拆分步骤：

第一步：理清需求（use case）

理清需求就是把用户可能会需要的功能罗列出来。建议用脑图（Xmind或其他）；

第二步：整理故事（user story）

用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。

讲故事需要有一个核心主题（主线）。比如现在我们的主线就是商品。

讲好故事就能做好产品，一个完整的故事包含时间地点人物，一个清楚的故事，在于细节。所以如果我们将上面这个故事加入更多的描述，这就会变成一个清楚的故事：

那天我打开手机，进入了“我的产品”APP，我看了首页长什么样，哪里有按钮，我点击了进入了商品列表，页看到了许多商品，这些商品都是什么样的，怎么展示的，我把商品添加至购物车，并选择了进入购物车，我看到购物车里的商品长什么样，我看到这些商品的总金额之后，觉得这个价格还不错，于是点击了确认下单，系统过了没多久就把我带到了订单确认页，于是我点击了确认支付，系统又把我带到了支付页面，我输入了正确的支付信息后，系统告诉我我的订单已经完成了支付，并且我还在订单列表里面看到了一条已经支付的订单记录，我一眼就能看到我买了什么东西，每个东西是多少钱，最后我总共付了是多少钱。

于是我们的表格变成了这样：

第三步：分解故事（functional requirement）

在第二步中，我们已经清楚地讲完了一个故事，分解之后我们发现里面涉及到的关键物其实就只有几个：APP前端（首页、商品列表、订单列表）、支付等等。所以在产品架构上，为了保证这些东西都得以实现，必须要保证有一个APP前端系统，这个系统由首页，商品列表，订单列表组成，除此之外，还需要有一个系统支持支付，为了方便管理，后台还需要将用户的订单记录保存或者展示。于是功能需求可能就是这样：

故事分解完了，功能需求列表同时完成。

 五大需求拆分技法

1.路径拆分法：

路径拆分法是根据用户使用场景的不同路径进行拆分。通俗点的理解就是：你要通过什么方式达成你的目的地。举个例子：放假了你打算去三亚旅游，你需要考虑通过什么交通方式抵达三亚：火车、汽车、飞机、骑行等等。你可以把不同方式的解决方案罗列出来，以进行利弊优缺点的综合考量以辅助你决策。用户故事就可以写：（1）用户可以通过坐飞机抵达三亚；（2）用户可以通过坐火车抵达三亚；（3）用户可以通过坐汽车抵达三亚。

2.接触点拆分法：

所谓的接触点指的是用户与系统之间的交互通道，例如移动端应用和PC浏览器是两种不同的接触点。在PC浏览器有可以按照不同的浏览器类型进行区分：Safari、Chrome、Firefox和IE。IE浏览器的适配工作量大，而其他几种浏览器的适配工作量较小，因此我们的用户故事可以分开写：（1）用户可以使用IE浏览器查看；（2）用户可以使用非IE的浏览器查看。

3.类型或格式拆分法：

这个就是我们常见的一种分类方式，举例：朋友晚上来家聚餐，需要买点喝的，那市场上可选择的喝的分类有很多：酒精类的、碳酸气泡类的、功能型、0糖类的等等。大家如果对分类想有进一步认识，可以了解一下“MECE原则”，该原则最初是由麦肯锡的女咨询顾问巴巴拉·明托在金字塔原理中提出的，主要讲如何给事物进行分类，能够做到不重叠、不遗漏的分类。

4.按规则拆分：

规则指的是业务规则或者技术规则。例如ios的设计开发规则与android的规则就大相径庭。再举个例子：假设研发一款系统，专门用来推荐邮寄方式的。妈妈要邮寄家乡特产给远在异地的你，其中有个需求就是：最快送达，邮费便宜。该需求就可以规则就可分成四个：（1）按速度最快；（2）按价格最便宜；（3）按速度最快价格可以稍微高点；（4）按价格最便宜，速度可以稍微慢点。四者产生的结果方案可能会截然不同。

5.探索路径拆分：

在开发过程中，团队总能遇到一些对团队来说比较陌生或者不确定的实现方案，是可以将对陌生事物的试验性探索逐步拆分成不同的探索故事。这种探索故事有较大的不确定性，因此要作为高风险点管理，保持持续关注。

《持续交付2.0业务引领的DevOps精要》书籍中有一节讲需求拆分的方法的原则写得非常好。其中的INVEST原则，需求拆分的5大技法及用户故事地图等工具的使用在实际的工作中有很好的指导意义。好多产品经理面对一堆用户场景和用户故事的时候不知道如何进行有效的需求拆分，要么颗粒度较大不利于迭代的顺利交付和后期的验证。要么对需求的优先级没有清晰的概念，什么都想要，眉毛胡子一把抓导致开发周期较长，最终上线之后发现与用户实际需求的偏差较大。本身一些核心原则如下：

INVEST原则

INVEST原则是用于检测用户故事是否拆分得当的原则，它由下方6个英文单词的首字母组成。

1.Independent（独立原则）：

指的是用户故事需要彼此独立，低耦合。笔者理解此处还有一层意思，每个用户故事需要是完整的，对应的每个需求都是相对完整可验收的。这样做的目的有利于团队开发任务分配和保证用户使用场景的完整可用。

2.Negotiable(可协商原则）：

在进入开发前，故事卡片/需求项用来提醒团队及干系人进行讨论，而不是作为产品经理与开发人员的契约来使用。这一点与我们常见的工作开发节奏是所有不同的，它更加强调团队各角色对于用户场景故事的讨论，这个需求和用户故事不是固定的，是个动态的逐步深入明晰的过程，不是产品经理直接定义好的需求项。这样做的好处能够集各角色之长，使得用户场景考虑的更加全面，减少产品经理因思考不周而造成的决策失误，也能使研发团队更好的理解项目的上下文，有助于产品的功能和体验的顺利达成。

3.Valuable（有价值原则）：

指用户故事（功能项）对于用户来说是重要的，有价值的。此观点较好理解，故不赘述。

4.Estimable（可估算原则）：

开发团队能够根据用户故事估算所需的工作量。这项类似于开发看到需求之后要对开发周期，工作量，难点有个清晰认识，方便后续开发的顺利推进。

5.Small&Similar Size（规模小且适中原则）：

用户故事必须足够小，尽可能在一个迭代内完成；并且多个用户故事之间的开发工作量差异不宜过大。这样做的目的是能够保证开发能够合理的预估工作时长，降低不确定因素的影响。此处有一个比较形象的比喻：你对一个足球体积的估算偏差一定远远小于对于月球体积的估算偏差。

6.Testable（可验证原则）：

用户故事必须是可以被验证的。笔者认为此处包含两层含义，一个是功能开发阶段：开发设计完成之后有明确的验收标准，确定开发完成了该用户需求。另一个是产品发布之后，针对这个场景/用户故事能够收集到明确的市场反馈，是否满足用户需求，有没有达到用户预期等等，方便后续的迭代改进。

用户故事在遵循了INVEST原则后，基本就是一个好的用户故事了。再重点分析三个准则，帮助在产出用户故事时更好地符合原则。

三个准则是：一个用户、完整价值、不依赖。

1. 一个用户

只包含一个用户，因为多个用户常常有细微的差别。一般是典型的用户，常常有共同的某类需求。

2. 完整价值

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

3. 不依赖

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

总体上来说，故事之间功能点相互重叠是需要避免的；顺序关系是现实存在，在多数情况下可以通过一些手段解决；包含关系对复杂系统是有帮助的，对排定发布和迭代计划的影响需要注意。

（1）重叠依赖

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

解决方式：

将重叠部分单独剥离出来做为独立的用户故事；合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的用户故事中；使用Scrum开发模式。（2）顺序依赖

顺序依赖是指要使某用户故事完成，另外的一个或多个用户故事必须在它之前完成。顺序依赖通常是无害的，而且有一些方式可以减轻这种依赖。

从敏捷开发的角度，整个系统是从初始的最小可行产品逐步演化为强大的产品，后面的每一步是建立在前面的基础之上的。

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

解决方式：

一个迭代内的用户故事尽量做到没有内在依赖；保持迭代之间只有单向依赖，在时间上只有后面迭代的故事对前面迭代故事的单向依赖（前向依赖）；剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求混在一个故事里。（3）包含依赖

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

解决方式：

用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划，特性一级可以用来做发布计划；特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去；遵从最小可行产品的理念，一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。

文章部分内容转自：https://zhuanlan.zhihu.com/p/376488196