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

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

《城市管理坑洼跟踪和修复系统需求分析说明书.docx》由会员分享，可在线阅读，更多相关《城市管理坑洼跟踪和修复系统需求分析说明书.docx（28页珍藏版）》请在冰点文库上搜索。

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

CMHR系统项目

需求分析说明书

第01版

二oo三年七月二十四日

版本控制信息

版本

日期

拟稿和修改

说明

01.00

2003-7-23

梁峰

初稿

01.01

2003-7-25

梁峰

修订

01.02

2003-7-26

梁峰

最终稿

1范围4

1.1标识4

1.2系统概述4

1.3文档概述4

2引用文档4

3项目概述4

3.1目标4

3.2用户的特点4

3.3假定和约束5

4需求规定5

4.1功能需求5

4.2性能需求6

4.2.1精度6

4.2.2时间特性要求6

4.2.3灵活性6

4.3输入输出要求7

4.4数据管理能力要求8

4.5故障处理要求8

4.6设计约束9

4.7属性9

4.7.1安全性9

4.7.2可维护性9

4.8其它需求9

4.8.1数据库9

4.8.2操作9

5系统分析10

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

5.2数据字典（DATADICTIONARY）19

5.3实体关系图（ERD）20

6运行环境规定22

6.1硬件22

6.2支持软件22

6.3接口需求22

7支持信息22

1范围

1.1标识

QR-10-02

CMHR需求分析说明书城市管理坑洼跟踪和修复系统（简称CMHR）S

1.2系统概述

CMHR是一个基于web的城市坑洼跟踪和修复系统，它为一般大城市的城市管理部门提供了高效快捷的工作方式，主要的设计目标是为了实现城市管理电子化网络化，使广大市民

真正的参与到城市管理中来，增强市民的主人翁精神和对于城市管理的责任感，另一方面相

对于以前的档案办公，电子化网络化的优势是极其明显的，它不但增大了信息的储存量，而且大大提高了城管各部门的协调能力，使有限的人力财力资源得到了最大化的应用。

1.3文档概述

该文档详细描述了CMHR系统的需求规约，为进一步的概要设计和详细设计奠定了基础。

2引用文档

《需求文档模板（国标）》

《CMHR系统需求分析草稿》

3项目概述

3.1目标

本软件的开发是实现城市管理网络化电子化的大胆尝试，在应用于实际之后，将大大提

高城市坑洼管理的效率，真正意义上实现高效无纸化办公。

它将替代现有的城市坑洼管理系统。

另外，整个系统是基于城市管理系统的，是整个管理系统的一个子系统。

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-500¥

1¥

单位成本

***Y/h

10-50¥/H

1¥/H

施工材料成本数据类型

数据项

格式

数值范围

精度

名称

***

不超过8个字

单位成本

***¥/单位

10-50¥/单位

1¥/单位

施工队信息数据类型

数据项

格式

数值范围

精度

施工队编号

长度固定为5个字符

施工队名称

不超过10个字

人数

**人^

1-50人

1人

当前工作状态

**

工作，空闲

4.4数据管理能力要求

根据A市现运行系统来看，过去的10年中，关于坑洼的记录在1万条左右，报告坑洼

的市民资料因为过一段时间会清理，所以大体在1000条，而A市现有坑洼修复施工队伍20

个，每个月平均的坑洼修复记录在100条左右。

但随着城市发展步伐的加快，城市建设越来

越重要，而且市民的主人翁精神也在增强，所以数据量大幅增长，对于系统的数据库也提出

了挑战，为了做长远打算，要求数据库有50万条数据存储的能力。

一般的大型数据库应该

能够胜任，例如oracle，db2等。

4.5故障处理要求

硬件故障：

WEB服务器运行超负荷，网站连接发生问题，市民不能登陆,如果经常发生类

似问题，要考虑升级服务器。

软件故障：

数据库管理系统出现故障，可能发生数据丢失，这就需要系统DBA切实做好

数据备份工作，在数据库发生故障时，能够迅速的给予恢复，保证系统的正常运

行。

4.6设计约束

