刚看到文章，询问DOORS的使用，到底比RP要好在哪里？

由于前文跟帖已多，因此另起一主体，讨论的范围还能更大一些。

单纯的工具比较没有意义，我们来考察需求管理的两大用途，或者说，需求管理能给大家带来什么？（或者说，为什么要有需求管理？）

从我经验看来，需求管理的核心用途有两个：

1、数据大集中，建立公司的知识经验库。

大家知道，配置管理的最大好处即是管理公司的源代码，这是公司的软件资产，使用配置管理工具之前，这些资产分散到各人手中，很明显，不利于公司的统一管理。同样，使用需求管理，将公司所有文档（用合同术语来说，包括但不限于需求说明书、规格设计文档，详细设计文档，测试规范，行业要求、标准等）都可以集中起来，并建立起这些文档内容之间的关联关系。从一个项目来说，记录了开发的全过程。从公司来说，建立了公司的知识库，这其实是比源代码更核心的公司资产。

有一家公司，从事打印驱动程序开发，为各打印机厂商提供打印驱动程序，这是一个很专业的范畴，需要很丰富的行业经验积累，公司总经理从事该行业多年，知道如何进展每一个项目，以及几乎所有的细节，如果应用好需求管理，将总经理的行业经验总结共享出来，这对公司的稳定、发展大有好处。

如果没有相应的项目过程文档，我们只好去看源代码，自己去领会其中的需求和设计之间的关系。如果有了需求管理，这些关系都被可视化出来了，一目了然。所以说，需求管理是比配置管理更高层的数据集中。

2、可追溯性 Traceability

这个用途在1中已有说明，重复一下，就是将项目研发的过程，从需求到设计、测试等项目成果演化过程之间的关系——可视化——出来，这就是Traceability，可追溯性。有了这个可视化关系，我们就能大大增强公司和用户之间以及公司内研发各部门之间的交流，从而保证了项目/产品的质量，也提供了开发的效率。

那么，我们回到开头，DOORS和RP的使用上有什么区别呢？从1和2来看，可以说，RP不是一个需求管理的工具，只是一个需求收集的工具。为什么呢？

1、RP还有数据的上下文是在word中，不能作为公司的知识库。
2、处理关联关系，RP是使用关联矩阵，这只是两两的关系，看到从一个文档到另一个文档的关系，还一般仅限于同一项目内的两个文档。所谓，牵一发而动全身，而不是牵一发而动另一发。

那么，DOORS是如何满足那两大用途的呢？我想，大家朝这两个用途去试一试DOORS，就可先意会，而再言传了。我们再来讨论。

因为对DOORS了解的不是太多,现在还没有资格对它进行有效的评价.

就了解到的RP来说,RP是以word为核心的数据存储体系,但这并不代表着它不可以用数据库的形式进行组织.个人认为,RP只是项目级的一个工具,也不单单一个traceability功能,如果从一个项目的开始阶段就使用,它也可以作为一个需求整理与分析的工具,记录需求,对需求进行过滤等.在关联关系上,RP确实很弱,但它的一对一从另一方面来说也是建立起一个需求架构网络,这个也可以从需求追踪树中得到.
多项目间的需求同样可以追踪到,但这个多少有点偏离RP的主旨,这点比较弱.

同样,对于公司过程资产库来说,以word为核心的知识体系只是存储的方式,在体系架构上并不能达到所想达到的要求,多少有点不适合.

以上只是自己的一点看法,再讨论交流.

斑竹人呢？？

给加钱鼓励啊 如此好贴

斑竹给点鼓励啦 ！

怎么没了下文呢？正精彩着呢............

此文
希望有关高手继续就此问题深入讨论！

个人认为，rp和doors有各自的优势：
1，rp的前端展现很好，与word的集成作的很好，便于一般的业务人员编写需求，使用门槛比较低；
2，doors的后端处理能力很强，在需求被创建完成后，对需求的追踪，冲突分析以及变更等功能都十分强大；
如果能够把两者的优势集中起来，那么将是最好的，呵呵

1、RP还有数据的上下文是在word中，不能作为公司的知识库。
2、处理关联关系，RP是使用关联矩阵，这只是两两的关系，看到从一个文档到另一个文档的关系，还一般仅限于同一项目内的两个文档。所谓，牵一发而动全身，而不是牵一发而动另一发。

看看是不是

转载请注明源自www.SCMLife.com,请保留版权. 本贴地址：http://www.scmlife.com/bbs/viewthread.php?tid=2223

因为国内现在的需求管理水平非常低，本身这个工具在使用方面易用性不强，对于在公司进行推广的话，存在一定的难度，如果能实现易用性的话，我感觉这个工具是个非常有前景的工具