需求规格说明书范文标准模板

软件需求规格说明书模版目录1简介..................................................错误!不决义书签。编写目的........................................错误!不决义书签。预期的读者和阅读建议............................错误!不决义书签。术语、定义、符号及缩略语........................错误!不决义书签。参照资料........................................错误!不决义书签。2综合描绘..............................................错误!不决义书签。项目背景........................................错误!不决义书签。产品功能........................................错误!不决义书签。应用模型........................................错误!不决义书签。运转环境........................................错误!不决义书签。假定和依靠......................................错误!不决义书签。3功能需求..............................................错误!不决义书签。包构造模型/模块关系模型.........................错误!不决义书签。用例包1（采纳用例模型）........................错误!不决义书签。用例模型图.................................错误!不决义书签。主要信息...................................错误!不决义书签。用例1......................................错误!不决义书签。特征1（不采纳用例模型）........................错误!不决义书签。<需求N>....................................错误!不决义书签。4非功能性需求..........................................错误!不决义书签。性能需求........................................错误!不决义书签。性能需求1..................................错误!不决义书签。靠谱性需求......................................错误!不决义书签。靠谱性需求1................................错误!不决义书签。安全需求........................................错误!不决义书签。安全需求1..................................错误!不决义书签。其余需求........................................错误!不决义书签。其余需求1..................................错误!不决义书签。5外面接口需求..........................................错误!不决义书签。用户接口........................................错误!不决义书签。<用户接口需求M>............................错误!不决义书签。硬件接口........................................错误!不决义书签。<硬件接口需求M>............................错误!不决义书签。软件接口........................................错误!不决义书签。<软件接口需求M>............................错误!不决义书签。通信接口........................................错误!不决义书签。<通信接口需求M>............................错误!不决义书签。6附录..................................................错误!不决义书签。简介[提出对《软件需求规格说明书》的纵览，帮助读者理解文档怎样编写而且怎样阅读和解说。]1.1编写目的[对产品（也可能是项目，可是我们统称为产品）进行定义，在该文档中详细说明这个产品的需求，包含修正或刊行版本号。假如这个《产品需求规格说明书》只与整个系统的一部分有关，那么只定义文档中说明的部分或子系统。举例：本文的目的是为了清楚地说明产品要实现的全部功能，产品的设计、编码和测试都要以本文的内容为基础。同时，本文确立的内容还作为产品查收的基准。客户、项目组要共同磋商本文内容。]1.2预期的读者和阅读建议[列举本文档所针对的不一样读者，比如开发人员、市场人员、测试人员、客户等。描绘文档中节余部分的内容及其组织构造，提出最合适每一种类读者阅读文档的建议。]1.3术语、定义、符号及缩略语[按字母或拼音次序列出全部的定义和缩略语，以便读者能够正确地理解《产品需求规格说明书》，包含词头和缩写。注意：只要要列出对理解本文实用的术语。举例：PRS：ProductRequirementSpecification（产品需求规格说明书）。]1.4参照资料[列举编写《软件需求规格说明书》时所参照的资料或其余根源。可能包含用户界面风格指导、合同、标准、系统需求规格说明书、用户需求、有关产品的产品需求规格说明书。这里应当给出参照资料详细的信息，包含标题名称、作者、版本号、日期、第一版单位或资料根源，以方便读者查阅这些文件。]综合描绘[这一部分概括了正在定义的产品以及它所运转的环境、使用产品的用户和已知的限制、假定和依靠。]2.1项目背景[描绘产品需求规格说明书中所定义的产品的背景和发源。说明该产品是不是产品系列中的下一个成员，是不是成熟产品所改良的下一代产品、是不是现有应用程序的代替品，或者是不是一个崭新的产品。]2.2产品功能[概括产品一定具备的主要功能，本文档在第三章对产品功能进行详细描绘，在此仅作归纳总结，要点在系统层次上描绘产品的功能需乞降功能分类，还可能包含保证产品与外面组件正确连结的需求。能够使用列表的方法给出，也可使用图形表示主要的需求分组以及它们之间的联系，比如数据流程图的顶层图或类图。以使描绘更为有效。]2.3应用模型[运用处合、环境、组网、应用举例。绘制产品的构造图示、与系统订交互的外面对象之间的关系。假如该部分内容与《市场需求剖析报告》中“产品的组网与应用剖析”内容完整同样，请直接引用（比如：请拜见《市场需求剖析报告》中“产品的组网与应用剖析”）。]2.4运转环境[描绘产品的运转环境，包含为支持产品工作所需的其余的组件或许与其共存的产品；关于软件产品还应包含硬件平台、操作系统和版本、一定安装的软件零件和其余应用软件等。]2.5假定和依靠[列出全部会影响需务实现的假定要素（有关于已知的事实而言），可能包含打算要用的商业组件或有关开发或运转环境的问题。比如，本项目产品计划要使用某些第三方软件产品或商业软件产品，固然目前还未获得这些软件，但我们能够假定这些软件必定能够获得。如果这些假定不正确、或发生改变，会影响项目的开发，所以，这些假定常常又是一种风险。别的，确立项目对外面要素存在的依靠。比如，假如项目的开发或项目产品的使用要依靠其余外面要素，比方与其余产品共用的软件包、准备重用的软件构件等，也要在此说明。]功能需求[本章将详细解说产品全部的功能需求。功能需求是依据系统特征即产品所供给的主要服务来组织的。你可能更喜爱经过用例、运转模式、用户类、对象类或功能等级来组织这部分内容，你还能够使用它们的组合。

总之，你一定选择一种使读者易于理解预期产出的组织方案。假如使用传统的需求剖析方法，

本章的每一节描绘一个功能需求，

每个功能需求又从编号、名称、优先级、输入、办理、输出、查收准则

7项来说明。假如使用

UML模型描绘需求剖析结果，本章的每一节采纳“使用用例”描绘一个功能需求，并在此说明参照的“使用用例”文件名；假如你采纳模型工具绘制用例视图，你应在此注明所用工具的名称、版本等信息。本章中所列出的需求，要求细化到以下程度：（1）设计人员能够依照该需求设计并实现系统；（2）系统测试人员能够依照该需求编写测案并对系统进行考证。]3.1包构造模型/模块关系模型[使用UML模型描绘需求剖析结果时，在本节区分出系统的包构造，用图表示出用户机构与本系统各个包之间的关系和本系统各包部分之间的关系。使用传统的需求剖析方法时，在本节区分出系统的各功能模块构造，用图表示出用户机构与本系统各个功能模块之间的关系和本系统各功能模块之间的关系。]3.2用例包1（采纳用例模型）3.2.1用例模型图3.2.2主要信息【关于每个包应当说明以下信息：名称简要说明该包所拥有的用例列表该包所拥有的角色列表直属该包的包列表】3.2.3用例1优先级[该需求的优先级，按高、中、低的优先级分类。对高、中、低的解说以下：高：要点的功能特征，必选，不可以实现意味着没法知足客户的需求。全部“高”优先级的需求一定在本次项目开发中实现。中：重要的功能，必选，不可以实现可能会影响产品的销售和客户满意度。全部“中”优先级的需求都应当作为产品的功能点，但在时间、资源的压力下，能够考虑在产品的下一个版本中实现。低：实用的功能或性能的提升，可选，不可以实现不会对产品产生实质性影响，但可能会在特定的应用处合增添产品的卖点，在时间、资源同意的状况下，能够考虑在产品的某一版本中实现。]简要说明【用例的简要说明应反应用例的角色和目的。在撰写说明时，应参照用例中所波及的主角、词汇表，并依据需要定义新观点。以下是回收机系统中“回收储藏物件”用例的简要说明示例：回收储藏物件：用户使用本机器来自动统计全部回收物件（瓶子、罐子以及箱子），并获得一张收条。收条将在收银机处兑现。】参加者事件流【用例事件流包含用例建模工作所获得的最重要的信息。应当清楚地说明用例的事件流，让外行也能很简单地理解它。请记着，事件流应当说明系统做什么，而不是说明为了执行所需的行为而对系统进行的设计。事件流的两个主要部分是主事件流和扩展事件流。主事件流应包含在履行用例时“往常”会发生的事件。扩展事件流包含与正常行为有关的可选或异样特点的行为，同时也包含正常行为的各样变形。您能够将扩展事件流看作是主事件流的“绕行道”，有些扩展事件流将返回到主事件流，而有些将结束此用例的履行。】主事件流扩展事件流前置条件【前置条件或后置条件所说明的状态应当是用户能够察看到的状态。“用户已经登录系统”或“用户已经翻开文档”都是可察看状态的示例。前置条件是对用例何时开始的拘束。它其实不是使用例开始的事件。比如自动柜员机中“提取现金”用例的前置条件为：客户拥有一张个人专用卡，这张卡正好能够塞进读卡器，而且该卡已经分到一个PIN号，还向银行业务系统进行了登记。】触发条件【触发条件是说明触发用例履行的条件。比如“预约客房”用例的触发条件是客户申请预约客房，其前置条件是目前有空的客房。】后置条件【比如，自动柜员机中“提取现金”用例的后置条件为：当用例结束时，全部帐户和交易日记都已进出均衡，与银行业务系统的通信已从头初始化，而且银行卡已经返还给客户。】3.3特征1（不采纳用例模型）[在此对<特征1>进行纲要性说明，比如：此模块中包含实现预支费业务所需的全部功能。]3.3.1<需求N>[本节的标题<需求N>需以实质的需求名取代。]编号[为需求定义一个独一的编号，便于需求追踪。]名称及说明[需求名称，假如需要能够在此对需求的内容作简要的描绘。]优先级[该需求的优先级，按高、中、低的优先级分类。对高、中、低的解说以下：高：要点的功能特征，必选，不可以实现意味着没法知足客户的需求。全部“高”优先级的需求一定在本次项目开发中实现。中：重要的功能，必选，不可以实现可能会影响产品的销售和客户满意度。全部“中”优先级的需求都应当作为产品的功能点，但在时间、资源的压力下，能够考虑在产品的下一个版本中实现。低：实用的功能或性能的提升，可选，不可以实现不会对产品产生实质性影响，但可能会在特定的应用处合增添产品的卖点，在时间、资源同意的状况下，能够考虑在产品的某一版本中实现。]输入[列出本需求全部的输入（触发条件、输入参数）。对每项输入，可能的属性以下：输入名说明种类[比如：Int、String]输入值的范围输入根源格式]办理[描绘为了知足该项功能应进行哪些事务办理。能够用文本方式、伪指令或流程图来描述。]输出[列出本需求全部的输出（输出参数、办理结果）。对每项输出，可能的属性以下：输有名说明种类输出值的范围输出值的目标格式]非功能性需求4.1性能需求4.1.1性能需求1编号名称及说明优先级查收准则4.2靠谱性需求4.2.1靠谱性需求1编号名称及说明优先级查收准则4.3安全需求4.3.1安全需求1编号名称及说明优先级查收准则4.4其余需求4.4.1其余需求1编号名称及说明优先级查收准则外面接口需求表三：外面接口需求分类表需求类型编号需求名称优先级描绘5.1用户接口[陈说产品中所需要的用户界面。描绘每个用户界面的逻辑特点。以下是可能要包含的一些特点：将要采纳的图形用户界面标准或整个产品系列的风格；屏幕布局；将出此刻每个屏幕的标准按钮（如帮助）、功能或导航链接；键盘快捷键；错误信息显示标准。假如必需，用户接口需求的细节可在独立的用户接口规格文件中描绘。]5.1.1<用户接口需求M>[本节的标题需以实质的需求名取代。]编号[为需求定义一个独一的编号，便于需求追踪。]名称及说明[需求名称，假如需要能够在此对需求的内容作简要的描绘。]优先级[该需求的优先级，按高、中、低的优先级分类。对高、中、低的解说以下：高：要点的功能特征，必选，不可以实现意味着没法知足客户的需求。全部“高”优先级的需求一定在本次项目开发中实现。中：重要的功能，必选，不可以实现可能会影响产品的销售和客户满意度。全部“中”优先级的需求都应当作为产品的功能点，但在时间、资源的压力下，能够考虑在产品的下一个版本中实现。低：实用的功能或性能的提升，可选，不可以实现不会对产品产生实质性影响，但可能会在特定的应用处合增添产品的卖点，在时间、资源同意的状况下，能够考虑在产品的某一版本中实现。]查收准则[说明用于考证知足需求的查收准则。]5.2硬件接口[描绘系统中软件和硬件每一接口的特点，可能包含软件所支持的设施种类、软硬件之间沟通的数据和控制信息的性质、通信协议等。]5.2.1<硬件接口需求M>[本节的标题需以实质的需求名取代。]编号[为需求定义一个独一的编号，便于需求追踪。]名称及说明[需求名称，假如需要能够在此对需求的内容作简要的描绘。]优先级[该需求的优先级，按高、中、低的优先级分类。对高、中、低的解说以下：高：要点的功能特征，必选，不可以实现意味着没法知足客户的需求。全部“高”优先级的需求一定在本次项目开发中实现。中：重要的功能，必选，不可以实现可能会影响产品的销售和客户满意度。全部“中”优先级的需求都应当作为产品的功能点，但在时间、资源的压力下，能够考虑在产品的下一个版本中实现。低：实用的功能或性能的提升，可选，不可以实现不会对产品产生实质性影响，但可能会在特定的应用处合增添产品的卖点，在时间、资源同意的状况下，能够考虑在产品的某一版本中实现。]查收准则[说明用于考证知足需求的查收准则。]5.3软件接口[说明本产品与其余外面组件（包含数据库、操作系统、工具、运转库、集成的商业部件等，要指明它们的名字和版本）的连结。明确并描绘在软件组件之间互换数据或信息的目的。描绘所需要的服务以及内部组件通信的性质。确立将在组件之间共享的数据。假如一定用一种特别的方法来实现数据共享体制，比如在多任务操作系统中的一个全局数据区，那么就一定把它定义为一种实现上的限制。]5.3.1<软件接口需求M>[本节的标题需以实质的需求名取代。]编号[为需求定义一个独一的编号，便于需求追踪。]名称及说明[需求名称，假如需要能够在此对需求的内容作简要的描绘。]优先级[该需求的优