Rational Requirements Composer 助力生命周期需求工程活动

Rational Requirements Composer(简称 RRC)是 IBM Rational 基于 Jazz 平台构建的集需求定义与需求管理于一身的需求工程平台。RRC 发展至今已有数载,版本也发展到 4.0.1,无论是从功能性、易用性、可用性上,还是从对需求工程理念的实现和遵从,都已经进入了一个良性发展的成熟期。本文首先对需求工程领域相关活动及其概念进行简要阐述,由此引出需要展开的需求活动以及相应目标和目的,进一步映射到 RRC 的使用场景和相关提供的功能。希望借助本文,对围绕需求工程以及 RRC 的生态圈贡献微薄之力,也希望能够帮助读者对需求工程有基本的认识,同时对 RRC 的能力有初步的了解,便于对其进行进一步评估,甚至能够投入使用。

姚 冬, 高级技术顾问, IBM

姚冬拥有十多年系统软件开发和软件工程实践经历,在相关行业系统软件开发领域积累了丰富的经验,目前关注复杂系统开发,以及软件过程改进等方面的研究。



2012 年 12 月 31 日

下载 IBM® Rational® Requirements Composer 试用版  |  在线试用 IBM Rational 协作化生命周期管理解决方案
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

概述

近两年与客户的交流过程中,我们越来越多的看到,国内客户对需求工程的意愿和认识都在逐步提升,众多的客户在努力尝试需求工程相关实践,走过许多误区,也欣喜看到许多长足的进步。成果是明显的,我们逐渐认识到需求工程能力的提升不是一朝一夕,能够一蹴而就的事情,但同时仅靠热情和时间的堆积也无法到达成功的彼岸。理论与实际的结合,实践与工具的结合,才是相辅相成,才能够确保一步一个脚印,扎实而坚定的向着需求活动的目标——质量保证而迈进。

Rational Requirements Composer(简称 RRC)是 IBM Rational 基于 Jazz 平台构建的集需求定义与需求管理于一身的需求工程平台。RRC 发展至今已有数载,版本也发展到 4.0.1,无论是从功能性、易用性、可用性上,还是从对需求工程理念的实现和遵从,都已经进入了一个良性发展的成熟期。

本文首先对需求工程领域相关活动及其概念进行简要阐述,由此引出需要展开的需求活动以及相应目标和目的,进一步映射到 RRC 的使用场景和相关提供的功能。希望借助本文,对围绕需求工程以及 RRC 的生态圈贡献微薄之力,也希望能够帮助读者对需求工程有基本的认识,同时对 RRC 的能力有初步的了解,便于对其进行进一步评估,甚至能够投入使用。

备注:RRC 是 IBM Rational 协作化的生命周期管理(CLM)整体方案中不可或缺的一部分,CLM 强调的协作不仅体现在团队、流程、人员以及资产之间,同样体现在研发生命周期的不同阶段。需求过程作为研发生命周期所有活动的起源,必然也必须要与开发过程以及质量过程产生密不可分的关联。因此对需求工程以及 RRC 的了解不能仅局限在需求领域,而是应该投射到整个生命周期的各个阶段。有关 CLM 的相关内容,可以参阅 Developer Works 上相关文档。


需求工程领域活动基本概念简述

需求活动贯穿整个软件 / 系统开发生命周期,是研发活动的源头,同时也是衡量研发结果的唯一标准。正因为需求过程跨度长,涉及的活动多,同时与整个开发生命周期其他活动相互交织,彼此关联,与需求活动相关的概念与名词也层出不穷,有些概念甚至彼此混淆。因而有必要对需求过程中涉及的常见活动以及相关概念进行简要描述,便于统一认识。同时也能够通过一条主线对 RRC 所提供的功能进行串联,有助于提升对 RRC 使用的理解。

需求工程

对于整个需求生命周期范围的活动,我们称之为"需求工程",需求工程包括两个阶段:需求定义和需求管理(包括变更管理)。前者更关注需求的衍生,后者更关注需求的实现,如下图所示:

