业务分析至关重要

业务分析承上启下

业务分析处在软件工程的上游，业务分析的时间投入直接影响了后续的开发过程。业务分析的时间占用的越长，留给开发的时间就越少。业务分析的时间投入不足可能会造成质量不好，而导致开发过程中反复确认，出现需求遗漏、错误、矛盾等问题。因此如何平衡业务分析的时间和业务分析质量是软件开发企业共同面临的挑战。企业都在寻找一种能够既能够提升质量又能够节省时间的需求分析方法，并为之做出了各种尝试。

业务分析师将来自客户或者是业务部门的需求转化为开发能够识别理解的需求文档形式。这个过程不是简单的翻译过程或者传达过程。这个过程包含了对需求的理解和设计的过程。业务分析师需要将需求以合适的形式表达出来，以满足业务专家和技术专家的共同的理解需要。

需求描述文档格式

在过去，软件企业多用软件需求规格说明书（SRS）作为软件需求规格说明的文档格式。但是SRS属于较为全面完善的文档形式，所以，需要花费更多的时间去书写。下图是一种叫做IPO格式的较为流行的SRS的书写方式。通过Input，Process和Output三个栏目来书写需求。这样书写的方式是希望能够达到尽量全面的目的。然而这样的书写方式会造成一来书写要花费很多功夫，二来阅读起来并不方便。比这个更大的问题是，这种书写方式直接误导程序员用面向过程的方式来书写代码，直接在需求分析阶段就把质量隐患给埋入了。如果一旦发生需求变更，这样的文档的修改将会有很多的不便之处，很多时间会花费在调整文档格式上。

业务分析师需要有合适的需求描述的格式，才能够兼顾效率和质量。效率并不光指的是书写文档的效率，阅读文档的效率同样是效率的一部分。质量并不是仅仅考核文档的全面性，文档对于开发的指导作用也同样是一个比较重要的质量参考。

 图：一个IPO格式的SRS例子

需求变更不可避免

需求变更一直是不可绕过的话题，打算采用需求冻结（Freeze）的方式来拒绝接受需求的变更在现实中往往会被各种理由来推翻而不得不接受各种需求变更。既然需求变更是一件不可避免的事情，那么是否可以通过对需求变更的预告而减少需求变更的时候带来的成本。并且通过需求分析工具来减少需求变更的发生的可能性，甚至将需求变更提前到最初的分析阶段。

对于这种有预告的需求变更，开发人员也好更早的做好准备，在代码中预先植入变化的应对措施。这样当变化到来的时候就可以从容不迫的应对。

当遇到提出要求的时候，就包含了下列关键词的时候，一般就预示着需求未来会变化。

条件、结果、权限、自由配置、任意调整、顺序颠倒、置换、升级、预留字段

当然，即使这样向开发人员解释需求变更仍然是一件具有挑战的工作。因此，如何说服开发人员接受需求变更也是业务分析师的一个重要挑战。

应对一句话需求

有时候业务分析师会接到一种需求，叫做：一句话需求。对于一句话需求往往会觉得无从下手。如何抽丝剥茧的将需求分解清楚，并且确认，得到客户最后的首肯对于业务分析师是一个极大地挑战。

首先，业务分析师会列出各种可能的优惠券的场景以及各种需要确认的疑问，然后，找到提出需求的干系人或其代理人，然后不断确认，直到各种细节都清晰。这个过程要求业务分析师能够充分了解需求干系人的意图，并且充分利用各种工具，跟干系人积极的确认各种需求细节。这对于业务分析师的沟通能力也提出了一定的要求。

需求文档读者的多样性

