故事板是对特定场景的系统功能的逻辑和概念描述,包括系统用户与系统之间所需的交互。故事板“讲述具体的故事”。 
角色: 系统分析人员 
可选/发生: 可选。在精化阶段早期、引发需求期间生成。
模板和报告:
     
示例:
     
UML 表示: 不适用。
更多信息:  
活动的输入:   活动的输出:  

用途 到页首

以下人员使用故事板:

  • 系统分析人员,调查、阐明和捕获用户预想的行为交互,作为需求引发的一部分;
  • 用户界面设计人员,设计用户界面并构建用户界面的原型;
  • 设计人员,提供用户界面功能;他们使用这些信息了解系统与用户的交互,这样就可以正确设计那些将实现用户界面的类;
  • 设计下一版本系统的人员,了解系统如何执行事件流;
  • 测试人员,测试系统的功能特性;
  • 管理员,计划和贯彻分析与设计工作。

可为每个用例定义一个故事板,从而支持软件工程的用例带动方法,同时提供极佳的方式来验证用例事件流中这些用例及其角色的用户(参与者)期望。

故事板主要用于了解整体流程和交互,而不是对用户界面的外观建立原型或进行测试(这是用户界面原型的用途),记住这一点很重要。故事板不应包含用户界面组件和其它用户界面相关项(那些应由用户界面原型包含)。

属性 到页首

可使用可视表示法、文本表示法或两者结合来表示故事板。有关特定示例,请参阅指南:故事板

计时 到页首

故事板是在精化阶段早期的需求引发期间生成的。

一旦可从可用性的角度来考虑故事板描述的流程,就生成了故事板。它们可与其它需求工件同时或在它们之后生成

职责 到页首

系统分析人员 角色负责故事板的完整性,并确保:

  • 故事板是可读的,并符合其用途;
  • 故事板正确捕获系统的期望行为;
  • 相关可用性需求是可读的,并符合其用途,且正确捕获系统的可用性需求;

有关开发故事板的指导信息,请参阅指南:故事板

定制 到页首

确定故事板是否对项目有用。应定制故事板的内容以支持项目需要。这可以包括只开发一部分属性,并定制创建和管理这些属性的正式程度。

故事板通常被视为临时工件,而一旦了解了行为需求且项目适合快速对用户界面建立原型或实现用户界面,就可以不再维护故事板。但在某些情况下,在数次迭代中维护故事板是有价值的,例如,当用户界面上存在要花时间(通过几次迭代)去理解的复杂需求时。另外,故事板与实际用户界面结合起来就是对最终用户文档的有用输入。



Rational Unified Process   2003.06.15