城市管理坑洼跟踪和修复系统需求分析说明书.docx
《城市管理坑洼跟踪和修复系统需求分析说明书.docx》由会员分享，可在线阅读，更多相关《城市管理坑洼跟踪和修复系统需求分析说明书.docx（24页珍藏版）》请在冰豆网上搜索。
城市管理坑洼跟踪和修复系统需求分析说明书
CMHR系统项目
需求分析说明书
第01版
二oo三年七月二十四日
版本控制信息
版本
日期
拟稿和修改
说明
01.00
2003-7-23
梁峰
初稿
01.01
2003-7-25
梁峰
修订
01.02
2003-7-26
梁峰
最终稿
范围
1.1
1.2
1.3
标识
系统概述文档概述
引用文档
项目概述
3.1
3.2
3.3
目标
用户的特点
假定和约束
需求规定
4.1
4.2
4.2.1
功能需求性能需求精度
4.2.2
时间特性要求
4.2.3
4.3
4.4
4.5
4.6
4.7
4.7.1
灵活性
输入输出要求
数据管理能力要求故障处理要求
设计约束
属性
安全性
7
8
8
9
9
4.7.2
4.8
4.8.1
可维护性其它需求数据库..
4.8.2
操作
系统分析
10
5.1
5.2
5.3
数据流程图（DFD并附PSPEC）数据字典（DATADICTIONARY）实体关系图（ERD）
10
19
20
运行环境规定
22
6.1
6.2
6.3
硬件
支持软件接口需求
22
22
22
支持信息
22
1范围
1.1标识
QR-10-02
CMHR需求分析说明书
城市管理坑洼跟踪和修复系统（简称CMHR）S
1.2系统概述
CMHR是一个基于web的城市坑洼跟踪和修复系统，它为一般大城市的城市管理部门提供了高效快捷的工作方式，主要的设计目标是为了实现城市管理电子化网络化，使广大市民
真正的参与到城市管理中来，增强市民的主人翁精神和对于城市管理的责任感，另一方面相
对于以前的档案办公，电子化网络化的优势是极其明显的，它不但增大了信息的储存量，而且大大提高了城管各部门的协调能力，使有限的人力财力资源得到了最大化的应用。
1.3文档概述
该文档详细描述了CMHR系统的需求规约，为进一步的概要设计和详细设计奠定了基础。
引用文档
《需求文档模板（国标）》
《CMHR系统需求分析草稿》
项目概述
在应用于实际之后，将大大提
它将替代现有的城市坑洼管理系
本软件的开发是实现城市管理网络化电子化的大胆尝试，
高城市坑洼管理的效率，真正意义上实现高效无纸化办公。
统。
另外，整个系统是基于城市管理系统的，是整个管理系统的一个子系统。
3.2用户的特点
本软件的最终用户将是广大热心市民，城市管理人员以及系统维护人员。
对于广大市民只要求有基本的电脑操作知识和会浏览网页即可。
对于城市管理人员，要求了解基本的电脑操作知识，有过使用管理系统的经历最佳。
对于系统维护人员要求有管理大型数据库的能力，另外还须对本系统有一定的了解，够在发生普通的异常情况时，根据使用说明手册进行维护。
3.3假定和约束
因为现有的城市坑洼管理系统陈旧不堪，需要CMHR尽快开发成功，政府方面要求以3
个月为期限。
开发经费方面，因为是A市对于城市管理系统的初次尝试，一切都是试探性的，所以资
金投入不是很大，尽量少花钱，多办事。
考虑到现有政府工作人员的计算机操作水平有限，希望开发的软件有良好的人机交互界面，较高的可操作性。
4需求规定
4.1功能需求
CMHR主要分为以下几个功能需求:
市民报告坑洼信息：
市民可以登陆网站并报告自己发现的坑洼，提交的坑洼概要信息包括:
坑洼所在街道，坑洼大小（大体），发现时间，坑洼现状。
系统对于用户填写的概要信息进行处理，根据坑洼所在位置，时间，坑洼现状等信息与数据库中现有信息进行比较，察看是否有类似记录，如果已有类似的坑洼报告，则提取此坑洼的详细信息，提示用户进行核实。
如果没有类似坑洼报告，则引导用户填写全面详细的情况报表，生成坑洼情况报告单。
用户报告完毕坑洼情况后，提示用户输入自己的姓名，家庭住址，联系电话，身份证号码等个人信息，记录入热心市民信息数据库。
坑洼信息报表评估（信息详化）
坑洼情况报告单输入，根据坑洼类型及参数标准信息对照表，加入新的更为详尽的信息，包括：
a.根据坑洼大小和尺寸对照表，确定坑洼大小等级（1-10）;b.根据城市街道区域图
路中或
和报告单中的街道地址，确定坑洼所在区域。
C.根据坑洼现状描述，确定所在位置
路边等）。
D.根据坑洼大小和坑洼所在区域，位置（生活区，工业区，商业区等的优先等级可能有所不同），确定坑洼修复的优先等级。
按照数据库现有坑洼信息报表，为此新坑洼分配一个唯一编号，生成最终的坑洼信息报表。
坑洼损害文件生成:
按照坑洼信息报表，安排调查人员实地考察一一核实坑洼信息报表中的各项，对于不准
确的信息给于精化，对于不正确的信息给予纠正，并且全面衡量各种信息（坑洼等级，所处地段，坑洼带来的危害等），最终确定是否需要对于此坑洼作进一步处理，如此坑洼暂时无需处理，则给予无需处理标记，将此信息报表备份归档。
如需继续处理，则给予需要处理且未处理标记。
未处理坑洼的施工分配:
检索未处理的坑洼损害文件，并从数据库中提取施工队的当前情况，依据坑洼的处理优先等级和施工队的当前状况，将优先等级较高的坑洼分配给近期无施工任务的施工队或施工任务较轻的施工队（此处需要一定的匹配算法）。
根据坑洼的大小，严重情况，所处地段，施工需要等信息，从仓库中分发施工材料以及所需装备给此施工队，最终根据这三方面信息
产生施工单。
向施工队分配施工任务。
施工完毕后对于损害文件的处理：
施工完毕后根据施工队施工过程中所消耗材料，工作日，人数等信息，关联施工队的简单信息和报告市民的信息后产生损害文件，备份入库，以备查询。
交互查询：
主要依据坑洼位置，大小，修复时间，负责的施工队，所耗材料，所耗人时等查询条件查询坑洼信息，施工队信息，材料设备使用状况等。
另外还可以查询热心市民信息，做出评比等。
CMHR是一个基于WEB勺管理系统，其并发程度很大程度上决定于WE冋艮务器和后台数据库的的并发处理能力，连接终端和同时并发用户数目控制在100。
4.2性能需求
4.2.1精度
该系统中没有对于较高数据精度的需要，例如：
市民报告坑洼情况时，对于坑洼位置精确到街道，坑洼大小给出目测的范围值即可（如0.5-1M），坑洼发现的时间精确到每日。
总之，对于所有的尺度量精确到CM日期精确到每日，人民币数目精确到元，时间长度度量精确到天。
在数据存储和传输过程中与输入时相同。
4.2.2时间特性要求
响应时间：
对于用户输入的响应时间大体上决定于网络传输速度。
更新处理时间：
坑洼的更新信息应该维持在每天。
规格说明号：
数据的转换和传送时间：
解题时间：
4.2.3灵活性
操作方式的变化：
运行环境的变化：
WEB服务器进行更新时，对于整个程序的结构应该没有太大的影响同整个城市管理系统其他部分接口的变化：
因为后台数据库与整个城市管理系统是集成在一起的，采用分布式数据库，对于数据的利用达到最大化。
当整个分布式数据库发生变化时，如果数据库关系模式无变化，只牵扯数据的导出和重新导入，如果模式变化，则需要进行异构数据库间的转化，较为复杂。
精度和有效时限的变化:
此CMHR系统的应用时间初步定位为10年，可以考虑使用过程中的系统硬件软件升级问题。
计划的变化或改进:
如果出现计划变化和改进，需要小组成员协调处理。
4.3输入输出要求
市民信息数据类型
数据项
格式
数值范围
精度
姓名
***（张三）
不超过8个字
地址
***（真南路）
不超过20个字
电话
********
长度为8位
12345678
身份证号码
*******
长度为15位
123456789012345
坑洼数据类型
数据项
格式
数值范围
精度
坑洼标识
HYYMMDD*
k
某年某月某日发现的几号
街道地址
长安街
不超过10个字
坑洼大小
位置
★
**
1-10
路中，路边
1
区域
***
坑洼状态
***
未处理，处理中
处理完毕
修理队编号
G****
实际参加人数
**人
0-20人
1人
修理使用时间
**天
1-10天
一天
损坏类型
**
严重，一般，轻微
施工工具成本数据类型
数据项
格式'
数值范围
精度
名称
***
不超过8个字
固定成本
***Y
100-500Y
1Y
单位成本
***Y/H
10-50Y/H
1Y/H
施工材料成本数据类型
数据项
格式
数值范围
精度
名称
***
不超过8个字
单位成本
***Y/单位
10-50Y/单位
1Y/单位
施工队信息数据类型
数据项
格式
数值范围
精度
施工队编号
G****
长度固定为5个字符
施工队名称
****
不超过10个字
人数
**人
1-50人
1人
当前工作状态
**
工作，空闲
4.4数据管理能力要求
10年中，关于坑洼的记录在1万条左右，报告坑洼1000条，而A市现有坑洼修复施工队伍20
城市建设越来所以数据量大幅增长，对于系统的数据库也提出50万条数据存储的能力。
一般的大型数据库应该
根据A市现运行系统来看，过去的的市民资料因为过一段时间会清理，所以大体在个，每个月平均的坑洼修复记录在100条左右。
但随着城市发展步伐的加快,
越重要，而且市民的主人翁精神也在增强，了挑战，为了做长远打算，要求数据库有能够胜任，例如oracle，db2等。
4.5故障处理要求
硬件故障：
如果经常发生类
DBA切实做好
WEB服务器运行超负荷，网站连接发生问题，市民不能登陆
似问题，要考虑升级服务器。
软件故障：
数据库管理系统出现故障，可能发生数据丢失，这就需要系统
数据备份工作，在数据库发生故障时，能够迅速的给予恢复，保证系统的正常运
行。
4.6设计约束
WEB
必须考虑WEB服务器的承受能力，在资金各方面允许的情况下，可以考虑大型的
服务器。
因为硬件的约束，所以开发时要切实根据服务器负载能力较好的进行并发控制。
4.7属性
4.7.1安全性
CMHR在使用过程中，要特别注意系统的安全性防护，一方面个城市管理系统的分布式数据库的一个站点，据安全，对于数据库的使用权限严格界定，作。
另一方面，作为基于WEB的管理系统,和严格的身份审核制度，防止服务器被攻击。
4.7.2可维护性
整个系统的各个功能高度模块化，达到高内聚低耦合的目标，实现清晰的模块接口，明确每个模块的功能，方便以后的系统维护，如果一个功能模块出现问题，不会致使整个系统瘫痪。
另外，有完整的数据库管理制度，以保证数据库的数据的完整性，安全性。
作为WEB项目，服务器端的管理维护异常重要，一定要保证程序有足够的并发性能。
4.8其它需求4.8.1数据库
因为CMHR系统服务器端
升级会员 