城市管理坑洼跟踪和修复系统需求分析说明书(2)

产生施工单。向施工队分配施工任务。

?

施工完毕后对于损害文件的处理：

施工完毕后根据施工队施工过程中所消耗材料，工作日，人数等信息，关联施工队的简单信息和报告市民的信息后产生损害文件，备份入库，以备查询。

?

交互查询：

主要依据坑洼位置，大小，修复时间，负责的施工队，所耗材料，所耗人时等查询条件查询坑洼信息，施工队信息，材料设备使用状况等。另外还可以查询热心市民信息，做出评比等。

CMHRS是一个基于WEB的管理系统，其并发程度很大程度上决定于WEB服务器和后台数据库的的并发处理能力，连接终端和同时并发用户数目控制在100。

4.2 性能需求

4.2.1 精度

该系统中没有对于较高数据精度的需要，例如：市民报告坑洼情况时，对于坑洼位置精确到街道，坑洼大小给出目测的范围值即可（如0.5-1M），坑洼发现的时间精确到每日。总之，对于所有的尺度量精确到CM，日期精确到每日，人民币数目精确到元，时间长度度量精确到天。在数据存储和传输过程中与输入时相同。

4.2.2 时间特性要求

? 响应时间：

对于用户输入的响应时间大体上决定于网络传输速度。 ? 更新处理时间：

坑洼的更新信息应该维持在每天。 ? ? ?

规格说明号：

数据的转换和传送时间： 解题时间：

4.2.3 灵活性

? ? ? ? ?

操作方式的变化： 运行环境的变化：

WEB服务器进行更新时，对于整个程序的结构应该没有太大的影响 同整个城市管理系统其他部分接口的变化：

因为后台数据库与整个城市管理系统是集成在一起的，采用分布式数据库，对于数据的利用达到最大化。当整个分布式数据库发生变化时，如果数据库关系模式无变化，只牵扯数据的导出和重新导入，如果模式变化，则需要进行异构数据库间的转化，较为复杂。

6

? ? ? ?

精度和有效时限的变化：

此CMHRS系统的应用时间初步定位为10年，可以考虑使用过程中的系统硬件软件升级问题。

计划的变化或改进：

如果出现计划变化和改进，需要小组成员协调处理。

4.3 输入输出要求

市民信息数据类型

数据项 姓名 地址 电话 身份证号码 格式 ***（张三） ***（真南路） ******** ******* 数值范围 不超过8个字 不超过20个字 长度为8位 长度为15位 精度 12345678 123456789012345 坑洼数据类型

数据项 坑洼标识 街道地址 坑洼大小 位置 区域 坑洼状态 修理队编号 实际参加人数 修理使用时间 损坏类型

格式 HYYMMDD** 长安街 * ** *** *** G**** **人 **天 ** 数值范围 精度 某年某月某日发现的几号 不超过10个字 1-10 路中，路边 未处理，处理中 处理完毕 0-20人 1-10天 严重，一般，轻微 1 1人 一天 7

施工工具成本数据类型

数据项 名称 固定成本 单位成本 格式 *** ***￥ ***￥/ H 数值范围 不超过8个字 100-500￥ 10-50￥/ H 精度 1￥ 1￥/ H 施工材料成本数据类型

数据项 名称 单位成本 格式 *** ***￥/ 单位 数值范围 不超过8个字 10-50￥/单位 精度 1￥/ 单位 施工队信息数据类型

数据项 施工队编号 施工队名称 人数 当前工作状态

格式 数值范围 G**** 长度固定为5个字符 **** **人 ** 不超过10个字 1-50人 工作，空闲 精度 1人 4.4 数据管理能力要求

