需求管理是发现、记录以及管理需求的一种系统的方法。需求定义了应用程序期望的特性和功能。更重要的是,记录需求形成了利益相关者和开发团队之间的协议,以便保证解决方案能够充分满足目标用户的需求。
关于为什么需求管理很必要的更多信息,请参阅 developerWorks 的文章“Requirements management: Your insurance policy on large-scale projects”。
要完成本文的步骤,需要一份 RequisitePro 2003 版本的拷贝(请下载 RequisitePro Version 2003 试用版)。还需要 Microsoft Word 2000、XP(Word 2002)或 Word 2003,以便从系统得到最大收益。
管理需求就是要管理变化。我们生活在一个动态的世界中,变化无处不在:客户在改变主意、竞争对手在我们发布解决方案之前带着同样的解决方案而来、业务环境也在变化。变化本身不是坏事,但是不受控制的变化(影响在发生之前无法测量)对于项目的成功则是有害的。终极目标就是及时地发布能够解决客户真正问题的解决方案。由于没有需求管理,超过三分之二的项目缺少用户提请的需求,延期完成,或者超过预算。成功项目的关键是通过清晰地定义需求来管理变化,并在解决方案开发周期中根据需求适应变化。
关于在迭代的团队开发环境中的需求管理的更多细节,请参考 developerWorks 的文章 “Supporting Iterative Development Through Requirements Management”。
用例用来表示需求。用例对用户是友好的,它代表用户角度对系统和系统行为的观察。因为用例模型是从业务分析师的视角定义的,所以它提供了一种层次的抽象,对项目相关者来说是有用的沟通工具。
要想更好地理解用例与需求的关系,请阅读 developerWorks 的文章“Ending Requirements Chaos”。
IBM Rational RequisitePro 是一个强大、易用、集成的需求和用例管理产品,它能够促进更好的沟通、提高团队协作、降低项目风险。RequisitePro 提供了用来保存和跟踪需求的数据库。可以用以下两个方法中的任意一个向数据库添加需求:
- 专门的项目管理式的界面
- 在 Microsoft Word 中记录的需求规范
后一种方法可以让人们继续使用熟悉的需求规范文档和模板,甚至在 Word 内部生成需求,同时帮助人们得到被管理的需求数据库的好处。本文重点介绍使用传统的用 Microsoft Word 创建的需求和用例文档来填充数据库。
首先,必须创建一个项目。RequisitePro 有四个项目模板:空、传统、用例以及复合。(也可以创建项目模板,这项工作本文后面会做。)这个场景采用的是用例模板,因为打算使用用例的方式来表示系统需求。
按以下步骤创建项目:
- 启动 RequisitePro application Programs > Rational Software > Rational RequsitePro。
- 软件会提问是创建新项目还是打开现有项目。要创建新项目:
a. 选择 New 标签。
b. 选择 Use-Case Template 项目类型并选择 OK,如图 1 所示。
图 1. 创建项目
c. 输入项目名称External Claims Assessor,如图 2 所示,并选择 OK。
图 2. 新项目的属性
d. 在提示创建项目目录时,选择 Yes, 如图 3 所示。
图 3. 创建新目录
e. 当项目创建成功时选择 Close。如果提示输入用户名,请用有管理权的用户或输入analyst。
项目目录默认创建在 C:\Rational\RequisitePro\Projects 目录下。如图 4 所示,用例项目模板创建了一个需求管理计划文档,还有 7 个带有额外文档和视图的包。每个视图都是对需求数据库中数据的一种特定的表示。
图 4. 用例项目
每个项目都有关联的文档类型、需求类型以及需求属性。可以用 File > Project Administration > Properties 打开项目属性对话框查看定义的项目值,如图 5 所示。
图 5. 项目属性
本文随项目在 Features and Vision 文件夹中准备好了一个 Vision 文档(用它替换空模板)。 (请点击顶部的代码图标下载 Vision 文档。)
- 首先,选择文档,并在上下文菜单中选择 Delete,删除空的 Vision 文档,如图 6 所示。
图 6. 删除文档
- 选择 File > Import 菜单选项,导入完成的 Vision 文档。如图 7 所示,把文件类型指定成 Microsoft Word Document,指定要导入的文档,然后选择 Next。
图 7. 导入文档
- 把导入的内容指定为 Document only 并选择 Next。随着对 RequisitePro 的熟悉,可以学习更高级的任务,例如如何只用一个导入功能解析和定义文档中的需求。
图 8. Document only 导入选项
- 在提示文档属性对话框时,提供必要的值:
-
Name:
Vision -
Filename:
Vision -
Document Type:
Vision
Filename 属性默认使用 My Documents 目录,在里面可以找到名字为 Name 值加默认 Word 扩展名 .doc 的文档。
现在有了一个源文档,从它采集需求,保存在项目数据库中。当文档在 Word 中打开时,会显示一个新的 RequisitePro 工具栏和菜单组,如图 9 所示。
图 9. RequisitePro Word 菜单和工具栏
必须要用 RequisitePro 工具栏和菜单执行典型的文件命令(例如 Save 和 Close),这样才能把变化与 RequisitePro 数据库同步。不要使用标准的 Word 菜单选项。
如图 10 所示,有 6 种基本需求类型与用例项目关联:
- Stakeholder Request(利益相关者请求)
- Feature(特性)
- Use Case(用例)
- Supplementary(补充)
- Glossary Item(术语表)
- None (无,充当占位符,容纳那些不符合默认类型定义的需求的值)
图 10. 需求类型
典型情况下,首先要启动利益相关者请求,它指的是那些在最终产品中有利的人的通用需求。接下来,产品特性是根据这些请求定义的。最后,产品特性被分解成系统用例以及能够被进一步分析并作为系统组件的低级需求细化的补充需求。由于开发是个迭代的过程,所以需求定义并没有终止在初始的项目定义阶段。随着系统的支持文档和组件级的架构不断发展,需求在整个过程中也在不断定义和重新定义。这种发展过程是与前面讨论的引起变化的优化过程同时发生的。
要在 RequisitePro 中定义记录的需求:
- 如图 11 所示,选择 Vision 文档中的需求文本(我们选择“产品特性”一节中描述的第一个特性的文本)。选择 RequisitePro > Requirements > New 菜单选项上的 New Requirement 工具栏图标(
) 。
图 11. 创建需求
- 正如在图 12 中看到的,在 Requirement Properties 对话框中指定以下值:
-
Type:
Feature -
Name:
Claims Process Monitoring and Management
图 12. 需求属性
需求以挂起的状态显示,直到保存文档为止。请记住要用 RequisitePro > Document > Save 菜单选项或者 RequisitePro 工具栏图标 Save Requirements Document (
)。现在,在 Vision 文档中需求不再显示为挂起。在项目数据库中也应当能够看到需求。在项目管理客户机中,现在可以看到在 Features and Vision 文件夹中列出了新特性。如果打开 All Features 视图,如图 13 所示,还会看到需求以及与其关联的属性。
图 13. 新需求视图
如图 14 所示,默认的属性包括 Priority(优先级)、Type(类型)、Status(状态)、Difficulty(难度)、Stability(稳定性)、Risk(风险)、Planned Iteration(计划的迭代)、Actual Iteration(实际的迭代)、Origin(来源)、Contact Name(联系人名称)、Enhancement Request(增强请求)、Defect(缺陷)以及 Obsolete(过期)。这些属性是用属性编辑器中的 Attributes 标签定义的(File > Project Administration > Properties)。
图 14. 需求属性
可以用这个编辑器添加、修改、删除或记录需求属性。如果添加新需求或编辑现有需求,就会出现属性编辑器,如图 15 所示。
图 15. 需求属性编辑器
要定制某个视图显示的属性,请打开视图,右击任何一个属性列,并选择上下文菜单中的选项,如图 16 所示。
图 16. 配置视图的属性显示
也可以用这个菜单排序、删除或查询属性。总结一下,RequisitePro 可以在项目级、需求级以及需求属性级上进行定制,这使它能够服务于任何组织流程及其工件。
用例是众所周知的统一建模语言(Unified Modeling Language,UML)的建模工件,它表示系统为了响应用户或其他系统交互而执行的能够产生可以观察到的且有价值的结果的一系列动作。换句话说,用例是系统需求的表示,而 RequisitePro 把用例当作特殊类型的需求。用例项目支持用例文档类型,可以用这个类型定义每个用例的细节。
要定义用例:
- 从上下文菜单中选择 New > Document 打开 Use Cases 文件夹,并创建用例文档,如图 17 所示。
图 17. 新建用例文档
- 指定文档名称为
Retrieve Claim Status,并选择文档类型为 Use Case Specification。
图 18. 用例文档属性
- 文档由用例模板创建,并在 Microsoft Word 内打开。通过添加项目名称、用例名称、用例细节等来编辑文件。文件模板有一些关于要定义什么需求的有价值的注释,但是本文提供了示例文档 Retrieve Claim Status.doc。这个示例文档可以像 项目定义 一节所示的导入 Vision 文档一样导入。(请单击顶部的代码图标下载示例 Retrieve Claim Status 文档。)
- 一旦定义了用例文档,就可以选择用例文本、创建
case类型的需求,从而用用例细节填充需求数据库了。a. 选择用例名称,创建用例需求。在 General 选项卡中输入名称
Retrieve Claim Status,如图 19 所示。
图 19. 用例需求属性 - general
b. 如图 20 所示,选择 Attributes 和 Name 属性。选择 OK 保存需求。
图 20. 用例需求属性 - attributes
c. 根据需要重复其他用例细节。也可以创建示例文件中提供的 Brief Description(简要说明)、Basic Flow(基本流程)以及 Alternate Flow(备选流程)这些用例属性。额外的属性类型包括:Special Requirement(特殊需求)、Pre-Condition(前提条件)、Post Condition(后置条件)以及 Extension Point(扩展点)。高级用户还可以通过定义自定义属性进行扩展(如图 14 和 15 所示)。
- 用例需求创建之后,就可以在 Use Cases 数据库视图中看到它们。请选择 Use Case Traced to Features 数据库并打开它,如图 21 所示。
图 21. Use Case Traced to Features 数据库视图
- 用例的细节可以进一步组织成父子关系:
a. 选择 Brief Description 用例需求并选择 Change Parent,如图 22 所示。
图 22. 创建用例父子关系
b. 从 Select New Parent 对话框的下拉列表中选择 <Choose Parent>。选择 UC1 Retrieve Claim Status 需求作为父亲,然后选择 OK 关闭 Parent Requirement Browser 对话框。
c. 选择 OK 关闭 Select New Parent 对话框。
d. 关系的变化处于挂起状态,在需求文档保存之前在数据库视图中都看不到。请选择 Word 中的 RequisitePro 工具栏上的 Save Requirement Document (
)图标保存需求文档。新的关系如图 23 所示。
图 23. 用例父子关系的数据库视图
- 根据需要为其余的用例重复这些步骤。同样,对数据库的填充、对属性和关系的分配是灵活的,可以进行定制以满足任何项目的需求。
图 24. 用例关系
用例父子关系在 Word 文档中显示,如图 25 所示。
图 25. 带有用例父子关系的 Word 文档
项目需求创建之后,就可以在不同的需求类型之间定义关系,这提供了在项目生命周期中跟踪需求的一种手段。因为变化是不可避免的,所以这些跟踪关系充当着提示,可以验证所有的变化都被分解到全部相关的工件。
要创建需求跟踪关系:
- 打开有关的数据库视图。要在特性和用例之间创建跟踪,请打开 Use Cases 文件夹中的 Use Cases Traced to Features 视图。
- 如图 26 所示,在映射到用例和相关特性细节的框中右击。选择上下文菜单中的 Trace To ,建立从用例到特性的跟踪。
图 26. 创建跟踪关系
- 跟踪用蓝色箭头表示,如图 27 所示。
图 27. 用例到特性的跟踪关系
- 可以在其他级别上设计额外的跟踪关系,例如从特性到相关者请求、跟踪的辅助需求到特性、需求到 XDE 模型工件等跟踪关系。当需求链的某个元素发生变化时,所有的跟踪关系都会标记成可疑,如图 28 所示。
图 28. 可疑的跟踪关系
- 在验证完变化已经完成之后,可以在上下文菜单中选择 Clear Suspect,清除可疑标志,如图 29 所示。
图 29. 清除可疑的跟踪
RequisitePro 提供了几个项目模板,但是可能还想为自己的团队定制一个模板。可以添加定制需求类型、需求属性、定制文件夹以及数据库视图。也可以在项目模板中删除或添加 RequisitePro 包含的文档类型。
要创建定制项目模板:
- 打开 RequisitePro 应用程序,但是不要打开任何项目。打开 Create Project 窗口(File > New > Project,或者在提示打开现有项目时选择 New 选项卡),并选择 Make New Template 图标。
图 30. 创建新的项目模板
- 选择 Next,如图 31 所示,并按向导的指示操作。
图 31. 创建新项目模板向导
- 输入模板名称
Extended Use Case,选择要作为基模板的 RequisitePro 项目(External Claims Assessor.rqs)。如果选择 Include Project Data,则需要把指定的项目数据结构作为新模板的一部分拷贝。否则,模板为空,可以从头开始添加元素。对于这个练习,不要选它。还可以提供一个带有文本说明的文档文件( .rtf 格式)作为新项目模板类型。
图 32. 新项目模板信息
- 带有模板特征的摘要屏幕出现。选择 Next 和 Finish 创建模板。
- 当模板完成时,选择 Close。出现一个对话框说明成功创建了模板。现在模板出现在模板列表中,如图 33 所示。
图 33. 创建新项目
- 用名为 Extended Use Case 的新模板创建称为 Test Project 的新项目。项目是空的(没有默认元素)。
图 34. 创建新包
- 选择项目的根 Test Project 并从上下文菜单中选择 New > Package,以添加名为
Use Cases的包。
图 35. 新包的属性
- 如果想要添加自己的文档类型,就必须在添加新文档类型之前创建相应的 Microsoft Word 文档模板(.dot 文件)和定义文件。定义文件包含大纲(或文档类型)名称、大纲说明以及对应的 .dot 文件。
- 要创建新文档大纲类型,请创建新的 Microsoft Word 模板(.dot 文件)。
注意:请在 RequisitePro 之外 打开 Word!创建一个空文档或者打开一个现有的文档作为自己的模板。把它保存成文档模板类型(File > Save As),并在 Word 中选择文档类型 Document Template (.dot)。
- 创建包含三行的文本文件:大纲名称、大纲说明以及大纲文档模板(.dot)。用与模板相同的名称和扩展名 .def 保存文件(use_case_model.def)。
- 把新的 .def 文件拷贝到 RequisitePro 的大纲目录。
- 本文提供了示例的文档模板(use_case_model.dot 和对应的定义文件 use_case_model.def)。(单击顶部的代码图标下载示例文档模板。)请把它们拷贝到 RequisitePro 的大纲目录 C:\Program Files\Rational\RequisitePro\outlines。
- 默认情况下,现有的全部文档类型对每个项目都可用,如图 36 所示。但是,可能还想向系统添加新的文档类型以便它能与自己的项目模板关联。为此,请打开项目属性窗口(File > Properties,或右击项目并从上下文菜单选择 Properties)。
图 36. 文档类型的项目属性
- 选择 Document Types 选项卡和 Add。
- 输入文档类型名称
Use Case Model、扩展名UCM,以及大纲名称,如图 37 所示。文档类型和扩展名是用户定义的值,它们应当能够表示新文档类型的意义。大纲名称是随 RequisitePro 一起提供的可用的文档模板列表。
图 37. 创建新文档类型
- 现在新文档类型出现在列表中,如图 38 所示。请选择 OK 确认。
图 38. 新文档类型
- 现在,在 Use Case Model 类型的 Use Cases 包下创建新文档。请选择 Use Cases 包并从上下文菜单选择 New > Document,如图 39 所示。
图 39. 创建新 Use Case Model 文档
- 输入新文档名称
Use Case Model,文件名为Use Case Model,文档类型为Use Case Model,并选择 OK,如图 40 所示。
图 40. 创建新 Use Case Model 文档
- 新文档显示在项目中,如图 41 所示。
图 41. 项目中的 Use Case Model 文档
RequisitePro 支持在项目级、文档级、需求级以及需求属性级上进行定制。也可以添加定制数据库视图和文档模板。RequisitePro 是管理项目需求、在项目生命周期中管理项目的跟踪的强大而灵活的工具。
关于使用 RequisitePro 管理需求的更多细节,请参考 developerWorks 的教程“Manage your requirements and more with RequisitePro”。
这个关于模型驱动开发的系列,着重为一个涉及两家保险公司的合并的场景采用端到端的开发视角,创建一个外部估损人系统。在整个系列中,您会发现集成问题、角色之间的交换,以及不同工具之间的开发工件流。在计划的工具故事中,还会学习到端到端的跟踪能力和目前的支持级别。
在本文中,学习了 IBM Rational RequisitePro 对管理需求的帮助,而且管理变化是开发项目面对的关键问题。如果定义了有效的需求并创建了适当的跟踪关系,那么任何规模的项目都更能成功地满足客户的期望。RequisitePro 是一个易用的、高度可定制的管理项目需求的工具。
后续的文章侧重于:
- Rational XDE 作为建模业务和设计资产的核心工具,还可能是资产代码生成的核心工具(您将会看到分析师、架构师和开发人员角色各自如何应用 Rational XDE 工具。还会了解如何把 RequisitePro 需求链接到 XDE 模型工件)。
- WebSphere Business Integration Modeler 和针对 Business Process Execution Language(BPEL)生成的业务流程建模,以及 WebSphere Process Choreographer 对它的支持。
- WebSphere Studio Application Developer Integrated Edition 把实现细节添加到业务流程,为应用程序代码资产添加编辑器支持(这个讨论的主要侧重点是开发和部署)。
- Bowstreet Portlet Factory 是 WebSphere Studio Application Developer 的一个插件,可以作为向业务流程添加 portlet face 的一个示例。
| 描述 | 名字 | 大小 | 下载方法 |
|---|---|---|---|
| Download the prepared Vision document | i-modev2.zip | 200K | HTTP |
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- 请访问 IBM 的杰出工程师 Alan Brown 的 blog,他的 blog 研究了 模型驱动开发。
- “Requirements management: Your insurance policy on large-scale projects”(developerWorks,2003 年 6 月)解释了尽早开始需求管理,特别是在处理大型、长期的项目时,对于项目的成功是至关重要的因素。
- “Supporting Iterative Development Through Requirements Management”(developerWorks,2004 年 6 月)解释了需求管理如何能够帮助团队成员更加有效地一同工作、支持迭代开发。
- “Ending Requirements Chaos”(developerWorks,2004 年 2 月)详细解说了需求混乱的成本和其他后果,以及如何避免这个问题。
- “Manage your requirements and more with RequisitePro”(developerWorks,2004 年 6 月)解释了如何把接收到的需求在 RequisitePro 中变成项目,这样就可以跟踪需求信息并利用信息产生项目计划和需求文档。
- “Writing good requirements is a lot like writing good code”(developerWorks,2004 年 6 月)证明开发人员能够有效地担当需求工程师。
- 在 Developer Bookstore 上以折扣价购买广泛的技术主题的图书。
