尽管数十年来在编程语言和测试工具方面都有了很大的进步，但是应用软件开发项目仍然极度的令人不满意。

Standish Group咨询公司报道说，软件开发项目彻底失败的比率在降低——该组织最著名的“混沌”（CHAOS）报道第一次发表时候说，1994年为31.1%，而2006年为19%——一直需要进行改善。

专家说，如果想有更大的发展，这还取决于企业会在多大程度上随着应用软件的变化而改变需求；需求在多大程度上明确地传达给了开发人员；并且业务分析师需要明确——这是指在开发与业务方面的联络——将每一方的需求向另一方解释。

展望未来

“BA的关键作用不是仅仅明白在那个时刻的业务需求，而是询问需求——会发生什么、为什么它会发生、什么时候发生。”Dan Walker说道，他是International Truck and Engine, Warrenville, Ill供应链业务系统的领导之一。

Walker说，在很多年以前，当他意识到IT企业并没有完全与其它商业领域同步的时候，他们公司就已经开始重视BA的作用了。“我们不希望IT企业是一个黑洞”，这是指，如果对业务需求描述不够充分的话，就会造成很大的损失。

Joe Marasco是Ravenflow的CEO，一个Emeryville，他说，Calif.-based公司的产品希望与开发商的需求结合起来，软件工程中至少有一半的错误是因为“对需求理解不当”所造成的。

实际上，需求开发日志中（Requirements Development Journal，http://www.requirementsdevelopment.com/) 93%的读者抱怨，用户最初所期望的功能并没有完成，然而恶化的原因其中89%是因为列举不全需求所造成的，回答者中85%说他们不得不努力的去猜测这些模糊的需求。由于给了这些错误传达，Marasco说，“在失败的工程中，开发人员承担了不公正的责备。”

如果是更复杂的事情，需求将处于更不稳定的状态。然而，微软Visual Studio项目组的产品经理Ian Knox说，追踪收集到的信息越多，结果就会越准确，应用软件应该影响组织的需求。

设置基线

虽然每个变化都受到时间和/或预算的影响, 但是为应用软件建立一套基本的需求，这将有助于所有的利益相关者衡量不可避免的变化所产生的影响。

“你不得不在设计阶段花费大量的时间，”Arsu Group的创始人SeemaPvhull说，Phoenix-based公司在供应链商业过程中与客户就业务流程再设计方面进行协商。她说，业务和软件开发人员之间讨论最关键的时候就是，当应用软件第一次概念化的时候。“否则IT人可能逃开，并且开始将技术规格集中在一起，可能最后所采取的技术是有许多附加功能的，但这并不是企业最需要的。”

Ravenflow的Marasco说，人们对需求处理的过程和文档需求漠不关心。最可能发生的情况就是，业务分析师编写了一套足足有“曼哈顿岛黄页”那么厚的需求，然而这些需求并没有得到有效的处理。

其他人认为BA的职责是在那些早期的会议中, 在一个新的应用软件中帮助管理并掌握选择的范围。“高级执行官并不笨，” Kvevin Brennan解释道，他是业务分析师国际学院的副总裁，blue sands项目业务分析师，同时还在多伦多一家咨询公司工作，“告诉他们，对于新软件，他们能做什么，同时告诉他们为什么他们应该小心。”

业务问题有时候可以通过非技术方案进行解决。当出现这种情况的时候，有经验的BA就能马上意识到。

“如果有IT背景的话，你思考任何事情都会倾向于软件，” Barbara Carkenord说，他曾经是General Motors 的一位程序员，“但是一些困境可能是程序上的；其它一些可能是组织上的。”

Stamford和Conn的Gartner Group的副总裁和研究主管Michael Blechar说，BA在组织中的位置——他们最终所处的位置——能影响开发项目的成败。

“通常从IT方面来看它的职责是引导分析师收集需求，”Blechar说，“但是由于业务流程方面管理和已经在商业领域出现的主动改善，这个角色已经从IT方面转移到了商业领域。”Blechar主张，那是因为三分之二的业务流程“本质上是人对人的。它们不涉及到计算机系统。”

不再模糊

从历史观点来看，那些在BA中——这些人可能在很多领域工作过，但是他们所有的服务都是作为技术和业务的连接——有“由于身份低微而工作得非常吃力。”Marasco说。然而，通过新的认证和训练他们的身价已经提高了。

IIBA目前为业务分析师制定了第一个行业认证考试，今年已经向整个美国南部提供。Carkenord估计，大约每年有5，000人参加B2T为期两个星期的业务分析师培训课程。在其它的评论中，他们听到“几乎一直以来，BA花费在收集资料和编写文档方面的时间要比程序员花费在编写应用软件上的时间长。”她说。

为了试图矫正这个不一致，软件开发商正在改变与开发人员的联系方式，并且也在摸索他们提倡的最优方式。“大约在五年前，我们认识到，我们不再需要特别地关心开发人员，”微软的Knox说，“我们不得不重视BA和测试人员。”

IBM Rational平台的总管Ashok Reddy认为“瀑布”方式——在这种方式下，在一开始，开发人员就试图收集所有业务需求，把它们整装成一个整体，然后再对一头雾水的用户进行讲解——已经渐渐被淘汰了。现在，项目一般采取反复的方式——这种方式下，开发代码的同时，向客户演示业务的流程，客户测试代码是否达到他们的需求并且提出需要改进的地方——这样就能“让你把风险降到最低。”

排除越多的风险——换句话说，用户有越多的机会参与到开发项目中——就越有可能使产品真正达到业务需求，并且使重写代码的可能性降到最低。

Arsu组的Phull说，设置并汇合反复校对点将对保证软件按预期计划工作有很大的帮助。

“定义业务流程，然后定义结束状态，”她说，“经常，公司只会关注像他们今天做什么这样简单的自动操作问题。”