前景文档模版
项目成功的基础是前景文档，它确认和组织最高层用户需求及应用程序的特性。这个文档将根据需要更新，并在团队成员及其他设计人员之间共享，以下的文档模版是一个起点。可根据不同机构的需要定制。
公司名
项目名
前景文档
©200X 公司名
修改记录 |
日期 | 修改 | 描述 | 作者 |
月/日/年 | 1.0 | 初始版本 | 作者名 |
| | | |
| | | |
| | | |
| | | |
1 介绍
这一部分应该提供整个前景文档的概述，包含以下几部分：
1.1 前景文档的目的
文档的目的是收集、分析、定义高层用户需求和产品特性，重点是目标用户所需要的性能以及为什么存在这些需求。有关系统如何满足这些需求的特定要求应该放在“用例规格说明”和“补充规格说明”中。
1.2 产品综述
■ 陈述应用系统的目的、版本以及应用。这一部分应该：
■ 确定要创建或增强的产品或应用系统。
■ 提供有关产品将做什么以及不做什么（如果需要的话）的一般性描述。
■ 描述产品的应用，包括与它相关的效益、目的、目标。
1.3 参考
这一部分应该：
■ 列出在前景文档中引用的其他文档的清单。
■ 标明每个文档的题目、报告号（如果有的话）、日期和出版机构。
■ 指定参考文献获取的来源。
■ 这个信息可通过引用附录或者其他文档来提供。
2 用户描述
为了有效地提供满足用户需要的产品和服务，理解完成这项工作时所要面对的挑战是很有必要的。这一部分应该剖析应用程序的用户和限制用户生产率的关键问题。这一部分不能用于陈述特定需求，而是说明为什么需要第5部分需求的背景和理由。
2.1 用户/市场统计
总结激发产品决策的主要市场统计。描述和定位目标市场。利用潜在用户数量或客户愿
意花在产品或其他增强方面的投资数量，来预测市场的大小和增长率。回顾主要的市场行业趋势和技术。回答以下战略问题：
■ 你的机构在这些市场中的地位如何？
■ 你希望它做什么？
■ 这个产品或服务如何支持你的目标？
2.2 用户剖析
描述系统中每个不同的用户。用户的类型从权威到新收集可能差距很大。例如，高手可能需要一个复杂，灵活的支持跨平台的工具，而一个新手可能需要一个易于使用、用户友好的工具。对每种用户的全面剖析应覆盖以下题目：
■ 技术背景和复杂程度。
■ 主要职责。
■ 用户为谁提交产品。
■ 使用户的工作更容易或更困难的趋势。
■ 阻碍成功的问题。
■ 目标用户对成功的定义以及用户如何等到回报。
2.3 用户环境
详细描述目标用户的工作环境。以下是一些建议：
■ 需要多少人来完成该任务？是否会有变化？
■ 任务的周期是多长？其中每项活动需要多少时间？是否会有变化？
■ 是否有一些独特的环境约束：移动的、室外的、飞机上的，等等？
■ 现在正在使用哪种系统平台？未来的平台是什么？
■ 正在使用其他什么应用系统？你的应用系统是否能与这些系统集成？
2.4 关键用户需求
列出用户认为的关键问题或需求。为每个问题澄清以下内容：
■ 这个问题的理由是什么？
■ 现在是怎么解决的？
■ 用户预期解决方案是什么？
重要的是理解用户所认为的解决每个问题的相对重要性。分级和累计式投票技术可以说明必须解决的问题以及用户想要解决的问题。
2.5 替代品和竞争
确定用户认为目前可得到的替代品，可包括购买竞争对手的产品、构建一个自己的解决方案或者维持现状。列出所有的已有的以及即将得到的竞争对手的产品，包括终端用户所理解的强项和弱项。
2.5.1 竞争对手1
2.5.2 竞争对手2
3 产品简介
这一部分对产品的能力、与其他应用系统的接口以及系统配置等等提供一个高层视图。通常由以下三个部分组成：
3.1 产品前景
这部分应该合理地把产品与其它相关产品及用户的环境放到一起。如果产品是独立的，并且完全配套，就在这里说明它。如果产品是一个大型系统的组件之一，那么这一部分应该说明系统之间如何交互，找出相关的接口。一种展示大型系统主要组件互连及外部接口的简单方法是利用框图。
3.2 产品定位陈述
提供一个整体陈述，从最高层面总结产品在市场上的独特定位。Moore（1991）称此为产品定位描述，并推荐以下格式：
for(为) | （目标客户） |
who（谁） | （陈述需要或机遇） |
the（产品名） | 是一个（产品分类） |
that（它） | （对主要好处的陈述，也是驱动购买的原因） |
unlike（不像） | （主要竞争替代品） |
our product（我们的产品） | （对主要区别的陈述） |
| |
产品定位陈述向所有人员说明了应用系统的意图，以及项目的重要性。
3.3 能力总结
总结产品将提供的主要利益和特性。例如，一个客户支持系统的前景文档可能会在这一部分进行问题建档、路线和状态报告——不提及各功能需求的细节。
组织特性，以便清单能够被客户或所有第一次阅读文档的人都呢理解。一个简单的表列出主要的优点及其所支持的特性。
客户支持系统
3.4 假定和依赖关系
列出所有一旦变更将影响整个前景的假定条件。例如，某个假定条件可能指出，指定用于软件产品的硬件可得到某个特定的操作系统。如果该操作系统得不到，则前景必须修改。
3.5 成本和定价
对于销售给外部客户的产品，以及许多机构内使用的应用系统，成本和定价将直接影响应用系统的定义和实现。在这一部分，把所有成本和相关的定价约束记录下来。例如，分销成本（CD-ROM,CD控制）或者其他货品销售成本（手册，打包）对于项目的成功可能无关，也可能有实质影响。
4 特性属性
特性也有属性，提供附加的项目信息，用于评估、跟踪、划分优先级、管理为实现提出的产品项。这一部分需要描述所选择的属性及其意思，使各方面都能更好地理解每个特性的情景。
4.1 状态
在项目管理团队协调和复审之后确定。状态信息在项目基线定义过程中跟踪进程。
■ 建议的（propod）：描述正在对该特性进行讨论，但还没有得到“正式渠道”的复审和
采纳，“正式渠道”可以是一个由项目团队、产品管理、用户或客户团体的代表组成的工作小组。
■ 批准的（approved）：他的能力被断定是有用的和可行的，得到正式渠道的认可加以实现。
■ 收编的（incorporated）：已经在某个特定时间收编入产品基线的特性。
4.2 优先级
产品优先级（优点）是由营销人员、产品经理或商业分析人员设置的。根据特性对最终用户的相对优先级把他们划分等级，这打开了一个与客户、分析人员、以及开发团队成员之间的对话。优先级用于管理范围和确定开发优先级。一种可能的优先级划分模式如下：
