1、远景 版本 注意：以下模板供与 Rational Unified Process 一起使用。包含在方括号中以蓝色斜体（ style=InfoBlue）显示的文本是用于向作者提供指导，在发布文档之前应将这些文本删除。在此样式之后输入的段落将自动设置为正常（ style=Body Text）。 要在 Microsoft Word 中定制自动字段（选中时显示灰色背景），请选择 “文件 属性 ”，然后用相应的信息替换本文档的 “标题 ”、 “主题 ”和 “公司 ”字段。关闭对话框后，可以通过选择 “编辑 全选 ”（或 Ctrl-A），然后按 F9 键，让整个文档中的自动字段更新，或者只需单击字段并按
2、F9 键。此操作必须对页眉和页脚分开进行。 Alt-F9 将在显示字段名称和显示字段内容之间切换。关于处理字段的更多信息，请参阅 Word 帮助。 版本： 远景 日期：机密 ，2019 第 2修订历史记录日期 版本 描述 作者版本： 远景 日期：机密 ，2019 第 3目录1. 简介 51.1 目的 51.2 范围 51.3 定义、首字母缩写和缩写 51.4 参考资料 51.5 概述 52. 定位 52.1 业务机会 52.2 问题声明 52.3 产品定位声明 53. 项目干系人和用户描述 63.1 市场人口统计信息 63.2 项目干系人摘要 63.3 用户摘要 63.4 用户环境 73.5
3、项目干系人概要信息 73.5.1 73.6 用户概要信息 83.6.1 83.7 关键项目干系人或用户需要 83.8 替代方案和竞争 83.8.1 93.8.2 94. 产品概述 94.1 产品透视图 94.2 功能摘要 94.3 假定和依赖关系 94.4 成本和定价 94.5 许可和安装 105. 产品功能 105.1 105.2 106. 约束 107. 质量范围 108. 优先顺序和优先级 109. 其他产品需求 10版本： 远景 日期：机密 ，2019 第 49.1 适用标准 119.2 系统需求 119.3 性能需求 119.4 环境需求 1110. 文档需求 1110.1 用户手册
4、 1110.2 联机帮助 1110.3 安装指南、配置和自述文件 1110.4 标注和包装 11A 功能属性 11A.1 状态 11A.2 好处 12A.3 工时 12A.4 风险 12A.5 稳定性 12A.6 目标发行版 12A.7 指定给 13A.8 原因 13版本： 远景 日期：机密 ，2019 第 5远景 1. 简介本文档的目的是收集、分析和定义 的高级别需要和功能。重点主要是在项目干系人和目标用户需要的功能以及这些需要存在的 原因 。 如何满足这些需要的详细信息在用例和补充规范中有详细描述。 远景 文档的简介提供整个文档的概述。它包括本 远景 文档的目的、范围、定义、首字母缩写、缩
5、写、引用和概述。 1.1 目的指定本 远景 文档的目的 。 1.2 范围简要描述本 远景 文档的范围、它与哪些项目关联，以及受本文档影响的所有其他方面。 1.3 定义、首字母缩写和缩写本子节提供所有术语、首字母缩写和缩写的定义，这些术语、首字母缩写和缩写对于正确解释 远景 文档是必需的。可以通过引用项目的词汇表来提供此信息。 1.4 参考资料本子节提供一份在 远景 文档中的其他地方引用的所有文档的完整列表。按标题、报告号（如果适用）、日期和出版组织标识每份文档。指定从哪些来源可以获得这些参考资料。可以通过引用附录或其他文档来提供此信息。 1.5 概述本子节描述 远景 文档的剩余部分包含哪些内容
6、，并解释文档是如何组织的。 2. 定位2.1 业务机会简要描述本项目符合的业务机会。 2.2 问题声明提供总结本项目所解决问题的声明。可以使用以下格式： 问题来源 描述问题 影响 问题影响的项目干系人 问题的影响 问题的影响是什么？ 成功的解决方案是 列出成功解决方案的一些主要益处 2.3 产品定位声明提供概要声明，在最高级别总结产品计划在市场上找到的独一无二的位置。可以使用以下格式： 版本： 远景 日期：机密 ，2019 第 6用于 目标客户 谁 需要或机会的声明 （产品名称） 产品类别 益处 主要益处的声明；即有说服力的购买原因 不同之处 主要竞争对手的替代产品 我们的产品 主要差异化的声
7、明 产品定位声明，该声明将应用的目的和项目的重要性传达给所有相关人员。 3. 项目干系人和用户描述为了有效地提供满足项目干系人和用户实际需求的产品和服务，必须确定所有项目干系人并将它们作为需求建模过程的一部分。您还必须确定系统的用户并确保该项目干系人团体可以充分地代表他们。本节提供项目所涉项目干系人和用户的概要信息，另外还包含了他们认为提供的解决方案针对的主要问题。本节不描述他们的特定请求或需求，因为这些内容在单独的项目干系人请求工件中已经包含。本节提供的是为何需要这些需求的背景和理由。 3.1 市场人口统计信息总结激发产品决策的关键市场人口统计信息。描述和定位目标市场段。估计市场大小和成长，
8、方法是通过计算潜在用户的数量或者客户尝试满足需求（您的产品或增强性能也将满足这些需求）所花费的费用。复审主要行业趋势和技术。回答这些策略问题： 您的公司在这些市场中的声誉如何？ 您希望它如何发展？ 本产品或服务如何支持您的目标？ 3.2 项目干系人摘要项目的开发会有众多存在利害关系的项目干系人，而这些人中并非所有都是最终用户。提供这些非用户的项目干系人的摘要列表。（用户在 3.3 节中概述。） 名称 描述 职责命名项目干系人类型。 简要描述项目干系人。 就开发的系统总结项目干系人的主要职责；即他们作为项目干系人的利益。例如，该项目干系人：- 确保系统可维护- 确保对于产品的功能会有市场需求-
9、监视项目进度- 批准资金筹集- 等等 3.3 用户摘要提供所有已识别用户的摘要列表。 版本： 远景 日期：机密 ，2019 第 7名称 描述 职责 项目干系人命名用户类型。简要描述他们就系统而言代表什么。就开发的系统列出用户的主要职责；例如：- 获取详细信息- 生成报告- 协调工作- 等等 如果不是直接代表用户的，请确定哪个项目干系人负责代表该用户的利益。 3.4 用户环境详述目标用户的工作环境。以下是一些建议： 完成该任务所涉及的人数？该数目是否在变化？ 任务周期有多长？每个活动所用的时间是多少？该数目是否在变化？ 是否有任何独特的环境约束：移动、户外、飞行中等等？ 今天使用了哪些系统平台？
10、将来的平台是？ 哪些其他应用程序也在使用中？您的应用程序是否需要与那些应用程序集成？在该位置可以包含业务模型的摘要以概述涉及的任务和角色等等。 3.5 项目干系人概要信息 在此处描述系统中的每个项目干系人，方法是对每个项目干系人填写下表。请记住项目干系人类型可以分成用户、部门和技术开发人员。一个全面的概要文件将对每种项目干系人类型涵盖以下主题。 3.5.1 代表 项目的项目干系人代表是谁？（如果已在别处记录，则此处可以不写。）此处需要写的是姓名。 描述 项目干系人类型的简要描述。 类型 对项目干系人的专长、技术背景、资深程度进行认定 即精英、业务、专家、普通用户等等。 职责 就开发的系统列出项
11、目干系人的主要职责 即他们作为项目干系人的利益。成功标准 项目干系人如何定义成功？ 项目干系人如何得到奖励？ 涉及方式 在项目中如何涉及项目干系人？尽可能与 Rational Unified Process 角色相关 即 “需求复审员 ”等。 可交付工件 是否有项目干系人要求的任何附加可交付工件？这些可以是项目可交付工件或者是来自开发中的系统的输出。 注释事项 在此处描述妨碍项目成功的问题和任何其他相关信息。 版本： 远景 日期：机密 ，2019 第 83.6 用户概要信息 在此处描述系统中的每个唯一的用户，方法是对每个用户类型填写下表。请记住用户类型也一样可以分为精英和新手。例如：精英可能需
12、要能够提供跨平台支持的复杂而灵活的工具，而新手可能需要便于使用、用户友好的工具。一个全面的概要文件需要对每种类型的用户涵盖以下主题。 3.6.1 代表 项目的用户代表是谁？（如果已在别处记录，则此处可以不写。）这通常指代表一组代表用户的项目干系人，例如项目干系人：项目干系人 1。 描述 用户类型的简要描述。 类型 对用户的专长、技术背景、资深程度进行认定 即精英、普通用户等等。 职责 就开发的系统列出用户的主要职责 即获取详细信息、生成报告、协调工作等等。 成功标准 用户如何定义成功？用户如何得到奖励？ 涉及方式 在项目中如何涉及用户？尽可能与 Rational Unified Process
13、 角色有关 即 “需求复审员 ”等等。 可交付工件 是否有任何用户产生的可交付工件，如有的话是提供给谁的？ 注释事项 在此处描述妨碍项目成功的问题和任何其他相关信息。这将包括使用户工作更方便或更困难的趋势。 3.7 关键项目干系人或用户需要列出项目干系人或用户察觉到的重要问题以及现有的解决方案。针对每个问题阐明以下事项： 该问题的原因是什么？ 现在如何解决该问题？ 项目干系人或用户需要什么解决方案？ 了解项目干系人或用户对解决每个问题所置的 相对 重要性很重要。排名和表决技术表明了 必须 解决的问题和希望针对的事项。填写下表 如果使用 Rational RequisitePro 捕获需求，则这
14、可以是该工具生成的摘要或报告。 需要 优先级 考虑内容 当前解决方案 建议的解决方案广播报文3.8 替代方案和竞争确定项目干系人认为可用的替代方案。这可以包括购买竞争对手的产品、构建自行开发的解决方案或者只版本： 远景 日期：机密 ，2019 第 9是维持现行状态。列出存在或可能成为可用的所有已知的竞争对手选项。包含项目干系人或最终用户发现的每个竞争对手的主要优势和弱点。 3.8.1 3.8.2 4. 产品概述本节提供产品功能、与其他应用程序的接口以及系统配置的高级别视图。本节通常包含三个子节，如下所示： 产品透视图 产品功能 假定和依赖关系 4.1 产品透视图远景 文档的这一子节将透视图中的
15、产品放在其他相关产品和用户环境中。如果产品独立并且完全自包含，请在此处声明。如果产品是大型系统的组件，则该子节需要说明这些系统如何交互并且需要确定系统之间的相关接口。显示大型系统主要组件、互连和外部接口的一个比较简单的方法是使用框图。 4.2 功能摘要总结产品将提供的主要好处和功能。例如客户支持系统的 远景 文档可以使用本部分来解决问题记录、传递和状态报告，而不用提到每个功能所要求的详细信息量。对功能加以组织，从而使列表对客户或者对于第一次阅读该文档的其他读者可以理解。用一个简单的表列出主要好处及其支持功能可能就够了。例如： 表 4-1 客户支持系统客户好处 支持功能新支持人员可以快速上手。
16、知识库可以辅助支持人员快速识别已知修订和变通办法。由于没有破解失败，客户满意度得到提高。在整个解决方案过程中问题一一得到记录、归类和跟踪。对于任何随时间推移发生的事项进行自动通知。管理层可以识别问题区域并调整人员工作负载。趋势和分发报告提供对问题状态的高级别复审。分散在各处的支持团队可以携手工作来解决问题。复制服务器允许当前数据库信息在整个企业中共享。客户可以帮助他们自己降低支持成本并改进响应时间。知识库可以在整个因特网中都可用。包含超文本搜索功能和图形查询引擎。4.3 假定和依赖关系列出影响 远景 文档中所声明功能的所有因素。列出一旦更改就会改变 远景 文档的假定。例如假定可能会声明特定操作
17、系统将对于为软件产品指定的硬件可用。如果操作系统不可用，则 远景 文档需要更改。 4.4 成本和定价对于销售给外部客户的产品和许多公司内的应用程序，成本和定价问题会直接影响应用程序的定义和实施。在本节中记录任何相关的成本和定价约束。例如分发成本（软盘数、 CD-ROM 数、 CD 后期处理）或已销售版本： 远景 日期：机密 ，2019 第 10商品的其他成本约束（手册、包装）可能是与产品的成功有关或无关的材料，这取决于应用程序的性质。 4.5 许可和安装许可和安装问题也会直接影响开发工作。例如需要支持序列化、密码安全性或网络许可的话，就会产生附加的系统需求，在开发工作中必须考虑到这些需求。安装
18、需求可能还会影响代码编写或产生单独安装软件的需要。 5. 产品功能列出并简要描述产品功能。功能是系统为了向用户提供好处所必需的高级别能力。每种功能都是外部要求的服务，它们通常需要进行一系列输入以获得期望的结果。例如问题跟踪系统的功能可以是提供趋势报告的能力。当用例模型形成时，请更新引用用例的描述。因为 远景 文档由范围广泛的所涉人员复审，所以详细级别需要达到让每个人都理解的通用程度。然而必须有足够的详细信息才能向团队提供创建用例模型所需的信息。为了有效地管理应用程序复杂性，我们建议对于任何新系统或对于现有系统的增量，能力被抽象到一个足够高的级别，在该级别下将生成 25-99 个功能。这些功能为
19、产品定义、范围管理和工程管理提供基础。每个功能都会在用例模型中扩展得更详细。在本节中每个功能都会让用户、操作员或其他外部系统从外部观察到。这些功能需要包含功能描述以及必须针对的任何相关可用性事项。以下指南适用于： 避免牵涉到设计。将功能描述保持在一个通用的级别。重点放在需要的功能以及为何需要（而不是如何需要） 实施这些功能。 如果使用的是 Rational RequisitePro 工具包，需要选择所有内容作为类型的需求，从而可以方便地引用和跟踪。 5.1 5.2 6. 约束 声明任何设计约束、外部约束或其他依赖关系。 7. 质量范围 针对性能、健壮性、容错、可用性以及功能集内没有包含的类似特
20、性定义质量范围。 8. 优先顺序和优先级定义不同系统功能的优先级。 9. 其他产品需求在高级别列出适用标准、硬件或平台需求、性能需求和环境需求。 9.1 适用标准列出产品必须符合的所有标准。可以包括法律和法规（ FDA、 UCC）、通信标准（ TCP/IP、 ISDN）、平台兼版本： 远景 日期：机密 ，2019 第 11容性标准（ Windows、 UNIX 等等）以及质量和安全标准（ UL、 ISO、 CMM）。 9.2 系统需求定义支持应用程序所需的系统需求。可以包括受支持的主机操作系统和网络平台、配置、内存、外围设备和配套软件。 9.3 性能需求使用本节详述性能需求。性能事项可以包括用
21、户负载因子、带宽或通信容量、吞吐量、准确性以及在各种负载条件下的可靠性或响应时间等。 9.4 环境需求根据需要详述环境需求。对于基于硬件的系统，环境事项可以包括温度、电击、湿度和辐射等。对于软件应用程序，环境因素可以包括使用条件、用户环境、资源可用性、维护事项以及错误处理和恢复。 10. 文档需求本节描述支持成功的应用程序部署必须开发的文档。 10.1 用户手册描述用户手册的目的和内容。讨论所需的长度、详细级别、是否需要索引、术语词汇表、教程及参考手册策略等等。还必须确定格式和打印约束。 10.2 联机帮助许多应用程序提供联机帮助系统来辅助用户。这些系统的性质对于应用程序开发来说是独一无二的，
22、因为它们将编程的各个方面（超链接等）与技术撰写（例如组织和演示）都组合在一起。许多人都发现联机帮助系统的开发是项目内的项目，该项目得益于提前的范围管理和计划活动。 10.3 安装指南、配置和自述文件对于完整的解决方案来说，包含安装说明和配置准则的文档是非常重要的。同样自述文件通常也作为标准组件包含在内。自述文件可以包含 “本发行版的新增内容 ”一节，还可以包含与先前发行版兼容性事项的讨论。大多数用户还希望在自述文件中有定义任何已知错误和变通办法的内容。 10.4 标注和包装当今最新的应用程序会提供一致的外观，首先通过产品的包装，然后通过安装菜单、闪屏、帮助系统、GUI 对话框等来体现出这一点。
23、本节定义了要在代码中加入的标注需要和类型。例如版权和专利声明、公司徽标、标准化的图标以及其他图形元素等。 A 功能属性功能就是一些给定的属性，它们可以用来评估、跟踪和管理为实施而提供的产品项并对它们划分优先级。所有需求类型和属性都需要在需求管理计划中概述，然而您可能希望列出并简要描述已选功能的属性。以下子节表示一组建议的功能属性。 A.1 状态在由项目管理团队协商和复审之后设置。在定义项目基线期间跟踪进度。 版本： 远景 日期：机密 ，2019 第 12已建议 用来描述讨论中的功能，但这些功能还没有被 “官方渠道 ”复审和接受，例如由项目团队、产品管理和用户或客户团体的代表组成的工作组。 已核
24、准 功能被认为是有用和可行的，并已由官方渠道核准实施。 已合并 功能已在特定时间点合并到产品基线中。 A.2 好处由营销部门、产品经理或业务分析员设置。所有的需求并不是以相同的优先级创建。根据需求对最终用户的相对好处对需求分级可打开与客户、分析人员和开发团队成员的对话。在管理范围和确定开发优先级时使用。 关键 必需的功能。未能实施意味着系统将无法满足客户需求。所有的关键功能都必须在发行版中实施，否则进度安排将落后。 重要 对于大部分应用程序的系统有效性和效率很重要的功能。无法通过其他某种方式很容易地提供该功能。未包含一项重要功能可能会影响客户或用户满意度，甚至是影响收入，但发行版不会由于缺少任
25、何重要功能而延迟。 有用 在不常用的应用程序中有用的功能部件会使用较少，或者可以有合理、有效的变通办法代替这些功能部件。未在发行版中包含此类功能项时，不会对收入或客户满意度产生明显的影响。 A.3 工时由开发团队设置。因为某些功能需要比其他功能更多的时间和资源，因此举例来说，估计团队或人员工作周数量、需要的代码行数量或功能点数量，就是评估复杂性、设置在给定时间范围内哪些功能可以实现、哪些功能无法实现这一期望值的最好方式。在管理范围和确定开发优先级时使用。 A.4 风险由开发团队根据项目将经历负面事件的可能性来设置，负面事件包括成本过高、进度安排延迟甚至取消等等。大多数项目经理会发现将风险列为高
26、、中、低已经足够（虽然可以将等级划分得更细）。风险通常可以通过评测项目团队进度安排估计情况的不确定性（范围）来进行间接的评估。 A.5 稳定性由分析人员和开发团队设置，这基于功能部件将更改的可能性，或者基于团队对于功能部件将更改的理解。用于帮助设定开发优先级和确定那些需要进行进一步的引发的项。 A.6 目标发行版记录功能首次出现的预期产品版本。该字段可以用来将 远景 文档的功能部件分配到特定的基线发行版。在与状态字段结合使用时，团队可以建议、记录和讨论发行版的各种功能，而无需将它们落实到开发中。只有 “状态 ”设置为 “已合并 ”且定义了 “目标发行版 ”的功能才会被实施。当进行范围管理时， “目标发行版版本号 ”可以增加，从而该项仍然会在 远景 文档中，但是会安排到之后的发行版中。 版本： 远景 日期：机密 ，2019 第 13A.7 指定给在许多项目中，功能部件会指定给 “功能部件团队 ”，这些团队负责进一步引发、撰写软件需求和实施。这个简单的下拉列表会帮助项目团队的每个人更好地理解职责。 A.8 原因这个文本字段用于跟踪所请求的功能的来源。需求由于特定的理由而存在。此字段记录说明或对说明的引用。例如可以引用产品需求规范的页码和行号，也可以引用重要客户复审视频上的分钟标记。
