<项目名称>
远景
版本 <1.0>
[注意:以下模板供与 Rational Unified Process 一起使用。包含在方括号中以蓝色斜体(style=InfoBlue)显示的文本是用于向作者提供指导,在发布文档之前必须删除这些文本。在此样式之后输入的段落将自动设置为正常(style=Body Text)。]
修订历史记录
日期 |
版本 |
描述 |
作者 |
<dd/mmm/yy> |
<x.x> |
<详细信息> |
<名称> |
|
|
|
|
|
|
|
|
|
|
|
|
目录
远景
[本文档的目的是收集、分析和定义<<系统名称>>的高级别需要和功能。着重于介绍项目干系人和目标用户需要的功能,以及这些需要存在的原因。<<系统名称>>如何满足这些需要的详细信息在用例和补充规范中有详细描述。注意:此远景模板尝试覆盖各种开发,范围从已获知市场需求而进行投机开发的收缩性薄膜包装产品,至按照合同为满足客户特定需求所开发的一次性系统。所以,“产品”和“系统”这些单词使用时不作仔细地区分,它们代表要开发的事物。我们期望文档自适器能将这些词的使用缩小到一个特定的应用中。]
[远景文档的简介提供整个文档的概述。它包括本远景文档的目的、范围、定义、首字母缩写、缩写、参考资料和概述。]
[指定本远景文档的目的。]
[简要描述本远景文档的范围、它与哪些项目关联,以及受本文档影响的所有其他方面。]
[本子节提供所有术语、首字母缩写和缩写的定义,这些术语、首字母缩写和缩写对于正确解释远景文档是必需的。可以通过引用项目的词汇表来提供此信息。]
[本子节提供一份在远景文档中的其他地方引用的所有文档的完整列表。每个文档都必须以标题、报告号(如果适用)、日期和出版单位特别标明。指定从哪些来源可以获得参考资料。本处信息可以通过引用附录或另一个文档的形式提供。]
[本子节描述远景文档的剩余部分包含哪些内容,并说明文档是如何组织的。]
[简要描述本项目符合的业务机会。]
[在本子节中,描述了现有系统或者业务环境的背景、目的和范围,包括一些可应用的,如应用的策略、当前系统的能力、涉及的项目干系人和所支持的问题。]
[在本子节中,描述了在业务和操作方面出现的一些需要得到更改的新环境或者需求。简要地标识一下提出与拒绝的更改和相关理由。如果已经完成了一些随机应变需求方面的行业研究,则可以引用它们。]
[提供总结本项目所解决问题的声明。 可以使用以下格式:]
问题来源 |
[描述问题] |
影响 |
[问题影响的项目干系人] |
问题的影响 |
[问题的影响是什么?] |
成功的解决方案是 |
[列出成功解决方案的一些主要益处] |
[提供概要声明,在最高级别总结产品计划在市场上找到的独一无二的位置。可以使用以下格式:]
用于 |
[目标客户] |
谁 |
[需要或机会的声明] |
(产品名称) |
是[产品类别] |
益处 |
[主要益处的声明;即有说服力的购买原因] |
不同之处 |
[主要竞争对手的替代产品] |
我们的产品 |
[主要差异化的声明] |
[产品或系统位置声明将系统的目的和项目的重要性传达给所有相关人员。]
[为了有效地提供满足项目干系人和用户实际需求的产品和服务,必须将所有项目干系人作为需求建模过程的一部分。您还必须确定系统的用户并确保该项目干系人团体可以充分地代表他们。本节提供项目所涉项目干系人和用户的概要信息,另外还包含了他们认为提供的解决方案针对的主要问题。本节不描述他们的特定请求或需求,因为这些内容在单独的项目干系人请求工件中已经包含。本节提供的是为何需要这些需求的背景和理由。]
[总结激发产品决策的关键市场人口统计信息。描述和定位目标市场段。估计市场大小和成长,方法是通过计算潜在用户的数量或者客户尝试满足需求(您的产品或增强性能也将满足这些需求)所花费的费用。复审主要行业趋势和技术。回答这些策略问题:
? 您的组织在这些市场中的声誉如何?
? 您希望它如何发展?
? 本产品或服务如何支持您的目标?]
[项目的开发会有众多存在利害关系的项目干系人,而并非所有这些人都是用户。提供这些非用户的项目干系人的摘要列表。(用户在 3.3 节中概述。) ]
名称 |
描述 |
职责 |
[命名项目干系人类型。] |
[简要描述项目干系人。] |
[就开发的系统总结项目干系人的主要职责;即他们作为项目干系人的利益。例如,该项目干系人: - 确保系统可维护 - 确保对于产品的功能会有市场需求 - 监视项目进度 - 批准资金] |
[提供所有已识别用户的摘要列表。]
名称 |
描述 |
职责 |
项目干系人 |
[命名用户类型。] |
[简要描述他们就系统而言代表什么。] |
[就开发的系统列出用户的主要职责;例如: - 捕获细节 - 生成报告 - 协同工作] |
[如果不是直接代表用户的,请确定哪个项目干系人负责代表该用户的利益。] |
[详述目标用户的工作环境。以下是一些建议:
完成该任务所涉及的人数? 该数目是否在变化?
任务周期有多长? 每个活动所用的时间是多少? 该数目是否在变化?
存在唯一的环境约束(移动中、在户外、飞行中等)吗?
今天使用了哪些系统平台? 将来的平台是?
哪些其他系统/应用程序也在使用中?您的系统是否需要与那些系统/应用程序集成吗?
在该位置可以包含业务模型的摘要以概述涉及的任务和业务工作者等。]
[在此处描述系统中的每个项目干系人,方法是对每个项目干系人填写下表。请记住项目干系人类型可以分成用户、部门和技术开发人员。一个全面的概要文件将对每种项目干系人类型涵盖以下主题。]
代表 |
[谁是项目的项目干系人代表?(若其他地方有记录则可选) 此处需要写的是姓名。] |
描述 |
[项目干系人类型的简要描述。] |
类型 |
[对项目干系人的专长、技术背景、资深程度进行认定 - 即精英、业务、专家、普通用户等。] |
职责 |
[就开发的系统列出项目干系人的主要职责 - 即他们作为项目干系人的利益。] |
成功条件 |
[项目干系人如何定义成功? 项目干系人如何得到奖励?] |
涉及人员 |
[在项目中如何涉及项目干系人?尽可能与 Rational Unified Process 角色相关 - 即“需求复审员”等。] |
可交付产品 |
[是否还有一些项目干系人要求的其他可交付成果?这些可能是项目可交付成果或开发中的系统的输出。] |
注释/问题 |
[在此处描述妨碍项目成功的问题和任何其他相关信息。] |
[在此处描述系统中的每个唯一的用户,方法是对每个用户类型填写下表。请记住用户类型也一样可以分为精英和新手。例如:精英可能需要能够提供跨平台支持的复杂而灵活的工具,而新手可能需要便于使用、用户友好的工具。全面的资源模型涵盖了以下关于每种用户的主题。]
代表 |
[谁是项目的用户代表?(若其他地方有记录则可选)这通常指代表一组代表用户的项目干系人,例如 Stakeholder: Stakeholder1。] |
描述 |
[用户类型的简要描述。] |
类型 |
[对用户的专长、技术背景、资深程度进行认定 - 即精英、普通用户等。] |
职责 |
[就开发的系统列出用户的主要职责?即获取详细信息、生成报告、协调工作等。] |
成功条件 |
[用户如何定义成功? 用户如何得到奖励?] |
涉及人员 |
[在项目中如何涉及用户?尽可能与 Rational Unified Process 角色有关 - 即“需求复审员”等。] |
可交付产品 |
[是否有任何用户产生的可交付工件,如有的话是提供给谁的?] |
注释/问题 |
[在此处描述妨碍项目成功的问题和任何其他相关信息。这将包括使用户工作更方便或更困难的趋势。] |
[列出项目干系人提出的与现有解决方案相关的关键问题。针对每个问题阐明以下事项:
? 这个问题的原因是什么?
? 现在如何解决?
? 项目干系人或用户需要什么解决方案?]
[了解项目干系人或用户对解决每个问题所置的相对重要性很重要。排名和表决技术表明了必须解决的问题和希望针对的事项。
填写下表。当使用 Rational RequisitePro 来记录需求时,该表可能是来自该工具的摘要或报告。]
需求 |
优先级 |
问题 |
当前解决方案 |
建议解决方案 |
|
广播报文 |
|
|
|
|
|
[确定项目干系人认为可用的替代方案。这可以包括购买竞争对手的产品、构建自行开发的解决方案或者只是维持现行状态。列出存在或可能成为可用的所有已知的竞争对手选项。包含项目干系人或用户发现的每个竞争对手的主要优势和弱点。]
[在本子节中,描述了提出且进行考虑的产品的备选方案及相关行业研究。]
[本节提供产品功能、与其他系统的接口以及系统配置的高级别视图。]
[远景文档的这一子节将透视图中的产品放在其他相关产品和用户环境中。如果产品独立并且完全自包含,请在此处声明。如果产品是大型系统的组件,则该子节要说明这些系统如何交互并且要确定系统之间的相关接口。显示大型系统主要组件、互连和外部接口的一个比较简单的方法是使用框图。
确定操作,组织和发展等方面对项目干系人和其他系统的影响。]
[总结产品将提供的主要好处和功能。例如客户支持系统的远景文档可以使用本部分来解决问题记录、传递和状态报告,而不用提到每个功能所要求的详细信息量。
对功能加以组织,从而使列表对客户或者对于第一次阅读该文档的其他读者可以理解。用一个简单的表列出主要好处及其支持功能可能就够了。例如:]
表 4-1 客户支持系统
客户好处 |
支持功能 |
新支持人员可以快速上手。 |
知识库可以辅助支持人员快速识别已知修订和变通办法。 |
由于没有破解失败,客户满意度得到提高。 |
在整个解决过程中问题一一得到记录、归类和跟踪。对于任何随时间推移而发生的事情进行自动通知。 |
管理层可以识别问题区域并调整人员工作负载。 |
趋势和分发报告提供对问题状态的高级别复审。 |
分散在各处的支持团队可以携手工作来解决问题。 |
复制服务器允许当前数据库信息在整个企业中共享。 |
客户可以帮助他们自己降低支持成本并缩短响应时间。 |
知识库在整个因特网中都可用。包含超文本搜索功能和图形查询引擎。 |
[列出影响远景文档中所声明功能的所有因素。列出一旦更改就会改变远景文档的假定。例如,远景是建立在一些大公司的环境之中,一旦那个环境中有什么更改的话,那么远景也需要更改。例如,这包括经济、政治、法律或者环境因素。远景还与设备,软件或其他系统组件或者一些特别的专家或者技术的可用性相关。]
[对于销售给外部客户的产品和许多公司内的系统,成本和定价问题会直接影响系统的定义和实施。在本节中记录任何相关的成本和定价约束。例如分发成本(软盘数、CD-ROM 数、CD 母盘制作)或已销售商品的其他成本约束(手册、包装)可能是与产品的成功有关或无关的材料,这取决于系统的性质。]
[许可和安装问题也会直接影响开发工作。例如,如果需要支持访问控制、序列化、密码安全性或网络许可,就会产生附加的系统需求,在开发工作中必须考虑到这些需求。
安装需求可能还会影响软件构造或产生单独安装软件的需要。物理系统也要满足特殊安装需求,例如,如果它们受到特别安全或者生存的约束。]
[列出并简要描述产品功能。功能是系统为了向用户提供好处所必需的高级别能力。它还描述了与每个特性相关的性能特征 - 用一些维来说事情办得如何好:例如,用时间维,响应时间和办事效率。“特性”一词并没有被赋予任何特别的重要性,您可以选择“能力”或者“功能”,所有这些都描述了系统或者产品必须要做的事情。每种功能都是外部要求的服务,它们通常需要进行一系列输入以获得期望的结果。例如问题跟踪系统的功能可以是提供趋势报告的能力。当用例模型形成时,请更新引用用例的描述。
因为远景文档由范围广泛的所涉人员复审,所以详细级别需要达到让每个人都理解的通用程度。然而必须有足够的详细信息才能向团队提供创建用例模型所需的信息。
为了有效地管理复杂性,我们建议对于任何新系统或对于现有系统的增量,能力被抽象到一个足够高的级别,在该级别下将生成 25-99 个功能。这些功能为产品定义、范围管理和工程管理提供基础。每个特性都可以通过用例模型、自然语言或说话扩展得更详细,如果项目选择不产生用例。
在本节中每个特性都会让用户、操作员或其他外部系统从外部观察到。这些特性应该包含功能描述以及必须碰到的任何相关可用性问题。以下指南适用于:
? 避开设计。将功能描述保持在一个通用的级别。重点放在如何实施需要的功能以及为何需要(而不是如何需要)。
? 如果使用的是 Rational RequisitePro 工具包,需要选择所有内容作为类型需求,从而可以方便地引用和跟踪。]
[描述了一些产品或者系统的使用,它们说明了系统与其用户、环境和/或其他系统之间的一些值得关注或重要的交互。]
[在本子节中,从概念上描述了如何提供支持,包括对支持组织、设备、维护周期和供应安排的描述。]
[声明任何设计约束、外部约束或其他依赖关系。]
[针对性能、健壮性、容错、可用性以及功能集内没有包含的类似特性定义质量范围。]
[定义不同系统功能的优先级。]
[在高级别列出适用标准、硬件或平台需求、性能需求和环境需求。]
[列出产品必须符合的所有标准。可以包括法律和法规(FDA、UCC)、通信标准(TCP/IP、ISDN)、平台兼容性标准(Windows、UNIX 等)以及质量和安全标准(UL、ISO、CMM)。]
[对于软件系统开发,定义支持应用程序所需的所有系统需求。可以包括受支持的主机操作系统和网络平台、配置、内存、外围设备和配套软件。]
[使用本节详述性能需求。性能事项可以包括用户负载因子、带宽或通信容量、吞吐量、准确性以及在各种负载条件下的可靠性或响应时间等。]
[根据需要详述环境需求。对于物理系统,环境事项可能包括温度、电击、湿度和辐射等。对于软件系统,环境因素可能包括使用条件、用户环境、资源可用性、维护事项以及错误处理和恢复。]
[如果有任何物理需求,例如重量或者质量及大小限制,在本子节中对它们进行描述。]
[本节描述支持成功的系统部署所必须开发的文档。]
[描述用户手册的目的和内容。讨论所需的长度、详细级别、是否需要索引、术语词汇表、教程及参考手册策略等。还必须确定格式和打印约束。]
[许多系统提供联机帮助来辅助用户。这些系统的性质是不寻常的,因为它们将编程的各个方面(超链接等)与技术撰写(例如组织和演示)都组合在一起。许多人都发现联机帮助系统的开发是项目内的项目,该项目得益于提前的范围管理和计划活动。]
[对于完整的解决方案来说,包含安装说明和配置准则的文档是非常重要的。同样自述文件通常也作为标准组件包含在内。自述文件可以包含『本发行版的新增内容』一节,还可以包含与先前发行版兼容性事项的讨论。大多数用户还希望在自述文件中有定义任何已知错误和变通办法的内容。]
[当今系统尽力提供一致的外观,首先通过产品的包装,然后通过安装菜单、闪屏、帮助系统、GUI 对话框等来体现出这一点。本节定义了要在系统中加入的标注需求和类型。例如版权和专利声明、公司徽标、标准化的图标以及其他图形元素等。]
[功能就是一些给定的属性,它们可以用来评估、跟踪和管理为实施而提供的产品项并对它们划分优先级。所有需求类型和属性都在需求管理计划中进行概述,然而您可能希望列出并简要描述已选功能的属性。以下子节表示一组建议的功能属性。]
[在由项目管理团队协商和复审之后设置。在定义项目基线期间跟踪进度。]
已建议 |
[用来描述讨论中的功能,但这些功能还没有通过“官方渠道”复审和接受,例如由项目团队、产品管理和用户或客户团体的代表组成的工作组。] |
已核准 |
[能力被认为是有用和可行的,并已通过官方渠道核准实施。] |
已合并 |
[功能已在特定时间点合并到产品基线中。] |
[由营销部门、产品经理或业务分析员设置。所有的需求并不是以相同的优先级创建。按照需求对于用户的相对好处对需求进行评级使客户、分析人员和开发团队成员之间能够进行交流。管理范围和确定开发优先级时使用。]
关键 |
[必需的功能。未能实施意味着系统将无法满足客户需求。所有的关键功能都必须在发行版中实施,否则进度安排将落后。] |
重要 |
[对于大部分用户的系统,有效性和效率是很重要的特性。无法通过其他某种方式很容易地提供该功能。未包含一项重要功能可能会影响客户或用户满意度,甚至是影响收入,但发行版不会由于缺少任何重要功能而延迟。] |
有用 |
[支持较少典型用途的功能部件会用得比较少,或者可以使用合理、有效的变通办法代替这些功能部件。未在发行版中包含此类功能项时,不会对收入或客户满意度产生明显的影响。] |
[由开发团队设置。因为某些功能需要比其他功能更多的时间和资源,因此估计团队或人员工作周数,或是测量和工作关联的量(例如,需要的代码行数或软件功能点数),就是评估复杂性、设置在给定时间范围内哪些功能可以实现、哪些功能无法实现这一期望值的最好方式。在管理范围和确定开发优先级时使用。]
[由开发团队根据项目将经历负面事件的可能性来设置,负面事件包括成本过高、进度安排延迟甚至取消等。大多数的项目经理认为将风险分类为高、中和低已经足够,虽然风险还可以进一步地细分。风险通常可以通过评测项目团队进度安排估计情况的不确定性(范围)来进行间接的评估。]
[由分析人员和开发团队根据功能发生更改的可能性或团队对功能的理解发生变化的可能性而设置。用于帮助设定开发优先级和确定那些需要进行进一步的引发的项。]
[记录功能首次出现的预期产品版本。该字段可以用来将远景文档的功能部件分配到特定的基线发行版。在与状态字段结合使用时,团队可以建议、记录和讨论发行版的各种功能,而无需将它们落实到开发中。只有“状态”设置为“已合并”且定义了“目标发行版”的功能才会被实施。当进行范围管理时,“目标发行版版本号”可以增加,从而该项仍然会在远景文档中,但是会安排到之后的发行版中。]
[在许多项目中,功能部件会指定给“功能部件团队”,这些团队负责进一步引发、捕获、优化需求和实施。这个简单的下拉列表会帮助项目团队的每个人更好地理解职责。]
[这个文本字段用于跟踪所请求的功能的来源。需求由于特定的理由而存在。此字段记录说明或对说明的引用。例如可以引用产品需求规范的页码和行号,也可以引用重要客户复审视频上的分钟标记。]