图 1. 需求工程概念
需求工程概念

需求定义阶段

简述

需求定义阶段主要关注从不同涉众获取需求,组织人员进行需求分析,定义需求规格说明书,评审并验证对需求的理解,确保对需求达成统一的理解与认识。

传统软件工程,例如瀑布式开发方法假设可以一次性得到完全正确的需求,长期实践证明过于理想化,需求定义事实上是一个不断反复的过程。现代软件开发实践表明,我们很难一次性得到完整并正确的需求,项目的开发总是伴随着需求的不断明确和演化而进行的,而这一过程的关键在于如何有效降低需求不确定性的风险。一个行之有效的方法就是不断迭代地进行需求的开发与验证。

同时需求根据涉众、角度以及阶段的不同,又划分了不同的层次:业务需求、用户需求、(软件)系统需求。如下图所示:

图 2. 需求定义的不同层次
需求定义的不同层次

其中业务需求是整个需求活动的源头,它阐明产品的高层次概念和将发布产品的主要业务内容。业务需求说明客户、企业以及想从该系统获利的风险承担者或从系统中取得结果的用户所要求的目标。业务需求为后继工作建立了一个指导性的框架。其它任何内容都应遵从业务需求的规定。需要注意的是业务需求并不能为开发人员提供许多开发所需的细节说明。

用户需求是从使用产品的用户处收集,用户能说清楚要使用该产品完成什么任务和一些非功能性的特性,而这些特性会对使用户很好接收和使用具有该特点的产品是重要的。

系统需求则是用户需求到软件系统层面的映射,描述了软件系统所应具有的外部行为,

分析方法

由上图可以看出,业务需求属于业务领域,更为宏观。业务需求通常来自于风险承担者,而用户需求则应来自产品的真正使用、操作者,用户需求与系统需求则属于解决方案领域。

正是由于需求有不同的层次、分属不同的领域、涉众人群有所区别,看待问题和分析问题的角度和方法也不尽相同。

在业务领域,我们通常通过业务流程来梳理描述业务需求,一张简单的示意图就可以用来描绘出用户的业务活动,输入输出数据,起始、中止以及判决条件等。编制业务流程有助于明确产品的使用实例和功能需求。

由于在业务领域有可能涉及到不同行业,不同的行业、不同的业务领域会有不同的术语。同时业务领域活动是后续分析、实现与验证的输入,需要与整个研发生命周期涉及到的不同团队形形色色不同人员进行沟通;因而定义一套统一的术语表有助于统一认识,减少误解。术语表有时也称为数据字典。

在用户需求层面,我们通常可以采用用例模型辅助进行需求分析,同时在这个阶段,除了功能性需求,我们还可以整理出非功能性需求。非功能需求包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性。

从系统角度我们可以通过多种方式使需求分析人员、设计人员,甚至开发人员、测试人员与需求干系人进行交流。通常我们建议开发领域人员能够尽可能的与用户进行沟通,尤其是敏捷开发更是强调用户的参与,用户如果能够在开发过程中,尤其是需求分析阶段更多的介入,能够有效提升团队对于需求的理解,避免由于信息的缺失或误解造成损失。

需求的信息,除了需求的内容以外,还包括例如优先级、必要性、来源、状态、负责人等信息,通常称为需求的属性。同时需求的层级之间,不同的需求之间会有关联关系,例如父子关系、追踪关系、依赖关系等,关联关系的维护和梳理同样有助于对需求的认识和理解。

在系统需求领域我们有例如故事板、草图、UI 设定、界面流程等多种方式对需求进行深入分析,同时通过这些手段与用户进行交流。诸如故事板、草图、UI 设定等图形化的方式更有助于双方对需求点达成一致,更加直观,能够有效的规避语言文字在理解上的二义性。

需求管理

