软需求规格说明书模板资料Word文档格式.docx

软需求规格说明书模板资料Word文档格式.docx

《软需求规格说明书模板资料Word文档格式.docx》由会员分享，可在线阅读，更多相关《软需求规格说明书模板资料Word文档格式.docx（7页珍藏版）》请在冰豆网上搜索。

项目代号

07A001

文档编号

04-04

文档版本

0.9

密　级

商密

XXXX系统（名称等在文件属性中设置）

软件需求规格说明书

xxxxx科技有限责任公司

2013年7月9日

文档修订记录

1引言

[引言提供一个概述，帮助读者理解软件需求规格说明的组织方式和使用方式。

]

目标

[确定在文档中进行了定义的产品或应用程序的需求，包括修订版本或发布版本号，如果该软件需求规格说明只与整个系统的一部分有关系，那么就只需确定这一部分或子系统。

文档约定

[描写编写文档时所采用的所有标准或印刷上的约定，包括文本样式、强调形式或其有特殊意义的表示符号。

例如，声明高层需求的优先级是否可以被其所有细化的需求所继承，或者每个功能性需求声明是否都有其自身的优先级。

读者对象和阅读建议

[列举软件需求规格说明面向的不同读者对象。

描述软件需求规格说明中的其余部分的内容及其组织结构。

就每一类读者最合适用什么顺序来阅读该文档提出建议。

项目范围

[提供对指定的软件及其作用的简短描述。

把软件与用户或公司目标相关联，把软件与业务目标和策略相关联，如果可以得到单独的前景和范围文档，那么应该引用它，而不要直接将其内容复制到这里。

如果是说明改进产品的增量发布的软件需求规格说明，那么应该包括它自己的范围声明，作为长期战略的产品前景的一个子集。

参考资料

[列举编写软件需求规格说明时所参考的所有文档或其他资源，如果可能的话，使用超文本链接。

具体说来可能包括用户界面样式指南、合同、标准、系统需求规格说明、用例文档、接口规格说明、操作概念文档或相关产品的软件需求规格说明。

在这里应该给出足够详细的信息，包括参考资料的标题、作者、版本号、日期以及来源或位置（例如网络文件夹和URL），以方便读者查阅这些资料。

2总体描述

[这一部分用于从总体上概述产品及其运行环境，以及产品用户对象和已知的约束、假设和依赖关系。

产品前景

[描述产品的背景和起源。

说明该产品是否是产品系列中的下一个成员，是否是成熟系统的下一版本，是现有应用程序的升级产品还是一个全新的产品。

如果该软件需求规格说明定义了大型系统的一个组件，那么就要说明这部分软件是怎样与整个系统相关联的，并且要确定二者之间的主要接口。

产品特性

[列出产品所具有的主要特性或者产品可实现的重要功能。

其详细内容将在该软件需求规格说明的第3部分中描述，所以在此只需要提供一个总体概括即可。

用图形来表示主要的需求组以及它们之间的联系，例如顶层数据流图，用例图或类图，可能是很有帮助的。

用户类及其特征

[确定我们能预料到的有可能使用该产品的各种用户类，并描述他们的相关特征。

有些需求可能只与某些用户类相关，应确定哪些是优先考虑的拥护类。

用户类是前景和范围文档中描述的涉众的一个子集。

运行环境

[描述软件的运行环境，包括硬件平台、操作系统和版本，以及用户、服务器和数据库的地理位置。

列出系统必须和平共存的其他软件组件或应用程序，前景和范围文档中可能包含这样的高层信息。

设计和实现上的约束

[描述限制开发人员进行有效选择的所有因素，以及每一种约束的基本原理。

约束可能包括如下内容：

必须使用或避免使用的特定技术、工具、编程语言和数据库。

由产品的运行环境所引起的一些限制，例如，将要使用的Web浏览器的类型和版本。

所要求的开发约定或标准（例如，如果由客户的组织负责软件维护，那么该组织就可能指定分包商必须遵循的设计符号和编码标准）。

业务规则强加的限制

硬件限制，例如定时需求、内存或处理器限制、大小、重量、材料或成本。

对现有产品进行改进时，要遵循的现存用户界面的一些约定。

标准数据交换格式，例如XML]

假设和依赖

[假设是这样一种声明，在缺少证据或不确定的情况下先相信它是真的。

如果假设不正确、不一致或被更改，那么就可能会产生问题，因此，有些假设将会转化为项目风险。

一个软件需求规格说明的读者可能假设产品将符合某个特定的界面约定，但是另一个读者却可能不这样认为。

开发人员可能假设某一组功能是为应用程序专门编写的，但是分析人员也许驾驶可以从以前的项目中重用这些功能，而项目经理则期望获得一个商业功能库。

此外，确定项目对其控制范围之外的外部因素的所有依赖关系，例如，操作系统下一个版本的发布日期或行业标准的发布。

如果您打算把其他项目正在开发的某些组件集成到系统中，就要以来那个项目能按时提供正常工作的组件。

如果这些依赖关系已经在其他地方进行了编档（例如在项目计划中）那么在此就可以引用那些文档]

3功能需求

功能需求1（优先级）

功能描述

[逐项列出与该特性相关的详细功能性需求。

这些是必须提交给拥护的软件功能，使用户可以执行该特性的服务或者完成一个用例。

描述产品如何响应可预知的出错条件以及如何响应非法输入或操作。

唯一地标识每个功能性需求。

用例（编号，UC＿＜模块缩写＞＜流水号＞）

[画出用例图]

用户界面描述

[描述和功能相关的用户描述，如果该功能没有用户界面，可以省略。

…]

4外部接口需求

[这一部分用于提供可确保系统正确地与外部组件进行通信的信息。

如果产品的不同部分有不同的外部接口，那么应该把这一部分的实例并如到每一个部分的详细需求中。

硬件接口

[描述系统中软件和硬件组件之间的每一个接口的特征。

这种描述可能包括支持的设备类型、软件和硬件之间的数据和控制交互以及所用的通信协议等。

软件接口

[描述该产品与其他软件组件（由名称和版本来识别）之间的连结，这些组件包口数据库、操作系统、工具、库和集成的商业组件等。

声明在软件组件之间交换消息、数据和控制项的目的。

描述外部软件组件所需的服务，以及组件间通信的本质。

确定将在软件组件之间共享的数据。

如果必须用一种特殊的方式来实现数据共享机制，例如一个全局数据区，那么就必须把它定义为一种实现上的约束。

通信接口

[描述产品将使用的所有通信功能的需求，包括电子邮件、WEB浏览器、网络通信协议和电子表格等。

定义所有相关的消息格式。

规定通信安全或加密问题、数据传输速率和同步通信机制等。

如果没有，需标明不适用。

5其它非功能性需求

[这部分用于定义所有非功能性需求，而不是外部接口需求，外部接口需求应该包括在第4部分中，也不是约束，约束应该记录在第2.5部分]

性能需求

[声明各种系统操作特定的性能需求，并解释其原理以指导开发人员做出合理的设计选择，指定每秒支持处理的交易量、响应时间、运算精度和实时系统的定时关系。

还应该指定内存和磁盘空间需求，并发的用户负载，或者数据库表中所能存储的最大行数。

如果不同的功能性需求或者特征具有不同的性能需求，那么比较合适的做法是使用其相应的功能性需求指定性能目标，而不要将他们都集中在这一部分中。

防护性需求

[这一部分声明与产品使用过程中可能发生的损失、破坏或危害相关的需求，定义必须采取的安全保护措施或动作，还有那些必须避免的可能危险的动作，明确产品必须遵循的安全标准、策略或规则。

安全性需求

[指定与安全性、完整性或保密性问题相关的所有需求，这些问题影响对产品的访问、使用以及产品所创建或使用的数据的保护。

安全性需求一般来源于业务规则，因此要确定产品必须遵守的所有安全或保密策略或规则。

另一个方法是，也可以在完整性质量属性中声明这些需求。

软件质量属性

[声明对可户或开发人员至关重要的其他产品质量特征。

这些特征必须是明确的、定量的和可以验证的。

应该指明各种属性的相对优先级，例如，容易使用与容易学习相比，要优先考虑容易使用，可移植性与有效性相比，要优先考虑可移植性。

6其它需求

[定义在此软件需求规格说明中其他部分未出现的所有其他需求，例如国际化需求及法律上的需求。

还可以添加操作、管理和维护等几部分来描述产品的安装、配置、启动和关闭、修复和容错，以及登陆和监控操作等方面的需求。

应在模板中加如与项目相关的任何新的需求部分。

如果不需要添加任何其他需求，就省略这一部分。

附录A术语表

[定义读者需要了解的所有专门术语（包括缩略词），以便他们能够正确地理解软件需求规格说明。

拼写出每一个缩略词的全称并给出其定义，还要考虑生成一个跨越多个项目的企业级术语表，然后在每个软件需求规格说明中只定义单个项目专用的术语。

附录B待确定问题的清单

[这一部分列出了有待于解决的需求问题。

这些问题包括标记为“待确定”的需求、悬而未决的决策、所需要的信息以及有待解决的冲突等。

这一部分并不是软件需求规格说明所必须的，但有些祖师总是在软件需求规格说明中附上一张“待确定”问题的列表。

我们要主动地管理这些问题直到解决，否则这些问题会成为我们及时将高质量的软件需求规格说明纳入基线的绊脚石。

THANKS!

!

致力为企业和个人提供合同协议，策划案计划书，学习课件等等

打造全网一站式需求

欢迎您的下载，资料仅供参考