软件需求规范(V1.0.0.0)

合集下载

软件需求规范

软件需求规范软件需求规范是对软件实施的全过程进行描述和指导的一种综合文件，是软件开发的基础文档之一。

软件需求规范的主要目的是明确软件的功能、性能、界面、安全等方面的需求，为软件开发和测试提供依据。

软件需求规范一般包括以下内容：1. 介绍：对软件的背景、目的、范围、读者等进行介绍，为后续内容提供背景信息和上下文。

2. 功能需求：对软件的主要功能进行详细描述，包括输入、输出、处理逻辑等方面的需求。

可以采用用例图、用例描述等方式进行描述。

3. 非功能需求：对软件的性能、可靠性、安全性、可用性等方面的需求进行详细描述。

可以包括性能指标、数据安全性要求、用户友好性等方面的要求。

4. 界面需求：对软件的用户界面进行详细描述，包括界面布局、样式、交互逻辑等方面的要求。

可以采用界面原型、界面流程图等方式进行描述。

5. 数据需求：对软件的数据模型、数据流程、数据存储等方面的需求进行描述。

可以使用数据模型图、数据流程图等方式进行描述。

6. 约束和限制：对软件开发和实施过程中的约束和限制进行描述，包括时间、成本、技术平台、法律法规等方面的约束。

7. 接口需求：对软件与其他系统、硬件设备等的接口进行描述，包括数据格式、通信协议、接口功能等方面的要求。

8. 测试需求：对软件测试的需求进行描述，包括测试用例、测试环境、测试数据等方面的要求，为测试人员提供指导。

软件需求规范应具有以下特点：1. 明确性：需求规范中的要求应该具有明确性，能够让软件开发人员和测试人员一目了然，不产生二义性。

2. 完整性：需求规范应该尽可能地覆盖软件的各个方面，包括功能需求、非功能需求、界面需求等。

3. 一致性：需求规范中的各个部分应该是一致的，相互之间不产生矛盾。

4. 可追踪性：需求规范应该具有可追踪性，能够将需求与软件的设计、实现、测试等阶段进行关联。

5. 可验证性：需求规范中的要求应该是可验证的，能够通过测试或其他手段进行验证。

以上只是软件需求规范的一些基本要点，具体的需求规范内容和格式可以根据具体项目的情况进行调整。

GJB5000A2008全套资料2204-2019软件配置管理规程

Q/BBTNL B B T N L A A A电子有限责任公司企业标准Q/BBTNL 2204-2019软件配置管理规程2019-05-31发布 2019-06-01实施BBTNLAAA电子有限责任公司发布XXX 2204-2019前言本标准代替Q/BBTNL 2204-2018《软件配置管理规程》。

本标准与Q/BBTNL 2204-2018相比，主要变化如下：1.修改开发库的建议结构；2.增加受控库的建议结构；3.过程记录流水号标识为可选项；4.修改开发库的存盘名称；5.统一标识规则的描述。

本标准由平台研究部提出并归口管理。

本标准由平台研究部起草。

本标准主要起草人：XXX。

本标准所代替标准的历次版本发布情况：----Q/BBTNL 2204-2018。

Q/LJDZ 2204-2019软件配置管理规程1 范围本标准定义了软件配置项的标识规则；规定了软件配置管理中基线管理、更改控制、配置管理记录、配置审核的基本要求；规定了软件开发库、受控库、产品库的管理要求。

本标准适用于本公司军用软件配置管理实施过程。

2 引用文件GB/T 11457-2006 信息技术软件工程术语GJB 5000A-2008 军用软件研制能力成熟度模型S/BBTNL XZ06-2018 档案管理制度3 术语与定义GB/T 11457《信息技术软件工程术语》和GJB 5000A《军用软件能力成熟度模型》确定的术语和定义适用于本标准。

4 活动4.1 软件配置项标识4.1.1 文档标识文档是在软件项目开发过程中产生的软件工作产品，是形成软件产品的部件或依据，属于软件配置项。

