软件需求规格说明书(2)

1、xxx项目软件需求规格说明书文件状态：文档编号： 草稿当前版本： 正式发布密级：内部公开 正在修改作者：完成日期：-合肥安慧软件有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。.变更记录版本号修改点说明变更人 /存放位置审批人审批日期创建人修改点说明的内容有如下几种：创建、修改（+修改说明）、删除（ +删除说明）.目 录1.引言.51.1.项目背景 .51.2.编写目标 .错误 ! 未定义书签。1.3.建设目标（可选） .错误 ! 未定义书签。1.4.系统范围 .51.5.定义 / 术语 /缩写 .51.6.

2、参考资料 .错误 ! 未定义书签。1.7.文档阅读指南（可选） .错误 ! 未定义书签。2.总体说明 .62.1.产品介绍 .62.2.假设和依赖（可选） .92.3.局限性和排斥性（可选） .错误 ! 未定义书签。3.功能描述 .93.1.业务描述 .错误 ! 未定义书签。3.2.用户说明 .错误 ! 未定义书签。3.3.基本配置及运行环境 .错误 ! 未定义书签。3.4.用户场景 .错误 ! 未定义书签。3.4.1.用例总览 . 错误 ! 未定义书签。3.4.2.详细用例说明 . 错误 ! 未定义书签。4. 非功能性需求 .204.1.性能要求 .错误 ! 未定义书签。4.2.可靠性（可选

3、） .204.3.安全性（可选） .204.4.可移植性（可选） .204.5.设计限制（可选） .204.6.电源、工艺结构要求（可选） .错误 ! 未定义书签。4.7.逻辑数据库需求（可选） .错误 ! 未定义书签。4.8.其他需求 .215.接口说明 .215.1.用户界面 .错误 ! 未定义书签。5.2.硬件接口 .215.3.软件接口 .215.4.通信接口 .错误 ! 未定义书签。6.需求变更流程 .错误 ! 未定义书签。7.设计描述（可选） .错误 ! 未定义书签。.7.1.设计和实现的约束条件 .错误 ! 未定义书签。7.2.设计架构 .错误 ! 未定义书签。7.3.分析模型

4、.错误 ! 未定义书签。7.4.数据库设计 .错误 ! 未定义书签。7.5.接口函数 /类 /对象 .错误 ! 未定义书签。8.其他（可选） .错误 ! 未定义书签。8.1.故障处理 .错误 ! 未定义书签。8.2.项目风险预估 .错误 ! 未定义书签。8.3.客户和市场需求 .错误 ! 未定义书签。9.项目建设安排 .错误 ! 未定义书签。9.1.项目优先级 .错误 ! 未定义书签。9.2.功能优先级 .错误 ! 未定义书签。9.3.项目进度计划 .错误 ! 未定义书签。9.4.项目人员配置管理 .错误 ! 未定义书签。9.5.项目实施方案 .错误 ! 未定义书签。10.附录（可选） .错误

5、 ! 未定义书签。10.1.数据字典 .错误 ! 未定义书签。10.2.业务规则 .错误 ! 未定义书签。10.3.算法说明 .错误 ! 未定义书签。10.4.相关干系人概览 .错误 ! 未定义书签。10.5.待确定问题清单 .错误 ! 未定义书签。10.6.用户文档 .错误 ! 未定义书签。10.7.相关文档 .21.1. 引言1.1. 项目背景此处说明项目建设的原由与背景，对项目建设内容的历史和现状进行概括性的描述，最终说明为什么决定开发该产品。直接引用用户需求说明或产品需求规格说明书中对应章节内容即可。1.2. 项目目标此处一般描述两项内容：1项目的建设目标，及该项目的成功实施给客户带来