需求管理阶段关注"建立并维护在软件工程中同客户达成的契约"(SEI),负责对需求进行组织和记录,并在发生变化时对它们进行评审与追踪,维护和追踪状态,对需求进行版本管理。

如果说需求定义阶段是关注于哪些是"正确的事情",则需求管理阶段关注在如何"正确的做事情"。

需求管理模型

如前面所述,需求是分不同层次和类型的,像下面的"需求金字塔"所示,不同层次的需求和同一层次的需求之间都可以建立追踪关系:

图 3. 需求管理模型
需求管理模型

为了建立一个真正满足客户需求的系统,项目团队首先必须确定系统要解决的问题。然后,团队必须确定涉众,从中获得业务和用户需要,对其进行描述,并区分它们的优先级。从这一组高层期望或需求出发,对产品或系统特性集达成一致意见。而后,由产品特性来抽取软件需求,在 IBM Rational 的需求管理模型中,软件需求是以用例模型的方式来描述。从测试的角度来看,测试项一定来自于软件需求,即软件需求中确定了哪些需求项,测试就要根据这些需求项来制定和实现。

结构化与条目化

从上面可以看到,多角度、多层面、多阶段的描述需求对用户和开发人员都极为重要,这也正是需求的结构化管理的必要性。同时,在不同层面的需求进行拆分映射时,需求的粒度是衡量需求质量的重要标准,这是需求的条目化的范畴。在结构化和条目化的基础上,建立起需求之间的关联,建立起需求与设计、开发以及测试之间的关联,包括活动及产物,是进行需求管理活动,例如覆盖率分析、影响分析、来源分析、需求变更管理等不可或缺的基础。

有了上面对需求工程的基本概念以及活动的概述作为基础,我们下面来看看这些概念是如何映射到 RRC 中相关的能力,同时可以了解如何在 RRC 中进行完整的软件需求管理活动。


需求的集中管理

集中管控所有产品 / 项目的需求一方面是产品经理 / 项目经理的职能所在,另一方面也是需求工程的提出的最基本的要求:在客户和项目团队,以及在项目团队内部对项目交付建立统一的认识。RRC 是一个基于数据库的工具,通过直观、文档风格的用户界面为并发用户提供统一的、可定制的视图,来显示最新的需求信息以及其它由需求分析演化而来的项目信息。在数据库中,客户可以同时存储、访问和管理多个项目的需求信息及其衍生的项目其他文档。

同时,集中管控能够有效保证需求的安全。高级用户可以被允许访问多个项目的数据,而特定用户可以被限制仅仅能够访问某个项目,或者项目中的某些文档,或者是文档中的某些需求条目。完善的访问控制是 RRC 能得到广泛应用的重要前提。

图 4. RRC 提供集中的需求管理
RRC 提供集中的需求管理

跨部门、管理多项目的需求信息

随着企业规模的增长,跨部门、管理多产品 / 项目线的需求信息的要求也日益增长。RRC 可以按照项目或产品线来组织整个需求管理库,但信息的流动和操作并不局限在一个项目或产品线内部。这是为企业级需求管理工具的重要特性:用户可以同时参与和管理多个项目,允许在多个项目需求条目之间建立关联。通过这些关联,用户可以记录和洞察项目或产品之间的相互依赖和作用,这些关联关系将在企业级解决方案层次的需求管理上具有重要作用。RRC 中对需求的管理更多偏重在内容管理,因此虽然 RRC 中需求库冠以项目区域的概念,但实际上我们可以根据不同需要,灵活的以系统或项目为单位组织相关需求,甚至可以在一个项目区域中管理整个企业层面所有需求。


多方位的需求定义与捕获能力

实现有效的需求工程,第一步就要解决需求的定义问题。项目的干系人众多:客户、业务部门、开发人员、维护人员等等,造成了需求的来源众多,而且渠道多样:开会收集的、市场调研的、电话沟通的、电子邮件交流的等等。但由于缺乏必要的系统平台,于是各种各样的需求就四散在各处,难免造成需求的遗漏,更无从进行有效的管理。RRC 提供了术语及词汇表维护、业务流程建模、用户界面草图、场景描述、故事板和富文本格式的需求规格,有效解决了需求的定义和确认过程中的各种问题。