为了方便检索配置项，需对每个文档的标识和其存盘命名进行规定。

文档标识规则为：图号+空格+文件缩写+空格+版本号文档存盘命名规则：（文档标识）+文档名称+文件后缀例如：控制信号处理板项目，该项目的图号为：DZJ3160，该项目的软件需求规格说明，版本号为V1.0.0，则：文件标识为：DZJ3160 SRS V1.0.0文档存盘名称为：（DZJ3160 SRS V1.0.0）控制信号处理板软件需求规格说明.doc4.1.2 代码标识代码标识包括软件产品标识、计算机软件配置项标识、计算机软件配置单元标识。

软件需求规范

软件需求规范文稿归稿存档编号：[KKUY-KKIO69-OTM243-OLUI129-G00I-FDQS58-编制：审核：批准：目录1.简介.......................................................1.1.系统简介..............................................1.2.文档目的..............................................1.3.文档范围..............................................1.4.与其它开发任务/文档的关系.............................1.5.文档结构..............................................1.6.术语和缩写词..........................................1.7.项目背景..............................................2.参考文档...................................................3.系统及软件概述.............................................3.1.软件目标功能..........................................3.2.运行环境..............................................3.3.限制条件..............................................4.需求假设...................................................5.需求分析...................................................6.软件范围...................................................7.功能需求...................................................8.质量属性需求...............................................9.接口需求...................................................9.1.用户界面..............................................9.2.硬件接口..............................................9.3.软件接口..............................................9.4.通信接口..............................................10.安全需求..................................................11.系统限制..................................................12.需求追踪..................................................1.简介1.1.系统简介提示：对系统进行简要介绍，包括系统的安全目标，安全评估的类型等。

软件需求规格说明(规范)

GC508.04 密级：（软件项目名称）软件需求规格说明标识：版本：页数：拟制：SQA审核：审核：批准：拟制部门：年月日修改文档历史记录：日期版本说明修改人目录1 范围 (1)1.1 标识 (1)1.2 系统概述 (1)1.3 文档概述 (1)2 引用文档 (1)3 需求 (1)3.1 要求的状态和方式 (1)3.2 CSCI能力需求 (2)3.2.X（CSCI能力） (2)3.3 CSCI外部接口需求 (2)3.3.1 接口标识和接口图 (2)3.3.X（接口的项目唯一的标识符） (2)3.4 CSCI内部接口需求 (3)3.5 CSCI内部数据需求 (3)3.6 适应性需求 (3)3.7 安全性需求 (3)3.8 保密性需求 (3)3.9 CSCI环境需求 (4)3.10 计算机资源需求 (4)3.10.1 计算机硬件需求 (4)3.10.2 计算机硬件资源使用需求 (4)3.10.3 计算机软件需求 (4)3.11 软件质量因素 (4)3.12 设计和实现约束 (4)3.13 人员需求 (4)3.14 培训需求 (4)3.15 后勤保障需求 (4)3.16 其它需求 (4)3.17 验收、交付和包装需求（修改有关内容） (4)3.18 需求的优先顺序和关键程度 (5)4 合格性规定 (5)5 需求可追踪性 (5)6 注释 (5)1 范围1.1 标识【本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号及发布号。

】1.2 系统概述【本条应概述本文档所适用的系统和软件的用途。

它还应描述系统与软件的一般特性；概述系统开发、运行和维护的历史；标识项目的需方、用户、开发方和保障机构；标识当前和计划的运行现场；列出其它有关文档。

】1.3 文档概述【本条应概述文档的用途和内容，并描述与它的使用有关的保密性方面的要求。

】2 引用文档【本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识所有不能通过正常采购活动得到的文档的来源。

软件开发软件需求说明书编写规范

1详细需求1.1 功能需求1.1.1 功能需求 1关于每一类功能或许有时关于每一个功能，需要详细描绘其输入、加工和输出的需求。

由四个部分构成：a．前言描绘的是功能要达到的目标、所彩的方法和技术，还应清楚说明功能企图的由来和背景。

b．输入详尽描绘该功能的所有输入数据，如：输入源、数目、胸怀单位、时间设定、有效输入范围（包含精度和公差）；操作员控制细节的需求。

此中闻名字、操作员活动的描绘、控制台或操作员的地点。

比如：当打印检查时，要求操作员进行格式调整；3)指明引用接口说明或接口控制文件的参照资料。