6、的商业上的利益。2定义该项目成功实施的标准，如项目的进度目标，质量目标等等。直接引用用户需求说明或产品需求规格说明书中对应章节内容即可。1.1. 系统范围概述本系统的相关业务范围，划清系统边界，明确项目的工作内容。直接引用用户需求说明或产品需求规格说明书中1.3 项目边界章节内容即可。1.2. 适用范围此处描述：编写软件需求规格说明书的主要目的和适用的读者。读者对象一般包括：需求提供方具体责任人、评审人员、 开发方的项目经理、系统分析设计人员、测试人员等。1.3. 定义 /术语 /缩写此处描述：文档中所有需要向读者解释的专业术语、名词定义、简称、缩写、项目组内达成一致意见的专用词汇等。包括 :

7、 词汇的来源、定义、对该词汇的其它叫法等。若内容较多，也可将这些的信息放在附录或其他文档中描述。.直接应用用户需求说明书中1.5 术语表章节内容即可，如果软件需求规格说明书中还引用了新的术语，也需要更新到该表中。2. 总体说明2.1. 系统介绍该章节从以下几个方面来对系统进行概要性的介绍。1系统功能结构图：着重从业务层面来介绍该系统，如果有关键业务过程，可用文字进行补充说明示例一 ：示例二：示例只提供参考，不产生任何约束性要求。.2系统结构图：从系统的交互来描述各个子系统之间的关系示例一：示例二：示例只提供参考，不产生任何约束性要求。3高层数据流图示例一：.示例只提供参考，不产生任何约束性要求

8、。4网络拓扑图示例：示例只提供参考，不产生任何约束性要求。5系统部署图示例：示例只提供参考，不产生任何约束性要求。.6关键业务过程（可选）：对本项目的关键业务过程进行描述，也可以通过业务流程图来表示2.2. 用户说明对该系统的用户/ 用户类进行说明， 可 直接引用用户需求说明或产品需求规格说明书中的 “用户与角色”章节2.3. 假设和依赖（可选）建议在此处描述所有会影响需求的因素。这些因素不是设计限制，但是只要他们改变就会影响需求规格说明书里的需求。例如：（1）某个具体的操作系统必须适用于为这个产品设计的硬件。如果这个操作系统不适用了，需求规格说明书就会相应改变。（2）假设与其他系统的接口程序

9、由对应系统的厂商在接口开发前提供。（3）假设各地市已有监控系统正常使用，且网络速度不低于2m/s.注意：这部分叙述的内容都是我们潜意识都知道，但容易遗漏的部分。2.4. 基本配置及运行环境建议在此处描述：产品的软硬件配置以及运行环境。若配置清单过长，则可在本处简述后，指定配置详细清单的存放位置（例如：附录或者另一份文档中）。3. 功能描述详细定义软件需求规格说明书的每个具体需求。具体需求应当按逻辑可读的方式组织。注意：（ 1）描述清楚对非正常情况和非法值的处理。（ 2）描述清楚临界点或者系统边界。.按功能结构图进行细化，软件需求规格说明书书的功能结构应该与用户需求说明书的功能结构基本一致，按照

10、子系统（可选）、模块、功能、功能点逐层进行拆分与细化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 监控页面，在左侧

11、设备树单击设备(或搜索 )，定位到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 地图上信号机图标获取信号机

12、id 请求相关接口和订阅信号机实时运行信息3：控制相位：锁定、恢复、快进、步进，相位配时信息的编辑下发，灯态控制7. 业务规则：1）基于 gis 地图展示信号机分布2）下发的控制指包括：相位控制（锁定、恢复、快进、步进）、单点控制（方案控制方式）3.1.1.1.1.3 监控信号机设备实时状态1.功能描述： 交通信号控制系统设备出现故障，gis 地图上相应显示为故障，详细故障信息可通过打开信号控制系统界面进行查看2.ui 界面：.3. 前置条件： 无4. 输入： 信号机设备名称 ( 支持模糊搜索 )5. 输出： gis 地图图标故障为红色， 在信号机管理页面展示信号机详细故障描述信息6. 处理过

