XX项目产品需求规格说明书模板目录1文档介绍 (2)1.1文档目的 (2)1.2文档范围 (2)1.3读者对象 (2)1.4参考文档 (3)1.5术语与缩写解释 (3)2综合描述 (3)2.1产品介绍 (3)2.2产品面向的用户群体（可选） (3)2.3产品应当遵循的标准或规范 (4)2.4产品范围 (4)2.5产品涉众（涉及角色） (4)2.6设计和实现的限制 (4)2.7假设和约束（依赖） (5)3产品需求 (5)3.1需求分类 (5)3.2用例图 (6)3.3功能需求 (7)3.3.1需求描述 (7)3.3.2特殊需求 (8)3.3.3数据规范 (8)3.4非功能需求（包括但不限制于以下几项） (8)3.4.1时间特性要求 (8)3.4.2精度要求 (9)3.4.3业务量估算 (9)3.4.4灵活性 (9)3.4.5可用性 (9)3.4.6安全性 (10)3.4.7兼容性 (10)3.4.8易用性 (11)3.4.9可维护性 (11)3.5运行环境 (11)3.5.1设备及分布 (11)3.5.2支撑软件 (12)3.6接口 (12)3.6.1硬件接口 (12)3.6.2软件接口 (12)3.6.3通讯接口 (12)3.6.4用户接口 (13)4验收标准 (14)4.1功能验收标准 (14)4.2非功能性验收标准 (14)附录A：需求建模与分析报告 (15)A.1需求模型1 (15)A.2需求模型N (15)附录B：需求确认 (15)【对本文档的说明：本文档中黑色斜字体为说明性文字，黑色正常字体为需求规格说明书实际写作时必需部分。
蓝色字体为举例说明文字。
】1文档介绍1.1 文档目的提示：软件需求规格说明主要描述系统的概貌、功能要求、性能分析、运行要求和将来可能提出的要求。
阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。
举例说明：示例：本文档的主要目的是描述XXX项目中XXX模块的功能需求和非功能需求，功能需求采用用例的方式描述。
以使所有涉众能够达成共识。
本需求说明书，在需求固化之前，会有相应的变更。
在文档历史中会详细记录变更的具体内容。
1.2 文档范围提示：文档范围包括：产品介绍，产品面向的用户群体，产品应当遵守的标准与规范，产品范围，产品中的角色，产品的功能性需求，产品的非功能性需求。
1.3 读者对象提示：1）各种管理人员及开发人员：专案经理、系统工程师、软件开发人员、硬件开发人员、测试人员、型态管理人员、品质保证人员、作业员和技术出版人员。
2）软件使用客户。
1.4 参考文档提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：[标识符] 作者，文献名称，出版单位（或归属单位），日期1.5 术语与缩写解释2综合描述2.1 产品介绍提示：1）说明产品是什么，什么用途。
2）介绍产品的开发背景。
2.2 产品面向的用户群体（可选）提示：裁剪说明：在需求阶段无法识别面向用户群体时可以对此部分进行裁剪。
1）描述本产品面向的用户（客户、最终用户）的特征；2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？2.3 产品应当遵循的标准或规范提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。
也包括需要遵守的法律法规要求。
2.4 产品范围提示：阐述本产品“适用的领域”和“不适用的领域”，清楚产品范围的好处是：1）有助于判断什么是需求，什么不是需求；2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；3）有助于控制需求的变更。
2.5 产品涉众（涉及角色）提示：阐述本产品的涉众人或物。
举例说明：2.6 设计和实现的限制提示：2.7 假设和约束（依赖）提示：列举出对软件产品需求分析报告中，影响需求陈述的假设因素(与己知因素相对立)。
如果这些假设因素不正确、不一致或者被修改，就会使软件产品开发项目受到影响。
这些假设的因素可能包括：3产品需求3.1 需求分类提示：需求编号规定：需求子类，数字编号二级需求类别，数字编号一级需求类别，数字编号将需求先粗分再细分，下表中的功能需求1、性能需求2，需求子类1.1、需求子类2.1等符号应当被替换成有含义的名称。
举例说明：需求类别需求子类需求描述功能需求1需求子类1.1非功能需求2需求子类2.1…………3.2 用例图提示：此处填写需求用例图。
举例说明：3.3 功能需求3.3.1需求描述3.3.1.1 需求子类M.N。
3.3.2特殊需求提示：特殊需求是该用例所专有，但无法在用例的事件流文本中较容易或较自然地进行说明。
3.3.3数据规范提示：裁剪说明：对于自研项目，在需求阶段，对产品数据格式识别不清晰时可以对此部分进行裁剪。
描述用到的数据项，包括名称、长度、显示属性以及备注说明等。
如下表所示：1）类型／长度可直接使用相应开发语言对数据项的类型和长度定义来描述。
2）显示属性表示可能的选项包括：必输项（必选项）、输入项（可选项）、只读项、隐藏项。
3.4 非功能需求（包括但不限制于以下几项）3.4.1时间特性要求提示：说明对于该软件的时间特性要求，如：响应时间、批处理时间、更新处理时间、数据的转换和传送时间、解题时间等。
举例说明：3.4.2精度要求提示：说明对输入、计算过程、输出数据精度的要求，可能包括传输过程中的精度。
3.4.3业务量估算提示：说明总业务量、日均业务量、峰值业务量等。
3.4.4灵活性提示：说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如操作方式上的变化，运行环境上的变化，同其他软件的接口变化，精度和有效时限的变化，计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.4.5可用性提示：指定一些因素，如检查点、恢复和再启动等，以保证整个系统可用性。
举例说明：3.4.6安全性提示：指保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。
个别领域的具体需求必须包括：1）要求利用的密码技术；2）要求对特定的记录或历史数据集的保护方法；3）对某些特定的功能的访问权限的限定；4）对某些数据的加密传输要求。
5）保证数据安全的能力，如双机热备份。
举例说明：除在网络层、操作系统层采用高级别的产品外，在应用软件层和管理层采用如下安全管理原则：1）提供了丰富的用户管理功能，能够对用户可进行的操作和可访问的网络资源范围进行灵活的权限控制。
2）系统具有完善的日志管理功能，能够对所有登录用户操作相关的日志进行详细的记录，并且所有操作日志记录不可删除。
3.4.7兼容性提示：指系统可兼容的软硬件以及相关的操作系统，可以包括：3.4.8易用性提示：指交互的适应性、功能性和有效性的集中体现，易用性是指在指定条件下使用时，软件产品被理解、学习、试用和吸引用户的能力，它包括：1）易理解性：用户人时软件的结构、功能、逻辑、概念、应用范围、接口等难易程度；2）易学习性：用户学习软件应用难易程度；3）易操作性：用户操作和运行控制软件的难易程度，要求软件的人机界面友好，界面设计科学合理以及操作简单等方面进行考量。
举例说明：系统基于中文的GUI管理界面，在系统初建、运行均提供友好人机界面，操作性好。
系统的界面构建在微机的Windows 下，浏览器方式显示管理信息，界面操作简单。
3.4.9可维护性提示：软件可维护性即维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进该软件的难易程度。
决定可维护性的因素：1）系统的大小2）系统的年龄3）结构合理性3.5 运行环境3.5.1设备及分布提示：1）主机类型2）网络类型3）存贮器容量4）其他特殊设备5）设备分布图3.5.2支撑软件提示：1）操作系统2）数据库管理系统3）其他支撑软件3.6 接口提示：简要说明该软件同其他软件之间的公共接口、数据通信协议等，如果外部接口仅与某子功能有关，该接口说明应列在子功能规格说明书中。
3.6.1硬件接口提示：详细描述与硬件的接口。
在此描述软件产品和系统硬件组件之间接口的逻辑特征，也包括支持哪些设备、怎样支持这些设备和协议等。
3.6.2软件接口提示：详细描述与其他系统/模块/项目之间的接口，包括内部接口、外部接口。
若提供给最终应用开发商的主要产品形式包括编程接口，可专门在此进行阐述，包括的内容可以有：1）新增/更改/删除/不鼓励使用的接口类。
2）新增/更改/删除/不鼓励使用的接口方法。
3.6.3通讯接口提示：说明采用的通讯协议，应用软件对外通讯实现方式等。
举例说明：3.6.4用户接口提示：说明用户通过什么手段使用本软件（例如：终端机、密码键盘等）。
基本操作方法，以及功能键使用说明。
3.6.4.1 用户界面需求提示：陈述需要使用在用户界面上的软件组件，描述每一个用户界面的逻辑特征。
必须注意，这里需要描述的是用户界面的逻辑特征，而不是用户界面。
以下是可能包括的一些特征：1）将要采用的图形用户界面(GUl)标准或者产品系列的风格；2）有关屏幕布局或者解决方案的限制；3）将要使用在每一个屏幕(图形用户界面)上的软件组件，可能包括：a)选单；b)标准按钮；c)导航链接；d)各种功能组件；e)消息栏；4）快捷键；5）各种显示格式的规定，可能包括：a)不同情况下文字的对齐方式；b)不同情况下数字的表现格式与对齐方式c)日期的表现方法与格式；d)计时方法与时间格式；e)等等。
6）错误信息显示标准；对于用户界面的细节，例如：一个特定对话框的布局，应该写入具体的用户界面设计说明中，而不能写入软件需求规格说明中。
如果采用现成的、合适的用户界面设计规范(标准)，或者另文描述，可以在这里直接说明，并且将其加入参考文献。
举例说明：4验收标准提示：裁剪说明：如果《合同》中或《用户需求说明书》已经定义了验收标准，该章节可删除。
说明对技术需求及非技术需求等方面的验收标准，如功能、性能的正确性、安全性、可靠性等方面的要求。
示例如下：4.1 功能验收标准举例说明：4.2 非功能性验收标准举例说明：附录A：需求建模与分析报告提示：指需求开发过程中建模与分析报告，若采用Rational Rose对产品需求进行建模与分析，可参考以下内容：A. 1需求模型1A. 2需求模型N附录B：需求确认提示：需求确认规程主要分两步：（1）需求评审，（2）需求承诺。
对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”。
在获取责任人（Stakeholders）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。