| 您首先需要知道的内容
本文关注于基于文档的需求，比如用例需求规约。基于数据库的需求可能需要不同的并行开发策略。
IBM® Rational® RequisitePro® 文件必须以 Microsoft® Word® 格式存储（而不是以 Rational RequisitePro 格式存储），而且包含的需求绝对不能包含有层级（父-子）关系。
本文描述的场景使用 Rational RequisitePro 7.1.0 版本与 Microsoft Office 2003 进行了测试，并是在 Microsoft® Windows® XP Service Pack 2 上运行。如果您想进一步了解基本的思想与技术，那么您最好创建一个测试环境，因为如果数据没有得到合适的处理的话，那么有些不当的操作将有可能使数据受到不可恢复的毁坏。
基础知识
Rational RequisitePro 没有提供像 IBM® Rational® ClearCase® 那样的分支和合并机制。在 ClearCase 中存储 RequisitePro 格式的文件，并想从 ClearCase 的分支和合并功能中获得的便利并不能解决这个问题，因为 ClearCase-Microsoft Word 合并管理器并没有考虑存储在 RequisitePro 数据库内的嵌入需求。
唯一的解决方法是使用本地的 Rational RequisitePro 功能，并创建 RequisitePro 文件与需求的单独实例。有了这些单独的实例，团队就可以独立地工作，然后将后面进行的变更组合到一起。附加的需求属性可以帮助您管理需求从哪里分支以及合并到哪里。原始需求与分支需求之间的追溯关系，可以帮助您对其他团队对需求所做的变更能保持一致。
Microsoft Word 自身包含了文件的比较与合并功能，并且可以用于合并一个文件的不同版本。
配置 Rational RequisitePro
对于 Microsoft Word 而言，即使文件的扩展名不是 .doc 的话（例如，对于用例规约则是.ucs），也会有什么不同。但是，Word 并不会使用 Rational RequisitePro 的格式来存储文件。
- 从 RequisitePro 菜单中，点击 File > Project Administration > Properties。
- 从 Project Properties 窗口中，选择 Documents 项，然后选中“以 RequisitePro 格式来存储文件”复选框（参见图 1，“改变 RequisitePro 文件格式”）。
图 1. 改变 RequisitePro 文件格式
为了增加 Rational RequisitePro 对于分支或者合并场景的支持力度，您需要向每一种需求类型添加两个附加的属性，分支或者合并操作会影响到这些需求类型。
- 从 RequisitePro 菜单中，选择 File > Project Administration > Properties。
- 从 Project Properties 窗口中，选择 Attributes 项，并添加两个名为
originates from （来自于）和 merged to（合并到）的附加文本属性（参见图 2，“ 为影响到的需求类型添加支持的属性”）。这两个属性含有需求从什么地方分支，以及需求合并到什么地方的信息。
- 应用一个默认的值，例如一个连字符（-），以显示当前没有任何值的属性。
图 2. 对影响到的需求类型添加支持的属性
并发开发的项目通常根据团队或者版本来进行组织。项目的组织结构也可以在 RequisitePro 中的包结构中来反映。在本例中，我们将会根据版本，R10 和 R11 来组织结构，如图 3 所示，“在包结构中反映项目的组织结构”。
图 3. 在包结构中反映项目的组织情况
为一个 Rational RequisitePro 文件建立分支
为了让这个例子尽可能的简单，在 R10 发布包中只有一个用例规约。R11 分支可以分支于 R10 版本（对于产品即将到来的 1.1 版本，编辑用例需求）。用例规约只包含有两个需求（参见图 4，“RequisitePro 数据库中的启动情形”，与图 5，“RequisitePro 文件的启动情形”）：
图 4. RequisitePro 数据库中的启动情形
图 5. RequisitePro 文件的启动情形
按照以下的方法，来将 R11 版本中已存在的 Rational RequisitePro 文件分支：
- 从 Microsoft Word 菜单中，选择 RequisitePro > Document > Save As，来打开 R10 RequisitePro 文件，并以原始的 Microsoft Word 格式存储文件。
- 从 RequisitePro 菜单中选择 File > Import。
- 在 Import Wizard 对话框（图 6，“分支 – Import 文件”）中，选择 Microsoft Word document，然后切换至前面存储的文件并点击 Next。
图 6. 分支 – 导入文件 1，Withdraw Cash R10.DOC
- 对于导入的内容，选择 Document only（图 7，“分支 – 导入文件 2”）然后点击 Next。
图 7. 分支 – 导入文件 2
- 为新的 Rational RequisitePro 文件提供一个有意义的名字。有一种比较有效的方法就是向名字添加发布的标记。
注意：RequisitePro 文件的名字在每一个项目中必须是独一无二的。
- 选择合适的文件类型（在本例中，是用例规约）并点击 OK（参见图 8，“分支 – 导入文件 3”）。
图 8. 分支 – 导入文件 3
- 在 Create Document 窗口中，选择 Yes。
- 识别包含的需求需要导入文件的书签，所以选择 No 以回答“您是否想要删除这些书签？”这个问题，因为您需要保持嵌入需求的书签（图 9，“分支 – 导入文件 4”）。
图 9. 分支 – 导入文件 4
- 最后，选择 Commit 按钮（图 10，“分支 – 导入文件 5”）。
图 10. 分支 – 导入文件 5
在导入文件之后，原始 Rational RequisitePro 文件会有一个一模一样的拷贝（如图 11，“分支 – 被分支的文件及需求”所示，包含标记的需求），而 R11 发布包含有它自己的 RequisitePro 文件（参见图 12，“分支：R10 的 R11 分支”）。
图 11. 分支 - 被分支的文件与需求
图 12. 分支 - R10 的 R11 分支
注意，在文件的导入期间，已经创建了新的需求。新创建的需求并不是原始需求的拷贝，而是应用默认值的新实例。检查一下，原始的需求是否拥有需要为需求的拷贝输入的默认值。
R11 发布版本现在还包含了一个单独的需求文档及其需求。这些需求可以单独进行编辑，而不用考虑原始的需求文档与需求。
追踪原始的和分支的版本
在这个简单的例子中，很容易追踪原始的和分支的需求。在拥有数百或者数千需求的实际项目中，您需要一个工具以仔细查看。
可以使用的另一种机制，就是创建原始需求与分支需求之间的追溯关系（图 13，“通过追溯关系来追踪原始的和已分支的需求”）。这起到两个目的：
- 有一些文档是为分支需求的起源而建立起来（追溯关系的方向，可以是从原始的需求到分支之后的需求）。
- 如果对需求所做的变更是在不同的分支中所做的，那么就会为通知团队成员创建一种机制（如果是复杂的用例，那么最好与其他的团队保持联系）。
其中有一条很小的限制条件，那就是追溯的关系不允许是闭环的。因此，您必须要么记录分支要么记录合并关系。
图 13. 根据追溯的关系来追踪原始的和已分支的需求
另一种机制就是使用其他的属性来管理分支或者合并。您可以通过向标为“来自于”和“合并至”的需求类型添加一条文本属性，来记录需求的状态。不能进入来自于则意味着它是一个原始的需求。不能进入合并至则意味着分支的需求尚未得到合并（参见图 14，“使用属性以管理分支/合并”）。
图 14. 使用属性以管理分支/合并
合并一个 RequisitePro 文件
如果一个已存在的文件被分支了，那么它会在一定程度上得到更改。这种更改可能一处变更、添加或者删除。我们将会向您展示怎样对分支的需求文档执行这三种变更操作，并完成合并过程，这样您就可以看一下怎样将这些操作集合到原始的需求文档中。用例标题上会有一点的变动：需求 UC4 被删除了，而添加了需求 UC5（图 15，“对已分支的需求文档所做的修改”）。
图 15. 对已分支的需求文档所做的修改
在从 Microsoft Word 菜单中应用变更之后，我们会选择 RequisitePro > Document Save 以提交对数据库所做的变更。
现在，将这些变更合并到原始的需求文档之中。首先，您需要创建一个临时文件。
- 从 Microsoft Word 菜单中，选择 RequisitePro > Document Save As，并以原始的 Microsoft Word 格式来存储这些文件。
- 打开临时文件，并从 Word 菜单中，选择 Insert > Bookmark。
通过双击书签来进行导航。就算没有 RequisitePro 文件，需求文档中每一个需求都仍然会有一个书签。在这个需求文档的例子中，我们有两个书签。一个是用于已编辑过的需求的。另一个是用于已添加需求的（图 17，“已添加的需求的书签”）。
- 删除与编辑需求相关的所有书签，因为您并不需要 RequisitePro 以在导入期间考虑它。结果如图 18，“已清理过的需求的书签”所示。
- 在您完成操作之后保存文件。
图 16. 已编辑的需求的书签
图 17. 已添加的需求的书签
图 18. 已清理过的需求的书签
您可以将编辑过的临时文件合并到原始的文件之中。
- 为了获得原始文件的位置，您可以右击文件并选择 Properties。
- 接下来，在 Document Properties 窗口中，选择 General 项。
- 您可以从 Directory 区域内复制文件的位置 （查看图 19. 文件属性）。
图 19. 文件属性视图
- 从临时的文件中，从 Microsoft Word 菜单中，选择 Tools > 比较和合并文件。
- 在接下来的窗口中，切换至原始的文件处（Withdraw Cash R10.ucs）。
差异可以通过接受或者拒绝变更来得到解决。基本上，您需要考虑三种不同的场景（图 20，“合并原始和已分支的文件”）。
方案 1：对已存在需求所做的变更
需求会同时呈现在原始和分支后的文件中。如果您想要将对分支需求所做的变更转移到原始的需求中，那么原始的书签必须还保留在原始的文件中。在解决这些不同点之后，拒绝所有引用格式变更或者用例删除的变更。您只需要接受对书签内文本所做的编辑操作（如果您想要让变更回到原始处的话，如果不是的话，就拒绝它们）。
场景 2：需求的删除
需求会呈现在原始的文件中，但是会从分支的文件中删除。如果您想要删除原始文件中的需求，那么您可以接受与该部分相关的所有变更。如果您并不想这样做，那么就完全地拒绝它。
场景 3：需求的添加
需求并没有呈现在原始的文件中，而是添加到分支了的文件中。如果您想要在原始的文件中添加需求，那么您可以接受与该部分相关的所有变更。如果您并不想这样做，就完全地拒绝它。
图 20. 合并原始和已分支的文件
出于这个例子的考虑，我们想要对原始的文件执行编辑操作、输出操作。因此，在接受和拒绝变更之后，合并结果如图 21，“在 Microsoft Word 中合并后的结果”所示。
- 完成之后您可以保存原始的文件。
重要提示：
Rational RequisitePro 并没有参与到合并的过程中，所以只有当您 RequisitePro 中打开原始文件之后，RequisitePro 才会检测到所做的变更。
图 21. 在 Microsoft Word 中合并后的结果
- 从 RequisitePro 客户端打开原始的文件。RequisitePro 将会检测到 Microsoft Word 合并文件过程对文档所做的变更（图 22，“RequisitePro 检测到来自外部的变更”）。
图 22. RequisitePro 探测到来自外部的变更
- 点击 Yes 以更改与编辑原始文件的数据库。
- 在命令行中提供一个有意义的描述（图 23，“RequisitePro 需要一个变更描述”）。
图 23. RequisitePro 需要一个变更描述
在更新过程中，RequisitePro 会检测到一个属于分支文件中的需求的书签。对于任意给定的需求 RequisitePro 需要一个单独的位置，所以您可以做一个选择，要么从其他的文件中剪切和粘贴，又或者创建一个拷贝。记住需求文本与属性值有一个完整的拷贝。
对于这个例子，创建一个拷贝以避免从 R11 版本中取出所有的需求（图 24，“Requirement Found 视图以及 RequisitePro 内的选项”）。
图 24. Requirement Found 视图以及 RequisitePro 内的选项
R10 需求文档中的最终合并结果如图 25 所示，“Rational RequisitePro 中的合并结果”。
注意：
如果存在有被编辑过的需求，属性值并不会像对添加的需求那样得到自动的复制。相反，属性值需要由人手动检查和修改。在最后一步中，改变分支的属性以反映合并操作已被执行的信息（图 26，“根据属性显示合并的状态”）。
一个精巧的视图组合，过滤所有可疑的链接（发生过变更的）以及属性（尚未执行的合并操作的），对哪些需求有差异以及哪些需求需要合并提供了一个清晰的理解。
图 25. Rational RequisitePro 中的合并结果
图 26. 根据属性显示合并的状态
总结
并行处理基于文档的需求，看起来好像为项目增加了一些灵活性。但并行工作也意味着需要付出更多的精力，尤其是在解决那些同时发生的变更时。虽然 Rational RequisitePro 不是为这样的一种环境所设计的，也因此没有提供分支或者合并功能，但它在某些程度上还是可以支持这一使用场景。由于这些限制因素的存在，在一个非常关键的项目中对这种使用场景的使用应该有所控制。
| 
