<项目名称>
业务前景
版本 <1.0>
[注:以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体(样式=InfoBlue)显示的文本,它们用于向作者提供指导,在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式(样式=正文)。]
修订版历史
|
日期 |
版本 |
说明 |
作者 |
|
<日/月/年> |
<x.x> |
<详细信息> |
<姓名> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目录
业务前景
[业务前景的简介应提供整个文档的概述。它应包括此业务前景的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]
[阐明此业务前景文档的目的。]
[简要说明此业务前景文档的范围:它的相关项目,以及受到此文档影响的任何其他事物。]
[本小节应提供正确理解此业务前景文档所需的全部术语、首字母缩写词和缩略语的定义。这些信息可以通过引用项目词汇表来提供。]
[本小节应完整地列出此业务前景中其他部分所引用的任何文档。每个文档应标有标题、报告号(如果适用)、日期和发布组织。列出可从中获取这些引用的来源。这些信息可以通过引用附录或其他文档来提供。]
[本小节应说明此业务前景中其他部分所包含的内容,并解释此文档的组织方式。]
[简要说明此项目面临的业务机会。]
[提供一段说明,总结此项目正在解决问题。可以采用以下格式:]
|
问题是 |
[描述问题] |
|
影响 |
[该问题所影响的涉众] |
|
其后果是 |
[该问题会导致什么后果] |
|
成功的解决方案是 |
[列出成功解决方案的一些重要优点] |
[提供一段总体说明,高度概括产品将要在市场上占据的独特位置。可以采用以下格式:]
|
针对于 |
[目标客户] |
|
谁 |
[说明需要或机会] |
|
该(产品名) |
属于[产品类别] |
|
因为 |
[陈述重要优点,即促使人们购买的原因] |
|
不同于 |
[主要的竞争产品] |
|
我们的产品 |
[陈述主要的区别] |
[产品定位说明向所有的相关人员传达应用程序的目的和项目的重要性。]
[为有效地提供可满足涉众及用户实际需要的产品和服务,有必要在需求建模流程中确定并包括所有涉众。您还必须确定系统的用户,确保涉众群能够充分代表这些用户。本节提供参与项目的涉众和用户的简介,以及他们希望通过所提议的解决方案来解决的关键问题。这里并不说明他们的具体请求或需求,因为这些内容将单独在涉众请求工件中记录。此处所提供的只是这些需求存在的背景和原因。]
[总结促使您作出产品决策的关键市场统计数据。说明并定位目标市场区段。估计市场的大小和增长率,估计的依据可以是潜在用户的数量,也可以是您的客户为满足您的产品或改进将要满足的需求所花费的金额。了解主要的行业趋势和技术。回答以下战略性问题:
• 您的组织在这些市场的声誉如何?
• 您想获得什么样的声誉?
• 该产品或服务将如何支持您实现这些目标?]
[提供所有已确定涉众的一览表。]
|
名称 |
表示 |
作用 |
|
列出涉众类型的名称。 |
简要说明他们在开发方面所表示的内容。 |
[简要说明他们在开发中的作用。 例如,确保。] |
[提供所有已确定用户的一览表。]
|
名称 |
说明 |
涉众 |
|
列出用户类型的名称 |
[简要说明他们在系统方面所表示的内容。] |
[列出代表用户的涉众。 例如,由涉众 1.1 来代表 |
[详细说明目标用户的工作环境。以下是几项建议:
该任务由多少人来完成?这是否在变化?
一个任务周期需要多长时间?执行每项活动要用多少时间?这是否在变化?
是否有特殊的环境约束:移动、户外、乘飞机旅行等?
目前使用的是哪些系统平台?以后会使用哪些平台?
正在使用哪些其他的应用程序?您的应用程序是否需要和这些应用程序集成?]
[通过在下表中填写各涉众的相关信息来说明系统中的各个涉众。要注意的是,涉众可能会有许多不同的类型,例如用户、策略部门和技术开发人员。详尽的简档应包括各种涉众在以下方面的信息:]
|
代表 |
[谁是此项目的涉众代表?(如何在其他地方有记录,则在此处为可选。)此处只需填写姓名。] |
|
说明 |
[对涉众类型的简要说明。] |
|
类型 |
[介绍涉众的技能特长、技术背景和熟练程度(即权威用户、业务用户、专家用户、初级用户等)] |
|
职责 |
[列出涉众对所开发的系统负有的关键职责,即他们作为涉众的利益。] |
|
成功标准 |
[该涉众对成功的定义是什么? 如何向该涉众给予回报?] |
|
参与 |
[该涉众如何参与此项目?尽可能地和 RUP 角色建立联系,例如需求复审员。] |
|
可交付工件 |
[涉众是否还需要其他的可交付工件?这些工件可以是项目可交付工件,也可以是正在开发的系统的输出。] |
|
意见/问题 |
[在此处列出会阻碍成功的问题以及任何其他相关信息。] |
[通过在下表中填写各用户类型的相关信息来说明系统的各种独特用户。详尽的简档应包括各种用户在以下方面的信息:]
|
代表 |
[谁是此项目的用户代表?(如果在其他地方有记录,则在此处为可选。)它通常是指代表一组用户的涉众,例如涉众:涉众 1。] |
|
说明 |
[对该客户类型的简要说明。] |
|
类型 |
[介绍该客户的技能特长、技术背景和熟练程度(即权威用户、初级用户等)] |
|
职责 |
[列出该用户对所开发的系统负有的关键职责,即记录客户的详细信息,生成报告,协调工作等。] |
|
成功标准 |
[该客户对成功的定义是什么? 如何向该客户给予回报?] |
|
参与 |
[该客户如何参与此项目?尽可能地和 RUP 角色建立联系,例如需求复审员。] |
|
可交付工件 |
[是否有该客户生成的可交付工件?如果有,是为谁生成的?] |
|
意见/问题 |
[在此处列出会阻碍成功的问题以及任何其他相关信息。 其中需包括将使该客户的工作变得更容易或更困难的趋势。] |
[列出涉众认为现有解决方案存在的关键问题。对于列出的每个问题,需澄清以下要点:
• 为什么会出现这一问题?
• 目前如何解决该问题?
• 用户需要什么样的解决方案?]
[务必要了解涉众对解决各个问题的相对重视程度。分级和累计投票技术表明,必须根据他们所关注的要点来解决问题。
填写下表 - 如果是使用 ReqPro 来记录需要,它就可能是该工具中的摘录或报告。]
|
需求 |
优先级 |
关注的要点 |
目前的解决方案 |
提议的解决方案 |
|
|
广播消息 |
|
|
|
|
|
[确定涉众认为可以使用的备选方案。其中可能包括购买竞争对手的产品、自行构建解决方案,或者仅维持现状。列出已经存在或可能会提供的竞争产品。列出涉众认为各种竞争产品具有的主要优缺点。]
[记录下所有的设计约束、外部约束或其他依赖关系。]
[定义性能、强壮性、容错、可用性以及业务工程目标中没有记录的类似特征的质量范围。]
[确定不同目标的优先级。]
[在高层次上列出适用的标准、硬件或平台需求、性能需求以及环境需求。]
[列出业务必须符合的所有标准。 其中可能包括法律和法规(FDA、UCC)标准、通讯标准(TCP/IP、ISDN)、平台一致性标准(Windows、Unix 等)以及质量和安全标准(UL、ISO、CMM)。]
[确定支持该应用程序所必需的任何系统需求。其中可能包括所支持的主机操作系统及网络平台、配置、内存、外围设备和配套软件。]
[本节用于详细说明性能需求。 性能问题可能包括在各种负载条件下的用户负载因素、带宽或通信容量、吞吐量、精确度以及可靠性或响应时间。]
[根据需要详细说明环境需求。对于基于硬件的系统,环境因素可能包括温度、振荡、湿度、辐射等。对于软件应用系统,环境因素可能包括使用条件、用户环境、资源可用性、维护问题、错误处理和恢复。]
[为了对提议进行实施的产品进行评估、跟踪、管理并确定其优先级,应该为目标指定属性。列出您已选择的属性,并对其进行简要说明。如需建议的功能属性集,请参见工件:需求管理计划。]