作为需求分析人员,首先需要和客户沟通,尽量全面的收集需求,并把它们记录到工具中。在 RRC 中,需求分析人员可以通过如下 6 种方式捕获需求。

图 5. 多方位的需求定义和捕获能力
多方位的需求定义和捕获能力

原始需求导入

将各类原始需求(年度需求计划、突发需求等)引入的需求管理系统中,作为整个需求管理流程的入口。RRC 作为需求分析和追踪工具,具备丰富的数据导入和导出以及报告、打印功能,包括 Word、RTF、CSV、文本等格式,并且支持标准化的方式确定需求项,支持文本、图形、表格、OLE 对象等各种数据形式,从而保证现有数据的完整性。

在新的 RRC 4.0.1 版本中,新增加了模块的功能,可以方便的将文档形式的需求直接导入形成富文本形式的工件,同时根据导入时设置的规则,工具可以自动的对文档进行条目化拆分。这样,即保留了原文档的完整展现方式,又可以通过条目化的形式便于后续的需求分拆与合并。模块方式类似 Word+Excel 风格,存放的内容都是以条目化的方式存在,可以建立与其他需求、开发任务、测试任务、需求变更等的关联。支持打基线、可以直接与开发测试计划进行关联。

图 6. 模块视图
模块视图

图 6 大图

导入后的原始需求,可以经需求分析之后,建立起原始需求和系统需求的关联关系,从而确保各种需求得到分析和实现。

需求的拆分与合并是需求分析过程必不可少的环节,操作的便利性以及合理性直接决定了需求存储结构的良莠。IBM 平台支持对需求内容的管理,包括内容的编辑、修改和维护,以及内容之间的关联,例如链接、内嵌、术语引用等。

图 7. 需求拆分与合并
需求拆分与合并

如上的内容编辑界面,可以选择插入图片或独立的工件,如果将多个子需求插入,则实现了需求的合并,将合并后的需求作为条目进行后续的追逐。

也可以由大的父条目进行拆分,拆分生成多个子条目,子条目与父条目可以是链接关系,子条目也可以直接嵌入到父条目,这样保证阅读父条目时,子条目的内容会直接显示出来,同时子条目的变化也能同步到父条目。

RRC 还可以设置需求标准模板,对进入系统的需求进行规范化,并可通过追踪视图,可便捷地对需求的满足性进行分析,从而确保需求的规范管理。

定义和维护术语表

RRC 提供了术语和词汇表的定义、同义词关联、缩略语对等以及状态等级等功能,同时通过方便的超链接功能使词汇表的履历与项目需求的定义保持动态的一致。并且可以通过标签(Tag)功能对术语和词汇表进行维护和查询。

通过业务建模了解业务需求

RRC 提供基于 Business Process Modeling Notation (BPMN) 2.0 的子集符号协助客户业务人员和开发人员创建和优化业务流程。

图 8. 业务流程图
业务流程图

用例建模,描述软件的功能需求

RRC 以基于用例 (Use Cases) 的需求组织方式和及其灵活的超链功能,将最初的基于富文本 (Rich Text) 的需求描述按照客户的业务流程逐步细化,并结合以原型、词汇术语的有机组合,最终以立体的方式展现客户的软件需求规格。

图 9. 用例建模
用例建模

图形化原型,便于沟通

RRC 提供了故事板、草图、UI 设定、界面流程等多种图形化的手段,为开发客户原型提供了便捷,同时可以将用户与开发团队拉到同一条水平线上,便于使用户对需求设计原型有一个直观的概念,及时调整误差。

图 10. 故事板与界面流程
故事板与界面流程

需求管理和需求追踪能力

计划层面的追踪