必须考虑WEB服务器的承受能力，在资金各方面允许的情况下，可以考虑大型的WEB

服务器。

因为硬件的约束，所以开发时要切实根据服务器负载能力较好的进行并发控制。

4.7属性

4.7.1安全性

CMHR在使用过程中，要特别注意系统的安全性防护，一方面CMHRS勺数据库系统是整

个城市管理系统的分布式数据库的一个站点，它的安全性涉及到整个城市其他管理系统的数据安全，对于数据库的使用权限严格界定，由专人DBA负责管理维护，并定期作数据备份工

作。

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

4.7.2可维护性

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

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

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

4.8其它需求

4.8.1数据库

因为CMHR系统服务器端所依靠的数据库是作为整个A市城市管理数据库的一部分，整

个数据库系统是分布式结构，CMHR数据库只是一个站点而已，所以必须考虑与整个数据库

系统的整合，在设计数据库时要和整个数据库系统的模式一致，不但本站点数据库可以使用其它站点上的数据，而且其他站点也应该可以应用本站点的数据，考虑使用相同的DBMS尽

量减少数据传输过程中的转化，提高效率。

4.8.2操作

以简单易用为宗旨，减少不必要

以最少的操作步骤引导市民完成

以提高广大市民的城市主人翁

市民登陆报告坑洼状况时，应该使用户界面亲切友好，的操作和可能引起歧义的操作要求，尽量在最短的时间内，报告坑洼情况的过程，并且对于市民的报告要给予鼓励的话，精神。

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

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

障系统的安全。

5系统分析

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

第o层数据流程图：

DFDO:

说明：

CMHRS统（F0）接受市民的坑洼情况举报，对坑洼进行确认，初步判断坑洼情况，将其标记并归档。

此归档的坑洼信息可供市民和施工管理部门查看

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

施工管理部门将施工队当前的情况输入CMHR系统，系统根据一定的算法进行人力

物力资源的分配。

并生成施工单。

施工管理部门按照此施工单进行施工。

第1层数据流程图：

（F0精化）

第2层数据流程图：

逐个bubble细化—F1:

用户交互：

输入：

市民报告的详细信息

输出：

交互系统整理后的坑洼信息

简介：

市民在任意浏览器中登录CMHR系统，报告所发现坑洼情况。

CMHR系统建议并提示用户将其个人信息登记入热心市民信息数据库。

作为市

民个人信用点的组成部分。

如果数据库中有类似的坑洼记录存在，CMHR系统提取记录返回用户，提示可

能的重复报告，并表示感谢。

如果没有类似记录，CMHR系统引导用户输入详细的坑洼信息。

初步生成坑洼情况报表。

原图:

细化后:

PSPEC:

F11查看数据中是否已有类似记录：

接受用户输入的坑洼情况报告（概要信息），这时接受到的只是简要的信息，

需要知道坑洼所在街道，及在街上的具体位置即可，F11对于接收到的坑洼信息概

要进行综合分析，并与数据库中已有的坑洼情况报表进行比较，主要比较位置信息，

如果发现在同一条街道的同一位置，就怀疑此坑洼是以前报告过的，则将坑洼已存

在的消息发送到F12，如果报告的是新的坑洼则确认此坑洼为新报告的，则发送消息到F13,引导用户进一步填写详细的情况报表。

F12提示用户核实：

如果通过F11检查，市民报告的坑洼是已报告过的，则将已有的坑洼报表信息

返回给用户，要求用户进一步的确认核实。

F13引导用户填写详细的情况报表：

如果通过F11检查，市民报告的坑洼确实为新的信息，则向市民提供更为详尽

的坑洼报告单，引导用户填写详细的坑洼情况报表，这时产生的坑洼情况报表为正

式报表，需要入库备份。

F14登载市民信息：

作为一个关心城市建设的热心市民，需要为这位市民建立个人信息，以备与城

市管理系统的其他子系统联合，对于热心市民给予物质或精神上的奖励，在后面的

步骤中，建立坑洼损害文件时，报告坑洼的市民信息也是其中很重要的一项，显示

