软件需求分析实践 - 需求拆分| 学习笔记

开发者学堂课程【阿里巴巴研发效能提升实践系列公开课：软件需求分析实践——需求拆分】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/608/detail/8874

软件需求分析实践——需求拆分

内容介绍

一、怎么做？

二、做什么？

三、如何进行有效的需求拆分？

四、需求拆分到什么程度为止？

五、总结

在开发软件过程中需要回答的两个根本问题：怎么做和做什么？

 

一、怎么做？

确定的是整个交付过程是什么。

 

二、做什么？

是确定具体的软件需求（是最重要的一个问题）。

《人月神话》作者布鲁克斯曾说：“软件开发中单一最困难的事情就是，精确决定做什么…”做什么问题中普遍出存在的是在需求开发过程中，可以说很难确定做什么或者确定做什么的需求很模糊，再或者这个需求超乎想象般大，这种现象成了交付的拦路虎，尤其是需求过大。

1、需求过大的困境有哪些？

比如说需求过大，隐藏的细节，也是隐藏的风险；拿闹钟来分解之后，它的零件可以铺满一张小桌子，修闹钟也跟想象中的简单有很大差别，太多细节使得这个工程变得复杂。在需求开发中，当拿到一个自认为很简单的需求时，打开细节之后，才发现之前并未了解过太多细节。

2、举例

需求是:二手商品提供货物担保服务（也就是在二手商品交易时，所提供的担保服务，由谁担保，商品如果出现问题，担保服务是基本上能解决）。

当打开背后的细节:

（1）需要什么样的担保服务;

（2）谁可以提供担保服务?

（3）服务商的资质有什么要求？

（4）需要审核吗?

（5）什么品类的商品可以提供担保服务?

（6）担保服务的服务费用如何结算?

等等

可以了解到需求后面的细节，便是我们需要交付的风险。

3、当需求量很大时

（1）、交付总是慢，进度不可控

当今天访问需求量很大的进度时，只能是正在运转中，或许一天好几天都是如此，能完成的日期也是未知，所有它的交付速度是很慢的，进度也无法控制。

（2）、总是难于集成交付

很大的需求很难集成，在交付的过程当中，需要把所有的需求集合在一起之后才能去交付，如果一个小的需求，会有足够的灵活性，能做到持续的集成之后在交付；大需求只能等所有的任务都做完之后，才能集成在一起之后在交付。

图片示例：

当开发的最早期时，所有的需求刚刚开始；等到开发中期时，有一部分任务已经完成，如果是一些较小的需求，那基本上可以提测，然后发布上线。如果说这个需要特别大，那就不得不等到迭代的最后一天，等待所有相关需求任务的完成之后再集成在一起，在做统一的交付。所以说需求的大小，决定了在研发过程当中的研发方式，来帮助用户把需求和需求背后的问题和风险了解清楚，来把需求调到相对来说合适的大小。

 

三、如何进行有效的需求拆分？

示例：

《门票竞拍转让》背景

在过去十年中，现场观看运动赛事的人数显著增加，在一些城市，如杭州，所有的门票从预售一开始都已售罄，几乎不可能通过正常渠道获得门票。做为赛事主办方严令禁止黄牛倒票以获取利润。但因为人们无法从正常渠道购买到门票，现在主要通过各种线上交易平台进行门票的转让和购买，一些球票持有者通过各种变通的方法，转让出售这些门票，以至于门票价格高达零售价的1000%，绝大部分利润被黄牛赚取。

为此，2022年杭州亚运会筹委会建设了票务系统负责门票的销售，并通过制定政策，从2019年起，所有杭州举办的赛事门票支持电子票形式;对于门票转让这种情况，筹委会专门找到闲鱼进行合作，其门票转售只能通过指定唯一平台-—闲鱼进行交易，并提供门票在转让过程的信息验证。

在转让交易过程中，卖家和买家能够在线销售和购买门票。卖家将通过拍卖功能向最高出价者拍卖门票。卖方设定了自己选择的初始竞拍价格，不设上限。卖方还可以限制拍卖的时间窗口，设置开始和结束时间。如果球票成功售出，买方通过支付宝向卖方付款，然后卖家将通过更改门票的所有人ID的形式，转交电子票给买家。