c．加工定义输入数据、中间参数，以获取预期输出结果的所有操作。

它包含以下的说明：1)输入数据的有效性检查；2)操作的次序，包含事件的时间设定；3)响应，比如，溢出、通讯故障、错误办理等；4)受操作影响的参数；5)降级运转的要求；6)用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）；7)输出数据的有效性检查。

d．输出1)详尽描绘该功能所有输出数据，比如：输出目的地、数目、胸怀单位、时间关系、有效输出的范围（包含精度和公差）、非法值的办理、犯错信息；2)有关接口说明或接口控制文件的参照资料。

别的，对侧重于输入输出行为的系统来说，需求说明应指定所有存心义的输入、输出对及其序列。

当一个系统要求记忆它的状态时，需要这个序列，使得它能够依据本次输入和从前的状态作出响应。

也就是说，这类状况如同有限状态机。

1.1.2 功能需求 2．．．．．．功能需求n1.2 外面接口需求1.2.1 用户接口供给用户使用软件产品时的接口需求。

比如，假如系统的用户经过显示终端进行操作，就一定指定以下要求：a．对屏幕格式的要求；b．报表或菜单的页面打印格式和内容；c．输入输出的相对时间；d．程序功能键的可用性。

1.2.2 硬件接口要指出软件产品和系统硬零件之间每一个接口的逻辑特色。

还可能包含以下事宜：支撑什么样的设施，怎样支撑这些设施，有何商定。

软件需求规范(V1.0.0.0)

河南新创元信息网络有限公司软件需求规范文档修订历史记录目录1引言.............................................................................................................................. 错误！未定义书签。

1.1目的 ......................................................................................................... 错误！未定义书签。

1.2范围 ......................................................................................................... 错误！未定义书签。

1.3参考资料 ................................................................................................. 错误！未定义书签。

2管理.............................................................................................................................. 错误！未定义书签。

2.1组织机构模型 ......................................................................................... 错误！未定义书签。

2.2任务 ......................................................................................................... 错误！未定义书签。

软件需求规格说明书v1.0.0.0

软件需求规格说明书规范编制：审核：批准：版本号：生效日期：目录1．引言 (3)1.1目的 (3)1.2文档约定 (3)1。

3预期的读者和阅读建议 (3)1。

4术语、定义、符号及缩略语 (3)1.5参考文献 (3)2.项目概述 (3)2.1项目背景 (4)2.2项目的功能 (4)2。

3用户类和特征 (4)2.4运行环境 (4)2。

5遵循标准和规范 (4)3。

业务描述 (5)3。

1用户组织机构模型 (5)3。

2用户业务流模型 (5)3。

3用户角色模型 (5)4.功能需求描述 (5)4。

1子模块系统 (5)5。

非功能性需求 (6)5.1用户界面要求 (6)5.2软硬件环境需求 (6)5。

3其它要求 (6)6.附录 (7)附录A：词汇表（术语表） (7)附录B：分析模型 (7)附录C：待定问题列表 (7)1．引言1.1目的对项目进行定义，在该文档中详尽说明这个项目的软件需求，包括修正或者发行版本号。

如果这个软件需求规格说明只与整个系统的一部分有关系，那么只定义文档中说明的部分或子系统。

1.2文档约定描写编写文档时所采用的标准或者排版约定，包括正文风格、提示区或重要符号。

