使用 IBM Rational Requirements Composer 中的故事板

文档选项 未显示需要 JavaScript 的文档选项 英文原文

级别： 中级

Tina Zhou, 高级产品经理, IBM

2009 年 5 月 12 日

故事板就是在一个特定情景对系统功能进行逻辑上和概念上的描述，包括系统用户与系统之间的所需的交互作用。

在 IBM® Rational® Requirements Composer 中，一个故事板就代表对一个使用场景逐框架变化的描述，其中每一框架都包含对引导下一框架行为的描述。它包括对线性事件的彻底预排，并在带有样本数据源的时间轴上描绘了图形框架。大体看来，一个故事板就是一系列详细说明用户经验的框架。它包括一个框架列表，时间轴视图，以及框架。框架实质上就是故事板中的示意图实例。

故事板软件

IBM® Rational® Requirements Composer 能够让你在开始开发之前对你的软件系统进行脚本分框架。要理解这个概念，请思考下面的问题。

“镜头的图片……”

你会多长时间使用这个词组来开始一个名声和财富，喜剧，或者悲剧的故事？你接下来会对你的故事进行什么样的相关描述。在软件开发过程中，你同样也有一个故事要讲述。无论你是构建还是修改软件系统，都是在方法还没确定或者还没完全理解的情况下进行的。

“事实上我根本无法描绘这个场景的图像……”

然而，很多时候你在脑子里根本就没有对这个故事有清晰的概念。你不完全理解这个故事，故事发生前的背景以及接下来会发生什么。即使你完全理解你将要阐述的问题，但是没有任何其它人会在脑袋里有清晰的画面。故事板脚本一个你可以利用它理解和向你周围的人解释的工具：将你脑袋里的概念转换成人们容易理解的实体。

故事板脚本并不是一种新技术。软件开发人员最近将这个概念和技术从电影行业借过来，因为故事板头在电影中的应用是众所周知的例子。从一个软件开发人员的角度来看，就是把故事板脚本定义为“……在特定情景中对系统功能逻辑和概念的描述，包括系统用户和系统之间所需的交互作用。一个脚本会‘显示讲述一个特定的故事’” 【IBM® Rational Unified Process® （RUP®）, 2008】

这个定义包含了把故事板脚本的使用看作一种获取解决方案表现方式的方法，尽管你已经解决了这个问题。故事板脚本同时还是一种探究系统上下文，探索系统原本要解决问题可能选项的方法。建立故事板脚本的任务称 故事板。“故事板是一种获取特定情景中系统功能逻辑和概念描述的技术”。【RUP， 2008】

故事板脚本主要显示了以系统为某个特定目的而操作的方式对用户界面描绘的过程。通常，一个故事板脚本就是由一系列框架所构成的，每一框架都对下一个框架的行为进行描述，然而，你并不会尝试设计一个用户界面：你将会描绘这个用户的经验。一个电影故事板就是获取情景，摄像视角，以及人物流，而软件故事板则是获取特定上下文中主要的软件意图。

回页首

故事板的好处

故事板可以帮助你降低项目风险，以及节省时间和资本。

消费者通常并不清晰他们真正想要什么。你经常会听到他们说这样的话，“当我看到它时候我就会明白。”故事板可以帮助你解决开发过程早期中不确定的请求。你可以利用这些请求定义中的不确定因素来确定故事板将在什么时候有用，以及通过肉眼观察带有故事板的请求与系统的行为形成一致。

故事板可以帮助你引出，澄清，完成，以及确认请求。故事板可以促进股东利益者的参与，以及允许你在没有编码的情况下探索可供选择的技术解决方案。你可以利用交互式请求和用例的故事板来回顾与股东利益者的会议。这些会议可以帮助你找到丢失的部分，错误之处，不需要的部分，以及所期望的结果。.

故事板还可以通过设计者，开发人员，测试人员，构架师，以及 UI Designers 来进行衡量。

回页首

故事板中包含了什么

这个部分描述了创建故事板过程中所包含的各种组件。

人物

人物就是描述一个虚拟的系统使用者。他代表一个基于真实用户的典型使用者。目的是通过开发带有名称，个性，行为等特征的人使这些用户成为鲜活的人物。你要为这个系统创建几个具有代表性的人物。一个人物就是一个角色实例，并且他能够与多个故事板联系起来。

描述人物的目的是：

• 确保你开发了你的用户群的所有需求
• 扮演一个用户的替身，有助于指导你对功能和设计的决定
• 使你的故事板集中于一个非常具体的用户背景和用户目的

表格 1中所示的一个人物实例。

使用场景

