整理了个软件需求规格说明书模板

 

 

 

1、引言

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

1.1目的

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

本文档详细描述影像系统一期工程中的必须满足的功能需求、非功能需求（质量属性和外部接口）与限制条件，作为本项目的项目管理人员、系统设计人员、编码和测试人员以及与本项目相关的其他人员开展工作的基础和依据，同时也界定了本项目的工作内容。

 

1.2文档约定

在本文档中描述的所有需求都有一个唯一的编号标识。该需求编号在需求确立时产生并在整个项目开发过程中保持不变。

1.3读者对象和阅读建议

(列举软件需求规格说明面向的不同读者对象。描述软件需求规格说明中其余部分的内容及其组织结构。就每一类读者最合适以什么顺序来阅读该文档提出建议)

本文档的读者包括参与本项目的项目管理人员、系统设计人员、编码和测试人员、用户代表以及市场人员，上述读者可以通过阅读本文档对将要开发的影像系统有一个全面、详细的了解和认识。

 

1.4项目范围

（提供对指定的软件及其作用的简短描述。把软件与用户或公司目标向关联，把软件与义务目标和策略相关联。如果可以得到单独的前景和范围文档，就应该引用它，而不要直接将其内容复制到这里。如果是说明改进产品的增量发布的软件需求规格说明，那么应该包括它自己的范围声明，作为长期战略的产品前景的一个子集。）

 

本系统是影像系统（一期）的产品，主要实现….

 

在本系统中实现 系统登录、图片管理、单证类型管理、权限管理。

 

1.5参考资料

（列举编写软件需求规格说明书时所参考的所有文档或其他资源，如果可能的话，使用超文本连接。具体说来可能包括用户界面样式指南、合同、标准、系统需求规格说明、用例文档、接口规格说明、操作概念文档、或相关产品的软件需求规格说明。在这里应该给出足够详细的信息，包括参考资料的标题、作者、版本号、日期以及来源或位置，以方便）

本文档引用如下参考文献：

 

 

2、总体描述

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

2.1系统前景

（描述从产品的背景和起源。说明该产品是否产品系列中的下一个成员，是否是成熟系统的下一个版本，是现有应用程序的升级产品还是一个全新的产品。如果该软件需求规格说明定义了大型系统的一个组件，那么就要说明这个部分软件是怎样与整个系统相关联的，并且要确定二者之间的主要接口。）

（系统用来做什么）

影像系统用来管理公司业务系统的图像信息，为公司其他业务系统提供统一的图像操作接口。

（系统最终会是什么样子）

     影像系统最终建设为非结构化数据的统一管理操作中心。

2.2 系统功能

         （列出产品所具有的主要特性或者产品可能实现的总要功能。其详细内容将在该软件需求规格说明的第3部分中描述，所以在此只需要提供一个总体概括即可。用图形来表示主要的需求组件以及它们之间的联系，例如顶层数据流图、用例图或者类图，可能是很有帮助的。）

   

   

2.3 用户分类及其特征

（确定我们能预料到的有可能使用该产品的各类用户类，并描述它们的相关特征。有些需求可能只与某些用户类相关，应确定哪些是优先考虑的用户类。用户类是前景和范围文档中描述的涉众的一个子集。）

2.4 运行环境

（描述软件的运行环境，包括硬件平台、操作系统版本，以及用户、服务器和数据库的地理位置。列出系统必须和平共存的其他软件组件或应用程序）

 

2.5 设计和实现上的约束

（

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

能包括如下内容： 

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

•  由产品的运行环境所引起的一些限制，例如，将要使用的web浏览器的类型

和版本。

•  所要求的开发约定或标准(例如，如果由客户的组织负责软件维护，那么该组

织就可能指定分包商必须遵循的设计符号和编码标准)。

•  与早期产品向后兼容。

•  业务规则强加的限制。

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

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

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

）

 

2.6 用户文档

（列出将要交付的用户文档组件以及可执行软件，可以包括用户手册、联机帮助和教程。确定所有要求的文档交付格式、标准或工具。）

3、系统功能需求

  3.1 系统功能a

3.a.1 描述和优先级

3.a.2 请求响应序列

3.a.3 功能性需求

4、外部接口需求

（外部接口需求指定了系统或组件必须与其进行接口的硬件、软件或数据库元素）

