问题是	[对问题进行说明]
影响	[问题影响的涉众]
问题的后果	[该问题会导致什么后果]
成功的解决方案可以	[列出成功解决方案的一些主要优点]

2.3 产品定位说明

[提供一段总体说明，高度概括产品将要在市场上占据的独特位置。可以采用以下格式：]

针对于	[目标客户]
谁	[陈述需要或机会]
该（产品名）	属于[产品类别]
具有	[陈述重要优点，即促使人们购买的原因]
不同于	[主要的竞争产品]
我们的产品	[陈述主要的区别]

[产品定位说明用于向所有相关人员传达应用程序的目的和项目的重要性。]

3. 涉众和用户说明

[为有效地提供符合涉众及用户实际需要的产品和服务，有必要在需求建模流程中确定并包括所有涉众。您还必须确定系统的用户，确保涉众群能够充分代表这些用户。本节提供参与项目的涉众和用户的简档，以及他们认为需要通过提出的解决方案来解决的关键问题。这里并不说明他们的具体请求或需求，因为这些内容将单独在涉众请求工件中记录。此处涉及的只是这些需求存在的背景和原因。]

3.1 消费者统计数据

[总结促使您作出产品决策的关键消费者统计数据。说明并定位目标细分市场。估计市场的大小和增长率，估计的依据可以是潜在用户的数量，也可以是客户用于满足您的产品或改进的需求的支出。了解行业大势和主流技术。回答以下战略性问题：

• 您的组织在这些市场的声誉如何？

• 您想获得什么样的声誉？

• 该产品或服务将如何支持您实现这些目标？]

3.2 涉众摘要

[提供所有已确定涉众的一览表。]

名称

代表

作用

指明涉众类型。

简要说明在开发方面他们所代表的对象。

[简要说明他们在开发中的作用。

例如，是否确信?]

3.3 用户摘要

[提供所有已确定用户的一览表。]

名称

说明

涉众

指明用户类型

[简要说明在系统方面他们所代表的对象。]