使用场景描述了一个人物是怎样与系统进行交互式作用，从而执行一个特定任务的。 它还受到用户需求以及完成任务动机的驱使。在你开始创建使用场景之前，它可以是一个人物 在故事板中行为的概述。如果你确实执行了用例驱动式开发，那么使用场景就是一个典型的完整 用例情景的实例，或者用例情景的一部分。

故事板

故事板就是特定情景中对系统逻辑和概念上的描述，包括系统用户与系统之间交互作用的需求。

在 Rational Requirements Composer 中，一个故事板就代表对一个使用场景逐框架变化的描述，其中每一框架都包含对引导下一框架行为的描述。它包括对线性事件的彻底预排，并在带有样本数据源的时间轴上描绘了图形框架。大体看来，一个故事板就是一系列详细说明用户经验的框架。它包括一个框架列表，时间轴视图，以及框架，如图 1所示。框架事实上就是故事板中示意图的实例。

回页首

查询并澄清带有故事板的需求

可以在 Inception 阶段的早期使用故事板技术，从而确定股东利益者将要达到的目的（目标）。在开发过程的这个阶段，系统（无论它包含硬件还是软件）其实并不存在。另外，故事板还可以在开发后期进行，并且你可以利用它来澄清某物（用户）是如何与正在被开发的项目（用户界面）进行交互作用的。因此，故事板的目的在开发过程的不同阶段有着不同的目的。

在采用故事板技术之前，清晰地定义要解决的问题是十分必要的。一旦问题被确定，那么故事板的目的也就清楚了。目的应该明显地“划为“调查研究的区域，这样就可以为故事板提供一个明确的范围。在这个分区范围中，任何对于故事板的限制都应该被识别出来。

紧接在故事板完成之后，你应该验证已经被解决的故事板的目的。故事板中股东利益者对先进的故事板技术拥有所有权是非常必要的，事实上是赞同和确认故事板更改准确地表达他们的想法。要授予他们所有权，开发的故事板技术必需使用他们能够理解的术语。

调查研究的项目的最终状态应该记载备份，任何潜在的与故事板进一步相关的因素也应该被确定（可能是附属关系）。故事板过程中所做的一系列假设都应该收集起来（这个列表稍后可以被证明是正确的），另外还加上故事板过程中查询的任何限制条件。

你应该从故事板的结果中产生需求（包括对故事板中特定元素的跟踪）， 并与股东利益者进行商讨。接下来，将这些诶需求置于适当需求设置中，故事板 需求就是从这里开始进行融合的。创建故事板的一个典型模板，在下面部分中应该 包括具体的先决条件和后置条件。

回页首

先决条件

先决条件如下：

1. 确定这个问题
2. 确定故事板的目的
3. 确定故事板的类型
4. 确定开发生命周期
5. 确定使用的精确度
6. 确定股东利益者的角色
7. 确定限制条件

确定这个问题

完全理解要解决的问题是十分重要的。如果在 Inception 阶段使用了故事板，那么要处理的问题很可能就是确定股东利益者将要达到的目的是什么。这可以从最初的股东利益者需求开始着手分析。如果在开发生命周期中采用故事板技术，那么要处理的问题很可能包括开发过程中某个对象特性或者行为的确认。 下面这些是问题状态的例子：

• Inception 阶段： 零售顾问需求的陈述，比如 我想在家里购买零售商店的东西。
• Elaboration 阶段： 执行中心需求，比如 怎样证明音乐爱好者将会喜欢他所购买的音乐呢？

确定故事板的目的

所开发的故事板技术应该着重被鉴定的问题；然而，正被解决的问题可能需要考虑股东利益者的观点。因此，你可能要创建几个故事板来彻底处理在被调查研究中的问题。股东利益者和分析师必须理解故事板的范围。这可以通过清晰地陈述特定故事板的目的来完美实现。下面是目的定义的两个例子：

• Inception 阶段： 要确定一个古典音乐爱好者如何能够在家里购买到零售商店中他想要的音乐
• Elaboration 阶段： 要确定网上市场 GUI 中 的位置，外观，以及 Sample 播放 功能

确定故事板的类型

故事板基本上有两种类型： 需求查询 故事板或者 需求澄清 故事板。这两种类型包含了故事板过程所需的所有情形（例如，需求查询，用例开发，用户界面，需求澄清，以及原型）。下面是故事板类型的两个例子：

• Inception p阶段： 性能需求查询
• Elaboration 阶段： 原型需求澄清

确定开发生命周期阶段

