产品视图蓝图.docx
《产品视图蓝图.docx》由会员分享，可在线阅读，更多相关《产品视图蓝图.docx（12页珍藏版）》请在冰豆网上搜索。
产品视图蓝图
<项目名称>
前景
状态
o草稿
标识号
BNSW-PRJ-项目名缩写-RD-VIEW
ü初始版
当前版本
V1.0
o修订版
发布日期
2003-05-31
模板编号
BNSW-TEMP-RD-VIEW
密级
o无密级ü秘密o绝密
[注：
以下提供的模板用于博恩软件公司。
其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。
按此样式输入的段落将被自动设置为普通样式（样式=BodyText）。
]
[要定制MicrosoftWord中的自动字段（选中时显示灰色背景），请选择文件>属性，然后将标题、主题和公司等字段替换为此文档的相应信息。
关闭该对话框后，通过选择编辑>全选（或Ctrl-A）并按F9，或只是在字段上单击并按F9，可以在整个文档中更新自动字段。
对于页眉和页脚，这一操作必须单独进行。
按Alt-F9，将在显示字段名称和字段内容之间切换。
有关字段处理的详细信息，请参见Word帮助。
]
修订文档历史记录
日期
版本
说明
作者
2003-05-12
0.1
提供《需求视图》模板草稿
蒋程
2003-05-23
0.2
提供模板编号，对首页和日期格式作了修改
蒋程
前景
1.简介
[此文档的目的是收集、分析和定义<系统名>的高层次需求和特性。
它侧重于涉众和目标用户所需的功能以及这些需要存在的原因。
<系统名>如何满足这些需要的详细情况记录在用例和补充规约中。
]
[前景文档的简介应提供整个文档的概述。
它应包括此前景文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。
]
2.目的
[阐明此前景文档的目的。
]
2.1范围
[简要说明此前景文档的范围：
它的相关项目，以及受到此文档影响的任何其他事物。
]
2.2名词释义
[本小节应提供正确解释此前景文档所需的全部术语的定义、首字母缩写词和缩略语。
这些信息可以通过引用项目词汇表来提供。
]
2.3参考资料
[本小节应完整列出此前景文档中其他部分所引用的任何文档。
每个文档应标有标题、报告号（如果适用）、日期和出版单位。
列出可从中获取这些参考资料的来源。
这些信息可以通过引用附录或其他文档来提供。
]
2.4概述
[此小节应说明前景文档中其他部分所包含的内容，并解释此文档的组织方式。
]
3.定位
3.1商机
[简要说明此项目面临的商机。
]
3.2问题说明
[提供一段说明，总结此项目正在解决的问题。
可以采用以下格式：
]
问题是
[对问题进行说明]
影响
[问题影响的涉众]
问题的后果
[该问题会导致什么后果]
成功的解决方案
[应列出成功解决方案的一些主要优点]
3.3产品定位说明
[提供一段总体说明，高度概括产品将要在市场上占据的独特位置。
可以采用以下格式：
]
针对于
[目标客户]
谁
[说明需要或机会]
该（产品名）
属于[产品类别]
功能
[陈述主要优点，即促使人们购买的原因]
不同于
[主要的竞争产品]
我们的产品
[陈述主要的区别]
[产品定位说明用于向所有相关人员传达应用程序的目的和项目的重要性。
]
4.涉众和用户说明
[为有效地提供可满足涉众及用户实际需要的产品和服务，有必要在需求建模流程中确定并包括所有涉众。
您还必须确定系统的用户，确保涉众群体能够充分代表这些用户。
本节提供参与项目的涉众和用户的简介，以及他们希望通过所提议的解决方案来解决的关键问题。
这里并不说明他们的具体请求或需求，因为这些内容将单独在涉众请求工件中记录。
此处只提供之所以存在这些需求的背景和原因。
]
4.1消费者统计数据
[总结促使您作出产品决策的关键消费者统计数据。
说明并定位目标细分市场。
估计市场的大小和增长率，估计的依据可以是潜在用户的数量，也可以是您的客户为满足您的产品或改进将要满足的需求所用资金的多少。
了解行业大势和主流技术。
回答以下战略性问题：
•您的组织在这些市场的声誉如何？
•您想获得什么样的声誉？
•该产品或服务将如何支持您实现这些目标？
]
4.2涉众概要
[提供所有已确定涉众的一览表。
]
名称
表示
角色
指明涉众类型。
简要说明他们在开发方面所表示的内容。
[简要说明他们在开发中的作用。
例如，确保某项工作顺利完成。
]
4.3用户概要
[提供所有已确定用户的一览表。
]
名称
说明
涉众
指明用户类型
[简要说明他们在系统方面所表示的内容。
]
[明确用户如何由涉众来代表。
例如，由涉众1.1来代表
4.4用户环境
[详细说明目标用户的工作环境。
以下是几项建议：
该任务由多少人来完成？
是否总在变化？
一个任务周期需要多长时间？
执行每项活动要用多长时间？
是否总在变化？
是否有特殊的环境约束：
移动、户外、乘机旅行等？
目前使用的是哪些系统平台？
以后会使用哪些平台？
还在使用哪些应用程序？
您的应用程序是否需要和这些应用程序集成？
在此处可以从业务模型中摘录一些内容来概述所涉及的任务和角色等等。
]
4.5涉众简档
[通过在下表中填写各涉众的相关信息来说明系统中的各个涉众。
要注意的是，涉众可能会有许多不同的类型，例如用户、策略部门和技术开发人员。
详尽的简档应包括各种涉众在以下方面的信息：
]
4.5.1<涉众名>
代表
[谁是此项目的涉众代表？
（如在他处已作记录，则此处为可选。
）此处只需填写姓名。
]
说明
[对涉众类型的简要说明。
]
类型
[介绍涉众的技能特长、技术背景和熟练程度（即权威用户、业务用户、专家用户、初级用户等）]
职责
[列出涉众对所开发的系统负有的关键职责，即他们作为涉众的利益。
]
成功标准
[该涉众如何界定成功？
该涉众如何得到回报？
]
参与
[该涉众如何参与此项目？
尽可能和RUP角色（如需求复审员）建立联系。
]
可交付工件
[涉众是否还需要其他的可交付工件？
这些工件可以是项目可交付工件，也可以是正在开发的系统的输出。
]
意见/问题
[在此处列出会阻碍成功的问题以及任何其他相关信息。
]
4.6用户简档
[通过在下表中填写各用户类型的相关信息来说明系统的各种独特用户。
要注意的是，用户可能有许多不同的类型，例如权威用户和入门用户。
权威用户可能会需要复杂、灵活并具备跨平台支持的工具；而入门用户则会需要使用方便、界面友好的工具。
详尽的简档应包括各种用户在以下方面的信息：
]
4.6.1<用户名>
代表
[谁是此项目的用户代表？
（如在他处已作记录，则此处为可选。
）通常指的是代表一组用户的涉众，例如涉众：
涉众1。
]
说明
[对该用户类型的简要说明。
]
类型
[介绍该用户的技能特长、技术背景和熟练程度（即权威用户、初级用户等）。
]
职责
[列出该用户对所开发的系统负有的关键职责，如记录详细信息、撰写报告、协调工作等。
]
成功标准
[该用户如何界定成功？
该用户如何得到回报？
]
参与
[该用户如何参与此项目？
尽可能和RUP角色（如需求复审员）建立联系。
]
可交付工件
[是否有该用户生成的可交付工件？
如果有，是为谁生成的？
]
意见/问题
[在此处列出会阻碍成功的问题以及任何其他相关信息。
其中还需指明将如何影响用户的工作，即：
让工作变得简单还是困难。
]
4.7关键的涉众/用户需要
[列出涉众认为现有解决方案存在的关键问题。
对于列出的每个问题，需澄清以下要点：
•为什么会出现这一问题？
•目前如何解决该问题？
•涉众需要什么样的解决方案？
]
[务必要了解涉众或用户对解决各个问题的相对重视程度。
分级和累积投票方法表明，必须解决的问题与涉众或用户希望解决的问题大有不同。
填写下表-如果是使用ReqPro来记录需要，这可能就是该工具所生成的摘录或报告。
]
需要
优先级
关注的要点
目前的解决方案
提议的解决方案
广播消息
4.8备选方案和竞争
[确定涉众认为可以使用的备选方案。
其中可能包括购买竞争对手的产品、自行设计解决方案，或者仅维持现状。
列出已经存在或潜在的竞争产品。
列出涉众认为各种竞争对手具有的主要优缺点。
]
4.8.1<一个竞争对手>
4.8.2<另一个竞争对手>
5.产品概述
[此节高度概括产品的功能、与其他应用程序的接口以及系统配置。
此节通常要包括以下三个小节：
•产品总体效果
•产品功能
•假设与依赖关系]
5.1产品总体效果
[前景文档的这一小节应将该产品放在其他相关产品环境和用户环境中进行介绍。
如果该产品自成一体，应在此处说明。
如果该产品是较大系统的构件，此小节则应说明这些系统如何进行交互，并确定系统之间的相关接口。
要显示较大系统的主要构件、互连情况和外部接口，一种简单的方法就是通过框图来表示。
]
5.2功能摘要
[总结该产品将提供的主要优点和特性。
例如，一个客户支持系统的前景文档可能会利用此部分来讨论存在问题的记录、消息传递和状态报告，而不必涉及每个功能的细节。
对功能加以组织，使客户或初次阅读该文档的其他人能够理解此功能列表。
下面的简表列出了主要优点及支持的特性，该示例应足以说明问题。
例如：
]
客户支持系统
客户利益
支持特性
新的支持人员能够很快地步入正轨。
知识库可协助支持人员迅速地找到已知的解决方法和变通方法。
因为考虑周全而提高了客户满意度。
在整个解决过程中可将问题一一列出，并进行分类和跟踪。
一出现老化问题就自动发出通知。
管理人员能够发现存在问题的领域并估计人员的工作量。
趋势及分布报告可从较高的角度来审查问题的状态。
分散的支持团队能够协同解决问题。
复制服务器使当前的数据库信息可以在整个企业的范围内共享
客户能够自行解决一些问题，从而降低了支持成本并缩短了答复时间。
可以通过Internet来访问知识库。
包括超文本搜索功能和图形查询引擎
5.3假设与依赖关系
[列出会影响前景文档中所述特性的所有因素。
列出其变更将引起前景文档随之变化的假设。
例如，有这样一项假设：
将为该软件产品指定的硬件提供特定的操作系统。
但如果没有提供该操作系统，就将需要更改前景文档。
]
5.4成本与定价
[对于向外部客户发售的产品和许多内部的应用程序，成本和定价问题会直接影响到应用程序的定义和施。
在此节中，应记录任何相关的成本或定价约束。
例如，分销成本（软盘的数量、光盘的数量、CD制作）或其他商品销售的成本约束（手册、包装）可能对于项目的成功非常重要，也可能无关紧要，这取决于应用程序的性质。
]
5.5许可与安装
[许可和安装问题也可能直接影响到开发工作。
例如，如果需要支持串行化、口令安全或网络许可，则会增加在开发工作中必须予以考虑的系统需求。
安装需求还可能会影响到编码，或需要单独安装的软件。
]
6.产品特性
[列出并简述产品的特性。
特性是为让用户获益而必须具备的高级系统功能。
每一项特性都是外部所需的服务，它通常需要一系列输入来实现预期的结果。
例如，问题跟踪系统的特性是能够提供趋势报告。
当用例模型成型后，更新这里的说明以指代用例。
由于前景文档将由各种各样的相关人员来复审，所以不应太过详细，应让所有人对此都有大致的了解。
但是，应该向团队提供他们创建用例模型所需的必要详细信息。
要有效地管理应用程序的复杂性，对于任何新系统或对现有系统的增量部分，我们建议将功能提炼到较高的程度，这样25到99项特性较为合理。
这些特性为产品定义、规模管理和项目管理提供了基础。
每项特性的详细程度可以使用用例模型中得到较深入的扩展。
贯穿此节的始终，都应能让用户、操作人员或其他外部系统从外部觉察到每项特性。
这些特性应包括功能性的说明以及必须考虑的任何相关的可用性问题。
以下原则将会适用：
•避免设计。
使特性说明保持一定的概括程度。
侧重于说明所需的功能以及为什么要（而不是如何）实现这些功能。
•如果您使用的是RationalRequisite工具，应将需求类型选择为“所有”，以便于引用和跟踪。
]
6.1<一个特性>
6.2<另一个特性>
7.约束
[记录所有设计约束、外部约束或其他依赖关系。
]
8.质量范围
[定义性能、强壮性、容错、可用性以及特性集内没有记录的类似特征的质量范围。
]
9.优先级
[定义不同系统特性的优先级。
]
10.其他产品需求
[在较高层次上列出适用的标准、硬件或平台需求、性能需求以及环境需求。
]
10.1适用的标准
[列出产品必须符合的所有标准。
其中可能包括法律和法规（FDA、UCC）标准、通讯标准（TCP/IP、ISDN）、平台一致性标准（Windows、Unix等）以及质量和安全标准（UL、ISO、CMM）。
]
10.2系统需求
[确定支持该应用程序所必需的任何系统需求。
其中可能包括所支持的主机操作系统及网络平台、配置、内存、外围设备和配套软件。
]
10.3性能需求
[本节用于详细说明性能需求。
性能问题可能包括在各种负载条件下的用户负载因素、带宽或通信容量、吞吐量、精确度以及可靠性或响应时间。
]
10.4环境需求
[根据需要详细说明环境需求。
对于基于硬件的系统，环境因素可以包括温度、振荡、湿度、辐射等。
对于软件应用系统，环境因素可以包括使用条件、用户环境、资源可用性、维护问题、错误处理和恢复。
]
11.文档需求
[此节说明为支持成功部署应用程序而必须制作的文档。
]
11.1用户手册
[说明用户手册的目的和内容。
讨论预期长度、详细程度，是否需要索引、词汇表、教程与参考手册策略等。
还应确定格式和打印约束条件。
]
11.2联机帮助
[许多应用程序提供了联机帮助系统来协助用户。
这些系统的性质对于应用程序开发来说独特的，因为它们综合了编程（如超链接）和技术写作（组织、演示）的各个方面。
许多人发现联机帮助系统的开发本身就是一个受益于先期规模管理和计划活动的项目。
]
11.3安装指南、配置文件、自述文件
[在提供全套的解决方案时，提供包括安装说明和配置指南的文档是非常重要的。
此外，自述文件通常也要作为一个标准构件包括在内。
自述文件可以包括一个“本发布版中的新特性”部分，并讨论与以前发布版的兼容性问题。
多数用户也希望在自述文件中列出任何已知的错误和变通方法。
]
11.4标签与包装
[目前最先进的应用程序从产品包装开始就提供了一致的外观，这种一致还体现在安装菜单、启动屏幕、帮助系统、GUI对话框等等。
此节定义对标签的需求和和标签类型，以便合并到代码中。
举例来说，标签和包装涉及版权和专利声明、公司徽标、标准化的图标以及其他图形元素。
]
12.附录1–特性属性
[为了对提议进行实施的产品项进行评估、跟踪、确定优先级和管理，应该为特性指定属性。
所有需求类型和属性都应在需求管理计划中列出，但最好列出并简要说明已选中的特性的属性。
以下小节建议了一组功能属性。
]
12.1状态
[在经过项目管理团队的商谈和复审后设置。
用于在确立项目基线的过程中对进度进行跟踪。
]
已提出
[用于说明正在进行讨论但尚未经过“正式渠道”（例如由项目团队、产品管理部门和用户或客户群的代表所组成的工作组）复审和验收的特性。
]
已批准
[被认为是有用、可行并已获得正式渠道批准，准备实施的功能。
]
已并入
[在特定时间点并入产品基线中的特性。
]
12.2利益
[由市场经理、产品经理或业务分析员设置。
并非所有需求都同等重要。
通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。
用于管理规模并确定开发的优先级。
]
关键
[必不可少的特性。
不满足这些需求就无法使系统满足客户的需要。
所有关键特性都必须在发布时实现，否则将错过预定的发布时间。
]
重要
[对于系统在大多数应用中的有效性及效率都较为重要的特性。
很难通过其他方式来实现这方面的功能。
如果遗漏了某项重要特性，可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少某一项重要特性而延期。
]
有用
[有些特性在不太典型的应用中比较有用，或者可以合理而有效地实现其替代特性，这些特性的使用次数将会相对较少。
即使发布版中没有包括某一项这样的特性，也不会对收入或客户满意度造成严重的影响。
]
12.3工作量
[由开发团队设置。
由于有些特性所需的时间和资源多于其他特性，所以举例来说，如果要评测复杂程度并预计在给定时间范围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数。
用于管理规模并确定开发的优先级。
]
12.4风险
[由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚或是项目取消。
虽然可以对风险级别进行细分，但大多数项目经理都发现把风险归类为高、中、低就足够了。
通过评测项目团队进度估计的不确定性（范围），一般都可以间接地对风险进行评估。
]
12.5稳定性
[由分析员和开发团队设置，设置的依据是特性发生变化的可能性或团队对特性的理解发生变化的可能性。
用于协助确定开发优先级并确定下一步需要继续获取哪些项。
]
12.6目标发布版
[记录将首次包括指定特性的产品版本。
该字段可用于将前景文档中的特性分配给特定的基线发布版。
如果将其与状态字段结合，您的团队就可以提出、记录和讨论发布版的各种特性，而不用对其进行开发。
只有状态被设置为“已并入”且目标发布版已确定的特性才将被实施。
当进行规模管理时，可以增加目标发布版号，这样该项特性虽然仍保留在前景文档中，但将安排在以后发布。
12.7职责分配
[在许多项目中，特性会被分配给各个“特性团队”，它们负责进一步获取需求，并编写软件需求和实施方案。
这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。
]
12.8原因
[此文本字段用于跟踪所需特性的来源。
需求的提出总会有一定的原因。
此字段记录相应的解释或对相应解释的引用。
例如，引用可以是产品需求规约的页码及行号，或者是一次重要的客户访谈录像的记录标记。
]
升级会员 