1.3预期的读者和阅读建议列举了软件需求说明规格说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或者文档的编写人员.描述了文档中剩余部分的内容及其组织结构。

提出了最适合于每一类读者阅读文档的建议。

1.4术语、定义、符号及缩略语对文档中出现频率高的术语、定义、符号及缩略词进行说明。

1.5参考文献列举编写软件需求规格说明书时所参考的资料或其它资源。

可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档或相关软件需求规格说明。

在这里，应给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源,以便于读者查阅这些文献。

2.项目概述这部分概述了正在定义的项目以及它所运行的环境、使用项目的用户和已知的限制、假设和依赖。

软件需求规格说明书

软件需求规格说明书1范围1.1标识SRS适用范围：城市教育资源管理系统标识号：GDGL004标题：城市教育资源管理系统版本号：V1.0发行号：Alpha001（内测版）1.2系统概述随着我国政治体制改革、经济体制和教育体制改革的不断深入，城市教育在构建和谐社会中发挥着重要作用。

教育资源的优劣，直接关系着教育效益的产出。

教育资源管理的好坏将直接影响着学校的建设和发展。

目前中国城市人均教育经费差异很大，城市间高等教育阶段生师比的差距比较大,而基础教育的差距相对较小;城市经济发展水平是影响这些差异的主要因素,其次是城市人口规模;促进不发达地区城市和小城市的经济发展、建立合理的人口流动机制是消除城市间教育资源差异的有利措施。

城市教育资源管理系统是指综合运用地理信息系统（GIS）、多媒体及虚拟现实等现代信息技术实现面向高校教学管理部门提供教学资源管理的服务平台，对学校校舍、课桌、教学用具等硬件设施和师资力量等软件设施的信息的采集、集成和管理，根据地区各等级基础教育学校个数、学校规模和周边做涵盖教育分配地区，确定各个学校教育资源的优劣、所需教育人员以及所能容纳学生人数，也可以进行教育资源的调动管理，教职工人事变动管理，教学资源合理分配与再分配，地区教育质量评价等等。

它的建设将为教育部门对教育资源的管理起到很重要的监督和管理作用。

并能够作为一项新兴的部门管理方法。

1.3文档概述在信息化高速发展的今天，时间效率这样的名词正主导着人们的生活和发展,有必要设计开发一个城市教育资源管理系统。

通过系统功能有效的解决城市间教育经费、教育阶段生师比等等间的差异，从而提高管理效率。

本文档具体对城市教育资源管理系统的软件需求等进行基本分析，确定该系统基本功能及需求，故在此针对本系统编写此文档，本文档的最终解释权在本小组手中，请勿随意更改。

1.4基线本文档的设计基线是《GBT8567-2006计算机软件文档编制规范》。

2引用文件[1]GBT8567-2006计算机软件文档编制规范. 2006[2]Y.Daniel Liang著李娜译,JA V A语言程序设计．北京：机械工业出版社2012[3]刘先锋,数据库系统原理与应用. 武汉：华中科技大学出版社2012[4]谢希仁,计算机网络（第五版）．北京：电子工业出版社20123需求3.1所需的状态和方式教育局，学校管理员根据各自实际身份登录城市教育资源管理系统，如果登录成功，则启动相应的管理系统，以及相应的权限，实现各项功能。

软件需求规格说明书模板(超详细的哦)

