工件:
|
![]() |
定义要开发的产品的涉众视图,根据涉众的关键需要和特性指定。由于包含预想的核心需求的概括,它为更详细的技术需求提供了约定根据。 |
---|---|
角色: | 系统分析人员 |
可选/发生: | 在先启阶段早期创建。在生命周期的早期发展演变。 |
模板和报告: |
|
示例: | |
UML 表示: | 不适用。 |
更多信息: |
活动的输入: | 活动的输出: |
远景 为更详细的技术需求提供高级(有时是约定性的)根据。它以高级需求的形式获取预想的解决方案的“本质”,并设计约束来让读者从行为需求的角度大致了解要开发的系统。它提供对项目批准流程的输入,因此与业务用例紧密相关。它传达项目的基本“原理和内容”,并且是要验证的所有未来决策的评估尺度。
该工件所用的另一个名称是“产品需求文档”。
远景 在先启阶段早期创建。在生命周期的较早阶段稳步发展,并在构造阶段缓慢变更。它与业务用例和风险列表的早期草稿一起发展,并将根据对需求、体系结构、计划和技术发展的了解进行修订。
(请参阅:工件:业务用例和工件:风险列表)。
远景 充当对用例建模的输入,并在整个项目范围内作为单独的工件进行更新和维护。
系统分析人员 负责“远景”的完整性,确保:
初始 远景 的作者可以是任何人,但如果在先启阶段建立了项目,该工件就变为由 系统分析人员 负责。
远景 通常由风险承担者(例如:筹资机构成员、管理员、用例建模中涉及的角色、测试人员和开发小组)读取。
针对项目的需要进行必要的定制。为了将“远景”尽快发布给涉众并使涉众易于查阅和理解,保持“远景”简短通常是一种很好的做法。通过只包含最重要的涉众请求和特性并避免详细需求,就可实现这一点。可在其它需求工件或附录中获取详细信息。
根据所开发的 远景 的用例和主要场景进行表达是很重要的,这样您就可以知道如何通过用例实现远景。用例还提供制订测试用例套件的有效根据。
决定在此处还是在需求管理计划中记录功能属性。确定要在“远景”中包括的信息(属性)和要使用需求管理工具管理的对象。
Rational Unified Process
|