内容


在 Rational Requirements Composer 中使用涉众协作策略,第 3 部分

链接策略

系列内容:

此内容是该系列 # 部分中的第 # 部分: 在 Rational Requirements Composer 中使用涉众协作策略,第 3 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:在 Rational Requirements Composer 中使用涉众协作策略,第 3 部分

敬请期待该系列的后续内容。

本文考虑了创建内容,选择工件,在背景中创建需求和链接的方法。

选择工件

所谓的工件,就是一件为实际应用中的软件开发而创建的。尽管一些工件有可能是最终的,但是可交付的工作产品,许多的工件都是在一个项目期间临时生成和使用的。图 1 显示了 IBM® Rational® Requirements Composer 所包含的工件类型。

图 1. Rational Requirements Composer 中所包含的工件类型
概述图
概述图

工件交流并确认对所解决问题的理解。它们还交流并确认了交付的方案。人们期望业务涉众参与到交流问题和方案之中。人们还希望项目团队成员,以一种涉众容易理解的方式,来描述问题和方案。在工件所包含的规划之中,考虑受众这一点是很重要的。包含的工件取决于以下的因素:

  • 用作考虑和交流需求的目的(例如,敏捷开发过程,工作环境,用户事例,用例,场景,业务进程图,词汇表)
  • 规划可视化的层次(例如事例板)
  • 项目类型(维护,新开发等等)
  • 背景和链接,或者工件相互之间是如何联系的
  • 系统界面(它是否包含有一个 UI,报告等等)

表 1 描述了其他类型的工件。

表 1. 可能的工件
工件类型描述,建议,考虑。
词汇术语对使用词的描述。目的就在于确保团队和项目之间的使用一致。
词汇相关词汇术语系列。
文本文件格式化功能的文本页面与其他的需求元素之间,可能是独立的也可能是相互联系的。范例包含了视频文件,业务用例文件;用例描述,描述性文本;包含一个或者多个其他需求工件的报告。
Microsoft® Word® 文件一般来说,这对于导入已存在的文件来说是十分有用的。需求可以得到标记和添加。
外部性工件进入项目的任意工件都可以澄清需求。一般来说,许多的工件都会导入,包含描述方案高层次的视图,来自工作区会话和扩展表的图片(例如: Microsoft® PowerPoint®、Microsoft® Excel®、iRise 模拟、RAVENFLOW、MP3、MP4,以及 AVI 格式记录的演示资料等等)。如果用户有工具在他们的电脑上打开工件,那么他就可以查看文件了。
业务进程图基于 BPMN 的进程图清晰地展示了方案的业务背景。考虑一下在活动图中使用一个业务进程图,来可视化地描述一个更加复杂的用例。考虑一下使用简单或者复杂的业务进程图。
UI 概述用户界面概述以及目的方案的方式。
图片图片用于反映已存在的用户界面以及界面的一部分,然后您可以对其进行注释以显示更改。
事例板使用方案的外观,来表现预定方案的基于概述的用户界面。
用户界面可以作为高忠诚度或者低忠诚度的概述来完成。考虑一下基于您从事例板中所选中的反应类型而进行选择。
界面流程在用户界面之间导航的路径选项的映射。
这可以帮助与用户界面背景和事例板背景有关系的涉众。对于决定流程是否能够发挥作用,这一点也十分有用。
用例图通过向即将使用系统的人员提供一个系统背景的行为性视图,来取得一个特定有价值的结果(用例)。
用例描述用例流程的细节信息,包括简单介绍,步骤,选择的流程。场景在这里可以得到记录。您还可以选择,复杂的流程使用业务进程图来进行描述。

在工件内创建需求

关键在于考虑,为什么需求是在 Rational Requirements Composer 中创建的。对于大多数的部分,标记需求使用属性组(业务优先级,起源等等)提供了追踪范围,然后查询信息的一种方法。它还提供了一种重要的输入方式,来规划,测试,开发所有到来的开发活动。标记的需求为 IBM® Rational® C/ALM 集成提供了一种重要的联系方式,这里需求就与 IBM® Rational® Quality Manager 中的测试用例联系了起来。

刚开始时,输入需求可能不是关注点。团队可能想要等待,直到在启动该活动之前有一定的稳定性为止。在需要规划,设计或者测试系统的一部分的一部分,可以追踪的需求列表就变得关键起来。