4.1 用户界面

   (描述系统所需的每个用户界面的逻辑特征。可能包括下面这些条目：

•  对图形用户界面(GUI)标准的引用或者将要采用的产品系列的样式指南。

•  有关字体、图标、按钮标签、图像、顔色选择方案、域的Tab顺序、常用控件等的标准

•  屏幕布局或解决方案的约朿。

•  每个屏幕中将出现的标准按钮、功能或导航链接，例如，帮助按钮。

•  快捷键。

•  消息显示约定。

•  便于软件定位的布局标准。

•  满足视力有问题的用户的要求。

 

应该将用户界面的设计细节，例如特定对话框的布局，写入单独的用户界面规格说明中，而不能写入软件需求规格说明中。应该将屏幕模型写入软件需求规格说明中，以便与需求的另一个视图进行交流，这样做是有益的，但要指明模型并不是所要提交的屏幕设计。如果软件需求规格说明描述的是对一个己有系统的改进，那么将实际将要实现的屏幕画面写入软件需求规格说明中，有时也是有意义的。开发人员己经被现有系统的当前现实所限制，因此，预先了解要修改的屏幕(也可能是新的屏幕)的精确外观也是应该的。

)

4.2 硬件接口

（描述系统中软件和硬件组件之间每一接口的特征。这种描述可能包括支持的设备类

型、软件和硬件之间的数据和控制交互以及所用的通信协议等。）

 

4.3 软件接口

（描述该产品与其他软件组件(由名称和版本来识别)之间的连接。这些组件包括数据库、操作系统、工具、库和集成的商业组件等。声明在软件组件之间交换消息、数据和控制项的目的，描述外部软件组件所需的服务，以及组件间通信的本质。确定将在软件组件之间共享的数据。如果必须用一种特殊的方式来实现数据共享机制，例如一个全局数据区，那么就必须把它定义为一种实现上的约束。）

 

4.4 通信接口

（描述产品将使用的所有通信功能的需求，包括电子邮件、Web浏览器、网络通信协

议和电子表格等。定义所有相关的消息格式，规定通信安全或加密问题、数据传输速率

和同步通信机制等。）

5、其他非功能性需求

5.1 性能需求

（声明各种系统操作特定的性能需求，并解释其原理以指导开发人员作出合理的设计选择。

例如，如果对数据库响应时间要求很严格，那么设计人员就会在多个地理位置放多个镜像数据库，或者是设计非规范化关系数据库表，以便更快速地响应査询请求。指定每秒钟支持处理的交易量、响应时间、运算精度和实时系统的定时关系。还应该指定内存和磁盘空问需求，并发的用户负载，或者数据库表中所能存储的最大行数。如果不同的功能性需求或特征具有不同的性能需求，那么比较合适的做法是使用其相应的功能性需求指定性能指标，而不要将它们都集中在这一部分中。

应当尽可能的量化性能需求。

）

 

5.2 防护性需求

 

5.3 安全性需求

（

指定与安全性、完整性或保密性问题相关的所有需求，这些问题影响对产品的访问、

使用以及产品所创建或使用的数据的保护。安全性需求一般来源于业务规则，因此要确

定产品必须遵守的所有安全或保密策略或规则。另一种方法是，也可以在完整性质量属

性中声明这些需求。下面是安全性需求的两个范例：

•  SE-1每个用户在第1次成功登录后，必须立即更改他最初的登录密码。最初

的登录密码不能重用。

•  SE-2如果门锁系统成功地读到安全性标记，那么门锁将保持打开状态8.0秒

）

5.4 软件质量属性

 

6 其他需求

（

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

(货币、日期格式、语言、国际规则以及文化和政治上的问题)及法律上的需求。还可以

添加操作、管理和维护等几部分来描述产品的安装、配置、启动和关闭、修复和容错，

以及登录和监控操作等方面的需求。应在模板中加入与项目相关的任何新的需求部分。

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

）

 

 

附录A：术语表

（定义读者霜要了解的所有专门术语(包括缩略词)，以便他们能够正确地理解软件需

求规格说明。拼写出每一个缩略词的全称并给出其定义，还要考虑生成一个跨越多个项

目的企业级术语表，然后在每个软件需求规格说明中只定义单个项目专用的术语。）

附录B：分析模型

（这一部分是可选的，它包括或指向相关的分析模型，例如：数据流图、类图、状态

转換图实体一关系图

）

附录C：待确定问题清单

（

这一部分列出了有待于解决的需求问题。这些问题包括标记为“待确定”（ to   be

determined ，TBD)的需求、悬而未决的决策、所需要的信息以及有待解决的冲突等。这

一部分并不是软件需求规格说明所必需的，但有些组织总是在软件需求规格说明中附上

一张“待确定”问题的列表。我们要主动地管理这些问题直到解决，否则这些问题会成

为我们及时将高廣量的软件需求规格说明纳入基线的绊脚石。

 

）