在美国纽约有一个“失败产品博物馆”，里面展出的“失败产品”高达8万多件，其中不乏大公司功能强大、新奇的产品。博物馆提供了这样一组数字：美国每年推向市场的新产品达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还支持在需求定义完毕后，生成测试用例，有
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