当需求收集、分析完毕后,在 RRC 中存储和展现的,便是经过结构化和条目化梳理的内容。此时我们需要由 RRC 中保存的需求,与开发团队、测试团队沟通,生成相应的开发计划以及测试计划,或者与现存的相关计划建立关联。在 RRC 中,我们使用需求集合(Requirements Collections)对需求进行归类,它是指将某些具有共同意义的需求,比如产品第一个版本包含的所有需求。需求集合需要与开发计划、测试计划保持一致,也就是我们所说的高层计划保持一致。

在 IBM Rational 的协作化的生命周期管理(CLM)中,开发管理主要在 RTC 中进行,质量管理是在 RQM 中进行,这两部分并非本文的关注内容,因此不在此详述。感兴趣的朋友可以参阅 Developer Works 上相关文档。

图 11. 需求集合与开发计划、测试计划的关联视图
需求集合与开发计划、测试计划的关联视图

图 11 大图

当需求集合、开发计划和测试计划都生成好后,就可以建立关联。如下图所示,点击图标图标,我们可以看到多种链接关系,可以选择关联到哪一个开发计划或者测试计划上。

图 12. 需求集合与开发计划、测试计划的关联操作
需求集合与开发计划、测试计划的关联操作
图 13. CLM 提供生命周期的追踪
CLM 提供生命周期的追踪

执行层面的追踪

在确认了某一个需求集合已经和开发计划、测试计划关联上之后,需求人员接下来要做的,是要确保需求集合中的每一条需求,都有开发人员在开发,都有测试人员在测试。展示了需求到开发任务、测试活动的追踪关系,每条需求由哪个开发任务实现,由哪个测试活动测试一目了然。如果没有协作平台展现这种关联,我们极有可能遗漏重要需求。如下图所示,点击打开相应的开发计划,选择"链接"选项卡,发现"2012-10 需求排期"在实现需求集合列表下。点击下拉箭头打开需求列表,发现新增的两条系统需求显示"不由任何计划项实现",表示目前没有任务对相应需求进行实现。鼠标放置在相应系统需求左侧的按钮图标上,显示"根据需求创建工作项",点击。

图 14. 需求执行层面的追踪
需求执行层面的追踪

一旦所有的需求都和开发任务、测试活动关联后,需求人员就已经做到了需求的任务覆盖率和测试覆盖率均为 100%。

同时在 RRC 中打开任意需求工件,查看链接信息,点击"链接浏览器",将打开以当前工件为根的树状跟踪,通过跟踪树,可以进行例如当前需求的影响度分析、生命周期追踪关系、依赖 / 关联关系分析等,为需求管理提供良好支持。

图 15. 需求跟踪树
需求跟踪树

图 15 大图


有效地组织管理需求

需求分解

需求分解包含 2 个层面的含义:

  • 一个用户需求可能是基于多个系统的同时更新来实现的,因此要将用户需求分解成对不同系统的需求;
  • 对同一个系统,一个用户需求也可能是基于多个系统需求来实现的。因此也存在需求分解工作。

需求分解,不仅要将一个用户需求对应到一个或多个系统需求,而且还要实现用户需求到系统需求的转换。这是两种不同的语言:用户需求是面向业务人员,面向客户的;而系统需求是面向技术人员,基于应用系统的语言。在需求分解过程中,要实现此 2 种语言的转换。最终将来自于市场的业务描述,转换为设计开发人员能理解的要求,分解成可执行的任务。

借助于 RRC 能够将:

  • 需求条目化:单一需求描述单一功能,消除歧义;
  • 需求分级分解:单一用户需求分解成清晰,可执行的系统需求。
图 16. 需求树状关系
需求树状关系

建立需求项的跟踪关系