详尽的表格给市民填写，记录其姓名，电话，地址，身份证号码等信息，并将这些信息记录入库，存储为热心市民信息表。

—F2:

报表评估

输入：

交互部分整理后的坑洼信息

输出：

坑洼情况报表

简介：

根据数据库中用来确定坑洼类型及参数的标准信息对照表（例如，街道地址、坑洼大小（1到10）、位置（路中或路边等）、区域（由街道地址确定）和修复的优先级（由坑洼的大小确定）等信息确定的参数），根据坑洼详细信息计算其处理优

先级等参数，拟定初步处理计划。

按照一定的格式，生成统一编号的坑洼报表。

原图：

PSPEC:

F21确定坑洼相应的参数和等级：

对于输入的坑洼情况报表，进行综合分析，结合数据库中以下的两项标准信息

查询对照表：

坑洼尺寸与大小对照表，坑洼大小与优先等级对照表。

来确定坑洼的

大小（1-10等级），坑洼的具体位置信息（路中或路边），对坑洼进行实地调查的

优先等级。

在原有坑洼情况报表基础上添入以上的三项信息后，经过完善后产生坑

洼情况报表，传入下一个处理。

F22分配唯一编号，声称坑洼报表：

根据F21输入的具有完整信息的坑洼信息报表，结合数据库现有的坑洼信息报表，为新的坑洼信息报表产生唯一编号，正式入库，至此，坑洼情况报表的前期处理工作完成。

—F3:

损害文件生成：

输入：

坑洼情况报表

输出：

损害文件

简介：

根据新坑洼报表的初步处理计划，派遣人员进行实地调查。

结合坑洼报表，得

到精确的信息，修改坑洼报表。

如果不需要进一步处理，坑洼报表归档。

退出。

如果需要进一步处理，损害文件管理系统将坑洼报表按照要求的格式生成损害文件，状态为未处理。

当一项处理完毕后需要调用损害文件管理系统。

此时修改损害文件状态为已处

理，根据实际处理的情况修改相应的损害文件。

并将损害文件归档。

施工管理人员可以从损害文件管理系统中查询损害文件信息。

原图：

细化后:

PSPEC:

F31得到确切的坑洼信息：

派出城市建设管理专业人员对于经过评估的优先级最高的坑洼进行实地考察，对市民报告的坑洼情况进行核实，核实坑洼所在街道是否属实，核实坑洼尺寸

是否偏离较大，实地调查坑洼状况是否有新的变化，接着利用调查到的真实信

息对坑洼报表进行修正，修改不正确及不精确的信息，另外，根据进行现场调研的专业人员意见，决定此坑洼是否需要做进一步处理，因为市政资金人员方面的紧缺，对于不很严重，影响不大的坑洼考虑归档日后再处理，对于较严重，影响较大的坑洼则需要进一步的处理。

F32再次评估报表，确定相应的等级和参数：

经过F31的进一步调研确认后，对于确实需要处理的坑洼情况报表，再次

进行评估，此次评估的内容与F21基本相同，只是此次评估依据的数据是新的准确信息，具有权威性，此时产生的是真正需要处理的坑洼情况报表。

F33归档坑洼报告，标记为无需处理：

经过F31的进一步调研确认后，对于暂时无需处理的坑洼情况报表，标记

为无需处理，并且归档记录，以便今后作进一步处理

F34A生成损害文件，标记为未处理：

F32对于坑洼情况报表作了进一步的评估，得到确定后的坑洼情况报表。

此处，将坑洼情况报表升级为坑洼损害文件，其中需要填写的报告市民信息，修复施工队信息，材料设备信息等有待后续过程处理，此处暂为空。

F34B完成损害文件，标记为处理完成：

此处理的完成有待施工队对坑洼的修复工作完成后进行，同样是对损害文

件进行处理，在修复工作完成后，具体的施工过程中到底使用了什么设备，使

用了多长时间，使用了什么材料，使用了多少，施工共进行了多长时间，消耗了多少人力等等这些详细信息都将得到确切的结果，这时的损害文件是最终的

完结版本。

—F4:

施工安排及材料分发：

输入：

损害文件

输出：