很显然，你使用的故事板类型与开发生命周期两者是有着紧密联系的。在 Inception 阶段中，很可能是正在查询需求。在 Elaboration 阶段，可能是对需求的进一步理解和澄清。

确定使用的精确度

当计划使用故事板技术时，你应该确定精确度（也就是说，故事板必须反映的调查研究中主题的准确度）。在 Inception 阶段你很可能使用低精确度的故事板技术，因为你不可能知道最终的产品将是什么。

在 Elaboration 阶段，你将最终产品以及产品的外观概貌有相当的了解。因此，使用高精确度来准确反映它的外观和需求澄清是非常重要的。

确定股东利益者的角色

你应该确定股东利益者的角色，在故事板过程中你将向他提出问题，尤其是当有多个故事板的时候。下面是不同阶段合适角色的两个例子

• Inception 阶段： 零售购买者
• Elaboration 阶段： 音乐爱好者

确定限制条件

在故事板开始之前，确定对故事板的所有限制条件是非常必要的。这样可以确保在人任何限制环境下开发可以继续进行（比如法定限制或者范围标准）。下面是限制条件的两个例子：

• Inception 阶段： 一个订购和购买过程都必须可检查的查账索引
• Elaboration 阶段： GUI 应该符合标准的 Microsoft® Windows® 惯例

后置条件

故事板完成之后，确认开发故事板的有效性和确定任何要继续的工作是非常有必要的：

1. 确认最初的问题已经解决
2. 确认已经达到了故事板的目的
3. 使故事板获得股东利益者的赞同
4. 确定进一步故事板的主题
5. 确定相关的故事板
6. 确定假设已经完成
7. 确定新的限制条件
8. 确定故事板中的需求源

确认最初的问题已经解决

故事板已经完全解决了最初确定的问题了吗？答案是 Yes， Partially 或者 No。

确认故事板的目的已经达到了

管理故事板的目的达到了吗？答案应该是 Yes 或者 No question。

使故事板获得股东利益者的赞同

故事板所涉及的股东利益者对故事板获得了所有权吗？这个问题的答案可能是 Yes， Under Review 或者 No。

确定进一步故事板的主题

在故事板的开发过程这种，其它的故事板主题已经确定了吗？那些主题是什么，会涉及哪些股东利益者，以及将会涉及什么样的股东利益者角色？下面是在不同阶段主题确定的两个例子：

• Inception 阶段： 零售商人是如何跟踪货物的
• Elaboration 阶段： 音乐专辑的位置，外观，以及播放

确定相关的故事板

确定其它计划中的或者开发中的故事板的位置。这在一系列的行为中是很独特的，每一个都可以通过故事板进行彻底查询。

确定所做的假设

确定任何在故事板开发过程中所做的假设。这些假设将需要进一步的行为来证实它们是否正确。在假设的例子中，解决方案只在 UK 法定管辖权中有效。

确定新的限制条件

确定在故事板开发过程中所发现的任何限制条件，而不是已经在先决条件中存在的

确定故事板中的需求源

对于故事板中的任何需求，要确定它们的源。

回页首

如果利用 Rational Requirements Composer 创建低精确度的故事板

这个部分描述了你如果利用 Rational Requirements Composer 创建低精确度的故事板。UI 示意图主要利用低精确度故事板作为一种帮助澄清和支持需求的方法。这并不意味着它们代表实际的 GUI 设计。Rational Requirements Composer 有强大的故事板性能，可以让你（作为已经分析师）快速创建故事板并将它们链接大其它需求构件中。

在这个例子中，故事板就是为在线 CD 购物引用而开发的。与用例不同的是，它作为演员描述了这个系统的完整使用，故事板着重于执行单个不相关联行为的人物的一个非常具体的故事上。在这个故事板例子中，你的人物， Gordon MacIntyre，搜寻并购买一张 Beethoven CD。

按照下面的步骤来创建你的故事板。

确定你的人物并组织你的故事板

1. 确定你的人物，如果你已经使用了。

人物在使你的故事板集中在一个非常具体的用户背景和用户目标上非常有用。记住故事板就是要补充你的用例，而不是它们的替代者！相反，一个故事板可以是一个用例流实例化的思想：他们在你所确定的人物背景中阐述这个流。故事板是一个功能非常强大的技术，可以帮助你描述已经用图形很好表达的信息（比如可用性，用户经验，用户界面标准，以及其它需求）。

如果你不使用用例来记载功能需求，那么故事板对于确定用户背景和用户情景将会更加重要。

Rational Requirements Composer 支持富有文本文献的创建和编辑。这个例子利用一个本地富有文本文献来记载我们的人物：

