列出用户认为的关键问题或需要。

为每个问题澄清以下内容：
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. 产品特征
这一部分记录产品特征。

特征提供了给用户带来利益所需要的系统能力，每个特征都提供了一个满足用户需要的服务。

例如，问题跟踪系统的一个特征可能是“提供走势报告”的能力，趋势报告可能继续支持一个“更好理解项目状态”的需要。

因为前景文档是由许多涉及人员审核的而且是达成共识的基础。

所以特征应该用用肪的自
然语言描述。

特征描述应该简短、精练，通常是1-2个句子。

为了有效管理应用的复杂度，我们建议：对于任何新系统或在原有系统上加强的系统，把能力抽象到较高层次产生大约25-99个特征。

这些特征是产品定义、广度管理和项目管理的基本基础。

每个特征都可以在后面的规格说明中被更详细地说明。

在整个这一部分中，每一个特征都应该是用户、操作者或其他外部系统可以感知的。

5.1 特征＃1
5.2 特征＃2
6. 关键用例
描述一些关键用例，可以是对体系结构有意义或最方便帮助读者理解系统如何使用的用例。

7. 其他产品需求
7.1 可应用标准
列出产品必须符合的标准，如法律和规章（FDA、FCC）、通信标准（TCP/IP、ISDN）、平台兼容标准（Windows、UNIX）以及质量和安全标准（UL、ISO、CMM）。

7.2 系统需求
定义支持应用所必须的所有系统需求。

包括支持的主机操作系统、网络平台、配置、内存、外设以及软件。

7.3 许可和安装
许可和安装问题对于开发工作有直接影响。

例如，支持序列号、口令安全或网络许可证的需要必须创建其他开发过程中必须考虑的附加的系统需注。

安装需求也会影响编码或者产生开发独立安装软件的需求。

7.4 性能需求
性能问题包括用户负载因素、带宽或通信能力、吞吐量、准确度、可靠性或在某些负载条件下的响应时间等。

8. 建档需求
这一部分描述所有支持成功地部署系统必
须开发的文档
8.1 用户手册
描述用户手册的目的和内容。

讨论其需要的长度、详尽程序、索引和词汇表的需要、指南及参考手册策略，等等。

还要指定格式和打印约束。

8.2 在线帮助
许多应用系统都提供一个在线的帮助系统
来辅助用户。

这些系统的本质是应用系统开发所特有的，因为它们把编程（如超链接）和技术书写（如组织和表示）结合起来。

许多人发现在在线帮助系统是项目中的项目，它从广度管理和计划活动中直接受益。

8.3 安装指南、配置和自述文件
对于一个全面的解决方案来说，有一个包括安装指令和配置指南的文档非常重要，而一个自述（Read Me）文件也通常作为标准组件而存在。

自述文件中可能包括一个“本版本的新增内
容”部分以及一个与以前版本的兼容问题的讨
论。

许多用户还希望在自述文件中说明所有已知的错误和变通方法。

8.4 标记和打包
当今最新的艺术化的应用系统提供了一个从安装菜单提示的产品打包和装载清单、炫耀的屏幕、帮助系统、GUI对话等开始的一致的外观和感觉。

这一部分定义要集成到代码中的标记的类型和需要。

包括版本和专利说明、公司商标、标准化图标及其他图形无素等。

9. 词汇表
词汇表定义所有项目特有的术语。

包括所有阅读文档的用户或其他人无法理解的缩写和简写。