开发需求分析的套路

一、简介

在处理中大型需求的时候，往往会让人感觉到心累疲惫。我想从过去的思考和实践的角度写下这篇文章，帮助大家更快、更有质量地去处理这一类复杂的需求分析和实现工作。

二、需求的三个层次

在开始全文之前，我想分享一个我的观点——需求实现中是有三个层次的：

软件始终是解决问题的。在 DDD 中，我们称之为问题空间和解决方案空间。在我们的流程下，这三个层次的关系是：

• 对于客户的诉求来说，功能的设计就是它的解决方案
• 对于功能的设计来说，代码的实现就是它的解决方案

之所以分享这个观点，是想表达大家在做需求分析的时候应该分两个阶段思考：

1. 理解客户的诉求，想明白功能的设计是如何解决客户的诉求的
2. 思考代码的实现，思考功能的设计的成本是否合理，是否可以建议出其他功能的设计去解决客户的诉求

千万不要变成代码的实现直接去解决客户的诉求。这样做往往会在下一个需求来临的时候给我们带来极大的负担——业务的发展是跟随客户的诉求发展，而不是跟随代码的实现发展。

三、如何理解需求

我们了解需求，往往是从需求评审会开始的。但真正理解需求往往是从产品提供的 PRD 中来——这是我们理解需求的重要手段（但不是唯一手段，与产品、前线的交流也非常重要）。

当我们开始理解需求的时候，第一件事情，就是应该先弄明白需求的目的是什么、客户的业务背景是什么——也就是上一段提到的客户的诉求。只有理解了客户的诉求，后面所有的方法论才有意义。

3.1 理解业务大致逻辑

在理解了客户的诉求之后，就去弄明白预期效果——理解产品期望实现的大致功能想实现的效果是如何的。

作为开发（Feature Owner），理解客户的诉求和预期效果要做三轮理解：

vagueconcrete

01大致了解

结合预期效果理解业务，建立整体概念

产出业务画像

→

02拆解交付

按业务整体交付维度切分，降低风险

产出可交付切片

→

03分析建模

完成建模，初步设计代码结构

产出业务模型

从模糊到具象 · 把不确定性收敛为团队统一认知

3.2 Step 1：大致了解需求

第一轮理解，尝试结合预期效果来理解需求。目的是让自己对这个业务有一个大致的了解，去尝试理解产品经理期望的功能的设计是如何解决客户的诉求的，让自己心里大致有一个概念。

3.3 Step 2：拆解出独立交付的需求

第二轮理解是去拆解需求。这块主要是针对中大型需求——中大型需求往往隐含的意思是包含大量功能，一次性交付的周期太长了，而且风险非常高。所以拆解成很多小的独立可交付的需求来处理，目的是为了减小交付的风险。

拆解的经验往往是这样：在一轮阅读之后，做第一次过滤：

• 对需求的内容进行分类，独立交付的部分总共有几块。独立交付的含义就是在已有的系统上不依赖其他任何新的功能所能实现的功能的设计
• 这里的拆分一定是按照业务整体交付来进行，而不是业务模块的划分——比如系统 A 一个 story、系统 B 一个 story，而是可以直接上线使用的功能
• 对每一块分类进行进一步的分解
• 判断离开某个功能，主流程是否可以正常流转下去
• 剩余的功能是否可以分成几个阶段交付
• 不论最终是不是要这样做，都应该先进行拆解

初步拆解的过程中，与产品的同事不断地进行沟通，确认必须交付的内容。我们这样对功能的设计拆分是否符合产品和前线同事的期望。这里要注意的是——即使是必须交付的内容，也可以拆分成几个不同的故事，这样我们的交付才能够足够的灵活和快速。

3.4 Step 3：独立交付需求分析建模

在拆解完独立交付的需求之后，就要开始对需要应对的需求进行分析工作了。这一轮的目标是完成建模，对代码进行初步的设计。

3.4.1 业务流程整理

通常我使用事件风暴：到了这一步，可以准备一个白板，开始尝试用事件风暴的方式来整理流程。

事件风暴是一个整理流程的工具，在整理客户的诉求和功能的设计时都可以使用。每次做事件风暴时要意识到——整理的目标是为了服务客户的诉求还是功能的设计，而不是二者兼顾。也可以使用流程图整理出当前功能对应的流程。

3.4.2 划分系统边界

在得出业务流程之后，要对整个流程进行拆解，确定业务的上下文边界——哪些流程应该在上下文 A，哪些流程应该在上下文 B。

3.4.3 寻找用例

使用事件风暴整理完流程之后，根据流程中发生的命令整理出需要实现的方法，形成一个有层级的结构。这些方法会成为未来分层架构中的 application service。

3.4.4 整理业务对象

主要流程：

1. 用 UML 描述出所有的业务对象——就是在事件风暴中找到的触发命令的角色，以及被影响的对象
2. 整理业务对象之间的关系，主要的目标是找到主要活动的业务对象
3. 在事件风暴中就是寻找业务的聚合根——比如在签署的场景中，签署人才是主要对象，合同是次要对象，合同就成了签署人的值对象
4. 填充业务对象的属性：根据业务流程、UI 图、自己的业务经验为每个业务对象添加所需要的业务属性

在这个过程中不断思考，然后去和参与业务的同事一起讨论和沟通，最终确定出业务模型的样子。

3.4.5 确定 DoD（Definition of Done）

与业务方确定好怎么样算是这个需求做完了——也就是验收标准是什么。目前考虑的边界是不是已经可以接受的了，约定好如果还有扩展的部分补充到另外一个 story 中完成。

这样一个分析过程，是一个对业务从模糊到具象的过程。目的是帮助自己和团队把不确定性转换成统一的认知——所以在这个过程中统一认识非常重要，要注意多与团队在一起讨论，找其他人讨论。

而且到目前为止，我们是完全没有考虑数据是怎么来的、怎么暴露的。不论数据是从数据库、还是从 Dubbo 获取数据、还是从 HTTP、MQ 暴露方法，都不应该是这个阶段考虑的重点。业务才是核心，所有的基础设施都是为了适应业务的，而不应该让业务去适应基础设施。

3.5 对功能的设计的质疑

在这个业务分析的过程中，随着对业务的深入，一定会有自己的困难和不解。这个时候就应该提出自己的一些问题，把自己困惑和不解讲出来和其他同事讨论。

具体来说：

• 大致了解需求阶段：通常会是一些方向性的疑问，此时应该去了解业务的目的。在充分了解业务背景之后如果还有困惑，应该此时就去跟产品进行讨论——也许还有你未知的业务背景
• 拆解出独立交付的需求阶段：可能会遇到任务分解上的困惑。在分解完任务的过程中，应该注意哪些业务是优先级更高的、哪些业务的优先级是次要的或者有替代方案的，将自己分解的任务和替代方案拿出来跟业务相关方进行讨论
• 独立交付需求分析建模阶段：遇到较多的就是细节问题了。这个阶段的问题零碎，建议整理出一些之后再一起讨论

在这个过程中，质疑和分歧会随着分析地深入、细节地增多逐渐变得容易让人接受。但是越是在流程中靠前的质疑和修改，越是有可能影响整体的产出，修改的成本也会越低。

到这一步之后，结合前一篇文章进行编码也会事半功倍了。

四、总结

最终大家会发现，业务构建中最重要的还是业务分析——去了解功能的目的，理解和纠正功能的有效性，跟产品达成一致，在开发前尽可能地去将不确定性转换成确定性。这样在开发中就会游刃有余。

毕竟我们需要致力的目标应该是一次性把事情做对——避免反复返工才是最大的效率体现。