软件需求规格说明书.docx

软件需求规格说明书.docx

《软件需求规格说明书.docx》由会员分享，可在线阅读，更多相关《软件需求规格说明书.docx（19页珍藏版）》请在冰豆网上搜索。

软件需求规格说明书

XXX项目

软件需求规格说明书

文件状态：

[]草稿

[√]正式发布

[]正在修改

文档编号：

当前版本：

密级：

部公开

作者：

完成日期：

---------------------------------------------------------------------

安慧软件对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。

变更记录

版本号

修改点说明

变更人/创建人

存放位置

审批人

审批日期

修改点说明的容有如下几种：

创建、修改（+修改说明）、删除（+删除说明）

1.引言5

1.1.项目背景5

1.2.编写目标5

1.3.建设目标（可选）5

1.4.系统围6

1.5.定义/术语/缩写6

1.6.参考资料6

1.7.文档阅读指南（可选）7

2.总体说明7

2.1.产品介绍7

2.2.假设和依赖（可选）8

2.3.局限性和排斥性（可选）8

3.功能描述8

3.1.业务描述9

3.2.用户说明9

3.3.基本配置及运行环境9

3.4.用户场景9

3.4.1.用例总览10

3.4.2.详细用例说明10

4.非功能性需求11

4.1.性能要求12

4.2.可靠性（可选）12

4.3.安全性（可选）12

4.4.可移植性（可选）13

4.5.设计限制（可选）13

4.6..电源、工艺结构要求（可选）13

4.7.逻辑数据库需求（可选）13

4.8.其他需求13

5.接口说明13

5.1.用户界面13

5.2.硬件接口14

5.3.软件接口14

5.4.通信接口14

6.需求变更流程15

7.设计描述（可选）15

7.1.设计和实现的约束条件15

7.2.设计架构15

7.3.分析模型15

7.4.数据库设计15

7.5.接口函数/类/对象16

8.其他（可选）16

8.1.故障处理16

8.2.项目风险预估16

8.3.客户和市场需求16

9.项目建设安排16

9.1.项目优先级16

9.2.功能优先级17

9.3.项目进度计划17

9.4.项目人员配置管理17

9.5.项目实施方案18

10.附录（可选）18

10.1.数据字典18

10.2.业务规则18

10.3.算法说明18

10.4.相关干系人概览18

10.5.待确定问题清单19

10.6.用户文档19

10.7.相关文档19

1.引言

1.1.项目背景

此处说明项目建设的原由与背景，对项目建设容的历史和现状进行概括性的描述，最终说明为什么决定开发该产品。

直接引用用户需求说明或产品需求规格说明书中对应章节容即可。

1.2.项目目标

此处一般描述两项容：

1．项目的建设目标，及该项目的成功实施给客户带来的商业上的利益。

2．定义该项目成功实施的标准，如项目的进度目标，质量目标等等。

直接引用用户需求说明或产品需求规格说明书中对应章节容即可。

1.1.系统围

概述本系统的相关业务围，划清系统边界，明确项目的工作容。

直接引用用户需求说明或产品需求规格说明书中1.3项目边界章节容即可。

1.2.适用围

此处描述：

编写软件需求规格说明书的主要目的和适用的读者。

读者对象一般包括：

需求提供方具体责任人、评审人员、开发方的项目经理、系统分析设计人员、测试人员等。

1.3.定义/术语/缩写

此处描述：

文档中所有需要向读者解释的专业术语、名词定义、简称、缩写、项目组达成一致意见的专用词汇等。

包括:

词汇的来源、定义、对该词汇的其它叫法等。

若容较多，也可将这些的信息放在附录或其他文档中描述。

直接应用用户需求说明书中1.5术语表章节容即可，如果软件需求规格说明书中还引用了新的术语，也需要更新到该表中。

2.总体说明

2.1.系统介绍

该章节从以下几个方面来对系统进行概要性的介绍。

1．系统功能结构图：

着重从业务层面来介绍该系统，如果有关键业务过程，可用文字进行补充说明

示例一：

示例二：

示例只提供参考，不产生任何约束性要求。

2．系统结构图：

从系统的交互来描述各个子系统之间的关系

示例一：

示例二：

示例只提供参考，不产生任何约束性要求。

3．高层数据流图

示例一：

示例只提供参考，不产生任何约束性要求。

4．网络拓扑图

示例：

示例只提供参考，不产生任何约束性要求。

5．系统部署图

