软件开发模板-前景.docx

软件开发模板项目名称前景版本<1.0>项目名称版本：<1.0>前景日期：文档编号：修订文档历史记录日期版本说明作者V日/月/年<x.x>详细信息姓名项目名称版本：<1.0>前景日期：文档编号：目录1.简介1.11.21.31.41.5目的范围定义、首字母缩写词和缩略语参考资料概述5555552.定位52.1商机52.2问题说明52.3产品定位说明53.涉众和用户说明63.1消费者统计数据63.2涉众概要63.3用户概要63.4用户环境63.5涉众简档73.5.1V涉众名73.6用户简档73.6.1<用户名>73.7关键的涉众/用户需要83.8备选方案和竞争83.8.1一个竞争对手83.8.2另一个竞争对手84.产品概述84.1产品总体效果84.2功能摘要84.3假设与依赖关系94.4成本与定价94.5许可与安装95.产品特性95.1一个特性105.2另一个特性106.约束107.质量范围108.优先级109.其他产品需求10项目名称版本：<1,0>前景日期：文档编号：9.1适用的标准109.2系统需求109.3性能需求109.4环境需求10文档需求1010.1用户手册1010.2联机帮助1010.3安装指南、配置文件、自述文件1010.4标签与包装11附录1-特性属性1111.1状态1111.2利益1111.3工作量1111.4风险1211.5稳定性1211.6目标发布版1211.7职责分配1211.8原因12项目名称版本：<1,0>前景日期：文档编号：前景1. 简介此文档的H的是收集、勿呦加7定义系统名的高层次需求和特性。它侧重于涉众和目标用户所需的功能以及这些需要存在的原因、系统名»如何满足这些需要的详细情况记录在用例和补充规约中。Ji前景文档的简介应提供整个文档的概述。它应包括此前景文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。1.1 目的阐明此前景文档的目的。1.2 范围简要说明此前景文档的范围:它的相关项目,以及受到此文档影响的任何其他事物。1.3 定义、首字母缩写词和缩略语本小节应提供正确解释此前景文档所需的全部术语的定义、首字母缩写词和缩略语。这些信息可以通过引用项目词汇表来提供。1.4 参考资料本小节应完整列出此前景文档中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。J1.5 概述此小节应说明前景文档中其他部分所包含的内容,并解释此文档的组织方式。12. 定位2.1 商机简要说明此项目面临的商机。12.2 问题说明提供一段说明，总结此项目正在解决的问题。可以采用以下格式：问题是对问题进行说明】影响问题影响的涉众1问题的后果该问题会导致什么后果成功的解决方案应列出成功解决方案的一些主要优点2. 3产品定位说明I提供段总体说明,高度概括产品将要在市场上占据的独特位置。可以采用以下格式：项目名称版本：<1.0>前景日期：文档编号：针对于目标客户谁说明需要或机会该（产品名）属于产品类别功能陈述主要优点,即促使人们购买的原因1不同于主要的竞争产品我们的产品陈述主要的区别I产品定位说明用于向所有相关人员传达应用程序的目的和项目的重要性。3. 涉众和用户说明为有效地提供可满足涉众及用户实际需要的产品和服务,有必要在需求建模流程中确定并包括所有涉众。您还必须确定系统的用户,确保涉众群体能够充分代表这些用户。本节提供参与项目的涉众和用户的简介,以及他们希望通过所提议的解决方案来解决的关键问题。这里并不说明他们的具体请求或需求,因为这些内容将单独在涉众请求工件中记录。此处只提供之所以存在这些需求的行景和原因。13.1 消费者统计数据I总结促使您作出产品决策的关键消费者统计数据。说明并定位目标细分市场。估计市场的大小和增长率,估计的依据可以是潜在用户的数量,也可以是您的客户为满足您的产品或改进将要满足的需求所用资金的多少。了解行业大势和主流技术。回答以下战略性问题: 您的组织在这些市场的声誉如何? 您想获得什么样的声誉? 该产品或服务将如何支持您实现这些目标?3.2 涉众概要I提供所有已确定涉众的一览表。1名称表示角色指明涉众类型。简要说明他们在开发方面所表示的内容。I简要说明他们在开发中的作用。例如,确保某项工作顺利完成。3. 3用户概要I提供所有已确定用户的一览表。1名称说明涉众指明用户类型I简要说明他们在系统方面所表示的内容。/明确用户如何由涉众来代表。例如,由涉众LI来代表3.4用户环境详细说明目标用户的工作环境。以下是几项建议:项目名称版本：1.0前景日期：文档编号：该任务由多少人来完成?是否总在变化?一个任务周期需要多长时间?执行每项活动要用多长时间?是否总在变化?是否有特殊的环境约束:移动、户外、乘机旅行等?目前使用的是哪些系统平台?以后会使用哪些平台?还在使用哪些应用程序?您的应用程序是否需要和这些应用程序集成?在此处可以从业务模型中摘录一些内容来概述所涉及的任务和角色等等。I1.1 5涉众简档通过在下表中填写各涉众的相关信息来说明系统中的各个涉众。要注意的是,涉众可能会有许多不同的类型,例如用户、策略部门和技术开发人员。详尽的简档应包括各种涉众在以下方面的信息：13.5.1V涉众名代表t谁是此项目的涉众代表?（如在他处已作记录,则此处为可选。）此处只需填写姓名。说明I对涉众类型的简要说明。】类型介绍涉众的技能特长、技术背景和熟练程度（即权威用户、业务用户、专家用户、初级用户等）I职责列出涉众对所开发的系统负有的关键职责,即他们作为涉众的利靛。成功标准该涉众如何界定成功?该涉众如何得到回报?J参与该涉众如何参与此项目？尽可能和RUP角色（如需求复审员）建立联系。可交付工件涉众是否还需要其他的可交付工件？这些工件可以是项目可交付工件,也可以是正在开发的系统的输出。J意见/问题I在此处列出会阻碍成功的问题以及任何其他相关信息。I3.6 用户简档通过在下表中填写各用户类型的相关信息来说明系统的各种独特用户。要注意的是,用户可能有许多不同的类型,例如权威用户和入门用户。权喊用户可能会需要复杂、灵活并具备跨平台支持的工具:而入门用户则会需要使用方便、界面友好的工具。详尽的简档应包括各种用户在以下方面的信息：3.6.1用户名代表I谁是此项目的用户代表?（如在他处已作记录,则此处为可选。）通常指的是代表一组用户的涉众,例如涉众:涉众I说明对该用户类型的简要说明。类型I介绍该用户的技能特长、技术背景和熟练程度（即权威用户、初级用户筝儿7职责列出该用户对所开发的系统负有的关键职责,如记录详细信息、撰写报告、协调工作等。成功标准I该用户如何界定成功?项目名称版本：<1.0>前景日期：文档编号：该用户如何得到回报?参与I该用户如何参与此项目？尽可能和RUP角色（如需求复审员）建立联系。可交付工件I是否有该用户生成的可交付工件?如果有,是为谁生成的?/意见/问题I在此处列出会阻碍成功的问题以及任何其他相关信息。其中还需指明将如何影响用户的工作,即:让工作变得简单还是困难。J3.7 关键的涉众/用户需要I列出涉众认为现有解决方案存在的关键问题。对于列出的每个问题,需澄清以下要点: 为什么会出现这一问题? 目前如何解决该问题? 涉众需要什么样的解决方案?务必要了解涉众或用户对解决各个问题的相对重视程度。分级和累积投票方法表明,必须解决的问题与涉众或用户希望解决的问题大有不同。填写下表-如果是使用ReqPr。来记录需要,这可能就是该工具所生成的摘录或报告。1需要优先级关注的要点目前的解决方案提议的解决方案2. 8备选方窠和竞争I确定涉众认为可以使用的备选方案。其中可能包括购买竞争对手的产品、自行设计解决方案,或者仅维持现状。列出已经存在或潜在的竞争产品。列出涉众认为各种竞争对手具有的主要优缺点。13. 8.1一个竞争对手）3.8.2另一个竞争对手4. 产品概述此节高度概括产品的功能、与其他应用程序的接口以及系统配置。此节通常要包括以下三个小节: 产储总体效果 产品功能 假设与依赖关系1.1 产品总体效果前景文档的这一小节应将该产品放在其他相关产品环境和用户环境中进行介绍。如果该产品自成一体,应在此处说明。如果该产品是较大系统的构件,此小节则应说明这些系统如何进行交互,并确定系统之间的相关接口。要显示较大系统的主要构件、互连情况和外部接口,一种简单的方法就是通过框图来表示。1.2 功能摘要I总结该产品将提供的主要优点和特性。例如,一个客户支持系统的前景丈档可能会利用此部分来讨论存在问题的记录、消息传递和状态报告,而不必涉及每个功能的细节。对功能加以组织,使客户或初次阅读该文档的其他人能够理解此功能列表。下面的简表列出了主要优点及项目名称版本：<1,0>前景日期：文档编号：支持的特性,该示例应足以说明问题。例如：I客户支持系统客户利益支持特性新的支持人员能够很快地步入正轨。知识库可协助支持人员迅速地找到已知的解决方法和变通方法。因为考虑周全而提高了客户满意度。在整个解决过程中可将问题一一列出，并进行分类和跟踪。一出现老化问题就自动发出通知。管理人员能够发现存在问题的领域并估计人员的工作量。趋势及分布报告可从较高的角度来审查问题的状态。分散的支持团队能够协同解决问题。复制服务器使当前的数据库信息可以在整个企业的范围内共享客户能够自行解决一些问题，从而降低了支持成本并缩短了答复时间。可以通过Internet来访问知识库。包括超文本搜索功能和图形查询引擎1.3 假设与依赖关系列出会影响前景文档中所述特性的所有因素。列出其变更将引起前景工档随之变化的假设。例如,有这样一项假设:将为该软件产品指定的硬件提供特定的操作系统。但如果没有提供该操作系统,就将需要更改前景文档。11.4 成本与定价对于向外部客户发售的产品和许多内部的应用程序,成本和定价问题会直接影响到应用程序的定义和施。在此节中,应记录任何相关的成本或定价约束。例如,分销成本（软盘的数量、光盘的数量、CD制作）或其他商品销售的成本约束（手册、包装）可能对于项目的成功非常革要,也可能无关紧要,这取决于应用程序的性质。1.5 许可与安装许可和安装问题也可能直接影响到开发工作。例如,如果需要支持串行化、口令安全或网络许可,则会增加在开发工作中必须予以考虑的系统需求。安装需求还可能会影响到编码,或需要单独安装的软件。5. 产品特性列出并简述产品的特性。特性是为让用户获益而必须具备的高级系统功能。每一项特性都是外部所需的服务,它通常需要一系列输入来实现预期的结果。例如，问题跟踪系统的特性是能够提供趋势报告。当用例模型成型后,更新这里的说明以指代用例。由于前景文档将由各种各样的相关人员来复审,所以不应太过详细,应让所有人对此都有大致的了解。但是,应该向团队提供他们创建用例模型所需的必要详细信息。要有效地管理应用程序的复杂性,对于任何新系统或对现有系统的增量部分,我们建议将功能提炼到较高的程度,这样25到99项特性较为合理。这些特性为产品定义、规模管理和项目管理提供了基础。每项特性的详细程度都将在用例模型中得到较深入的扩展。贯穿此节的始终,都应能让用户、操作人员或其他外部系统从外部觉察到每项特性。这些特性应包括功能性的说明以及必须考虑的任何相关的可用性问题。以下原则将会适用:5.1 避免设计。使特性说明保持一定的概括程度。侧重于说明所需的功能以及为什么要（而不是如何）项目名称版本：<1.0>前景日期：文档编号：实现这些功能。5.2 如果您使用的是Reql淞加工具包,应将需求类型选择为“所有'：以便于引用和跟踪。5.3 一个特性5.4 另一个特性6. 约束记录所有设计约束、外部约束或其他依赖关系。7. 质量范围I定义性能、强壮性、容错、可用性以及特性集内没有记录的类似特征的质量范围。18. 优先级定义不同系统特性的优先级。9. 其他产品需求在较高层次上列出适用的标准、硬件或平台需求、性能需求以及环境需求。9.1 适用的标准列出产品必须符合的所有标准。其中可能包括法律和法规（FDA.UCO标准、通讯标准（TCP/IP.ISDN）.平台一致性标准（Windows.Unix等）以及质量和安全标准（UL、ISO、CMM）。/9. 2系统需求I确定支持该应用程序所必需的任何系统需求。其中可能包括所支持的主机操作系统及网络平台、配置、内存、外围设备和配套软件。J9.3 性能需求本节用于详细说明性能需求。性能问题可能包括在各种负载条件下的用户负载因素、带宽或通信容量、吞吐量、精确度以及可靠性或响应时间。9.4 环境需求I根据需要详细说明环境需求。对于基于硬件的系统,环境因素可以包括温度、振荡、湿度、辐射等。对于软件应用系统,环境因素可以包括使用条件、用户环境、资源可用性、维护问题、错误处理和恢复。110. 文档需求此节说明为支持成功部署应用程序而必须制作的文档。10.3 用户手册说明用户手册的目的和内容。讨论预期长度、详细程度,是否需要索引、词汇表、教程与参考手册策略等。还应确定格式和打印约束条件。】10.4 联机帮助I许多应用程序提供了联机帮助系统来协助用户。这些系统的性质对于应用程序开发来说独特的,因为它们综合了编程（如超链接）和技术写作（组织、演示）的各个方面。许多人发现联机帮助系统的开发本身就是一个受益于先期规模管理和计划活动的项目。10.5 安装指南、配置文件、自述文件I在提供全套的解决方案时,提供包括安装说明和配置指南的文档是非常重要的。此外,自述文件通常也要项目名称版本：<1,0>前景日期：文档编号：作为一个标准构件包括在内。自述文件可以包括一个“本发布版中的新特性”部分,并讨论与以前发布版的兼容性问题。多数用户也希望在自述文件中列出任何已知的错误和变通方法。110.6 标签与包装I目前最先进的应用程序从产品包装开始就提供了一致的外观,这种致还体现在安装菜单、启动屏幕、帮助系统、GUl对话框等等。此节定义对标签的需求和和标签类型,以便合并到代码中。举例来说,标签和包装涉及版权和专利声明、公司徽标、标准化的图标以及其他图形元素。I11. 附录1-特性属性为了对提议进行实施的产品项进行评估、跟踪、确定优先级和管理,应该为特性指定属性。所有需求类型和属性都应在需求管理计划中列出,但最好列出并简要说明己选中的特性的属性。以下小节建议了组功能属性。11.3 状态在经过项目管理团队的商谈和复审后设置。用于在确立项目基线的过程中对进度进行跟踪。】已提出用于说明正在进行讨论但尚未经过“正式渠道”（例如由项目团队、产品管理部门和用户或客户群的代表所组成的工作组）复审和验收的特性。已批准I被认为是有用、可行并已获得正式渠道批准,准备实施的功能。己并入在特定时间点并入产品基线中的特性。11.4 利益由市场经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级,可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模并确定开发的优先级。1关键I必不可少的特性。不满足这些需求就无法使系统满足客户的需要。所有关键特性都必须在发布时实现,否则符错过预定的发布时间。1重要对于系统在大多数应用中的有效性及效率都较为重要的特性。很难通过其他方式来实现这方面的功能。如果遗漏了某项重要特性,可能会影响客户或用户满意度,甚至会影响收入,但发布并不会因为缺少某一项重要特性而延期。用I有些特性在不太典型的应用中比较有用,或者可以合理而有效地实现其替代特性,这些特性的使用次数将会相对较少。即使发布版中没有包括某项这样的特性，也不会对收入或客户满意度造成严重的影响。）11.5 工作量由开发团队设置。由于有些特性所需的时间和资源多于其他特性,所以举例来说,如果要评测复杂程度并预计在给定时间范围内能否完成哪些工作时,最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数。用于管理规模并确定开发的优先级。项目名称版本：<1.0>前景日期：文档编号：11.6 风险I由开发团队根据项目遭遇意外事件的可能性来设置,这些事件包括超支、工期延误,甚或是项目取消。虽然可以对风险级别进行细分,但大多数项目经理都发现把风险归类为高、中、低就足够了。通过评测项目团队进度估计的不确定性（范围），一般都可以间接地对风险进行评估。11.7 稳定性由分析员和开发团队设置，设置的依据是特性发生变化的可能性或团队对特性的理解发生变化的可能性。用于协助确定开发优先级并确定下一步需要继续获取哪些项。111.8 目标发布版I记录将首次包括指定特性的产品版本。该字段可用于符前景文档中的特性分配给特定的基线发布版。如果将其与状态字段结合，您的团队就可以提出、记录和讨论发布版的各种特性,而不用对其进行开发。只有状态被设置为“已并入”且目标发布版已确定的特性才将被实施。当进行规模管理时,可以增加目标发布版号,这样该项特性虽然仍保留在前景文档中,但将安排在以后发布。11.9 职责分配在许多项目中,特性会被分配给各个“特性团队”，它们负责进一步获取需求,并编写软件需求和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。11.10 原因此文本字段用于跟踪所需特性的来源。需求的提出总会有一定的原因。此字段记录相应的解释或对相应解释的引用。例如,引用可以是产品需求规约的页码及行号,或者是一次重要的客户访谈录像的记录标记。