需求工程的“拨乱反正”

  上次谈到，在软件开发产业链中，甲方（信息系统建设方）该为自己的需求负责了。接着这个茬，我们今天详细谈一谈甲方自己做需求的好处和如何做需求（业务建模）。需要说明：甲方做需求并不等于乙方对需求不管了，乙方的中心从需求获取转移到对业务需求的“显式理解”和软件需求上来了。

（一）甲方自己做需求的好处。

    以前是因为甲方对计算机、对软件太陌生，现在，经过20年的成长，甲方对计算机和软件系统也有了一定的了解，信息化部门也运行了许久，信息化团队也建立起来了，甲方对软件系统的依赖也成为长期的事情。据此，甲方自己做需求的条件也就成熟了。这样的责任转换使得需求工程过程中多年来的顽疾就可以迎刃而解了。可谓是：拨乱反正。

    其实，在一些大型企业，如：电信运营商、金融系统、军方系统等的信息化过程中，甲方自身一直是需求的主导者，他们对自己想要的东西越来越清晰，同时，他们表达自己需求的能力也是与日俱增，由此，实际上已经产生了围绕这些大型企业的软件外包产业链。（关于软件外包，我的观点：它是软件产业链的分工和完善，有利于降低软件系统的开发风险。由此，将逐渐形成：面向需求的专业咨询公司、软件设计公司、软件开发公司、第三方测评公司等不同关注点的产业环节。）这些外包公司依照甲方的规格化需求，开始系统的分析和设计，避免了需求获取这个对自己来说既非强项又非意愿的痛苦的工作过程。

    那么，甲方做需求到底有什么样的明确的好处呢？

   （1）最重要的一点就是，项目因为需求失败的风险大大地降低了。有句话讲：让命运掌握在自己的手里。由于甲方已经具备了自己做需求的基础，所以，只要采用和软件开发商一致的建模符号，就能够在很大程度上消除双方在需求沟通、需求理解上的严重误差。这样就从源头上降低了需求风险和返工的可能性。

   （2）软件开发商可以集中自己的专业优势，为软件交付保留足够的资源。我们多年来，由于需求的问题使得开发商很难把精力集中到自身的软件工程能力建设上来，常常公司上上下下全员陷于对甲方需求的无休止的讨论。因此也就给系统设计和开发带来了很大的交付压力。如果需求建模的工作转移到甲方，使得合同的期限就会宽松-----那个该死的“Deadline”就不对让我们Dead了。开发商会在设计和开发上投入足够的精力，会不断地积累自己的工程能力和发挥自己的优势。

  （3）把业务(需求)建模和软件需求分析分离开了。之前，有些人主张软件开发商省略业务建模，直接进行软件需求分析。其实，面对越来越大和复杂的信息系统，业务建模有利于明晰业务需求，特别有利于业务需求的稳定。一个稳定的业务需求才能导出一个稳定的软件需求。我们之前面对我们不愿面对的需求变更，真正地“猛虎”是甲方自己业务需求的不稳定。因为，甲方没有提前充分设计业务。另外，软件开发商有时合并了业务需求和软件需求，使得业务需求的问题被掩盖起来。直到最后，第一次交付或者设计评审等反向推动了甲方对需求的优化。甲方的主动性并不足够。

   在这方面，一些国内外领先的软件开发商，已经通过挖掘甲方行业中的专业人士，组成自己的“业务专家”，负责需求获取和业务建模。这也说明，只有甲方才会比任何人在业务需求上做得到位。   另外一个最佳实践就是，从甲方分离出来的一些专业人员组建专业咨询公司，为甲方提供业务规划和BPR。总之，把软件开发商从这个工作中分离出来是对的。

（二）甲方如何做需求。

   这里从高层谈一下甲方需求开发的整体思路。具体的技术层面的问题，有现成的方法论指导（如果有机会，我会在以后的博客里谈谈这个层面的技术，它不单是面向甲方的。）。

  （1）调整好工作心态。当甲方容易，当一个负责任的甲方其实并不容易。甲方是项目的发起者和投资人。项目的失败对甲方来说是最大的受害者。随着项目的复杂度不断地增大，项目失败的可能性也在不断地增大。甲方应该从风险管理的角度管控项目，“让合适的人做合适的事情”是降低风险的最好的办法之一。当一个项目被规划时，甲方应该从可行性分析到业务建模都自己负责，不要认为这是乙方的事情，调整心态，扛起需求开发的大旗。

  （2）选择合适的业务建模工具。不要使用文本自然语言格式（其缺点在另一篇博文已经谈过。）描述业务了，请选择合适的业务建模工具吧。对于软件开发商来说，很多建模工具都是熟悉的，也是可以快速学习的，这叫“本分”。但是，甲方没有必要一定要懂各种建模工具。甲方只要根据自己的业务和项目特点选择建模工具就可以了。比如：电子政务项目，工作流建模工具必不可少。BPR时也可以选择BPMS2.0；一般信息系统，IDEF也是足够用的。这里我重点推荐UML2.X，因为，UML可以确保从业务用例模型到系统用例模型的平滑过渡。

  （3）交付经过评审的业务模型。 提交项目的可行性分析报告已经远远不够说明白目标业务系统了。甲方应该开发结构化的业务需求报告，并且在甲方内部获得一致的评审，并作为招标书的一部分。

  （4）与乙方一起建立业务需求到软件需求的分配。从外包管理的角度，或者信息系统项目监理的角度，都应该关注业务需求是否被软件开发商没有遗漏的识别到软件系统里了。

  （5）管理业务需求。在整个项目的实施过程中，关注业务的实现和验证。让乙方确保业务的实现，让第三方确保业务的验证，如果需要的话。