软件需求分析闲谈之敏捷需求分析【原创】

16年7月份的时候，我接手了一个产品研发团队。团队中有一些人有比较好的需求分析的sense，能够设计出很合理的用户界面，但是其他的文字性产出就五花八门；在面临一个完整的业务时，也无法由浅入深的去剖析。所以，我萌发了分享关于如何进行敏捷需求分析的念头，希望能让大家了解需求分析的“套路”，规范需求分析的产出。 17年1月初，我给团队以及公司内其他同事就这个话题做了第一次分享。分享完了还意犹未尽，就想把分享的内容用博客的形式展现出来。

软件需求分析是一个比较大的话题，仅仅通过一两篇博客肯定无法说清楚。所以我想通过闲谈的方式，与大家聊一聊这个话题，知道多少聊多少吧，但愿可以有些作用。

作为软件研发流程中的其中一个环节，软件需求分析也是有流程的，如果我们按照这样的流程去分析软件需求，一般都可以分析的八九不离十。这个就是人们常说的“套路”。从2012年开始接触敏捷开发，到现在5年多的时间一直都在带团队做敏捷项目，自己也比较沉迷于此，所以，今天主要想聊聊敏捷需求分析的“套路”。除去项目管理相关的流程，我认为敏捷需求分析流程应该如下图所示。

任何软件项目的需求，最初肯定都是由老板（投资人）提出来的，带有明确的商业目的。比如，通过向市场销售获取商业回报；又比如，通过软件提高管理效率，缩减管理成本；等等。诸如此类的需求，我们可以定义为“商务需求”。商务需求可以用User Story的标准格式来表述。有了最初的商务需求，接下来业务分析人员（BA）就应该开始忙活了。

首先需要进行业务架构分析。这个过程中需要辨别系统需要处理哪些业务，每个业务都有哪些人参与，业务流程是怎样的。这个过程结束后应该有两个产出，一个是业务框架图，另一个是每个业务的流程图；接下来需要做的工作是业务模块分解，对照着业务流程图，业务模块往往是流程图中某个步骤或者某几个步骤的合并。这个过程的产出是在业务框架图的基础上生成业务模块矩阵。业务模块分解完成后，可以用User Story的格式对业务模块矩阵中的每个模块进行描述，从而形成“业务模块需求”。业务架构分析与业务模块分解的过程中，BA需要与具体业务人员进行深入沟通，了解业务的每个细节。业务模块需求产生后，接下来需要针对每个业务模块， 进行业务场景分解。这个过程会涉及到一些技术范畴的内容，实现某种业务的场景可能会有多种，在不影响用户体验的前提下，尽量使用相对比较容易实现的场景。从这个时候开始，需要有技术人员的参与，以尽早避免一些技术性风险。业务场景分解完成后，每个场景就是相对应的“业务场景需求”，这种需求也可以用User Story的格式书写。业务场景需求是面向实现层面的，如果BA人员要偷懒，有了这个需求，开发人员也可以进行开发了，但是口头沟通的成本会很高，所以还需要接着往下分析。场景流程分析与界面设计是两个必要的步骤（当然，对于某些没有用户交互的功能，界面设计可以省略）。这两个步骤很难说一定是谁先谁后，但是界面设计完成后，基本上场景流程也就确定了，所以从思维的进展方向考虑，我倾向于把场景流程分析放在前面。这两个过程需要技术人员的深度参与， 比如说用户管理中的用户登录功能，考虑与未考虑安全性因素，分析出来的结果完全不同。需求分析做到这里，加上少量的口头沟通，基本上已经可以满足技术开发的要求了。事实上，很多敏捷项目也都是这样做的。这样的需求，对于衡量测试覆盖率这样的指标还有些困难，所以考虑到软件质量，最好再往下做一步，即“需求条目化”。我的理解，“需求条目化”是针对每个业务场景需求，给出具体的接受条件。这种接受条件也有标准的书写格式，用Given/When/Then这样的三段式来表述，测试人员需要为每个条件写一个或多个测试用例。我认为，为了提高软件质量，“需求条目化”这个步骤是必要的，但是，要完成这个步骤需要的工作量不小，对于小规模的敏捷团队要求比较高。我正在我的团队中实施这个步骤，具体效果如何还要时间检验。

以上是我对敏捷软件需求分析流程做的一个简单总结，“商务需求”，“业务模块需求”和“业务场景需求”是我针对需求分析三个层次的不同产出给出的不同定义。