根据A市现运行系统来看，过去的10年中，关于坑洼的记录在1万条左右，报告坑洼的市民资料因为过一段时间会清理，所以大体在1000条，而A市现有坑洼修复施工队伍20个，每个月平均的坑洼修复记录在100条左右。但随着城市发展步伐的加快，城市建设越来越重要，而且市民的主人翁精神也在增强，所以数据量大幅增长，对于系统的数据库也提出了挑战，为了做长远打算，要求数据库有50万条数据存储的能力。一般的大型数据库应该能够胜任，例如oracle，db2等。

4.5 故障处理要求

?

硬件故障：

WEB服务器运行超负荷，网站连接发生问题，市民不能登陆,如果经常发生类似问题，要考虑升级服务器。 ?

软件故障：

数据库管理系统出现故障，可能发生数据丢失，这就需要系统DBA切实做好数据备份工作，在数据库发生故障时，能够迅速的给予恢复，保证系统的正常运

8

行。

4.6 设计约束

必须考虑WEB服务器的承受能力，在资金各方面允许的情况下，可以考虑大型的WEB服务器。因为硬件的约束，所以开发时要切实根据服务器负载能力较好的进行并发控制。

4.7 属性

4.7.1 安全性

CMHRS在使用过程中，要特别注意系统的安全性防护，一方面CMHRS的数据库系统是整个城市管理系统的分布式数据库的一个站点，它的安全性涉及到整个城市其他管理系统的数据安全，对于数据库的使用权限严格界定，由专人DBA负责管理维护，并定期作数据备份工作。

另一方面，作为基于WEB的管理系统，WEB服务器的安全性不容小觑，必须设置防火墙和严格的身份审核制度，防止服务器被攻击。

4.7.2 可维护性

整个系统的各个功能高度模块化，达到高内聚低耦合的目标，实现清晰的模块接口，明确每个模块的功能，方便以后的系统维护，如果一个功能模块出现问题，不会致使整个系统瘫痪。

另外，有完整的数据库管理制度，以保证数据库的数据的完整性，安全性。

作为WEB项目，服务器端的管理维护异常重要，一定要保证程序有足够的并发性能。

4.8 其它需求

4.8.1 数据库

因为CMHRS系统服务器端所依靠的数据库是作为整个A市城市管理数据库的一部分，整个数据库系统是分布式结构，CMHRS数据库只是一个站点而已，所以必须考虑与整个数据库系统的整合，在设计数据库时要和整个数据库系统的模式一致，不但本站点数据库可以使用其它站点上的数据，而且其他站点也应该可以应用本站点的数据，考虑使用相同的DBMS,尽量减少数据传输过程中的转化，提高效率。

4.8.2 操作

市民登陆报告坑洼状况时，应该使用户界面亲切友好，以简单易用为宗旨，减少不必要的操作和可能引起歧义的操作要求，尽量在最短的时间内，以最少的操作步骤引导市民完成报告坑洼情况的过程，并且对于市民的报告要给予鼓励的话，以提高广大市民的城市主人翁精神。

城市规划管理人员在操作本软件时，已经具备了一定的电脑操作知识，而且对本系统有

9

了一定的认识，必须提醒管理人员注意系统的安全问题，对于登陆密码等不能轻易泄漏，保障系统的安全。

5 系统分析

5.1 数据流程图（DFD并附PSPEC）

?

第0层数据流程图： DFD0： 说明：

CMHRS系统(F0)接受市民的坑洼情况举报，对坑洼进行确认，初步判断坑洼情况，将其标记并归档。此归档的坑洼信息可供市民和施工管理部门查看

CMHRS系统根据一定的划分标准将坑洼划分为不同等级，并在此基础上进行时间和财力的初步判定，生成损害文件，可供施工管理部门查看。

施工管理部门将施工队当前的情况输入CMHRS系统，系统根据一定的算法进行人力物力资源的分配。并生成施工单。施工管理部门按照此施工单进行施工。

10

施工队 市民 CMHRS系统管理员

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库城市管理坑洼跟踪和修复系统需求分析说明书(2)在线全文阅读。