因为用例中的事件流通常是用 Microsoft? Word 来记录的，并且 IBM Rational RequisitePro 允许用户在 Microsoft Word 中编辑需求，因此 Rational RequisitePro 是用来管理用例的一个理想的工具。在使用 Rational XDE Developer 时，为用例附加一个简单的 Word 文档，与之相比，使用 Rational RequisitePro 来详细描述用例，是一项关键性的优势。
可以清楚地识别用例事件流文本中所包含的功能性需求。
因为使用 Rational RequisitePro，需求文本在显示方式上，不同于文档中其他描述性信息，因此很容易识别用例事件流中所表述的功能性需求。您可以选择在用例流级别上标记功能性需求，或在单个的步骤流级别上标记功能性需求。当某一测试场景典型地用于测试基本步骤流与备用流结合时，在流级别上标记需求，有利于从用例出发，来创建测试用例。
自动跟踪对用例文档的修改。
每项需求变更的审计跟踪（谁做出的变更、内容、时间、原因）存储在 Rational RequisitePro 数据库中。这些修订帮助您实现对用例变更的控制。
跟踪功能性需求
用例事件流中包含的功能性需求标记为软件需求，并为它们分配了属性（优先级、难度、风险等），而且与高级业务需求或产品功能链接起来。
可以将用例文档中的需求与相关的其他需求链接起来
通过跟踪用例到业务需求，或跟踪到产品功能，更易于度量与需求相关的变更所带来的影响，并且验证覆盖度。
根据详细的用例，生成设计类别
根据用例规格说明书的事件流，设计人员可以构建顺序图，将事件流作为对象之间的一连串消息来表述。
在 IBM Rational XDE Developer 中创建顺序图，并且与 Rational XDE Developer 对用例图的标注链接起来。请注意：我们经常被问起工具是否可以将用例事件流自动转换成顺序图。最好的回答是，不良的设计可能来源该方法，而好的设计却进行优化，来表达所有的关键性事件流。
根据顺序图中确认的对象，可以进行设计分类。
在 Rational XDE Developer 中创建类图和其他 UML 图，并与它们的源顺序图链接起来.用来表示用例设计的 UML 图的集合通常被称作"用例实现"。该命名说明了这样一个事实，通过设计实现了用例中的需求。
使设计与需求变更保持一致
当设计活动开始时，需求促使原始用例（和随后的顺序图及类）变更的创建。不断变更的需求是（软件）生命周期中的事实，也是（软件）生命周期的信号，同时也是健全的项目的信号。在项目开始时，不可能 100% 了解软件需求和用户需要，因此变更反映了从您必须创建的（如果只是等待得到全部需求，那么您永远也不会有一个开始，最终将导致分析过程瘫痪）最初的需求集向最终的需求汇聚的过程。为了确保所交付的软件确实能够满足用户需要，需要使设计与不断变更的需求保持同步。
IBM Rational RequisitePro 可跟踪性矩阵将需求之间链接起来。
利用 Rational RequisitePro 和 Rational XDE Developer 的集成，还可以将设计要素与它们所实现的需求链接起来。The IBM Rational XDE Developer 设计要素反映在 Rational RequisitePro 可跟踪性矩阵中。
通过过滤需求和设计之间的可跟踪性矩阵，可以访问所需的特定信息。
利用 IBM Rational XDE Develope