RRC 中将映射关系直接显示在文档中使得对映射关系的追踪不必脱离文档而能够直接即时操作完成。

  • 通过 RRC 可以建立各个分解需求项之间的关系,快速而简洁的操作建立它们之间的映射(关联)关系。从而在修改和变化某一个需求时,可以迅速定位该需求会关联的到哪些需求项,不会有需求变更的漏查和漏执行;
  • RRC 能够有若干种不同的方式分析和观看映射关系,其中最有效的方式是在一个视图上显示所有从用户需求到系统需求(或测试活动)的映射关系(通过一个表单的显示方式),从而找出系统需求满足用户需求(或测试活动)的覆盖关系(即每一用户需求项都映射到至少一个系统需求项)和覆盖率,或从系统需求项(或测试活动)到用户需求的覆盖关系(即每一个系统需求都是用来满足至少一个用户需求的),如下图所示:
图 17. 需求追踪关系
需求追踪关系

基于需求的注释和讨论

IBM 平台对需求内容的管理还体现在,需求分析等相关人员可以直接针对需求内容添加注释以及发起讨论,相关信息将直接与需求内容保持关联,保证其他人员在阅读时可以了解需求背后的过程,提供更完整的需求信息。同时,界面的展现方式又便于阅读,注释和讨论信息不会干扰阅读的过程。

图 18. 需求讨论
需求讨论

需求文档的权限管理

此外,在管理需求文档资料时,RRC 中设定了严格的文档访问权限,该权限能够控制只有被授权的用户才能对其进行修改和更新。RRC 的访问权限能够应用在需求库的各层结构。

需求锁

当需求分析人员对需求进行编辑时,系统会自动加锁防止内容冲突,也可以主动加锁以防止其他人对需求进行修改。加锁者可以主动释放需求锁定,管理员(可配置权限)可以强制解锁。

图 19. 需求加锁
需求加锁

需求的评审

需求的确认以及需求变更需要走评审流程,根据类型由不同角色人员参与评审,例如业务部门、产品经理、开发经理、测试主管等。

评审可以走正式的评审流程,组织评审会议,可以将评审会议的决议作为附件形式添加变更申请,也可以作为会议纪要保存,同样可以建立评审申请与会议纪要的链接,以便于追踪评审决议过程。

评审也可以简单的基于工具提供的评审流程进行,添加适当人员作为评审人员,评审人员将收到邮件通知(需配置邮件服务器)并且在登录系统时有信息提示待评审条目。只有全部评审人员都评审通过后才能交由开发部门进行实施,评审的过程都有详细历史记录。

图 20. 需求评审
需求评审

相关评审人员有义务评估需求内容、变更内容、优先级等条目的合理性,并给出评审建议,所有评审的过程或会议纪要均保持有历史记录,便于问题追溯。可以基于评审发起讨论,提交注释和建议,查看相关评审状态,以及查看一次评审中多条内容各自状态,如下图所示。

图 21. 需求评审状态信息
需求评审状态信息

需求的变更是不可避免的,为了能够更好的理解需求,我们需要知道每个需求的变更过程(何时,变成什么,被谁改变)。RRC 能够帮助用户自动完成需求变更的记录,对于每条需求都记录了它变化的历史。

有些项目的时间很长,如何评价和估量某个变更对整个系统及其若干子系统的影响,是非常关键的。如果给定需求发生变化,它将带来哪些影响,这个影响可能改变设计 , 也可能会影响对应的测试活动。

在做出决定是否接收该需求的变更之前,RRC 将通过如前面所示的需求跟踪视图等报告或报表来帮助相关责任人分析需求的关联关系和影响程度,以此来评估需求变化给整个系统及其若干子系统带来的影响和影响的程度。

引入 RRC 的突出优势就是帮助项目面对各种变更。变更理由可能是客户、设计或者业务的变化,也可能是具体需求或者规格的变化。RRC 的引入将极大帮助项目资产的管理。RRC 中可以记录此间由需求而产生的功能需求、测试变化等等,更重要的是记录怎样把高层用户需求转换为下层的需求信息及其项目中的其他由需求驱动而来的产出物。这样,项目各方都能了解各个信息之间的关系。只有有力地保障贯穿整个项目的信息跟踪性,清楚了解需求及其产出物的关系,我们才能全面把握项目活动的成果,轻松应对各种可能的变更,准确地进行变更的影响分析。


