Rational 公司有一整套用于需求管理的工具，功能非常强大，包括 Requisite Pro、Clear Quest
等等，这些需求分析工具可以对需求进行全面的管理，包括记录需求的变化情况，需求之
间的依赖关系等等。但是，我们考虑到

Rational 的一套工具全面实施会非常昂贵与复杂，需

要非常强的项目管理能力才能全面实施，因此，我们只采用了其中最简单的一部分功能，
那就是记录需求变更，记录需求之间的依赖关系，其他跟

RUP 有关的功能都给略去了。之

所以这样做，主要是考虑到项目的经费、人力以及国内软件开发的实际情况。正如前面所说，
我们根据自己的理解并写出基本需求后，交由客户做评审井做适当补充，我们将经过补充
整理后的需求作为正式需求记录入

Requisite Pro 所维护的数据库中，并对各个需求进行分

类，设定优先级等，这些工作完成后，就可以从数据库中直观地了解客户到现在为止提出
了哪些需求，哪些需求是必须优先考虑的，哪些是难度较大的等等。在这个过程中，我们遇
到了一些问题，譬如：用户对我们用自然语言书写的需求文档有许多地方不理解，往往在
花了较长时间阅读之后，仍不明白我们所描写的需求过程与他们所完成的业务之间的对应
关系；另外是由于首次采用

Requisite Pro 进行需求管理，在类型划分，属性值的确定上，

部分开发人员没有经验，造成了不少反复，对于前者，我们的方法是想办法增加一些示意
图，将大的流程分解为小流程，再与客户反复交流与沟通，最终达到双方理解一致的目的。
对第二个问题，则参考了一些例子，再结合实际中属性的使用情况，给予取舍或者选择，
经过这一阶段的工作，我们建立了基本的需求库，定出了基本需求规格说明。
    第三步则是在第二步的基础上建立起原型，利用原型与客户进行更深入的交流，通过交
流修改相应的需求。
    在这一阶段的工作是在对第二步任务进行报告交流的基础上进行的。我们用 PB 开发了一
个原型系统，就具体的业务流程与客户进行交流与沟通，通过原型，客户发现了许多我们
与他们的理解相互不协调的地方，我们在修改需求的同时，也在

Requisite Pro 需求数据库

中记录下修改的历史。事实证明，这种记录历史的作用是很有效的，如曾经有客户在两个不
同的时间对同一需求提了相反的需求，我们根据历史记录很快证实了该客户的提法有错误
在事实面前无需再作争论，同时利用

Requisite Pro，我们还发现了一些需求相互之间有矛

盾。经过这一阶段工作，我们终于获得了经过用户认可的需求基线，即是可用于下一步进行
详细设计的基线需求。
    在 这个 项目 中， 我 们 利用 了 Power Designer 、PB Documents 等 逆向 工程 分析 工具 和
Requisite Pro 需求管理工具，这些工具的使用，使我们提高了工作效率，起到了一定的辅
助作用。但是，就需求分析工具方面而言。我们觉得国内应用得还是太少了，这一方面是因
为对需求分析不够重视，另一方面是因为管理水平还达不到相应的层次。

Rational 公司的一

整套需求分析工具，其功能是非常强大的，国外已在普遍地使用，在国内也逐渐开始普及
特别是那些通过

CMM 二级以上评审的单位，都必须使用工具对需求进行管理。在本项目中，

我们仅仅利用了

Requisite Pro 功能的一些小方面，已经体会到该工具对于项目管理的诸多

好处。如果一个有实力的公司能够全面实施

RUP，那么需求管理这个老大难的问题会变得

不再那么棘手了，项目的质量也会得到相应的提高。目前国内由于

CMM 热潮的兴起，已经

逐渐重视需求分析，也逐渐使用需求分析工具，这是非常可喜的，当然，更希望在不久的
将来，能用上国产的需求分析工具，那时我们的软件产业也许会真正地腾飞了。