2. 组织完备！ 如果你计划进行大量的故事板，这将会对你非常重要。充分利用 Rational Requirements Composer 中利用的故事板来对常用构件进行管理和分组，如图 2所示。

由于人物，局部，以及梗概可以在多个故事板中使用，所以最好将这些储存在一个中心位置，与故事板本身隔离开来。例如，有一个角色文件夹，一个故事梗概文件夹，一个人物文件夹，以及一套为相关故事板分组的文件夹。有意义的名字和标题也会对你的有条不紊的组织有所帮助。

3. 创建你的框架列表。 列表中的每一框架都有一个标题和描述，如图 4所示。一个适当的描述可以帮助你充实使用场景。至少，也要记下每框架的标题，为复杂的或者尚未清晰的框架提供额外描述的几句台词或者点句。在你开发单个的框架之前，请花足够的时间来定义和精炼这个框架列表：最好是在添加图片之前直接将故事置于计划文本中。
   

这儿框架列表就是故事板的概要（与用例步骤类似），可以帮助你形象化一个面貌，一个特俗的用例情景，或者部分情景。记住故事板没有分支或者循环逻辑。相反，它们是穿过目标系统特定执行的直线路径。以框架列表开始可以使故事板有组织，而且还可以帮助你钻研每一框架或者示意图细节之前确定一步步的纲要。

4. 在这个阶段，列表中的每个项目都有一个与它相关联的空白框架。你可以直接在故事板中 开始描绘单个框架 。另一种方法是在多个框架和多个故事板中 开始创建一组可以重新使用的示意图和局部。

在 Rational Requirements Composer 中，一个用户界面示意图就是在这个应用软件操作的任何一点的软件产品的图形化用户界面模型。 [Rational Requirements Composer Version 1.0， Help]

在 Rational Requirements Composer 中，一个用户界面示意图部分就是一套可重新利用的用户界面元素。你可以利用一个局部来填充示意图，屏幕流，以及故事板。局部可以包括一个单个元素，比如菜单，或者它可以包含许多聚集在一个储存元素中元素，比如一个面板或者组。可以在多个用户界面示意图，屏幕流，以及故事板框架中重复使用这些局部来持续的用具界面元素。 [Rational Requirements Composer V1.0, Help]

局部，示意图，以及框架

图 5展示了一个局部与示意图之间关系的图示。一个局部可以被从零到多个示意图来使用，而一个示意图可以包含零到多个局部。

图 6 显示了一个示意图和一个框架之间的关系的图示。一个示意图用于从零到多个框架的创建，从零到一个示意图都可以来创建一个框架。

局部可以在任何时候从框架或者示意图中提取：即使在故事板已经构成之后。因此使你的局部和示意图保持组织完好是十分重要的。最大的优势是重新利用和变更管理：修改单个局部并使所有使用这个局部的示意图和框架都自动更新，比在大量潜在故事板框架中重新绘制这些 UI 元素要简单得多。

在这个例子中，有一些常用工具条菜单，页面标题，购物车，以及 CD 光盘的局部，如图 7所示。

浏览故事板的实例

你将浏览的这个故事板实例拥有16个框架，但是构建了五个示意图。

查阅 Rational Requirements Composer Help 获取详细的指令：

• 任务： 创建一个用户界面示意图局部
• 任务： 创建一个用户界面示意图

5. 开始填充你的框架。 框架内容可以来自三个位置中的一个：
   1. UI 元素可以直接绘制成框架。
   2. 一个框架可以从一个示意图中继承内容。继承意味着这个框架是基于一个现存的示意图的，如果那个示意图变化，那么这个框架也将自动被更新。
   3. 框架可以从先前的或者早期框架继承内容。这样就会在你的故事板中创建一个附属关系链，它将有助于鉴定常见框架。

开始构建框架：欢迎和搜索

Frame 1： 这个 Welcome 页面其实就是直接绘制成故事板的框架，如图 8所示。要创建一个基于示意图的独立框架，可以双击这个框架列表底部的任何框架，它将在这个编辑器中打开。记住这是一个框架编辑器，因此你所做的一切都是这个故事板的一部分，并且在其它故事板中是不能重新利用的。

Frame 2： 这个框架是从一个示意图继承内容的框架实例。这时在你的故事板中， Gordon （我们的人物）已经导航到 CD 清单页面。框架 2显示了这个 CD 清单屏幕的最初视图，而且是从这个 CD 目录示意图中构建而来的。要创建这个框架，可以按照下面的操作进行：

6. 在这个空白框架中选择 从一个现存的示意图创建 选项，如图 9所示。