需求版本与基线管理

需求文档评审的结束,标示着项目管理的一个里程碑,该控制的主要活动包括:

  • 需求文档入库管理
  • 建立里程碑基线

RRC 的版本管理功能可以帮助将文档入库管理,并可建立基线。RRC 的基线提供审核功能,通过电子签名来确保基线的有效审核。RRC 的基线功能提供两个纬度的管理:模块基线和项目快照,可确保项目成果的一致性。RRC 中的需求基线与快照的组合能够建立起整个项目的多层次的需求结构。

图 22. 两条需求集合基线之间的差异
两条需求集合基线之间的差异

同时,每一条需求工件,无论是需求条目、文件还是集合、模块,都会保存完整的历史修改记录,便于查证。可以按日期查看所有修改记录,可以查看具体修改内容,鼠标悬停可以查看内容预览。点击某一条记录,可以在界面右上角选择恢复记录,实现记录的回滚。

图 23. 需求修改历史记录
需求修改历史记录

需求模板与属性配置

IBM 的需求管理平台内置了业界通用的需求模板,可以有效的指导企业进行需求管理活动,点击 RRC 界面右上方齿轮形状图标,选择管理项目属性,在模板选项卡中可以查看项目模板、工件模板,涵盖了传统需求模板、敏捷开发需求模板等。用户可以新建、上载模板,也可以从现有项目导入模板,便于实现需求管理的持续提升和传承。

图 24. 需求项目模板
需求项目模板

图 24 大图

图 25. 需求工件模板
需求工件模板

图 25 大图

选择工件类型、工件属性、属性数据类型等选项卡,可以查看和编辑工件类型、工件包含的属性以及属性的数据类型等信息,界面友好,操作灵活。便于根据企业需要定制适合自身的需求管理模型。

图 26. 需求工件类型定制
需求工件类型定制

图 26 大图

图 27. 需求工件属性及数据类型定制
需求工件属性及数据类型定制

总结

需求的能力,直接关系到后续活动直至最终产出物的质量。在笔者看来,需求工程活动,如果不是第一重要的研发过程活动,也应该是第二件需要重视和提升的能力。Rational Requirements Composer 提供了企业级的需求工程平台,在国际和国内众多客户得到越来越多的应用,希望读者通过本文能够对其有简单的了解,并开启需求工程乃至整个软件工程的奇幻之旅。

参考资料

学习

获得产品和技术

  • IBM Rational Requirements ComposerRRC)是一个基于 Jazz 平台技术的实时协作式需求分析和管理环境,可以帮助跨地域分布的开发团队简化协作需求分析过程,并使其软件需求管理过程实现自动化管理。

    免费下载:

  • 获取免费的 Rational 软件工具包系列,了解最新的 IBM Rational 软件开发工具技术文档和资源。
  • 下载更多免费的 IBM Rational 试用版软件,了解 IBM Rational 软件的最新特性。
  • 获取更多 IBM 试用版软件,并熟练掌握来自 DB2®、Lotus®、Tivoli®,以及 WebSphere® 的开发工具和中间件产品,用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。

讨论

  • 加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
  • 访问 developerWorks 社区上的 Jazz 技术小组,这里汇集了丰富的 Jazz 平台中文技术资源。 您可以通过这里了解更多关于 Jazz 平台和 Jazz 技术发展趋势的最新信息。
  • 访问 developerWorks 社区上的 敏捷开发小组,在那里您将有机会与更多的开发人员一起交流敏捷开发最佳实践。
  • 加入 IBM 软件下载与技术交流群组,参与在线交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=853730
ArticleTitle=Rational Requirements Composer 助力生命周期需求工程活动
publish-date=12312012