WORD文档可编辑X X X X X X单位X X X X X X X项目软件需求规格说明书金碧信息科技目录第一章引言 (5)1编写目的 (5)2软件需求分析理论 (5)3软件需求分析目标 (5)4参考文献 (6)第二章需求概述 (7)1.项目背景 (7)2.需求概述 (7)3.条件与限制(可选) (8)4.移动办公系统结构 (8)5.移动办公网络拓扑图 (9)第三章系统功能需求 (10)1.移动办公系统升级改造需求 (10)界面显示要求 (11)待办公文列表 (11)待办公文列表排序 (11)公文详细信息界面元素 (11)网站信息审批 (12)会议申请 (12)意见录入 (12)移动邮件 (12)会议管理 (13)通知通告 (13)通讯录管理 (14)2.车辆管理模块升级改造需求 (14)系统功能架构 (14)网络拓扑结构 (15)3.电子公文预览需求 (15)电子公文交换网络 (16)电子公文交换流程 (18)4.政务信息管理系统平台功能需求 (19)第四章软硬件或其他外部系统接口需求 (21)1.用户界面 (21)2.硬件需求 (22)3.网络需求 (22)4.接口需求 (22)5.通信需求 (23)6.运行环境 (23)第五章其他非功能需求 (24)1.性能需求 (24)2.安全设施需求 (25)3.安全性需求 (25)4.扩展性需求 (26)5.可移植性需求 (26)第一章引言1编写目的为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。

2软件需求分析理论软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。

软件需求分析是一个项目的开端，也是项目实施最重要的关键点。

据有关的机构分析结果表明，设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。

中国移动软件需求规格说明书_v1.00

沟通从心开始REACHING OUT FROM THE HEART. . . . . . .中国移动XXXX 分公司【项目名称】软件/系统需求规格说明书（SRS ）版本 <V1.0>拟制日期审核日期批准日期声明本文件所有权和解释权归CMCC所有，未经CMCC书面许可，不得复制或向第三方公开。

修订历史记录目录1.引言 (5)1.1.编写目的 (5)1.2.系统涵盖范围 (5)1.3.缩略词 (5)1.4.假设和限制 (5)1.5.文档组织结构 (5)1.6.参考资料 (5)2.系统概貌 (6)2.1.系统远景 (6)2.2.体系结构 (6)2.3.系统边界和A CTORS (6)2.4.系统功能 (6)2.5.用户特性 (6)2.6.一般限制 (6)2.7.出错处理 (6)2.8.假设和依赖条件 (6)3.功能性需求 (7)3.1.【子系统1】 (7)3.1.1.【模块 1】 (7)3.1.2.【模块 2】 (7)3.2.【子系统2】 (7)3.2.1.【模块 3】 (7)3.2.2.【模块 4】 (7)4.用例视图 (9)4.1.【子系统1】 (9)4.2.【子系统2】 (9)5.外部接口需求 (10)5.1.用户接口 (10)5.2.硬件接口 (10)5.3.软件接口 (10)5.4.通信接口 (10)6.非功能性需求 (11)6.1.易用性 (11)6.2.可靠性 (11)6.3.性能 (11)6.4.可维护性 (12)6.5.安全性 (12)6.6.可扩展性 (12)7.系统配置 (13)7.1.硬件和软件配置 (13)7.2.网络配置 (13)7.3.网络拓扑图 (13)7.4.开发环境 (13)附件 A:术语表 (14)附录 B: 分析模型 (15)附录C: 问题清单 (16)1. 引言1.1. 编写目的【本节应该完成如下工作:1. 描述本SRS的直接目的例：对开发小组–本SRS作为概要设计，系统测试计划，测试案例编写等的输入源。

软件产品需求规范