需求文档并不是只有一种读者，需求的文档书写后要有很多读者，指望通过一种固定格式的混合内容的文档让所有的读者都产生正确的理解是一件困难的事情。而不同的读者希望获得的信息的视角是根本不相同的。项目经理也许更关注是否确定了范围，是否能够及时保证质量交付，有没有什么风险；开发工程师可能更关注技术的可实现性；测试工程师则把可测性和覆盖率当成首要任务；而业务用户则关注自己的商业价值是如何实现的。因此，不同的角色希望看到不同的内容的前提条件下，业务分析师就应该考虑如何更好地组织文档，从而让各自角色不怎么费劲就可以拿到自己想要的信息。

需求的全面性保证措施

需求的分析的时候应该确保需求的全面性，这样可以减少由于分析不足而造成的功能遗漏和场景遗漏。对于不同的情形有不同的工具去确保需求分析的全面性，下面举个例子，应对多条件组合的场景。当有两个条件会影响执行结果的时候，将两个条件的可能的取值都列出来，在本例中，条件1有A和B两个选项而条件2有a,b,c三个选项，那么它们的组合有2*3=6种。通过下列表格，将所有的可能性都列出来，然后对每种结果都做出描述，这样开发的时候就会考虑到所有的场景，并且测试的时候按照这个表格就可以进行测试。条件部分相当于测试中的Given，操作相当于测试中的When，而预期则是测试中的Then。

另外，再举一个例子，这是一个时间轴的例子。在本例（优惠券的有效期）中，将可能的时间组合用枚举的方式列出来，并且标记有效/无效。从而明确需求的各种场景。

通过上述两个例子不难看出，通过图形和表格的方式来表达，比文字更清晰、更全面。而制作过程也并不是很麻烦，甚至比文字的书写更容易，因为书写文字的版本的时候要自己思考是否书写全面了，而画图的过程或者制表的过程更为一目了然。除了上述工具之外，还有更多的工具可以帮助全面而有效的分析业务需求。以达到质量更高，效率更高的目的。因此业务分析师要对不同的场景应该采用什么样的工具进行总结才能够在不同的场景下能够用到合适的工具来分析需求。

需求分析的基本原则

经过上述分析来看，业务分析本身是一个至关重要的工作，业务分析的质量和效率直接对项目的成败产生重要影响。

下列是需求分析的基本原则，如果能够遵循下列原则，而不是拘泥于需求文档的形式，可以更好地分析需求，达到高质量高效率的目的。

完整性

需求的描述应该覆盖尽可能的完整，从而确保各种情况都得到实现。

正确性

需求的描述应该确保其准确性，以防止需求没有被正确的实现。

精确性

需求的描述应该确保其精确性，以防止由于模糊而造成的实现错误。

一图胜千言

一张图可以表达更多的信息，更吸引阅读。

一张图的描画时间并不会比写文字长。

解耦合

和代码书写一样，文档的书写也要遵循解耦合的原则，能够解耦合的文档也容易维护。并且解耦合的代码也会让程序员按照解耦合的方式来书写代码。

例如，通过依赖注入、校验分离、界面逻辑分离等方式可以将耦合的文档分解开。

复用性

相同的内容尽量不要重复书写，否则需要多处维护，万一造成不一致就会引起问题。

例如：如果术语统一定义、消息统一定义可以增加复用性。

柔软性

需求的描述应该具备一定的柔软性，在需求变更的时候可以容易的应对。

一致性

需求的描述应该保持同一种风格和方式，确保阅读理解的容易。

多面性

需求的描述要考虑多种读者的不同诉求，能够让他们快速的获取想要的信息。

时间投入

业务分析师多投入的时间吗，会让开发减少返工。

业务分析师少投入时间，会让开发及早开始。

创造价值

应该聚焦在如何创造价值上，而不是把经历花费在调整文档格式上。

需求分析不是银弹

不要试图让系统解决所有问题。

墨菲定律

凡是不分析的地方一定有问题。

综上所述，业务需求分析并不是一件简单的工作，也不是单纯的翻译或者是传话的工作，而是一种设计工作。这个过程要求业务分析师具有相关的行业经验，如果有一定的技术背景那就可以更好地胜任工作了。