下面我们试着通过以躺平app技术团队的躺平app来讲解需求拆分的实施步骤。
躺平app技术团队的躺平app引流需求
项目背景：计划通过发放红包的方式从站外引流，提升躺平app技术团队的躺平APP的DAU。
项目目标：拉新用户xxx，目标用户为xxx，促进躺平app技术团队的躺平APP DAU增长xxx。
项目方案：引流入口的曝光和营销逻辑由导流端实现，用户触发后会记录用户信息和引流商品信息，尝试拉起躺平app技术团队的躺平APP客户端或者引导至下载页；此方案为躺平app技术团队的躺平APP被拉起后，或者通过用户自主下载安装并打开后的承接。
躺平app技术团队的躺平APP的需求细节
1）领取红包的触发条件：导流端拉起躺平app技术团队的躺平APP时，会弹出红包领取卡片，红包卡片弹出时间为用户登录后；用户自行下载躺平app技术团队的躺平APP打开后主动登录，经校验如果是符合红包领取条件的用户，则弹出红包领取卡片。如果用户不符合领取条件（比如已经领取过），则不会再弹出红包领取卡片窗口。
2）拆红包：用户登录状态下点击领取，即完成拆红包的动作。
3）如用户未领取红包而是主动关闭红包领取卡片，或者用户通过导流端二次触发打开情况，则都不再弹出红包。
4）领取后展示领取结果页面，可能存在“领取成功”“不符合领取条件”“已领取过”“已领完”几种状态，具体详情请见交互稿。
5）领取红包调用资金平台的红包发放接口。
6）成功领取红包页面，点击“去查看”前往红包卡券页；点击“去使用”前往购买引流商品详情页。
7）红包卡券页本次需求使用卡券包的H5页面。
步骤一：澄清目标，明晰场景
1）澄清目标：
从上述的躺平app技术团队的躺平APP引流需求这个案例中，我们可以明确的一点是，躺平app技术团队的躺平APP需求的核心目标是为了拉新，考虑到躺平app技术团队的躺平APP数据保密的原因，此处没有直接透露躺平app技术团队的躺平APP拉新需求的核心目标，在实际操作过程中，我们需要在需求提出的时候就明确本次需求的数据化目标，即该需求需要实现的拉新DAU等一系列数据化目标。
很多项目组在落地需求的过程中经常会偏离方向，实现一堆没有价值、并非项目真正目标的需求，到最后将会发现该项目组虽然实现了一大堆功能，但并不是做了一个好的产品，对用户来说，该产品无法很好地满足其需求。
当然，如果不了解真正的目标，没有目标驱动，则会难以保证投入的效率和效果，因为自己都搞不清楚为何而做、将去向何方。当接到一个需求时，我们要问的第一个问题就是，这个需求的目标是什么。第一步就应该澄清需求的目标，即澄清以下几个问题。
· 躺平app技术团队的躺平APP的目标用户是谁？
· 躺平app技术团队的躺平APP的需求需要解决什么问题？
· 现存的解决方案是什么？
2）常见误区：
· 笼统的目标：如“为了获得GMV1000万”这样不具体的业务目标，或者是“为了让用户用得爽”这样的用户目标。
· 编造的目标：不清楚目标是什么，于是从需求功能倒推进行猜测。可能是为了什么….猜测是为了什么.....
如果在目标澄清的过程中，很难搞清楚这个目标是什么，那么可以试试这样一个小窍门，就是向小朋友学习，不断地提出问题，如下所示。
· 为什么……？为什么……？为什么……？
· 如果不做这个需求会怎么样？
澄清需求的目标，同时也是在需求目标这个层次进行拆分的过程，一个大的需求目标，可以拆分成多个子目标，目标的拆分，也是对需求的拆分。
3）明晰场景：
有了明确的目标，我们需要知道基于该目标的用户场景有哪些，用例可以帮助我们描述用户场景，与此同时，还需要通过系统上下文，明确需求的各参与方。
系统上下文会将需求的各参与方（用户或系统）列举出来，并将它们之间的关系用相对简单的模型进行呈现，对业务团队而言，这个系统上下文，就是业务上下文，开发团队也非常容易与具体的实现模型相关联。
系统上下文只需要列出简单的模型即可，而不需要是一个完整的精确模型，模型的演进细化是一项逐步发展的过程。从上面列举的躺平APP引流需求的表述中，我们可以简单列出如图1-16所示的对象模型。
技术对象模型
接着我们再从目标出发，列出相应用户的使用场景（即用例），这样我们从用户场景上也有了一层分解（如图所示）。站在用户的角度，他们只关心系统所能提供的服务，即开发出来的系统是如何被使用的，而对系统内部的结构和设计并不关心，这就是用例的基本思路。在这个阶段，我们也只关心这个层次。
用户场景图
步骤二：用户操作，理清流程
列出具体的用户使用场景，由多个场景一起完成某个业务目标，这样的需求分析依然没有结束。接下来我们再就某个用户的使用场景做更深入的分析。例如，如何实现这样的场景？用户会进行哪些操作，操作如何与系统进行交互？系统与其他外部系统是否也有交互，它们之间的交互过程又是怎样的？顺着这些问题深入到具体的细节，每个用例都可以产生相应的用户操作流程及系统交互过程。如下图。
用户使用的完全链路图
随着信息的逐渐打开，我们又会有新的发现，例如，在该用户交互工作流中，会引入新的参与者、新的对象，我们可以基于之前的系统上下文进行更深入的细化，打开更多的细节，从而形成新的领域模型，并逐渐演进。
下面说明一下这个阶段常见的两个误区，希望大家注意。
1）误区一
这个阶段很容易陷入的误区是交互图或对象模型，不是从业务操作和业务领域对象的视角进行描述，而是直接进入实现的细节，这一点在技术开发团队中很常见。对于程序员而言，接到一个需求，首先很容易想到的是应该如何实现这个需求，而不是用户操作流程和业务领域模型。而且我们在这里用到的图表，很可能会被技术人员理解为技术时序图。图1-18中结合了用户的交互路径图及技术时序图，以方便大家理解，但是在实际操作中，用户路径图和时序图是解耦的，用户路径图在前，技术时序图在后。
2）误区二
追求完美，担心出错。在构建用户操作过程和领域模型的过程中，追求完美会使得我们迟迟不敢有所动作，因为每一次的动作都会担心不够完美。其实大可不必，有比没有好，先打一个草稿，然后基于草稿，不断讨论演进，才是正确的分析过程。
步骤三：列出规则，逐步细化
完成以上两个步骤之后，我们对流程的主要操作步骤、交互过程就都梳理出来了，这个时候，就需要进一步对业务规则进行明确。例如，用户领取红包的规则、发放红包金额的计算规则、个性化商品推荐规则，等等。将规则列举出来之后，我们需要对规则有一个更具体的描述，例如，领取红包的规则为符合淘宝天猫用户人群画像，红包发放规则为xx用户的金额为5元红包、xx用户的金额为10元红包，等等。
下面说明一下这个阶段常见的两个误区，希望大家注意。
1）误区一
对于业务规则定义过于复杂，难于列举穷尽，我们会陷入一种用抽象代表具体的表述方式，例如，“小于10的数”，这种定义方式是抽象笼统的，具体的表述应该是“0到9的整数”。通过举例的方式可以帮助我们走出这样的误区。
2）误区二
另一个误区，则是完全穷举。有的规则其组合非常复杂，很难一一进行穷举，这个时候，我们应该看看，在操作步骤上是否可以进行再拆分，一个四个变量的规则组合，可以拆分成串联的两个变量的规则组合。
综上所述，我们可以发现需求的拆分过程是从目标出发，到相应的业务场景，再到具体的用户操作和系统交互，最后落实交互过程中的业务规则并进行逐层分解。从目标获取需求的范围，操作交互过程获得需求说明，而规则是对需求说明业务规则的提炼，在以上实践中，我们分别获取了基本上下文、用例图、工作流图及业务规则。如图1-19。
需求拆解金字塔
总结：由外而内，动静结合的需求拆分方法
以上的分析过程，是一个由外而内，逐步分解的过程，从用例到用户的操作流程，由上下文到领域模型，是一个逐步打开细节的过程。用户的操作流程代表场景，是一个动态的过程，而领域模型作为可视化的术语表，是一个静态的模型，场景结合模型，达到动静结合。
这里还有两点建议，具体如下。
1）信息可视化
字不如表，表不如图。沟通过程中，文字的还原度是很差的，善于用图表的方式进行沟通具有如下优势。
· 可以快速理清内在逻辑，找到不足之处或矛盾之处。
· 可以通过少量必须要素传达大量信息。
· 可以将复杂关联性可视化。
图表的的绘制过程，就是一次需求分析过程。
2）分析协作化
所谓一人计短，二人计长，一个人或单一职能的思考难免会存在局限。在软件开发中，需求评审的过程，需要多个角色共同参与进来，业务角色可以提供业务目标、业务场景和视觉交互，开发角色可以确认需求的影响范围，以及实现的可行性，而测试角色则可以站在用户操作和系统行为的视角提供更多的输入，所以，需求分析拆分是团队协作的过程。