完成交易，平台将费用（减去25%的票务转让验证费用给赛事主办方）转账给卖方。同时，系统需提供黄牛预警。

1、通过标题，可以了解到需求就是通过竞拍和转让门票；通过例子可以看到的细节有以下几点：

（1）信息验证

（2）卖家将通过拍卖功能向最高出家者拍卖门票

（3）转交电子票给买家

（4）减去25%的票务转让验证费用给赛事主办方

（5）黄牛预警

2、一般很容易被拆成以下这样：

（1）对接票务系统

（2）对接支付平台

（3）前端页面展示

（4）报警模块实现

这样的拆分很大程度上是从实现的角度上拆分的，拆分出的也不是需求，可通过观察发现，这样的拆分，拆分出的是一个一个模块任务，从业务的角度讲，也并不能提供出一个完整的业务模块。

3、正确的拆分：

第一步分析为什么要做这个需求?

（1）买家能买得到票

(2)卖家能卖高价

(3)交易过程中，能鉴别真伪，提高交易成功率

(4)赛事主办方能从中抽成

(5)防止黄牛

多问几个为什么之后，可以了解到为什么要做这件事，或者它背后的需求了解清楚，从大目标拆分成小目标的一个过程，这也是需求的一次拆分。拆分过程中，发现子目标已经很小了，这时可以不用继续拆分下去。

第二步分析这些需求有哪些用户？

(1)卖家

(2)买家

第三步分析交付的过程会有哪些系统？

(1)闲鱼

(2)票务系统

(3)支付平台

此示例中的系统上下文:

买家和卖家都把系统看作一个黑盒，此例子中是闲鱼，针对这样的分析过程，在需求分析时应该做到此步。

第四步分析针对不同的用户，会有哪些操作呢？

(1)卖家：需要发布门票和取消卖票，也就是可以下架商品

发布门票的操作流程

卖家要把门票的信息登记在闲鱼平台上，闲鱼平台会告诉卖家登录成功或失败。站在用户的视角来说，其实是登记信息和获得登记信息的结果。如果要跟票务系统打通的话，能够获得自动获取门票详情，那需要闲鱼跟票务系统之间先打通。可以根据某id的信息，然后从票务系统里把详情反馈并展现给用户。在票务系统里，比如说哪个场馆哪个区第几排第几个座位，具体哪个时间，是有这样的一些细节。

有这样的信息，整个发布的过程，可以有详情页和目录的需求，另外的需求就门票详情可以自动获取。而在交付的过程当中，如果没有跟票务系统做对接的话，只要卖家提供更多的一些详细也是可以的。但是为了提供更好的用户体验，很有必要只输入一个id,票可以从票务系统里自动获取。那可以在自动获取门票详情这件事上，建立一个功能。这样一来，操作流程上又可以进行拆分。

(2)买家：需要能查询到需要的商品、和卖家竞价和支付商品

买家竞价操作流程

存在用户操作过程当中，出发点和起点是从买家开始。就是买家进入门票的相亲宴。比如说买家到闲鱼之间结构详情页，闲鱼会展示相应的详情页，此时买家给出价格之后，作为竞价者给出具体价格；卖家需要锁定一定的费用，怕出现乱说价格最后拍下之后不要的场景。

因为实际的竞拍过程中是需要先付一部分钱压在那，费用锁定到了支付平台，这时的决策竞得者，谁能获得这张票，比如说在一定时间范围内，按出价的高矮排序，在此段时间范围内出价最高谁就获得。此时需要通知买家已经成功拍下此张票，并会通知卖家，哪个买家成功拍下。

之后买家支付成功后，卖家需要转让此张票，门票的转让实际是闲鱼后台跟票务系统对接的，从用户的角度来说，只能看见闲鱼，闲鱼要跟票务系统发起转让门票的请求，最终结果会反馈给买家，此时会产生相应的结账单，也就意味着这次交易已经接近完成。接下来要考虑分账25%的费用转给票务系统，也就是这个赛事主办方，余下的再支付给卖家。最后，整个过程结束。

4、在需求拆分工程中分了几个阶段：