需求可以在文本性或者可视性的模型中创建(或者“标记”)。在涉众协作性策略之中,需求可以基于所创建的地方来赋予主要的工件类型(例如,视图文件中的特性类型,或者业务进程之中的任务类型 )。

表 2. 工件
工件名工件类型默认的需求类型评论
需求演示外部性的工件:演示描述初始性需求的业务演示。
视频多信息文本特性解决所交付问题与方案的多信息文本。
补充性的规格多信息文本补充性的结构性与非功能性的需求。
业务内容图外部性工件:
JPG 文件
在 Rational Software Modeler 中勾画与导入。
用例图用例图合成来自用户与第三方系统视角范围的图。
用例文件多信息文本用例使用公司标准用例模板描述一个用例的文件。
场景多信息文本指定演示用例的特定范例。
业务进程图业务进程图产生特定业务目标的相关,结构化活动或者任务的集合体。它提供了高层次的业务背景,帮助理解方案需求是否满足业务进程背景之下的目的。
事例板事例板对应于一个业务进程特定的场景。它帮助用户查看背景之中的业务进程。
UI 概述UI 概述对应于来自业务进程图和用例需求的概述。使用它来理解需求,而不是作为设计的规格。
报告实体模型多信息文本末端用户报告的实体模型。
界面流程界面流程来自用例的流程。

工件模板

模板提供了再使用标准标题,格式以及数据的功能。存在的工件模板,对标准的模板提供了一种稳定的方法与格式。模板可以与工件联系起来。例如,可以为用例描述创建一个模板。创建并建立模板,是项目管理员工作的一部分,尽管在需要的时候不用转换格式就能完成。在可以用作模板的整体工件的实例之中,工件可以标示为再使用的模板。

表格显示了一些可能的公司模板,以及为该项目所选择的模板。

表 3. 可得到的模板
可用的模板使用评论
视频使用的注释
用例事例X
用例
UI 概述X

工件连接策略

在需求定义与管理之中涉及到了两种类型的连接:背景连接与追踪性连接。背景连接 反映了工件以某种形式联系起来(以一种思维导图的形式联系起来)。而 追踪性连接 则显示了需求之间的附属映射。这种连接可以发生在一个高层次的需求与一个更加具体的需求,甚至一个业务规则与任意的需求之间。如果有什么部分发生了变动,那么它潜在意义上会影响到其他的部分。在编写时,Rational Requirements Composer 最初时用于背景连接,这就是为什么它是本文关注点的原因。背景连接可以是内部性的,也可以是外部性的;外部性的连接使用的是 URLs。

提示:
一种联系的标准项目方法,通常有助于理解,并帮助您找到工件与需求。

连接策略可以显示出这些工件与工件元素之间的关键工件类型与典型的背景连接。工件 连接策略提供了一种框架来帮助进行背景性的理解,以及提取信息到通用报告之中。它有助于定位需求信息。Rational Requirements Composer 被设计成让一个团队的成员一起工作。使用标准的方式来指定,阅读和导航,有助于有效的协作。

但是,您要意识到涉及到的业务涉众,可能想要更加自由地添加工件。如果这成为事实,那么通过提供一个简单的结构,例如一个根据系统功能性区域来命名的新文件夹,您就可以服务他们了。使用标签与筛选规则,可以提供一种非规范的方式,来组织和帮助人们找到适当的资源。

您还可以选择,可能的连接策略允许人们来将任意的工件与其他的工件或者元素联系起来。通过提供有用的背景,这也有助于理解。劣势在于理解和搜索信息变得更加困难。找到一些方法来进行报告是不实际的。这是因为一个不稳定的方法,使得提取信息变得更加困难。

决定最终决定于受众。底线是所有的协会都能使用格式。涉及业务和 IT 代表来决定方法也是可行的。

图 2. 默认的 Rational Requirements Composer 联系
可用工件联系的域模型
可用工件联系的域模型

Rational Requirements Composer 包含了一系列的默认背景联系。它们显示在上面的图表之中。联系都是强制性的。但是,用户界面使得添加和切换这些联系变得十分简便。请自由查看建议的联系 - 团队需要采用一种联系的策略,该策略会适应它自己的项目,进程和人员。

图 3 中的图显示了联系策略的范例,该范例与共享的视图,用例开发和事例板操作一起联合使用。

