定义要开发的产品的涉众视图,根据涉众的关键需要和特性指定。由于包含预想的核心需求的概括,它为更详细的技术需求提供了约定根据。 
角色: 系统分析人员 
可选/发生: 在先启阶段早期创建。在生命周期的早期发展演变。
模板和报告:
     
示例:
     
UML 表示: 不适用。
更多信息:  
活动的输入:   活动的输出:  

用途 到页首

远景 为更详细的技术需求提供高级(有时是约定性的)根据。它以高级需求的形式获取预想的解决方案的“本质”,并设计约束来让读者从行为需求的角度大致了解要开发的系统。它提供对项目批准流程的输入,因此与业务用例紧密相关。它传达项目的基本“原理和内容”,并且是要验证的所有未来决策的评估尺度。

该工件所用的另一个名称是“产品需求文档”。 

计时 到页首

远景 在先启阶段早期创建。在生命周期的较早阶段稳步发展,并在构造阶段缓慢变更。它与业务用例和风险列表的早期草稿一起发展,并将根据对需求、体系结构、计划和技术发展的了解进行修订。
(请参阅:工件:业务用例工件:风险列表)。

远景 充当对用例建模的输入,并在整个项目范围内作为单独的工件进行更新和维护。

职责 到页首

系统分析人员 负责“远景”的完整性,确保:

  • 工件已创建,然后按需要进行更新和分发。
  • 所有相关涉众的输入均得到处理。

初始 远景 的作者可以是任何人,但如果在先启阶段建立了项目,该工件就变为由 系统分析人员 负责。

远景 通常由风险承担者(例如:筹资机构成员、管理员、用例建模中涉及的角色、测试人员和开发小组)读取。

定制 到页首

针对项目的需要进行必要的定制。为了将“远景”尽快发布给涉众并使涉众易于查阅和理解,保持“远景”简短通常是一种很好的做法。通过只包含最重要的涉众请求和特性并避免详细需求,就可实现这一点。可在其它需求工件或附录中获取详细信息。

根据所开发的 远景 的用例和主要场景进行表达是很重要的,这样您就可以知道如何通过用例实现远景。用例还提供制订测试用例套件的有效根据。

决定在此处还是在需求管理计划中记录功能属性。确定要在“远景”中包括的信息(属性)和要使用需求管理工具管理的对象。



Rational Unified Process   2003.06.15