示例：

示例只提供参考，不产生任何约束性要求。

6．关键业务过程（可选）：

对本项目的关键业务过程进行描述，也可以通过业务流程图来表示

2.2.用户说明

对该系统的用户/用户类进行说明，可直接引用用户需求说明或产品需求规格说明书中的“用户与角色”章节

2.3.假设和依赖（可选）

建议在此处描述所有会影响需求的因素。

这些因素不是设计限制，但是只要他们改变就会影响需求规格说明书里的需求。

例如：

（1）某个具体的操作系统必须适用于为这个产品设计的硬件。

如果这个操作系统不适用了，需求规格说明书就会相应改变。

（2）假设与其他系统的接口程序由对应系统的厂商在接口开发前提供。

（3）假设各地市已有监控系统正常使用，且网络速度不低于2M/s.

注意：

这部分叙述的容都是我们潜意识都知道，但容易遗漏的部分。

2.4.基本配置及运行环境

建议在此处描述：

产品的软硬件配置以及运行环境。

若配置清单过长，则可在本处简述后，指定配置详细清单的存放位置（例如：

附录或者另一份文档中）。

3.功能描述

详细定义软件需求规格说明书的每个具体需求。

具体需求应当按逻辑可读的方式组织。

注意：

（1）描述清楚对非正常情况和非法值的处理。

（2）描述清楚临界点或者系统边界。

按功能结构图进行细化，软件需求规格说明书书的功能结构应该与用户需求说明书的功能结构基本一致，按照子系统（可选）、模块、功能、功能点逐层进行拆分与细化

3.1.信号控制

3.1.1.信号监控

3.1.1.1.GIS监控

3.1.1.1.1.1查看路口交通信号情况

1.功能描述：

通过GIS地图显示信号机分布情况，选择地图上信号机图标或者选择信号机编号，可以显示该路口的信息，包括该路口信号机的工作参数，周期、运行相位、相位时间、路口闯红灯设备采集的视频图像。

2.UI界面：

3.前置条件：

无

4.输入：

无

5.输出：

路口编号、路口名称、生产厂家、信号机IP、当前信号机状态，方案号、周期、当前运行相位、阶段数、控制方式、相位时间

6.处理过程：

1：

在GIS监控页面，在左侧设备树单击设备（或搜索），定位到GIS地图的具体位置

2：

双击GIS地图上信号机图标获取信号机ID请求相关接口和订阅信号机实时运行信息

7.业务规则：

无

3.1.1.1.1.2控制信号机

1.功能描述：

信号配时人员可以通过平台向信号控制系统下发控制指令：

进行相位控制、单点控制。

2.UI界面：

3.前置条件：

无

4.输入：

无

5.输出：

1：

相位控制状态信息（锁定、恢复、快进、步进），相位配时信息输出下发成功

2：

单点控制（方案控制方式）

6.处理过程：

1：

在GIS监控页面，在左侧设备树单击设备（或搜索），定位到GIS地图的具体位置

2：

双击GIS地图上信号机图标获取信号机ID请求相关接口和订阅信号机实时运行信息

3：

控制相位：

锁定、恢复、快进、步进，相位配时信息的编辑下发，灯态控制

7.业务规则：

1）基于GIS地图展示信号机分布

2）下发的控制指包括：

相位控制（锁定、恢复、快进、步进）、单点控制（方案控制方式）

3.1.1.1.1.3监控信号机设备实时状态

1.功能描述：

交通信号控制系统设备出现故障，GIS地图上相应显示为故障，详细故障信息可通过打开信号控制系统界面进行查看

2.UI界面：

3.前置条件：

无

4.输入：

信号机设备名称（支持模糊搜索）

5.输出：

GIS地图图标故障为红色，在信号机管理页面展示信号机详细故障描述信息

6.处理过程：

无

7.业务规则：

无

3.1.1.2.信号机方案设计

1.功能描述：

信号配时人员可以通过平台事先对信号机的相位设计、方案配时、调度计划进行实时配置，以便在使用信号机的时候能够对信号机进行正常的调度控制。

2.UI界面：

3.前置条件：

无

4.输入：

1相位添加：

相位号（最大支持32个相位）、相位通道

2配时添加：

相位差、相位号、绿灯时间、红灯时间、黄灯时间、延迟时间

3调度计划添加：

调度日期、时段划分、配时方案号、控制模式、辅助功能

4相位删除：

相位号

5配时删除：