2、写清楚查询规则，是只能但条件查询或者是可以多个条件查询。
3、写清楚查询范围。如图文信息，是查询标题或者标题和内容都可以查询。
展示方式
1、一页展示的信息条数。电脑端默认展示10条。
2、标题最长展示两行，超出用.....代替
3、PC端图文信息默认展示行数。超出进行折叠。
4、APP端图文信ቤተ መጻሕፍቲ ባይዱ默认展示行数。超出进行折叠。
3、写明哪些是有默认值的，默认内容是什么、格式是什么；
4、写明哪些是需要选择的，选择项从哪里来，
5、写明哪些是从选择中带入过来的，如选择人员后带入人员的性别，身份证号等；
6、写明多级选择或前后填写顺序的填写规则要求；如：如果选择置顶，则首页图片必须上传等
7、写明是否需要做重复验证，验证如何做
修改方式
业务逻辑
1、写清楚具体的业务逻辑
2、写明是否需要批量导入，如果导入，提供导入模板。
3、写明是否导出，如果导出，提供具体导出模板，是固定模板或者自定义多种样式。
4、其他增删改查或者流程中需要特别注意的业务逻辑信息
1、写明逐条修改或者可以批量修改是的修改规则；
2、写明修改跳转；
3、写明是否需要做重复验证，验证如何做
删除功能
1、支持逐条删除
2、支持批量删除
3、删除时的业务逻辑，如部门下面有人员，则不能删除部门或直接删除部门的时候，删除部门下面的所有人员，并删除人员所关联的所有账号信息等
查询功能
1、写清楚查询项，默认查询基础信息所有固定字段项。在页面上可以显示常用的几项，不常用的折叠。
产品需求规范
1、权限说明
对各大板块，不同角色的使用权限做出详细说明。
2、功能说明
（1）带有跳转逻辑的原型图

软件需求规格说明

软件需求规格说明软件需求规格说明（Software Requirement Specification）1 引⾔1.1 ⽬的本⽂档描述了⼀个⼩型图书资料管理系统MiniLibrary V1.0版本的软件功能需求和⾮功能需求，其阅读对象是本项⽬的客户、开发和维护系统的开发团队成员。

1.2 ⽂档约定本⽂档的命名遵从如下规范：SRS-XXX-YYY：需求标识●XXX表⽰需求类型。

需求类型分为3类：接⼝需求INT、功能需求FUN、⾮功能需求NTF；●YYY表⽰具体需求项，⽤3位数字表⽰。

UC-XXX：⽤例标识●XXX表⽰具体⽤例项，⽤3位数字表⽰。

ANL-DGM-UCR-XXX：⽤例实现交互图标识●XXX表⽰具体⽤例实现交互图项，⽤3位数字表⽰。

ANL-XXX-CLS-YYY：分析类标识●XXX表⽰分析类类型。

分析类类型分为3类：边界类BOD、控制类CTR、实体类ENT；●YYY表⽰具体分析类项，⽤3位数字表⽰。

1.3 预期的读者和阅读建议●项⽬管理⼈员可以根据功能的优先级来安排项⽬的开发进程；●项⽬开发⼈员可以根据分析模型来指导系统设计和详细设计；●测试⼈员可以根据详细的⽤例描述来指导测试⽤例的开发。

1.4 产品的范围⼩型图书资料管理系统MiniLibrary是⼀个基于WEB的应⽤软件，它允许读者在线搜索图书资料信息，并且可以预订⽬前借不到的图书资料。

同时，图书管理员使⽤计算机实现对学院图书资料的登记、借出、归还、查询等管理。

1.5 参考⽂献《⽤户界⾯规格说明（User Interface Specification）》2 综合描述2.1产品的前景MiniLibrary系统是⼀个应⽤计算机的新系统，它取代了当前在某学院图书资料室以⼿⼯⽅式管理图书资料的过程，可以提⾼学院图书资料管理的⼯作效率，并为读者带来便利。

该系统有图书管理员和普通读者两种⽤户，普通读者必须⾸先进⾏注册才可以使⽤该系统。

图书管理员负责添加、更新和删除系统中的图书资料信息，并登记和查询图书资料的借出或归还情况。

软件需求文档规范

需求文档的规范需求文档需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致协议。

协议综合了业务需求、用户需求和软件功能需求。

就像我们早先所看到的，项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求。

你必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。

只有以结构化和可读性方式编写这些文档，并由项目的风险承担者评审通过后，各方面人员才能确信他们所赞同的需求是可靠的。

你可以使用以下三种方法编写软件需求规格说明：用好的结构化和自然语言编写文本型文档。

建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。

编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。

由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。

虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。

包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。