[明确用户如何由涉众来代表。

例如，由涉众 1.1 来代表

3.4 用户环境

[详细说明目标用户的工作环境。以下是几项建议：

该任务由多少人来完成？是否总在变化？

一个任务周期需要多长时间？执行每项活动要用多长时间？是否总在变化？

是否有特殊的环境约束：移动、户外、乘机旅行等？

目前使用的是哪些系统平台？以后会使用哪些平台？

还在使用哪些应用程序？您的应用程序是否需要和这些应用程序集成？

在此处可以从业务模型中摘录一些内容来概述所涉及的任务和角色等等。]

3.5 涉众简档

[通过在下表中填写系统中各个涉众的相关信息对涉众加以说明。要注意的是，涉众的类型多种多样，例如用户、策略部门和技术开发人员。详尽的简档应包括各种涉众在以下方面的信息：]

3.5.1 <涉众名>

代表	[谁是此项目的涉众代表？（如何在其他地方有记录，则在此处为可选。）此处只需填写名称。]
说明	[对涉众类型的简要说明。]
类型	[介绍涉众的技能特长、技术背景和熟练程度（即权威用户、业务用户、专家用户、初级用户等）]
职责	[列出涉众对所开发的系统负有的关键职责，即作为涉众，他们应享有的利益。]
成功标准	[该涉众如何界定成功？该涉众如何得到回报？]
参与	[该涉众如何参与此项目？尽可能和 RUP 角色（如需求复审员）建立联系。]
可交付工件	[涉众是否还需要其他的可交付工件？这些工件可以是项目可交付工件，也可以是正在开发的系统的输出。]
意见/问题	[在此处列出会阻碍成功的问题以及任何其他相关信息。]

3.6 用户简档

[通过在下表中填写系统的各种用户的相关信息来说明这些用户。要注意的是，用户可能有许多不同的类型，例如权威用户和入门用户。权威用户可能会需要复杂、灵活并具备跨平台支持的工具；而入门用户则会需要使用方便、界面友好的工具。详尽的简档应包括各种用户在以下方面的信息：]

3.6.1 <用户名>

代表	[谁是此项目的用户代表？（如果在其他地方有记录，则在此处为可选。）通常指的是代表一组用户的涉众，例如涉众：涉众 1。]
说明	[对该用户类型的简要说明。]
类型	[介绍该用户的技能特长、技术背景和熟练程度（即权威用户、初级用户等）。]
职责	[列出该用户对所开发的系统负有的关键职责，如记录详细信息、撰写报告、协调工作等。]
成功标准	[该用户如何界定成功？该用户如何得到回报？]
参与	[该用户如何参与此项目？尽可能和 RUP 角色（如需求复审员）建立联系。]
可交付工件	[是否有该用户生成的可交付工件？如果有，是为谁生成的？]
意见/问题	[在此处列出会阻碍成功的问题以及任何其他相关信息。其中还需指明将如何影响用户的工作，即：让工作变得简单还是困难。]

3.7 关键的涉众/用户需要

[列出涉众认为现有解决方案存在的关键问题。对于列出的每个问题，需澄清以下要点：

• 为什么会出现这一问题？

• 目前的解决方案是什么？

• 涉众需要什么样的解决方案？]

[务必要了解涉众或用户对解决各个问题的相对重视程度。分级和累积投票方法表明，必须解决的问题与涉众或用户希望解决的问题大有不同。

填写下表 - 如果是使用 ReqPro 来记录需要，这可能就是该工具所生成的摘录或报告。]

需求	优先级	关注的要点	目前的解决方案	提议的解决方案
广播消息

3.8 备选方案和竞争

[确定涉众认为可以使用的备选方案。其中可能包括购买竞争对手的产品、自行设计解决方案，或者仅维持现状。列出已经存在或潜在的竞争产品。列出涉众认为各种竞争对手具有的主要优缺点。]

3.8.1 <竞争对手一>

3.8.2 <竞争对手二>

4. 产品概述

[此节高度概括产品的功能、与其他应用程序的接口以及系统配置。此节通常要包括以下三个小节：

• 产品总体效果

• 产品功能

• 假设与依赖关系]

4.1 产品总体效果

[前景文档的这一小节应将该产品放在其他相关产品环境和用户环境中进行介绍。如果该产品自成一体，应在此处说明。如果该产品是较大系统的构件，此小节则应说明这些系统如何进行交互，并确定系统之间的相关接口。要显示较大系统的主要构件、互连情况和外部接口，一种简单的方法就是通过框图来表示。]

4.2 功能摘要

[总结该产品将提供的主要优点和特性。例如，一个客户支持系统的前景文档可能会利用此部分来讨论存在问题的记录、消息传递和状态报告，而不必涉及每个功能的细节。

对功能加以组织，使客户或初次阅读该文档的其他人能够理解此功能列表。下面的简表列出了主要优点及支持的特性，该示例应足以说明问题。例如：]

客户支持系统

客户利益	支持功能
新的支持人员能够很快地步入正轨。	知识库可协助支持人员迅速地找到已知的解决方法和变通方法。
因为考虑周全而提高了客户满意度。	在整个解决过程中可将问题一一列出，并进行分类和跟踪。一出现老化问题就自动发出通知。
管理人员能够发现存在问题的领域并估计人员的工作量。	趋势及分布报告可从较高的角度来审查问题的状态。
分散的支持团队能够协同解决问题。	复制服务器使当前的数据库信息可以在整个企业的范围内共享
客户能够自行解决一些问题，从而降低了支持成本并缩短了答复时间。	可以通过 Internet 来访问知识库。包括超文本搜索功能和图形查询引擎

4.3 假设与依赖关系

[列出会影响前景文档中所述特性的所有因素。列出其变更将引起前景文档随之变化的假设。例如，有这样一项假设：将为该软件产品指定的硬件提供特定的操作系统。但如果没有提供该操作系统，就将需要更改前景文档。]

4.4 成本与定价

[对于向外部客户发售的产品和许多内部的应用程序，成本和定价问题会直接影响到应用程序的定义的实施。在此节中，应记录任何相关的成本或定价约束。例如，分销成本（软盘的数量、光盘的数量、CD 制作）或其他商品销售的成本约束（手册、包装）可能对于项目的成功非常重要，也可能无关紧要，这取决于应用程序的性质。]

4.5 许可与安装

[许可和安装问题也可能直接影响到开发工作。例如，如果需要支持串行化、口令安全或网络许可，则会增加在开发工作中必须予以考虑的系统需求。

安装需求还可能会影响到编码，或需要单独安装的软件。]

5. 产品特性

[列出并简述产品的特性。特性是为让用户获益而必须具备的高级系统功能。每一项特性都是外部所需的服务，它通常需要一系列输入来实现预期的结果。例如，问题跟踪系统的特性是能够提供趋势报告。当用例模型成型后，更新这里的说明以指代用例。

由于前景文档将由各种各样的相关人员来复审，所以不应太过详细，应让所有人对此都有大致的了解。但是，应该向团队提供他们创建用例模型所需的必要详细信息。

要有效地管理应用程序的复杂性，对于任何新系统或对现有系统的增量部分，我们建议将功能提炼到较高的程度，这样 25 到 99 项特性较为合理。这些特性为产品定义、规模管理和项目管理提供了基础。每项特性的详细程度都将在用例模型中得到较深入的扩展。

贯穿此节的始终，都应能让用户、操作人员或其他外部系统从外部觉察到每项特性。这些特性应包括功能性的说明以及必须考虑的任何相关的可用性问题。以下原则将会适用：

• 避免设计。使特性说明保持一定的概括程度。侧重于说明所需的功能以及为什么要（而不是如何）实现这些功能。

• 如果您使用的是 Requisite 工具包，应将需求类型选择为“所有”，以便于引用和跟踪。]

5.1 <特性一>

5.2 <特性二>

6. 约束

[记录所有设计约束、外部约束或其他依赖关系。]

7. 质量范围

[定义性能、强壮性、容错、可用性以及特性集中没有记录的类似特征的质量范围。]

8. 优先级

[定义不同系统特性的优先级。]

9. 其他产品需求

[在较高层次上列出适用的标准、硬件或平台需求、性能需求以及环境需求。]

9.1 适用的标准

[列出产品必须符合的所有标准。其中可能包括法律和法规（FDA、UCC）标准、通讯标准（TCP/IP、ISDN）、平台一致性标准（Windows、Unix 等）以及质量和安全标准（UL、ISO、CMM）。]

9.2 系统需求

[确定支持该应用程序所必需的任何系统需求。其中可能包括所支持的主机操作系统及网络平台、配置、内存、外围设备和配套软件。]

9.3 性能需求

[本节用于详细说明性能需求。性能问题可能包括在各种负载条件下的用户负载因素、带宽或通信容量、吞吐量、精确度以及可靠性或响应时间。]

9.4 环境需求

[根据需要详细说明环境需求。对于基于硬件的系统，环境因素可以包括温度、振荡、湿度、辐射等。对于软件应用系统，环境因素可以包括使用条件、用户环境、资源可用性、维护问题、错误处理和恢复。]

10. 文档需求

[此节说明为支持成功部署应用程序而必须制作的文档。]

10.1 用户手册

[说明用户手册的目的和内容。讨论预期长度、详细程度，是否需要索引、词汇表、教程与引用手册策略等。还应确定格式和打印约束条件。]

10.2 联机帮助

[许多应用程序提供了联机帮助系统来协助用户。这些系统的性质对于应用程序开发来说独特的，因为它们综合了编程（如超链接）和技术写作（组织、演示）的各个方面。许多人发现联机帮助系统的开发本身就是一个受益于先期规模管理和计划活动的项目。]

10.3 安装指南、配置文件、自述文件

[在提供全套的解决方案时，提供包括安装说明和配置指南的文档是非常重要的。此外，自述文件通常也要作为一个标准构件包括在内。自述文件可以包括一个“本发布版中的新特性”部分，并讨论与以前发布版的兼容性问题。多数用户也希望在自述文件中列出任何已知的错误和变通方法。]

10.4 标签与包装

[目前最新技术水平的应用程序从产品包装开始就提供了一致的外观，这种一致还体现在安装菜单、启动屏幕、帮助系统、GUI 对话框等等。此节定义对标签的需求和和标签类型，以便合并到代码中。举例来说，标签和包装涉及版权和专利声明、公司徽标、标准化的图标以及其他图形元素。]

11. 附录 1 - 功能属性

[为了对提议进行实施的产品项进行评估、跟踪、确定优先级和管理，应该为功能指定属性。所有需求类型和属性都应在需求管理计划中列出，但最好列出并简要说明已选中的功能的属性。以下小节建议了一组功能属性。]

11.1 状态

[在经过项目管理团队的商谈和复审后设置。用于在确立项目基线的过程中对进度进行跟踪。]

已提出	用于说明正在进行讨论但尚未经过“正式渠道”（例如由项目团队、产品管理部门和用户或客户群的代表所组成的工作组）复审和验收的特性。
已获准	[被认为是有用、可行并已获得正式渠道批准，准备实施的功能。]
已并入	[在特定时间点并入产品基线中的特性。]

11.2 利益

[由营销经理、产品经理或业务分析员设置。并非所有创建的需求都处在同一级别上。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。]

关键	[必不可少的特性。不实现这些特性就无法使系统满足客户的需要。所有关键特性都必须在发布时实现，否则将错过预定的发布时间。]
重要	[对于系统在大多数应用中的有效性及效率都较为重要的特性。很难通过其他方式来实现这方面的功能。如果遗漏了某项重要特性，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项重要特性而延期。]
有用	[有些特性在不太典型的应用中比较有用，或者可以合理而有效地实现其替代特性，因而这些特性的使用频率相对较低。即使发布版中并未包括某一项有用的特性，也不会对收入或客户满意度造成严重的影响。]