13、程： 无7. 业务规则： 无3.1.1.2. 信号机方案设计1.功能描述： 信号配时人员可以通过平台事先对信号机的相位设计、方案配时、 调度计划进行实时配置，以便在使用信号机的时候能够对信号机进行正常的调度控制。2. ui 界面：.3. 前置条件： 无.4. 输入：1 相位添加：相位号(最大支持 32 个相位 )、相位通道2 配时添加：相位差、相位号、绿灯时间、红灯时间、黄灯时间、延迟时间3 调度计划添加：调度日期、时段划分、配时方案号、控制模式、辅助功能4 相位删除：相位号5 配时删除：配时方案号6 调度计划删除：调度计划号7 相位修改：相位号8 配时修改：配时方案号9 调度计划修改：调度计

14、划号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）操作类型包括：黄闪控制、步进控制

15、、快进控制、锁定相位、停止控制、检测器维护、人工校时、其他3.1.1.4. 信号机配置管理1.功能描述： 用户可在相应图层的gis 地图上对信号机进行添加、修改、删除等操作。2. ui 界面：3.前置条件： 无4.输入：1 添加信号机：设备名称、设备编号、所属机构、型号、厂商、ip、关联视频、接入平台、最大相位数2 删除信号机：信号机id3 修改信号机：信号机需要修改的基本信息5.输出：1 添加信号机：添加成功2 删除信号机：删除成功.3 修改信号机：修改成功6.处理过程： 无7.业务规则：1)设备编号长度18 位2)设备号唯一示例： 用户管理 （是将用户管理作为一个功能点还是将增删改查作为一

16、个功能点，根据具体需求的复杂程度来由项目组自行决定）功能描述：增加新用户，并能用户进行修改、删除、查询ui 界面：.前置条件：无输入： 用户名、姓名、性别、年龄、单位、联系方式输出： 一条用户记录处理过程：1. 用户进入用户管里界面，添加用户，输入用户基本信息，点击保存2. 保存成功，用户能够在用户列表中查询到该条用户信息。3. 若输入用户基本信息非法，则提示保存失败。4. 对选定的用户进行基本信息的修改，点击保存后能修改成功5. 对选定的用户进行删除，删除成功后列表中不再显示该用户信息6. 可以对用户进行查询，支持模糊查询。业务规则：1. 用户名不可重复，姓名可重复。2. 只有管理员拥有删除

17、用户的权限。4. e-r 图在此章节画出本系统的实体关系图。5. 性能需求在此章节要描述本系统的数据量（接入设备的数据量）需求以指导开发人员在进行软件设计时，性能上至少要满足此数据量的要求。.6. 其他非功能性需求6.1. 可靠性（可选）系统在一定时间内、在一定条件下无故障地执行指定功能的能力或可能性。例如： 除电源、硬件、操作系统、服务器管理系统外，程序不允许异常退出或崩溃。24 小时不间断运行 。6.2. 安全性（可选）指定与安全性、 完整性或保密性问题相关的所有需求， 这些问题影响对产品的访问、 使用以及产品所创建或使用的数据的保护。 安全性需求一般来源于业务规则， 因此要确定产品必须遵

18、守的所有安全或保密策略或规则。可从如下方面考虑系统的安全性：（ 1）网络安全（信息认证）（ 2）资料安全（重要信息加密）和用户权限管理（用户信息保密，操作权限明确）（ 3）日志管理（ 4）数据备份（例如：系统灾难恢复）注意： 有些系统的安全性要求高， 可能会独立成一章， 描述从安全管理制度到安全保护措施的所有内容。安全管理制度定义了用户在系统使用过程中应当遵循的安全原则。6.3. 可移植性（可选）本节列出确保用户程序和用户界面的兼容方面的需求，以及把被开发软件从一种运行环境移植到另一个运行环境的需求等。6.4. 设计限制（可选）写明任何因为行业标准、公司制度、硬件条件原因所导致的设计限制。注意：此处的限制是指客户的要求导致的设计限制。例如： 客户要求采取 b/s 架构 .系统在开发过程中涉及的设计限制将在第七章设计描述中说明。.