图形化分析模型通过提供另一种需求视图，增强了软件需求规格说明。

软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。

它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。

除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。

许多读者使用软件需求规格说明来达到不同的目的：客户和营销部门依赖它来了解他们所能提供的产品。

项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源。

软件开发小组依赖它来理解他们将要开发的产品。

测试小组使用软件需求规格说明中对产品行为的描述制定测试计划、测试用例和测试过程。

软件维护和支持人员根据需求规格说明了解产品的某部分是做什么的。

软件需求规格说明书(格式规范)

项目名称（The English Name）软件需求规格说明书XXX项目小组修订表审批记录目录1.引言 (5)1.1目的 (5)1.2适用范围 (5)1.3参考资料 (5)1.4术语和缩略语 (5)2.系统概述 (5)2.1产品描述 (5)2.2产品功能 (6)2.3一般约束 (6)3.功能性需求分类 (6)3.1功能描述1 (9)3.2功能描述2 (9)4.产品的非功能性需求 (9)4.1外部接口说明 (9)4.1.1用户接口 (9)4.1.2软件接口 (10)4.2性能需求 (10)4.2.1硬件的限制 (10)4.3属性 (10)4.3.1友好性 (10)4.3.2安全性 (10)4.3.3可维护性 (10)4.3.4可转移/换性 (10)4.4系统的运行环境 (11)4.5其他需求 (11)4.5.1用户操作需求 (11)附录A：需求确认 (12)1.引言1.1目的【说明编写这份软件需求说明书的目的，小组长、项目负责人和其他各部门领导及用户是文档的预期读者。

明确系统范围、系统与其他系统的接口问题、及用户的各种功能、界面等需求。

由预期读者签字确认，审核人中应该包括用户部门领导。

】1.2适用范围【说明：a. 待开发的软件系统的名称；b. 说明软件将干什么，如果需要的话，还要说明软件产品不干什么；c. 说明软件与其他系统的接口，本系统要完成什么，不完成什么，要实现的系统功能，需要其他系统提供什么，本系统需要为其他系统提供什么。

】1.3参考资料1.4术语和缩略语2.系统概述2.1产品描述【叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。

解释被开发软件与其他有关软件之间的关系。

如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。

如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张结构图来说明该系统的组成和本产品同其他各部分的联系和接口。

软件需求规定

一、功能需求(1)售饭消费系统。

该售饭系统主要由售饭终端、发卡机、通信网卡以及售饭管理软件组成，具有性能稳定、传输速率快，网络容量大，数据安全性能好，使用方便、安全可靠等特点，具有主机、窗口机、等多种存储方式，多重保护，任何时候均确保数据准确、可靠、不丢失。

每台终端也可脱机运行，然后将所有的售饭信息定期上传给管理主机进行处理，即使在断电情况下，亦可将数据保存而不丢失。

(2)门禁控制系统。

本门禁系统能够24小时限制人员、车辆进出支队大院，保护财产安全。

对进入大院的人员、车辆进行详细的实时记录，可设置在什么日期, 什么时间,可通行什么门，对所有门均可在软件中设定门的开启时间,重锁时间, 以及每天的固定常开时间，从而获得更高的安全性和控制水平。

(3)大院、询问室监控系统。

该系统采用8路视频监控设备，嵌入彩色数码摄像机，大容量硬盘储存，高清晰录像，支持24小时不间断实时监控和录像，录像回放和提取，录像资料保存30天以上，实现动态录像、静态监控功能。

二、性能需求(1)售饭消费系统。

系统采用ID卡作为身份验证，多重加密，防止假冒和非法卡使用，确保系统运行安全可靠。

同时应具有：a、电源与节电方式，收费终端自带电源，确保掉电或流动使用时连续工作八小时以上；间断工作时自动进入待机保护状态，节电并延长设备使用寿命。

b、报警提示，设备自检设计可对运行情况达到实时监控，使用非法卡、挂失卡或运行异常等即时报警提示，系统维护简便。

