在美国纽约有一个“失败产品博物馆”，里面展出的“失败产品”高达８万多件，其中不乏大公司功能强大、新奇的产品。博物馆提供了这样一组数字：美国每年推向市场的新产品达54000多种，而真正受到青睐的只有20％。产品失败的原因有很多，但最主要的就是产品功能与消费者的需求相去甚远。
从需求分析到原形设计再到编程、测试、应用维护，在软件产品的全生命周期内，需求作为根源和基础，它的优劣实际上决定了一个软件产品或者软件研发应用项目的成败。
疲于应对总在变化的需求
“我是在需求报告上签字确认了，可是我并没有时间读完这么厚的文档，是你们要我签字的。”不少开发团队经常听到他们的客户——业务部门说这样的话，尤其是客户对软件感到不满意，需要提修改意见的时候。
就像一条河流，如果源头被污染了，那么整条河流也就被污染了。需求是软件项目的根源，对产品的影响最大。好的开始等于成功的一半。从软件项目一开始，就要有正确的输入，也就是正确的用户需求。
如何才能做到呢？首先要讨论的就是做需求的工具。当前在软件项目的需求分析阶段最常用的工具是什么呢？Word！对，就是Word文档。技术人员通常是通过与业务人员交流等方式熟悉业务流程，根据自己头脑中对某个业务的理解，按照自己的逻辑，用系列的Word文档来描述业务需求。由于一个软件开发项目都是要多人完成，在写需求的时候，由于每个人的逻辑和习惯不一样，以及在共享协同方面的不完善，往往导致无效需求，这是导致项目失败的根源。
我们以银行ATM机的程序为例，来说明无效需求是怎样产生的。ATM机的需求怎么写？一般来讲，简而言之，开发人员会按照业务流程来写，第一步是读卡；第二步是在读卡的时候读用户身份信息，给客户一个窗口输入密码；第三步验证；第四步开始有分支，给客户操作界面，往下再按照细化的业务流程继续。但问题是项目合作中并不是每个开发人员都会严格按照这种顺序来写，并相互共享。某个开发人员他可能是按照自己想的业务逻辑先写一遍，比如他本来已经写了16条需求，第8条到第10条是描写查询的，第10条到12条是描写取款的，12条到16条是写转账的，但该开发人员可能写着写着突然发现在取款方面应该让客户更方便一点，于是在16条之后又产生了一条有关取款的需求，这样可能就会有重复，有遗漏，造成需求无效。
而且因为在一个软件项目进行的过程中，普遍的是业务需求在不断变化：一边是业务需求本身就在不断变化，一边是需求和需求之间又互相关联引导。这对项目团队做出正确有效的需求提出了巨大的挑战。
长篇累牍的Word文档如何能做到有效的需求确认和变更管理呢？康普科纬迅公司（以下简称Compuware）中国区技术经理马怡骢的答案是将需求结构化，并定义好需求之间的约束关系，从而做好需求管理。这也正是Compuware日前发布的最新的业务需求管理解决方案Optimal Trace 5.1的核心所在。
微软的Visual就是结构化。马怡骢说，如果有人已经用Visual来写需求，那么说明他已经比还在用Word的人进步了，因为他已经开始使用结构化需求。但是很遗憾，Visual的结构化需求默认没有约束关系，如果再请几个需求管理的专家把约束关系写进去，这就有了一半Optimal Trace的意思了。马怡骢说，Optimal Trace不光描述需求，它还可以描述需求之间的关系和影响力，所以当需求变动的时候，开发人员可以轻易地追溯到还有哪几个需求要重新查看编写。另外，Optimal Trace还支持在需求定义完毕后，生成测试用例，有针对性地对这些需求做出验证。这对于测试人员来说也是一个福音。
对于新版本的重要性，Compuware产品解决方案副总裁John Williams表示，一方面是结构化需求，另一方面它是一个开放性的架构，可以跟第三方的测试工具和测试管理工具进行相应的集成，包括需求的版本管理工具在内。这样用户可以看到需求变化带动的整个软件的基线变化，以及针对性的解决办法，告诉用户不同需求版本要在具体什么地方产生变化，并提供适用相应变化的测试用例。结构化需求，并对其进行更有效管理，可以给业务市场人员的访问、管理团队的审批和技术团队的实现提供更高的灵活性。
行百里者半九十。在整个软件研发过程中，保持整个团队对需求一以贯之的关注、确保所有开发活动都可以跟踪到最初的用户需求无疑是极为关键的。用封装的平台解决问题
在整个软件的生命周期中，要确保各项工作和需求之间的一致性，需求管理就显得格外重要。对于这一点，从事了十几年软件研发的创恒信软件有限公司（以下简称创恒信）技术总监吕建海深有感触。而除了需求管理之外，根据吕建海的十几年开发经验，他表示搭建一个良好高效的应用开发平台，应需而变，也是实现敏捷开发的重要保障。
应用软件开发平台的构建一般基于底层的开发语言和一些开发框架进行，进行一些比较底层的封装，制订一系列软件开发的模板或规则，要求软件开发人员按照应用开发平台的规则进行应用实现。应用软件开发平台一般都得到了若干个项目的应用，具备很强的稳定性和可靠性，同时能实现大量的应用组件的重用，又能规范软件开发的编码规范，极大地增强了项目管理人员的控制能力，是当前大多数公司沿用的项目开发方法。如用友的UAP、金蝶的BOS、SAP 的Netwaver都是用这种方法开发的。管理软件平台化是近两年来很热的话题，也是趋势所在。
从系统集成商转型而来的创恒信，曾经自主开发过电力企业的ERP系统、工作流软件、电子政务系统。有了多年的项目经验积累之后，创恒信自主开发了一套Web应用软件开发平台eFlow，将软件开发可视化，进行高度封装，通过设置来实现应用软件的各项功能，实现软件开发的无编码化。
现有市场的Web应用开发平台一般都依附于特定应用领域和特定行业。所有这些Web应用开发平台基本上都基于底层语言进行开发设计，涉及大量的编码，对软件开发人员的要求比较高。而eFlow应用开发平台作为一个高度封装的Web应用开发系统，其开发系统中内置了门户系统、工作流管理系统、电子表单管理系统等，提供了一个通用的平台组件，而主要的应用开发由电子表单管理系统和工作流管理系统来完成，其门户及展现由信息门户系统来完成。
配置后的敏捷开发
利用eFlow应用开发平台进行开发，并不需要开发人员懂得J2EE的各种技术，只须使用浏览器，开发人员就可以像设计网页一样完成最终的应用开发，其开发效率相对于使用传统的SSH（STRUTS + SPRING + HIBERNATE）快一个数量级。应用开发使用IE浏览器完成，应用的运行可以实现跨浏览器平台应用，在Linux上的Firefox上也可以运行。
eFlow应用开发平台涵盖了底层引擎、应用组件和上层基础系统，能够做到配置化实现各种复杂的Web应用，其总体结构如下：
eFlow应用开发平台以组件构建的方式实现软件开发，大多数应用无需编写代码，对于复杂应用，也只需编写少量脚本，就可以实现复杂的应用。平台提供基于浏览器的专用应用设计工具，进行应用的开发设计、测试、跟踪、调试以及软件维护。平台根据分层设计的开发思路进行封装，同时引入了大量的构件，开发人员无需手工修改Java类、表现层的页面、后台逻辑等，直接通过开发工具进行可视化配置降低了开发人员的学习难度。通过系统内置的设计工具，基于浏览器进行模板设计、模块设计以及流程设置，能够大幅度地减少开发工作量，提高了开发效率。而同时由于在开发实现过程中，压缩了编码的工作量，应用跟踪调试的时间也相应减少，整个应用实现的时间相应减少，提高了应用的可维护性和软件的稳定性。
