列出用户认为的关键问题或需要。为每个问题澄清以下内容：
1）这个问题的原因是什么？
2）现在是怎么解决的？
3）用户预期的解决方案是什么？
重要的是理解用户对解决每个问题所放的相对重要性。分级和累积投票技术可以说明
必须解决的问题以及每个问题强调的事物。
2.5 替代品和竞争对手
确定用户认为目前可得到的替代品。可包括购买对手的产品、构建一个全部是自己的解决方案或者维持现状。列出所知的已有的以及即将得到的竞争对手的产品。包括最终用户所理解的每位对手的强项和弱项。
2.5.1 竞争对手1
3. 产品综述
这一部分对产品能力、到其他应用系统的接口以及系统配置等等提供一个高层视图，通常由以下三个部分组成。
3.1 产品前景
这部分应该合理地把该产品与其他相关产品及用户的需求放在一起。如果产品是独立的而且是完全独立的，就在这里说明它；如果产品是一个大型系统的组件之一，那么这一部分应该说明系统之间如何交互而且应该确定相关的接口。一种展示大型系统主要组件、互连及外部接口的简单方法就是利用框图。
3.2 产品定位陈述
提供一个整体陈述，从最高层次总结产品在市场上的独特定位。Moore（1991）称此为产品定位陈述，并推荐以下格式：
产品定位陈述向所有相关人员说明了应用系统的意图以及项目的重要性。
3.3 能力总结
总结产品将提供的主要优点和特征。例如，客户支持系统的前景文档可能会使用这一部分强调问题建档、路电和状态报告—不提及各个功能需求的细节。
组织特征，以便清单能够被客户或所有第一次阅读文档的人理解。一个简单的表列出主要的优点及其所支持的特征。
客户支持系统
3.4 假定和相关条件
列出所有一旦变更将影响整个产品前景的假设条件。例如，某个假定条件可能指出，指定用于软件产品的硬件可得到某个特定的操作系统，如果该操作系统得不到，则前景必须变更。
3.5 成本和定价
对于将销售给外部客户的产品以及许多机构内使用的应用系统，成本和定价将直接影响应用系统的定义和实现。在这一部分，把所有成本和相关的定价约束记录下来。例如，分销成本（磁盘、CD-ROM、CD母盘的编号）或者其他货品销售成本（手册、打包）根据应用的性质对于项目的成功可能无关也可能有实质性影响。
4. 特征属性
与需求一样，特征也有属性，提供附加的项目信息，用于评估、跟踪、划分优先级、管理为实现提出的项。这一部分陈述所有建议在前景文档中使用的属性，描述所选择的属性及其意义，使各方都能更好地理解每个特征的背景。
4.1 状态
在项目管理团队协商和评审之后确定。状态信息在项目基线定义过程中跟踪进程。
1）建议的（proposed）：描述正在对该特征进行讨论，但还没有得到“正式渠道”的审核
与采纳，“正式渠道”可以是一个由项目团队、产品管理、用户或客户团队的代表组织的工作小组；
2）批准的（approved）：它的能力被断定是有用和可行的，得到正式渠道的认可并加以实现；
3）收编的(incorporated)：已经在某个特定时间收编入产品基线的特征；
4.2 优先级
产品优先级是由营销人员、产品经理或商业分析人员设置的。根据特征对最终用户的相对优先级把它们划分等级打开了一个与客户、分析人员以及开发团队成员之间的对话。优先级用于管理广度和确定开发优先级。一种优先级划分模式如下：
1）关键的（critical）：本质特征。实现的失败意味着系统将不能满足客户的需要。所有关键的特征必须在发布中实现，否则进度将推迟。
2）重要的（important）：对于大多数应用的系统效率和效力都重要的特征。该功能无法容易地用其他方式实现。如果缺少重要的特征，可能影响客户或用户的满意程度，甚至影响收益，但发布不会因此而推迟；
3）有用的（useful）：在不太典型的应用中有用的特征，但不经常使用或者有其他合理的有效变通。如果发布中没有这类特征也不会对客户满意程度或收益造成重大的影响
4.3 工作量
由开发团队设置，用于管理广度和确定开发优先级。由于有些特征比其他特征要求更多的时间和资源，因此对各特征采用团队数量或人周、代码行、功能点等等进行评估将是预测复杂度的最好办法，从而可对在给定时间范围内能完成什么不能完成什么有一个预期。
4.4 风险
由开发团队设置，设置的依据是项目经历意外事件的可能性，如成本过高、进度延迟甚至项目被撤消等。许多项目经理发现，把风险分为高、
中、低就已经足够了，尽管还可以再细一些。风险通常可以通过度量项目团队进度预测的不确定性（范围）进行间接地评估。
4.5 稳定性
由分析人员和开发团队设置，设置的依据是特征变更的可能性或团对变更特征的理解。这个信息有助于建立开发优先级或确定下一步中哪些附加启发是适当的。
4.6 目标当布
记录特征将首先出现在哪一个产品版本中。这个域可用于把特征分配到特定的基线版本中。当把目标版本与状态域结合起来时，团队可以建议、记录和讨论该版本的各个特征，而不必把它们提交给开发。只有一些状态被设置为“收编的”特征并且其目标版本被定义的特征才能实现。在发生广度管理时，目标版本的版本号会不断增加，于是该项仍然存在于前景文档中，但被安排到以后的版本中去。
4.7 分配给
在许多项目中，把特征分配给“特征团队”，负责进一步启发、书写软件需求和实现。这个简单清单将帮助所有项目团队成员更好地了解自己的职责。
4.8 原因
这一文本域用来跟踪所要求特征的来源。特征的存在有很多特定的理由。这个域记录了特征的解释或对解释的引用。例如，引用可以是产品需求规格说明的页号和行号，或是重要客户面谈录像带上的一个分钟标志。
5. 产品特征
这一部分记录产品特征。特征提供了给用户带来利益所需要的系统能力，每个特征都提供了一个满足用户需要的服务。例如，问题跟踪系统的一个特征可能是“提供走势报告”的能力，趋势报告可能继续支持一个“更好理解项目状态”的需要。
因为前景文档是由许多涉及人员审核的而且是达成共识的基础。所以特征应该用用肪的自
