产品需求规格说明书模板.doc

.xxxxxxx产品需求规格说明书文件状态： 草稿 内部版本 发布版本文件标识号文件版本文件编制/修改人编制/修改日期审批人审批日期地址：电话： ;.版本信息版本编制/修改人编制/修改日期修改对象修改原因说明例如：V1.0.0例如：XXXXXX例如：2015-5-18例如：电机控制模块设计;.目录1文档概述11.1编写目的11.2文档范围11.3定义、术语及缩写解释11.4参考资料21.5假定条件22产品定位22.1产品背景22.2问题说明32.3产品定位说明33用户和相关方说明33.1用户说明33.2用户环境说明33.3相关方说明43.4关键的用户/相关方需求44产品概述44.1产品总体效果54.2功能摘要54.3假设和依赖关系55产品功能性需求65.1功能性需求概述65.2产品功能关联65.3产品功能性需求描述75.3.1功能A76设计约束87外部接口88产品非功能性需求88.1适用标准需求88.2系统软硬件环境需求98.3用户界面需求98.4产品质量需求99文档需求119.1用户手册119.2联机帮助文件119.3安装指南、配置文件、自述文件1210附录A：需求确认1211附录B：需求评审辅助列表1312附录C：待定需求列表13;.1 文档概述产品需求说明书文档的简介应提供整个文档的概述。它应包括此产品需求说明书文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。1.1 编写目的阐明此产品需求说明书文档的目的。例如：此文档的目的是收集、分析和定义的需要和特性。它包括目标用户或相关方需要的产品功能和这些需要存在的原因，以及详细地说明所确定的产品的关键外部流程、接口和非功能性特性的需求、设计约束。1.2 文档范围简要说明此产品需求说明书文档的范围、它的相关产品，以及受到此文档影响的任何其他事物。1.3 定义、术语及缩写解释提供正确理解此产品需求说明书文档所需的全部术语的定义、首字母缩写词和缩略语。可以通过参考产品词汇表来获取这些信息。术语或缩写解释1.4 参考资料完整地列出产品需求说明书中其他部分所引用的所有文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过参考附录或其他文档来提供。1.5 假定条件说明阅读和理解本产品需求说明书文档需要具备的前提条件。例如：假定读者了解misc的框架和业务流程；假定读者了解短信业务的业务流程。2 产品定位产品定位指整个产品生命周期的整体定位，在后续版本的需求定义中可以直接引用。如果是全新的版本定义需要重新描述。2.1 产品背景说明此产品需求产生的背景。例如：本产品产生的背景是上一个版本的稳定性不足，本产品的主要目的是为了解决此重要问题。2.2 问题说明提供一段说明，罗列此产品所需要解决的问题。2.3 产品定位说明提供一段总体说明，高度概括产品将要在市场上占据的独特位置。产品定位说明用于向所有相关人员传达产品的目的和产品的重要性。3 相关方和用户说明为有效地提供符合相关方及用户实际需要的产品和服务，有必要在需求建模流程中确定并包括所有相关方。您还必须确定系统的用户，确保相关方能够充分代表这些用户。本节提供参与产品的相关方和用户的简要资料，以及他们认为需要通过提出的解决方案来解决的关键问题。这里需要说明他们的具体请求或需求。3.1 相关方说明提供该产品所有已确定相关方的一览表。相关方名称说明3.2 用户说明提供该产品所有已确定用户的一览表。用户名称说明3.3 用户环境说明详细说明目标用户的工作环境。以下是几项建议：一个任务周期需要多长时间？执行每项活动要用多长时间？是否总在变化？是否有特殊的环境约束？目前使用的是哪些系统平台？以后会使用哪些平台？还在使用哪些应用程序？您的应用程序是否需要和这些应用程序集成？在此处可以从商业策略中摘录一些内容来概述所涉及的任务和角色等等。3.4 关键的相关方、用户需求列出用户或相关方认为现有解决方案存在的关键问题。对于列出的每个问题，需澄清以下要点： 为什么会出现这一问题？ 目前的解决方案是什么？ 相关方或用户需要什么样的解决方案？务必要了解用户或相关方对解决各个问题的相对重视程度。分级和累积投票方法表明，必须解决的问题与相关方或用户希望解决的问题大有不同。4 产品概述高度概括产品的功能、与其他应用程序的接口以及系统配置。4.1 产品总体效果产品需求说明书文档的这一小节应将该产品放在其他相关产品环境和用户环境中进行介 绍。如果该产品自成一体，应在此处说明。如果该产品是较大系统的构件，此小节则应说明这些系统如何进行交互，并确定系统之间的相关接口。要显示较大系统的主要构件、互连情况和外部接口，一种简单的方法就是通过框图来表示。4.2 产品功能摘要总结该产品将提供的主要功能优点和特性。例如：一个客户支持系统的产品需求说明书文档，可能会利用此部分来讨论存在问题的记录、消息传递和状态报告，而不必涉及每个功能的细节。对功能加以组织，使客户或初次阅读该文档的其他人能够理解此功能列表。功能A优点特性4.3 假设和依赖关系列出会影响产品需求说明书文档中所述特性的所有因素。列出其变更将引起产品需求说明书文档随之变化的假设。5 产品功能性需求5.1 功能性需求概述列出产品的特性。特性是为让用户获益而必须具备的高级系统功能。每一项特性都是外部所需的服务，它通常需要一系列输入来实现预期的结果。 此节为设计的系统功能性需求, 一般以用例结合自然语言来表达。此节通常按特性来组织，但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。 这一节应包含所有的产品需求，其详细程度应使架构设计人员和软件需求设计人员能够设计出可以满足这些需求的系统，不包括可选流程和异常流程，不对具体语义做约束。 “版本划分”中，填入给产品规划的版本：基础版本、扩展版本1、扩展版本2。编号功能类别编号功能名称及标识符版本划分描述功能A子功能A1功能B子功能B1功能C子功能C15.2 产品功能关联描述功能划分后，各功能之间的关联关系。建议用描述方式，结合图的形式来说明。 这里的关联性，描述粗分的功能A，功能B，功能C之间的关联关系。而子功能放在下一章的各功能详细描述中。5.3 产品功能性需求描述5.3.1 功能A1 概要描述功能A。 2. 描述功能A中各个子功能的关联关系。5.3.1.1 子功能A1名称、标识符功能描述描述相关参数及其范围优先级高必须完成；中在时间不足，或是发生风险时，可以考虑暂缓；低属于优化功能，若资源足够，也可以实现难度高不熟悉的技术；中未做过类似的但熟悉技术；低曾做过类似的输入键盘或鼠标，数据流，报文流正确操作序列（可用图）输出界面显示，数据流，报文流错误处理对于错误的输入、错误的操作方式的处理方法说明补充说明6 设计约束 记录所有设计约束、外部约束或其他依赖关系。此节应列出所构建系统的所有设计约束。 设计约束代表已经批准并必须遵循的设计决定，其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。7 外部接口 此节规定应用程序必须支持的接口。它应非常具体，包含协议、字段和功能描述等，以便于按照接口需求开发并检验软件。此节说明产品与其他外部系统之间的软件接口。8 产品非功能性需求 在较高层次上列出适用的标准、硬件或平台需求、性能需求以及环境需求。8.1 适用标准需求列出产品必须符合的所有标准。其中可能包括法律和法规（FDA、UCC）标准、通讯标准（TCP/IP、ISDN）、平台一致性标准（Windows、Unix 等）以及质量和安全标准（UL、ISO、CMM）。编号需求名称详细要求8.2 系统软硬件环境需求确定支持该应用程序所必需的任何系统需求。其中可能包括所支持的主机操作系统及网络平台、配置、内存、外围设备和配套软件。8.3 用户界面需求列出产品为满足客户需要应该具备的用户界面需要，包括： 界面菜单：是否需要统一的菜单风格，包括菜单图片、颜色，菜单栏目的划分，各种功能的菜单标题等 操作方式：鼠标操作还是键盘操作 色彩方案 快捷方式：是否需要快捷方式，快捷方式是否显示，快捷方式的定义方案 导航方式：是否需要导航方式，导航的显示方法、操作过程等。8.4 产品质量需求需求名称具体要求性能概述系统的性能特征。其中需包括具体的响应时间。如果可行，按名称引用相关用例。 对事务的响应时间（平均、最长） 吞吐量，例如每秒处理的事务数 容量，例如系统可以容纳的客户或事务数 资源利用情况，如内存、磁盘、通信等具体的细化和实现设计，在产品的设计书中体现。易用性包括所有影响易用性的需求。例如， 指出普通用户和高级用户要高效地执行特定操作所需的培训时间 指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系统的可 用性需求 指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标准） 方面的需求具体的细化和实现设计，在软件需求说明书中体现安全性说明系统所需安全性需求，包括系统本身的运行安全、操作安全等，以及其他硬软件方面、制度方面的要求。例如： 系统本身的物理安全要求 系统防攻击要求 系统数据安全要求 环境建设的安全要求 用户使用的安全制度等。可靠性对系统可靠性的需求应在此处说明。例如： 平均故障时间，或平均故障次数，如小时/年，或者次/年 容错能力，比如对于错误输入的响应或处理，对于常见错误操作的处理 恢复能力，比如某功能失效后系统的运行方式以及恢复方式等。兼容性描述系统的兼容性需求，说明系统是否需要与其他系统兼容，与哪些系统进行怎样的兼容，兼容的方式如何。可维护性列出将提高所构建系统的可支持性或可维护性的所有需求，其中包括编码标准、命名约定、类库、维护访问权和维护实用程序。可扩展性描述系统的可扩展性需求，说明系统发布是否需要进行扩展，如需扩展，方式如何，将会产生的影响。可移植性描述系统的可移植性需求，说明系统将来是否需要进行移植，应当如何考虑。9 文档需求说明为支持成功部署应用程序而必须制作的文档。需求名称具体要求产品说明书提供产品说明书的目的和内容。讨论预期长度、详细程度，是否需要索引、词汇表、教程与引用手册等。还应确定格式和打印约束条件。用户手册说明用户手册的目的和内容。讨论预期长度、详细程度，是否需要索引、词汇表、教程与引用手册等。还应确定格式和打印约束条件。安装指南配置文件自述文件在提供全套的解决方案时，提供包括安装说明和配置指南的文档是非常重要的。此外， 自述文件通常也要作为一个标准构件包括在内。自述文件可以包括一个“本发布版中的新特性”部分，并讨论与以前发布版的兼容性问题。多数用户也希望在自述文件中列出任何已知的错误和变通方法。联机帮助文件许多应用程序提供了联机帮助系统来协助用户。这些系统的性质对于应用程序开发来说 独特的，因为它们综合了编程（如超链接）和技术写作（组织、演示）的各个方面。许多人发现联机帮助系统的开发本身就是一个受益于先期规模管理和计划活动的产品。10 附录A：需求确认提示：需求确认规程主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式”，将产生一份需求评审报告。在获取责任人对需求的承诺之前，该产品需求规格说明书必须先通过需求评审。需求评审报告摘要需求文档输入名称，标识符，版本，作者，完成日期，需求评审报告输入