配时方案号

6调度计划删除：

调度计划号

7相位修改：

相位号

8配时修改：

配时方案号

9调度计划修改：

调度计划号

5.输出：

1相位添加：

添加成功

2配时添加：

添加成功

3调度计划添加：

添加成功

4相位删除：

删除成功

5配时删除：

删除成功

6调度计划删除：

删除成功

7相位修改：

修改成功

8配时修改：

修改成功

9调度计划修改：

修改成功

6.处理过程：

无

7.业务规则：

1）配置的相位不能有冲突

3.1.1.3.查询交通信号控制指令下发日志

1.功能描述：

用户要能查询对信号机任何控制操作的日志情况。

2.UI界面：

3.前置条件：

无

4.输入：

日志类别、操作类型、操作日期：

5.输出：

列表

6.处理过程：

无

7.业务规则：

1）根据操作类型、操作时间查询；

2）操作类型包括：

黄闪控制、步进控制、快进控制、锁定相位、停止控制、检测器维护、人工校时、其他

3.1.1.4.信号机配置管理

1.功能描述：

用户可在相应图层的GIS地图上对信号机进行添加、修改、删除等操作。

2.UI界面：

3.前置条件：

无

4.输入：

1添加信号机：

设备名称、设备编号、所属机构、型号、厂商、IP、关联视频、接入平台、最大相位数

2删除信号机：

信号机ID

3修改信号机：

信号机需要修改的基本信息

5.输出：

1添加信号机：

添加成功

2删除信号机：

删除成功

3修改信号机：

修改成功

6.处理过程：

无

7.业务规则：

1）设备编号长度18位

2）设备号唯一

示例：

用户管理（是将用户管理作为一个功能点还是将增删改查作为一个功能点，根据具体需求的复杂程度来由项目组自行决定）

功能描述：

增加新用户，并能用户进行修改、删除、查询

UI界面：

前置条件：

无

输入：

用户名、、性别、年龄、单位、联系方式

输出：

一条用户记录

处理过程：

1.用户进入用户管里界面，添加用户，输入用户基本信息，点击保存

2.保存成功，用户能够在用户列表中查询到该条用户信息。

3.若输入用户基本信息非法，则提示保存失败。

4.对选定的用户进行基本信息的修改，点击保存后能修改成功

5.对选定的用户进行删除，删除成功后列表中不再显示该用户信息

6.可以对用户进行查询，支持模糊查询。

业务规则：

1.用户名不可重复，可重复。

2.只有管理员拥有删除用户的权限。

4.E-R图

在此章节画出本系统的实体关系图。

5.性能需求

在此章节要描述本系统的数据量（接入设备的数据量）需求以指导开发人员在进行软件设计时，性能上至少要满足此数据量的要求。

6.其他非功能性需求

6.1.可靠性（可选）

系统在一定时间、在一定条件下无故障地执行指定功能的能力或可能性。

例如：

除电源、硬件、操作系统、服务器管理系统外，程序不允许异常退出或崩溃。

24小时不间断运行。

6.2.安全性（可选）

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

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

可从如下方面考虑系统的安全性：

（1）网络安全（信息认证）

（2）资料安全（重要信息加密）和用户权限管理（用户信息，操作权限明确）

（3）日志管理

（4）数据备份（例如：

系统灾难恢复）

注意：

有些系统的安全性要求高，可能会独立成一章，描述从安全管理制度到安全保护措施的所有容。

安全管理制度定义了用户在系统使用过程中应当遵循的安全原则。

6.3.可移植性（可选）

本节列出确保用户程序和用户界面的兼容方面的需求，以及把被开发软件从一种运行环境移植到另一个运行环境的需求等。

6.4.设计限制（可选）

写明任何因为行业标准、公司制度、硬件条件原因所导致的设计限制。

注意：

此处的限制是指客户的要求导致的设计限制。

例如：

客户要求采取B/S架构.

系统在开发过程中涉及的设计限制将在第七章设计描述中说明。

6.5.其他需求

建议在此处描述：

任何上述没有提到的非功能性需求。

例如国际化需求以及法律上的需求。

7.接口说明

7.1.硬件接口

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

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

可以用列表的形式来表述，如：

硬件名称

厂商

设备类型

通信协议

7.2.软件接口

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

8.附件

8.1.API说明

如果有接口需求，应该附上对应的API说明文档。

8.2.相关文档

列举出该需求规格说明书参考的文档