CMM实践－利用RequisitePro进行需求管理
需求管理中的问题
在CMM3中需求管理（RM）关键过程域是非常重要的一个环节。在我们公司CMM3级的实践中，需求管理往往是非常花费成本的一个工作，比如，在需求分析、建立需求跟踪矩阵等活动中，如果是一个团队或是几个小组在进行协作时，会有大量的Word、Excel文件需要在不同的人员间传递，其间即使用了类似VSS等工具，仍然没办法避免繁琐低效的工作方式，其间会产生例如文档传递不顺畅、协作人员的需求用例重叠、扩展需求遗漏等等问题，在实施CMM3时，此环节更为公司增加了大量运作成本。
比如，在多人协作完成需求分析，对所有需求用例进行管理的活动中，需求人员只能根据前面的需求调研报告，所有的人使用同一份Word文档模版，分别详细分析与描述属于自己任务内的需求用例，然后负责人再把每个人写好的Word文档进行合并，这种合并完全是手工的合并，同时，对于每个人需求分析的情况，只能阅读所有的文档内容才能检查出是否有所遗漏等严重问题。
再比如，公司在使用最原始方法建立需求跟踪矩阵时，往往是用一个Excel表，列出一个二维表，把软件生存期的几个阶段做为几列，例如“需求”，“设计”、“编码”、“测试”、“发布”等，然后首先由需求分析人员在第一列的“需求用例”上，列出所有的需求点，然后再把这个Excel表交给设计人员，再由设计人员在第二列的“设计”上，列出每个需求对应的设计项，这样一直传递下去。其间这张表也不知经过了多少人的手，一旦其中某阶段一项做了修改，很难安全保障正确的向前追溯。
如果为了解决以上问题，公司自行开发一些管理工具，仍然需要花较大成本。
Rational RequisitePro特性
- IBM® Rational® RequisitePro® 解决方案是一种需求和用例管理工具，能够帮助项目团队改进项目目标的沟通，增强协作开发，降低项目风险，以及在部署前提高应用程序的质量。
- 通过与 Microsoft® Word 的高级集成方式，为需求的定义和组织提供熟悉的环境
- 提供数据库与Word 文档的实时同步能力，为需求的组织、集成和分析提供方便。
- 支持需求详细属性的定制和过滤，以最大化各个需求的信息价值。
- 提供了详细的可跟踪性视图，通过这些视图可以显示需求间的父子关系，以及需求之间的相互影响关系。
- 通过导出的XML格式的项目基线，可以比较项目间的差异。
- 可以与 IBM Software Development Platform 中的许多工具进行集成，以改善需求的可访问性和沟通。
在CMM实践中Rational RequisitePro的灵活应用
通过上面列出的特性，可以看出，此软件是一个功能很强大的需求管理工具，我们可以利用它的一些特性灵活的处理CMM3级中有关需求的一些操作性较难的活动。
对于多个人使用Word进行需求分析时，可以利用此工具的与数据库、Word文档的实时同步能力，及多人协作能力，把需求进行组织、集成。
对于建立需求跟踪矩阵，我们可以利用它的具有非常丰富的可跟踪性视图的特性，按照我们原始的方法，把Excel二维表中每列的阶段项分别设置为一种类型的需求。比如“Use Case 需求”、“设计”、“编码”、“测试”这几种自定义类型需求分别添加成四列。然后，再把这些需求项连接到Word文字段。比如“设计项”可以关联到Rose中的Use Case项或是关联到设计文档中相关的段落。
这时，项目组的需求人员就可以利用RequisitePro来添加第一列的“Use Case 需求”了，需求都添加完了，设计人员也可以使用它来添加“设计”这一列的项，而这些操作完全不用再传递某个Excel文档了，只要使用RequisitePro打开同一个项目即可。同样，项目组进入到不同的阶段，就可以让相关的人员使用此工具在此项目中进行添加与修改。
这样，我们就可以进行需求覆盖分析。通过建立视图的方法，对“Use Case 需求”、“设计”、“编码”、“测试”等我们定义的需求类型间的覆盖程度进行分析，即某个阶段的记录是否可回溯(可跟踪到)到某个Use Case 需求项，即由果->因。
特别地，也可以产生从阶段项可以到Use Case需求项的回溯跟踪矩阵,带红线的箭头表示suspect(可疑)的跟踪，即若存在跟踪关系的二个项中的任何一个独立修改后，requisitePro将自动标记为可疑跟踪，以提醒注意。
以上仅仅举了个Rational RequisitePro的例子，总之，灵活使用工具，可以很大程度上解决在CMM3实施过程中很难操作的一些问题，减少实施成本。
CMM的实施过程中要善于利用工具
我个人认为，在实施CMM的过程中是不能本本主义，生搬硬套的，否则会使实施成本巨大，怎样在实践中利用工具更好的解决问题是最重要的，当然，对于不同的情况可以使用不同的工具，这就要充分发挥实施者的能力了，从这一点上说，CMM只告诉我们应该做什么，但没有告诉我们应该怎么做却是有道理的了。因为同样一个目标，会有非常多的方法去实现，对于一个CMM实施者来说，他相当于一个改革者，就像我们国家的改革一样，没有什么西方已有的方法是最好的，只有通过自己的实践找到最适合我们自己的方法才是成功的关键。
Rational RequisitePro使用方法介绍
- Rational RequisitePro是一款不错的需求构建、管理工具，这里以RequisitePro自带的例子Learning Project-UseCases为例，简要说明部分使用方法。
- 1．打开项目的模式
- 当需要(这是由requisitePro决定的)修改某些project属性时，需要选择该模式，这时当前用户为该project的唯一用户。不过一般情况下，无需对“Open Project Option”做任何选择，在requisitePro检测到你将修改某种project属性只有在Exclusive模式下才可执行时，requisitePro将给出对话框供你确定“Exclusive”模式。
- 2．界面元素
- 通过可视化的图标可以确定相应的概念。
- 这里仅对Package、Document(word文档)、Requirement(需求)、View(视图)，作出说明：
- 1) Package：是需求的组织机制，与UML中的包在概念上基本类似，Package还可以包含子Package、Document、Requirement、View。
- 2) Document：这是呈现打印版需求文档、也是需求编写的一个重要方法。一般通过在Package图标上的快捷菜单建立word文档，并在word文档中对文本进行选择，以建立自动编号的UC事件、TERM项、FEAT项等。可以说Document是需求的容器。文档在requisitePro中被类型化。
- 3) Requirement：主要指UC事件、TERM项、FEAT项等。
- 4) View：在创建完自动编号的UC事件、FEAT项后，就可以对这两种需求进行分析，而分析的可视图就是通过View来实现的，View基本上就是一个查询的结果，在requisitePro中可通过设置查询的需求类型和其属性来得到特定的视图，如根据需求优先级进行需求排序。
- 3．通过包组织需求文档
- 在构建基于Use-Case Template的需求管理project时，一级包名如下：
- 1) Coverage Analysis包：需求覆盖分析。通过建立视图的方法，常于用于对UC事件、FEAT项这两种需求类型实例间的覆盖程度分析，即某个UC事件是否可回溯(可跟踪到)到某个FEAT项，即由果->因。
- 2) Features and Vision包：特点和前景。这是高层的需求，这是相对use case规范文档而言，相当于系统overview：有主要特点、关键的风险承担人的需要、关键服务。
- 3) Glossary包：术语。对本应用领域的术语。如应用领域的角色。基本上是与计算机无关的概念。
- 4) Impact Analysis包：影响分析。以视图的方式显示需求间(如：UC事件、FEAT项)的前溯关系。与Coverage Analysis包不同的是本包存放的是需求的正向跟踪矩阵，以表达需求的影响链，即由因->果。
- 5) Supplementary Requirements包：补充需求。这个词语不是很准确，因为该包存放的是无法由单个use case规范文档表达的需求，即非功能需求，如：可移植性、可重用性、安全性、可伸缩性等，这些需求一般对多个use case规范表达约束。
- 6) Use Cases包：用例。存放use case规范文档，描述的是功能需求。
- 4．文档类型
- 通过对需求文档进行类型化，以标识不同的需求、文档的格式(通过文档类型所对应的文档模板做到这一点)。
- 主要用到3种文档：
- 1) Glossary Document Type：术语文档类型。
- 注意：双下划线的段落存放在requisitePro项目所对应的DB中，其它的段落只保存在该word文档中(但扩展名为GLS)，故requisitePro将保持双下划线的段落与DB的双向同步。
- 2) Use case specification document type：use case规范文档类型，专用于陈述某个use case。
- use case规范文档的目录中，可以看到基本流程、可选流程、特别的需求(一般为非功能需求)、前件、后件。这种类型的文档表达use case图中的某个椭圆(即一个use case)的详细内容，详细内容主要是该use case所涉及的交互事件(UC项)、该use case执行的前件、后件。一般可在该文档后附上一张use case图以概要地描述该use case与其它use case间的关系。
- 上图是该类型文档的一个样例，其中陈述了：可用性、易用接口、培训、等非功能需求。作为链接到use case 规范文档包，其中有功能性一项。
- 5．需求类型
- 这里的需求类型是对在word文档中可被存入DB的段落的类型化。注意：这些类型通过前缀表达其含义：
- FEAT项：标识某个特点段落，其一般存放在vision.VIS文档(word)中。
- (双划线的段落将被存放入DB)。
- 其它的需求项，与FEAT项类似。
- 6．需求项的属性
- 所有requisitePro元素都有properties，但只有需求项拥有attribute(需求属性)。
- FEAT项：FEAT: product Feature的需求属性，从中可设置其优先级、难度、状态、稳定性等。
- 通过建立视图查询，可以将某个包中的所有需求项例出来。
- 7．视图类型
- 有三种视图类型：不同类型的视图，可从其图标上分别。
- 1) attribute matrix：属性矩阵.
- 2) Traceability Matrix：跟踪矩阵
- 从UC项到FEAT项的回溯跟踪矩阵,带红线的箭头表示suspect(可疑)的跟踪，即若存在跟踪关系的二个项中的任何一个独立修改后，requisitePro将自动标记为可疑跟踪，以提醒需求分析员注意。
- 3) Traceability Tree：跟踪树：基本上是跟踪矩阵的树型表示。
- 8．在word中建立需求项
- 以建立UC项为例，在word中建立UC项。虽然也可在requisitePre界面中建立UC项，但该UC项不会自动出现在word文档中，故推荐采用在word中建立UC项的方法。
- 1)选中待建立UC项的word段落
- 2)打开new Requirement并进行设置
- a) 设置UC项名
- b) 设置hierarchy
- 设置该UC项的父UC项，用于供requisitePro自动计算该UC项的编号：
- c) 设置其它属性后，并保存文档
- 在requisitePro中就可看到该UC项了。
- 9．对团队开发的支持略。