施工单

简介：

CMHR系统中存有施工队当前情况（人员调度情况，资源分配情况，资金流动情况…）。

施工管理队需要队这些信息实时的修改。

CMHR系统根据施工队当前情况，结合损害文件中的各种要求，实施一定算法进行规划管理，将其列入施工计划，制定施工单。

施工管理人员按照施工单安排执行。

原图:

施工单

细化后:

F41施工安排情况综合评估：

根据输入的损害文件中坑洼的大小，修复等级，具体位置等信息，依据经

过修订的施工队信息，结合这两方面，综合分析，得到简单的相互关系。

F42施工单生成：

根据分析得到的结果，将两方面信息联系在一起，得到一份有具体安排的施工单，其中包括针对某个坑洼情况以及施工队现状的施工任务安排，并将此

施工任务分配给施工队，以使施工任务尽快进行。

F43施工队实际情况修订：

因为施工队的具体情况可能随着时间发生变化，例如过一段时间由于人事调动，某施工队人员出现变化等，所以在进行任务分配前，需要现对施工队具体情况进行进一步修订，得到确切的施工队情况。

—F5:

坑洼损害文件查询:

输入：

查询条件

输出：

符合条件的损害文件

简介：

CMHR系统的一个重要功能便是实现坑洼损害文件的交互查询，城市管理人员，需要掌握坑洼修理的历史信息，进行简单的统计，以作为城市规划建设的基础。

主要查询依据坑洼位置，大小，修复时间，负责施工队，所耗材料，所耗人时等查询条件查询坑洼信息，施工队信息，材料设备使用状况等。

原图:

细化后:

F51接受查询条件输入：

接受城市管理者输入的查询条件，例如：

根据坑洼大小，位置查询坑洼损害文件，根据查询某施工队在某段时间完成的修复工作等。

这里需要先做出初

步的分类工作，按照不同的查询条件，细化查询动作。

F52细化查询分类并进行查询：

将已经进行了初步细化的查询条件进一步细化分类，使一个条件查询成为

系统内部几个基本的查询动作的合成，按顺序调用系统内部的基础查询模块，得到一般的查询结果。

F53返回查询结果：

在上一步处理得到的一般查询结果的基础上，根据管理者的具体需求，再

次将查询结果个性格式化，将此格式化后的查询结果返回给管理者。

5.2数据字典（DataDictionary）

依据以上的数据流程图，将其中的数据流具体化，得到以下的相应的数据字典:

数据字典

数据流名称

别名

输入（输出）

具体内容

坑洼情况报告

坑洼情况报告概要

输入：

市民

输出：

F11,F12,F31,F32

包含关于一个坑洼的初步详细信息，所在街道，尺寸，报告时间等。

市民个人信息

输入：

市民

输出：

F14

包含报告坑洼的热心市民的个人信息，姓名，地址，联系电话，身份证号码。

坑洼情况报表

新的坑洼情况报表，经过评估的坑洼情

况报表

输入：

F13

输出：

F34a

包含坑洼在经过评估後的较详细信息，比情况报告多了大小，位置，修复优先等级等信息。

坑洼具体处理情

况

输入：

施工队

输出：

F34b

施工队在进行完修复工作后需要填写，包括对于某个坑洼的修复工作，使用了什么设备，使用了什么材料等信息。

坑洼损害文件

未处理的损害文件

处理后的损害文件

输入：

F41,F42

输出：

F34a

关于一个坑洼从市民报告，评估到修复的所有完整信息，包含坑洼自身大小位置等方面信息，还有报告市民的信息，以及修复此坑洼的施工队和使用的材料和设备的详细清单

施工队情况

经过修正的施工队

情况

输入：

F41

输出：

施工队

包含一个施工队伍的详细信息，编号，名称，人数，当前工作状态等。

施工单

输入：

施工队

输出：

F42

此单是根据坑洼的详细信息以及施工队的当前工作状态综合评定后得到的施工任务安排单据，施工队伍依据此施工单领取设备材料，以及进行施工任务

查询条件

经过细化的查询条

件

输入：

F51

输出：

管理者

管理