在Standish集团对软件项目失败原因的年度调查中，去年的结果是：仅有54%的功能被实现，而实现的功能中近半数没有被使用。根据Standish的报告，这种情况的原因通常源于定义不佳的需求。
Telelogic AB公司的DOORS（全名是Dynamic Object Oriented Requirements System，面向对象的动态需求系统） 软件的目标是捕获细致定义的软件需求并将其转为代码。周一Telelogic在其套件中增加了一个新的产品，DOORS/Analyst 1.2，以捕获需求并将他们转交给其他Telelogic工具以生成代码。这些工具过去只能生成C代码，按照Telelogic AB公司的声明，现在它们已经可以生成Java和C++的代码了。
系统可以使用标准的行业建模语言UML 2.0创建需求模型，UML 2.0中增加了使用活动图、交互总览图（interaction-overview diagrams）及组件图来表达业务的能力。
模型也可以导入到Telelogic's Doors/Architect 2.3中，其中可以进行满足需求的系统架构的初始设计。
全球市场部的副总裁Michael Donner介绍，最后一步是将模型导入到Doors/Developer 2.3中，其中可以基于需求及架构设计系统模型。Developer的最终输出是自动生成的C++或Java代码。
Andy Gurd，Telelogic工具集的高级项目主管，介绍说，通过使用以上三种Doors工具，需求分析员或者软件设计人员可以从定义好的需求开始工作，并跟踪到最终实现来满足该需求的软件。如果某些地方和最终用户的期待有出入的话，“可跟踪性就起作用了”，它能够帮助你尽快地做出补救。
Doors可以和主流的Java开发工具一起使用，例如Sun的Java Studio或者IBM赞助的开源的Eclipse。Doors/Analyst 1.2、Architect 2.3和Developer 2.3在4月30日都将问世。这三个工具都可以工作于Windows 2000和Windows XP平台的。架构师和开发人员同样可以在Sun的Solaris 8和Red Hat企业版Linux上使用这些工具。
Telelogic 和IBM Rational的软件竞争，在需求分析和系统建模领域，这两个产品目前在市场份额上差不多是平分秋色，各占大约30%。
对于高质量的软件开发而言，需求管理的重要性益发突出。Rational 试图定义五个需求管理级别并分别提供度量集。Meta Group 的Thomas Murphy在一份研究报告中提到，Rational的Rational 统一过程（Rational Unified Process）“掌握了需求管理的很多需求。”
他指出，“大多数组织都掉进了这样一个陷阱：不停地为项目增加一些不成文的插件（add-on）”，这些增加的部分或者没有进行很好的文档化，或者使用和过去的需求所不同的结构在描述。
Murphy 在报告中指出，不论是使用Doors还是Rational的方法，都需要能够理解系统的业务需求的有经验的系统分析师 。
Standish的报告中总结到，“没有基本的系统需求的处理，一个项目注定失败”。
文章来源于领测软件测试网 https://www.ltesting.net/