(2)门禁控制系统。

门禁系统是支队大院主要出入口通道, 是为保障支队办公秩序和财产安全设定的，除了安装电控锁具、门磁开关外, 还安装遥控器、自动感应式非接触读卡器，门禁系统采用先进的接近式读卡技术, 避免多次插卡造成的物理损伤和卡片丢失与被盗现象。

同时感应卡门禁系统具有多种报警状态，并通过中心控制主机加以区别和处理, 如对非法卡的限制，电控门锁损坏, 控制门开启超过设定时间未关闭, 破坏读卡器等事件进行自动报警，确保高度保安的可靠性。

软件需求执行规范

文件编号文件类型制订日期
-CP-RJ-WI- 0001 三级文件/3 2013-11-07
页版
码本
1 OF 3 A0 2013-12-01
生效日期
软件需求执行规范
№
版本
修订记录修订摘要
修订人
日期
编
制
审
查
批
准
1.0 目的：
文件编号文件类型制订日期
-CP-RJ-WI- 0001 三级文件/3 13-11-07
文件编号文件类型制订日期
-CP-RJ-WI- 0001 三级文件/3 2013-11-07
页版
码本
3 OF 3 A0 2013-12-01
生效日期
5.3 审批流程：
客户
经测试后释放软件
提需求整理需求
软件工程师
安排软件释放软件
方案部门
达标
不达标
测试结果反馈测试工程师
测试测试结果反馈软件经理
阶段性软件不达标
审核
客户确认的软件达标
项目部量产
6.0 参考文件：无。 7.0 表格记录： 7.1《软件项目记录表》 7.2《软件测试报告模板》
页版
码本
2 OF 3 A0 2013-12-01
生效日期
规范、建立软件部门工作流程，确保新项目的客户的软件需求顺利及时地开展并且完成。 2.0 范围：本规定适用于软件部对客户需求的规范管控。 3.0 职责/权限： 3.1 软件工程师负责对客户软件需求的整合，深刻理解客户需求，并提交与方案部门，使方案部门获知并且实现客户需求。并且在当软件版本释放时，安排好软件的测试，将测出的 BUG,及时反馈到方案部门得以解决。安排销售推广样机和客户需求样机的测试。在软件需求开发过程中，做好软件版本的相应的配置记录，进度记录以及在本地分类并保存好软件版本。 3.2 测试工程师负责对客户软件测试并真实反馈软件版本存在的问题，一并写入软件测试报告中，当测试完成，要及时发邮件通知相应的软件工程师相关的问题，以便及时发现问题并解决；对于销售经理要求的样机测试，要进行基本功能点测，测试完成后发现硬件相关问题要向相应的项目经理反馈该问题，解决后再重新点测。 4.0 定义：无。 5.0 程序： 5.1 新项目客户需求： 5.1.1 当客户下单或者立项时，软件工程师要与该项目的项目经理获取该项目的详细配置，同时申请两台该项目的样机，以便进行测试工作。 5.1.2 当客户下单或者立项时，软件工程师向销售经理获取客户的具体需求，整合需求向方案公司安排需求工作，并及时追回软件释放时间。 5.1.3 当客户确认软件时，软件工程师向测试工程师以及方案部门申请软件全功能测试。 5.2 客户软件阶段性版本测试以及最终版本的测试： 5.2.1 对于客户阶段性软件版本的测试，软件工程师安排测试工程师进行软件基本功能点检测试，测试结果以邮件形式发往软件经理以及软件工程师，经软件经理核实后再决定是否能外发到客户。 5.2.2 对于客户量产软件版本的测试，软件工程师安排测试工程师进行软件全功能检测表，同时根据客户需求表核对客户需求是否达标，测试完成后将结果以邮件的形式发往软件工程师，软件工程师综合方案部门的测试报告发往软件经理，经软件经理核实后再决定是否能进行量产。