7. 在这个清单中找到你的示意图并点击 OK。这个框架现在已经填充了这个示意图的实例，可以在不影响最初示意图的情况下对它进行编辑

8. 编辑这个框架来添加所需的额外信息和数据 ，从而促进故事的讲述。在这个例子中，有些数据添加到了购物车区域，如图 10所示。在这个最初的示意图中，这个区域已经被标记但是没有填充，因此它可以在任何故事板框架中适当地进行重新使用。

Frame 3： 在框架 3中， Gordon 已经输入 Beethoven 作为搜索条件。因为这仍然是同一个屏幕，你可以不以它的前身作为基础，而仅仅需要编辑这个数据来描述这个故事的步骤：

9. 在这个空白框架中选择 从先前的框架创建 选项。注意因为它是从框架 2创建的 （不是 从最初的示意图），因此它有一半性能是框架 2所专用的（也就是，这个填充的购物车）。

10. 编辑这个框架来阐述 Gordon 所进行的搜索： 输入 Beethoven 到快速搜索文本，并添加一个描述性的插图编号。

Frames 4 和 5： 在框架 4 和 5中，系统会返回搜索结果，Gordon 就会得到一个可查看的 CD。在这两个框架中，你可以继续构建开始于框架 2的附属关系链 （选择 从先前的框架中创建）。只需要编辑框架 4来显示搜索结果，框架 5则表示 Gordon 正获取可查看的 CD，如图 12和13所示。

更多的框架： 产品详情和购物车

Frames 6 和 7： 这是在故事中，你正显示一个具体 CD 的详细情况。框架 6是建立在一个不同的叫做 CD Details 示意图的。尽管这个示意图不用，但是你应该注意到这个工具条菜单看起来极其相似，如图 14所示。这是因为它是一个在两个示意图可以共享的可重新利用部分。

框架 7 显示了 Gordon 正将这张 CD 添加到他的购物车，如图 15所示，是基于框架 6的。

注意这样就在框架 6和7之间创建了一个新的附属关系链，如图 16所示。

Frame 8： 这个框架是建立在框架 5基础上的，因此可以继续与显示在购物车中的 CD 产生附属关系。

11. 选择 从先前的框架中创建。

12. 从这个 Select a Frame 对话框中，选择你想从中继承它的内容的框架，如图 17所示。

13. 在框架 8中，系统返回了目录搜索结果，并且 Gordon 通过付账决定完成这次购买，如图 18所示。

最后的框架： 检验并付账

Frames 9 – 12： 这时，为检验程序会出现一个新的对话框。框架 9-12 显示 Gordon 输入他的个人信息，运送方式，以及联系方式，都是建立在常用示意图基础上的，如图 19所示。

框架 9 是复选框的开始，如图 20所示。

图 21 显示了框架 9，10，11，12之间的附属关系链。

Frames 13 和 14： 这些框架代表一个附加的对话框，Gordon 在这个对话框中输入了他的信用卡信息，如图 22所示。

图 23 显示了完整的信用卡信息

Frame 15： 这是一个独立的框架，它显示了预定确认，如图 24所示。

Frame 16: 故事的结尾

回页首

准备好故事板

故事板的根本目的就是带某人查看实施一个活动的过程，并将视觉向可以创建这个视觉的开发人员表达出来。

故事板是需求确定中的一种技术，它用于查询和澄清需求。这个技术还可以用在开发生命周期的很多地方，它对系统开发的相关度与软件开发的相关度相差无几。

IBM Rational Requirements Composer 实际就是一个需求定义产品，它能够让你有效地权衡故事板技术，从而驱使更好的需求并交付质量更高的产品。

参考资料

• 访问 developerWorks 上的 Rational 专区，了解有关 Rational 软件交付平台产品的技术资源和最佳实践。
  
  
• 订阅 IBM developerWorks 时事通讯，获得有关最佳的 developerWorks 教程、文章、下载、社区活动、网络广播和事件的每周更新。
  
  
• 查看 Rational Edge 中文版，获得了解高效软件开发背后概念的文章。
  
  
• 浏览 技术书店，获得有关这些和其它技术主题的书籍。
  
  

• 下载 IBM Rational Requirements Composer 的试用版。
  
  
• 下载 IBM Rational 软件的试用版。
  
  

• 加入 developerWorks 社区 的讨论区，博客，播客，wiki，以及更多。
  
  
• 加入 developerWorks 上的 Rational Requirements Composer 讨论区。

关于作者

		Tina 是一名高级产品经理，并且是一名 Rational Expertise Development 和 Innovation (REDI) 团队的成员。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首