(1)详情页展示

(2)竞价机制

(3)支付

(4)转让门票功能

(5)结账策略

这样很容易把用户竞拍的场景梳理出来，然后拆出具体功能

5、需求分析:

需求分析=需求分解×需求梳理

（1）需求分解:需求(大)==>需求(小),需求(小)

就是说把大需求分解成很多给子需求的一种过程；

（2）需求梳理:增加更多细节

对拆分之后的需求进行梳理，对拆到的某一个操作，具体操作流程是如何的？中间的一些交互过程这样的一些细节，可能还会针对某一个业务细节进行梳理。

6、需求分解层次图示：

通过例子可以了解到整个需求分解层次，最开始是通过一个大的问题出发，将大问题分解成若干个小问题，再通过小问题，比如子问题是针对解决哪些用户的问题？可以把用户列出来；那在用户会有哪些操作问题上，比如说操作流程又会怎样？这时要把操作流程当中的具体规则是什么，一层一层分解下去。

第一步是把问题和分解成子问题的过程，这是目标呈现的过程；第二部是把用户场景的呈现，是说哪些用户具体的操作场景会有哪些；第三步是整个操作过程有哪几个步骤，用户的操作步骤是什么？在操作过程当中，系统与系统之间的交互是什么，也就是说系统的交互和用户的操作流程；最后一步便是业务规则的呈现，就是说每一个点的业务规则是什么。

7、小概括：

需求拆分是需求有效分析的副产品

详解：

需求拆分不是主要目标，主要目标是需求的澄清，把需求澄清掉之后需求也就分解好了。

 

四、需求拆分到什么程度为止？

如果需求一直拆，要拆到什么程度截至，是到业务规则还是操作流程、还是说到某个用户就够了，一直没有给定义，只是给出了采取到什么层次或者步骤。

1、需求拆分的原则

（1）足够小

确保在一个迭代中能完成或持续交付,小的需求比较清晰；比如说迭代是一周，那需求应该在一个礼拜以内完成，不建议迭代期太长；小的需求会特别清楚，更方便问题出现之后解决，在交付过程中延期或者需要返工的都是需求太大的。

（2）端到端

需求应该具有客户价值,端到端才能保证交付有意义的价值；比如说交了某一个模块，串在一起看不到业务价值是什么，做了事情，但是业务结果并无任何意义。

（3）独立性

需求与需求之间应该是相互独立,便于持续集成和灵活安排；需求不能是和另一个需求集成在一起才能交付，这样的需求偶合性太高，需求之后独立，集成才灵活。

（4）可测性

能够独立验证，以便验证该需求已经完成。

2、参考

整个操作流程中，注意有没有一些异常的分支，是可以在时序图里表达出来的，这些异常的场景，往往很容易漏掉，举例生活案例：之前在做拆分时，漏掉了其中一个场景，导致后面返工了一个月，多花了一个月的时间去完成漏掉的场景并实现。

3、窍门

（1）可视化信息∶

善于用图表，可以快速理清内在逻辑，找到不足或矛盾之处少量必须要素传达大量信息，一图胜千言，将复杂关联性可视化；

（2）协作化分析:

业务角色提供业务目标、场景和视觉交互开发角色确定影响范围和技术可行性测试角色站在用户操作和系统行为的角度提供输入。

 

五、总结

1、大的需求隐藏问题和风险，交付慢、难于控制进度，并且集成困难;

2、需求拆分的步骤是:目标澄清,梳理场景，理清流程

列出规则，逐步细化;

3、需求拆分应该满足:足够小、端到端、独立性和可测性;

4、善于应用图表，找到正确的人协作完成需求澄清。

本节课主要是有一个具体的目标来进行拆分的，在不明确目标的情况下进行拆分，在以后的课程中会继续讲解到需求的探索和需求的规划中做深入的探讨。对于一下问题：针对每一流程来说，具体的业务规则应该怎么样去细化？应该细化成什么样的程度？细化的规则呢？有没有具体的方法？和测试用例之间又有什么样的一些关系？这些规则又怎么来去推导出测试用例？最后怎么来着验证这些需求？在后面的课程里会解答。