注意:
Glossary 项目可以与任意的工件联系起来。它在图表中并没有显示出来,以确保可读性。

图 3. 与用例开发,共享视频与事例板实践之间联系的范例
工件联系:视频,用例与事例板
工件联系:视频,用例与事例板

事例板可以用于演示一个业务进程或者用例。业务进程事例板最初可以用于理解高层次的功能。映射用例的事例板用于与用例具体内容相关的具体实现情景。就算在这种情况下,有些人还是对事例板采取了一种双重的方法:一些用于理解并就系统的意图达成一致,另一些用于规范地指定 UI 设计。

最终,不是所有的场景都需要事例板可视化。您需要判断哪些建模的场景,有助于分析,理解和确认系统的需求,以及哪些场景只是简单地重复已存在的功能。当然,不是所有的需求都可以进行可视化地演示。

作为对事例板的一个替换方案,您还可以使用一个节目流程,来总结 UI 概述之间的流程。与事例板相比,它有着更加简洁的优势。但是,这就偏离了基于场景的方法,该方法对于更多的业务涉众来说更加容易,以得到完整的理解。

一般来说,只是在一些更加复杂的用例情况下,才需要一个用例流程图,此时用例流程工件是使用业务进程图来建模的。与之同时,有一些公司更喜欢使用一种注释的流程图,而不是用例文本。此时,就会再次需要进程决策来决定总体的布局。

需求可以与视图,补充性的规格以及用例连接起来,这样它们就可以提供这些工件之间的附加性背景,图 4 中的图表没有清晰地显示工件。

图 4. 规则化敏捷软件开发连接的范例
视频连接
视频连接

该图显示了规则化敏捷开发的范例连接形式。注意事例板可以用于演示用例或者话题的实现方法。与之类似,一个业务进程图或者业务用例可以出现在该范例上,以演示一个话题。当然,在一个敏捷方法中,只有添加值的规格和联系才会得到使用。其他的联系可以存在于视图以及各种元素之间。用户事例可以作为需求演示,稍后它将会用作在 Rational Team Concert 中创建规划项目,然后实现产品的备份。


在有些阶段,团队还想要存储工作方案的演示视频,并将它们与用户事例联系起来。

需求嵌入与联系

需求的类型可以通过它的属性组来理解,这指示了它的层次(高层次,具体的等等)。但是,当前将需求与需求联系起来,以查询它们的追踪性。

正如上面讨论的那样,需求可以在不同的可视化与文本元素及工件之中得到标记(创建和嵌入)。在一个文件之中,文本可以得到强调,并用于创建需求。文本文件成为新需求的联系。

注意:
当需求得到更改和保存时,嵌入需求内容会在文件中得到更改。

该需求可以嵌入到许多的文件之中。将这些相同的需求与任意数量的可视化和文本的工件联系起来,也是可能的。这些联系有助于理解需求。

场景性建模可以使用嵌入式的需求。例如,可以为每一个流程创建需求,然后它们可以嵌入到场景与用例中。

将不同项目联系起来,以及在不同的项目之间再使用元素也是可能的。对于可重复使用的构件,例如词汇项目和 UI 概述来说,这一点十分的有用。可以创建一个项目来简单地存储可重复使用的工件。
当可重复使用的元素得到修改时,再使用元素的所有项目也会接受该元素的更改版本。例如,当标签更改端口名时,重复使用该端口的所有 UI 概述都会随着新标签得到自动的更新。

对于企业层次-业务进程概述来说,这一点也十分的有用,概述可以由不同的项目来更改或者扩展。它提供了项目的一种企业视图以及它影响到什么。更常见的是,项目在开发时会独立地开发,而涉及到的人员就不会意识到他们正在付出双倍的努力。

总结

本文描述了选择工件,然后在工件内创建需求,并将它们联系起来,以创建信息网。接下来的一篇文章将会描述人员如何进行协作,从早期的收集信息,到评审,到软件开发生命周期的其他部分,例如测试阶段。

致谢

作者感谢 Rational 需求定义与管理协会的实践结构师 Robin Bater,以及需求定义与管理的市场管理提供管理员 Daniel Moul,对本文所做的技术性评审与支持工作。


相关主题

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=605671
ArticleTitle=在 Rational Requirements Composer 中使用涉众协作策略,第 3 部分: 链接策略
publish-date=12072010