1 RequisitePro简介
IBM Rational RequisitePro一种最常见的需求和用例管理工具，通过与 Microsoft Word 的高级集成方式，方便的对需求进行采集、组织、沟通、跟踪，加强对需求过程的管理。
接下来就介绍一下RequisitePro的基本概念和使用方法。
2项目
RequisitePro对需求按照“项目”的方式进行管理。一个需求项目包含了需求项、需求文档、需求的变更、沟通等内容。需求项目按照树的方式进行管理。针对每个需求项目可以设置需求的类型、属性、文档模板等。
2.1新建项目
在File -> New -> Project中新建一个项目，新建项目有四种选择：
(1)新建一个空项目，选择Blank，新建空项目后，你可以任意定义项目中需求，文档的类型等属性。
(2)根据模板新建一个项目。RequisitePro预置了几个模板。选择模板创建后，项目会有一些目录结构，需求类型、属性。减轻定制工作量。
(3)从一个基线创建。从一个导出的基线创建一个新项目，项目中包含基线的需求内容。
(4)创建一个模板。“Create a NewTemplate”，创建后的模板在“\RequisitePro\templates”下。要把一个模板移除，只要删除相应目录既可。
2.2打开一个项目
在File->Open Project中打开一个已经存在的项目。
在使用RequisitePro做团队开发的时候，通常把项目放在一个共享目录中（用户必须对这个目录有读写权限），一方面可以通过操作系统的用户访问建立安全性。另一方面，RequisitePro对项目也有用户权限的控制。
打开项目有三种模式：读写、只读、独占。RequisitePro打开项目时，缺省是读写模式。
只读模式下，不能对需求内容、项目属性作任何修改。
读写模式下，可以修改项目内容，添加、修改项目属性。
读写模式下，可以修改项目内容，添加、修改、删除项目属性，可以作重新排号等工作。
如果是要选择“只读”、“独占”，可以分别选择“Read Only”和“Exclusive”选项。
3基本知识
打开项目后，在界面的左边可以看到一个树状的需求工程。一个需求项目主要包括四种类型元素，分别是“包（Package）”、“文档（Document）”、“需求项（Requirement）”、“视图（View）”。
四种元素可以在需求项目的一个节点上，点击鼠标后出来的“new”菜单中选择相应类型创建。接下来解释意下四种元素的具体含义：
3.1包（Package）
包是组织需求的一种方式、包让需求项目具有良好的可读性。一个包可以包含“包”、“文档”、“视图”、“需求项”等内容。
常见的包组织方式有：
Features and Vision包，特点和前景。这是高层的需求，这是相对use case文档而言，相当于系统总览overview。包括系统的主要特征（通常是甲方的期望甚至是合同的内容）、关键的涉众请求。
Glossary包：术语。对项目牵涉到的业务名称、专有名词进行解释。
Supplementary Requirements包，补充需求。这个包中存放的是即非功能需求，如：可移植性、可重用性、安全性、可伸缩性等。
Use Cases包：用例。存放use case规范文档，描述的是功能需求。
3.2 文档（Document）
可以根据模板新建一个文档。文档的类型和模板可以根据项目的需要定制。可以理解为，文档是需求的一种容器，文档中可以包含各种类型的需求。
文档的类别在“File->Properties->Document Types”中设置。设置文档类别设置的界面见下图
3.2.1扩展名(File Extension)
文件的扩展名，新建需求文档的时候，按照指定的扩展名保存，便于识别。其实不管是什么扩展名，都可以用Word打开，指定不同的扩展名，只是问了方便识别不同的文档类型。
3.2.2缺省类别(Default Requirement Type)
文档中缺省的需求类别。设置了缺省需求类别后，在文档新建一个需求项时，如不特别制定，系统自动识别为该类别。
3.2.3模板(Outline)
大纲，其实就是指定一个模板。新建一个需求文档时，从这个模板生成。可以用下面的方法定制自己的模板。
首先，模板存放的路径是在“Tools->Options”中设置的“Document Outlines”中。在相应目录下，存放这模板文件*.DOC，并且每一个模板对应一个同名的解释文件*.DEF。
一个DEF文件由三行文字组成：第一行是模板的名称，就是在3.2.3中Name一栏显示出来的名字。第二行是模板说明，显示在Description一项中。第三行就是对应模板的文件名。
3.3需求项（Requirement）
文档的类别在“File->Properties-> Requirement Types”中设置。常见的需求类别有用例（UC）、术语（TERM）、特征（FEAT）等。需求类别设置的界面见下图
3.3.1名称和描述(Name/Description)
需求的名称和注解。在新建一个需求的时候，提示这些内容。
3.3.2起始编号(Initial Requirement)
初始编号，建立需求项的时候，系统会自动为需求分配一个唯一编号，添加时分配、并且不随着需求的修改和删除改变。需求从设置的初始编号开始累加。
3.3.3允许外部跟踪(Allow External Traceability)
是否允许外部跟踪。选中时，该需求类别可以和其他项目的的需求项建立跟踪关系。
3.3.4强制包含内容(Requirement Must Contain)
需求需要强制包括的内容。如果在编辑框中填写了内容（大小写不敏感），这个所有的需求内容（Text）中必须包含这个内容。否则每次保存的时候系统将提示警告信息（但是还是可以保存）。
3.3.5前缀(Requirement Tag Prefix)
需求前缀，需求的编号有两个部分组成，即前缀加上数字，如TERM1。
3.3.6版式(Requiment Color/Style)
需求的版式，在文档中，一段文字标识成需求的时候，就自动修改为设置的版式（字体和字号不修改，版式只改变颜色和添加下划线什么的）。
3.4视图（View）
视图可以看作一种报表，在requisitePro中可通过设置查询的需求类型和其属性来得到特定的视图。View的作用主要有两个方面，第一通过配置查询的限制、排序的属性可以直观的看到需求概貌，第二个就是通过View实现不同特性间需求的跟踪，通过需求跟踪，我们能清楚的知道需求之间的相互影响关系。视图总体上分为属性矩阵(attribute matrix)、跟踪矩阵(Traceability Matrix)、跟踪树(Traceability Tree)三种。
3.4.1属性矩阵(attribute matrix)
把某个类型的需求按照列表的方式显示出来，可以定制需要显示的内容。这样可以通过总览的方式查看需求和需求属性。
3.4.2跟踪矩阵(Traceability Matrix)
跟踪矩阵可以将两种类型的需求用矩阵合并显示出来，并且还可以在矩阵的交叉为止标记两个需求项之间的“Trace To”和“Trace From”关系。
3.4.3跟踪树(Traceability Tree)
其实就是跟踪矩阵的树型表示。
最常见的视图有
需求覆盖分析“Coverage Analysis”：通过建立视图的方法，常于用于对需求间（如：用例－UC、特征－FEAT这两种需求类型）实例间的覆盖程度分析，即某个需求（用例－UC）是否可回溯(可跟踪到)到另一个需求（特征－FEAT）项，即由果->因。
影响分析“Impact Analysis”：显示需求间(如：UC事件、FEAT项)的前溯关系。与Coverage Analysis视图不同的是本视图表达的是需求的正向跟踪矩阵，以表达需求的影响链，即由因->果。
