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

1、 CMHRS系统项目 需求分析说明书 第01版 二三年七月二十四日 版本控制信息 版日拟稿和修说初梁2003-7-2301.00修2003-7-25梁01.01梁2003-7-2601.02最终 ii 目录 范围 . 1 4 标识 .1.1 . 4 系统概述 . 4 1.2 文档概述 .1.3 . 4 引用文档 2 . 4 项目概述 . 43 目标 . 4 3.1用户的特点 . 3.2 4 假定和约束 .3.3 . 5 需求规定 . 54 功能需求 4.1. 5 性能需求4.2 . 6 精度 4.2.1. 6 时间特性要求 . 4.2.2 6 灵活性 . 6 4.2.3 输入输出要求 .4.3

2、 . 7 数据管理能力要求4.4 . 8 故障处理要求 4.5 . 8 设计约束 . 4.6. 9 属性 . 4.79 安全性 . 9 4.7.1 可维护性 . 9 4.7.2 其它需求 . 9 4.8数据库 . 9 4.8.1操作 . 4.8.2. 9 系统分析5 . 10 数据流程图（DFD并附PSPEC） . 5.1. 10 数据字典（ 5.2DD） . 19 ICTIONARYATA 实体关系图（ERD） . 2 5.30 运行环境规定 . 6. 22 硬件 6.1. 22 支持软件 6.2 . 22 接口需求 . 22 6.3 支持信息 . 722 iii 1 范围 1.1 标识 Q

3、R-10-02 CMHRS需求分析说明书 城市管理坑洼跟踪和修复系统（简称CMHRS） 1.2 系统概述 CMHRS是一个基于web的城市坑洼跟踪和修复系统，它为一般大城市的城市管理部门提供了高效快捷的工作方式，主要的设计目标是为了实现城市管理电子化网络化，使广大市民真正的参与到城市管理中来，增强市民的主人翁精神和对于城市管理的责任感，另一方面相对于以前的档案办公，电子化网络化的优势是极其明显的，它不但增大了信息的储存量，而且大大提高了城管各部门的协调能力，使有限的人力财力资源得到了最大化的应用。 1.3 文档概述 该文档详细描述了CMHRS系统的需求规约，为进一步的概要设计和详细设计奠定了基

4、础。 2 引用文档 需求文档模板（国标） CMHRS系统需求分析草稿 3 项目概述 3.1 目标 本软件的开发是实现城市管理网络化电子化的大胆尝试，在应用于实际之后，将大大提高城市坑洼管理的效率，真正意义上实现高效无纸化办公。它将替代现有的城市坑洼管理系统。另外，整个系统是基于城市管理系统的，是整个管理系统的一个子系统。 3.2 用户的特点 本软件的最终用户将是广大热心市民，城市管理人员以及系统维护人员。 对于广大市民只要求有基本的电脑操作知识和会浏览网页即可。 对于城市管理人员，要求了解基本的电脑操作知识，有过使用管理系统的经历最佳。 对于系统维护人员要求有管理大型数据库的能力，另外还须对本

5、系统有一定的了解，能够在发生普通的异常情况时，根据使用说明手册进行维护。 4 3.3 假定和约束 因为现有的城市坑洼管理系统陈旧不堪，需要CMHRS尽快开发成功，政府方面要求以3个月为期限。 开发经费方面，因为是A市对于城市管理系统的初次尝试，一切都是试探性的，所以资金投入不是很大，尽量少花钱，多办事。 考虑到现有政府工作人员的计算机操作水平有限，希望开发的软件有良好的人机交互界面，较高的可操作性。 4 需求规定 4.1 功能需求 CMHRS主要分为以下几个功能需求： ? 市民报告坑洼信息： 市民可以登陆网站并报告自己发现的坑洼，提交的坑洼概要信息包括：坑洼所在街道，坑洼大小（大体），发现时间

6、，坑洼现状。系统对于用户填写的概要信息进行处理，根据坑洼所在位置，时间，坑洼现状等信息与数据库中现有信息进行比较，察看是否有类似记录，如果已有类似的坑洼报告，则提取此坑洼的详细信息，提示用户进行核实。如果没有类似坑洼报告，则引导用户填写全面详细的情况报表，生成坑洼情况报告单。用户报告完毕坑洼情况后，提示用户输入自己的姓名，家庭住址，联系电话，身份证号码等个人信息，记录入热心市民信息数据库。 ? 坑洼信息报表评估（信息详化）： 坑洼情况报告单输入，根据坑洼类型及参数标准信息对照表，加入新的更为详尽的信息，包括：a.根据坑洼大小和尺寸对照表，确定坑洼大小等级（1-10）；b.根据城市街道区域图和报

7、告单中的街道地址，确定坑洼所在区域。C.根据坑洼现状描述，确定所在位置（路中或路边等）。D.根据坑洼大小和坑洼所在区域，位置（生活区，工业区，商业区等的优先等级可能有所不同），确定坑洼修复的优先等级。按照数据库现有坑洼信息报表，为此新坑洼分配一个唯一编号，生成最终的坑洼信息报表。 ? 坑洼损害文件生成： 按照坑洼信息报表，安排调查人员实地考察一一核实坑洼信息报表中的各项，对于不准确的信息给于精化，对于不正确的信息给予纠正，并且全面衡量各种信息（坑洼等级，所处地段，坑洼带来的危害等），最终确定是否需要对于此坑洼作进一步处理，如此坑洼暂时无需处理，则给予无需处理标记，将此信息报表备份归档。如需继续

8、处理，则给予需要处理且未处理标记。 ? 未处理坑洼的施工分配： 检索未处理的坑洼损害文件，并从数据库中提取施工队的当前情况，依据坑洼的处理优先等级和施工队的当前状况，将优先等级较高的坑洼分配给近期无施工任务的施工队或施工任务较轻的施工队（此处需要一定的匹配算法）。根据坑洼的大小，严重情况，所处地段，施工需要等信息，从仓库中分发施工材料以及所需装备给此施工队，最终根据这三方面信息 5 产生施工单。向施工队分配施工任务。 ? 施工完毕后对于损害文件的处理： 施工完毕后根据施工队施工过程中所消耗材料，工作日，人数等信息，关联施工队的简单信息和报告市民的信息后产生损害文件，备份入库，以备查询。 ? 交

9、互查询： 主要依据坑洼位置，大小，修复时间，负责的施工队，所耗材料，所耗人时等查询条件查询坑洼信息，施工队信息，材料设备使用状况等。另外还可以查询热心市民信息，做出评比等。 CMHRS是一个基于WEB的管理系统，其并发程度很大程度上决定于WEB服务器和后台数据库的的并发处理能力，连接终端和同时并发用户数目控制在100。 4.2 性能需求 4.2.1 精度 该系统中没有对于较高数据精度的需要，例如：市民报告坑洼情况时，对于坑洼位置精确到街道，坑洼大小给出目测的范围值即可（如0.5-1M），坑洼发现的时间精确到每日。总之，对于所有的尺度量精确到CM，日期精确到每日，人民币数目精确到元，时间长度度量

10、精确到天。在数据存储和传输过程中与输入时相同。 4.2.2 时间特性要求 ? 响应时间： 对于用户输入的响应时间大体上决定于网络传输速度。 ? 更新处理时间： 坑洼的更新信息应该维持在每天。 ? 规格说明号： 数据的转换和传送时间：? 解题时间： ? 4.2.3 灵活性 ? 操作方式的变化： 运行环境的变化： ? WEB服务器进行更新时，对于整个程序的结构应该没有太大的影响 ? 同整个城市管理系统其他部分接口的变化： ?因为后台数据库与整个城市管理系统是集成在一起的，采用分布式数据库，对于数? 据的利用达到最大化。当整个分布式数据库发生变化时，如果数据库关系模式无变化，只牵扯数据的导出和重新导

11、入，如果模式变化，则需要进行异构数据库间的转化，较为复杂。 6 ? 精度和有效时限的变化： 此CMHRS系统的应用时间初步定位为10? 年，可以考虑使用过程中的系统硬件软件升级问题。 计划的变化或改进： ? 如果出现计划变化和改进，需要小组成员协调处理。? 4.3 输入输出要求 市民信息数据类型 数据项 格式 数值范围 姓名*（张三） 不超过地址 *（真南路） 不超过电话 * 长度为 身份证号码* 长度为 精个2个123456781234567890123451 坑洼数据类型 数据项 当前工作状态 格式 坑洼情况报表 * 数值范围新的坑洼坑洼标识 HYYMMDD* 报表评估(F2) 情况报表街

12、道地址 长安街 CMHRS坑洼情况报告 不超过 系统确定坑洼类型及参数 坑洼大小 位置 * * 路中，路边 施工队区域 * 未处理，处理中坑洼状态 * 修理队编号 G* 人*实际参加人数 天* 修理使用时间 损坏类型 * 严重，一般，轻微精某年某月某日发现的几1个11-10处理完0-2一1-1 7 施工工具成本数据类型 数据项 格式 数值范围 精度 名称 个字* 不超过81￥*￥ 100-500￥ 固定成本1单位成本 / H ￥/ H 10-50￥*￥/ H 施工材料成本数据类型 数据项 格式 数值范围 精度 名称 不超过8* 个字1￥/ 单位 单位成本 10-50￥*￥/ 单位 /单位 施工

13、队信息数据类型 数据项 格式 数值范围 精度 施工队编号 5个字符 G* 长度固定为 * 不超过10个字施工队名称 1人*人 人数 人 1-5工作，空闲 4.4 数据管理能力要求 根据A市现运行系统来看，过去的10年中，关于坑洼的记录在1万条左右，报告坑洼的市民资料因为过一段时间会清理，所以大体在1000条，而A市现有坑洼修复施工队伍20个，每个月平均的坑洼修复记录在100条左右。但随着城市发展步伐的加快，城市建设越来越重要，而且市民的主人翁精神也在增强，所以数据量大幅增长，对于系统的数据库也提出了挑战，为了做长远打算，要求数据库有50万条数据存储的能力。一般的大型数据库应该能够胜任，例如or

14、acle，db2等。 4.5 故障处理要求 ? 硬件故障： WEB服务器运行超负荷，网站连接发生问题，市民不能登陆,如果经常发生类似问题，要考虑升级服务器。 ? 软件故障： 数据库管理系统出现故障，可能发生数据丢失，这就需要系统DBA切实做好数据备份工作，在数据库发生故障时，能够迅速的给予恢复，保证系统的正常运 8 行。 4.6 设计约束 必须考虑WEB服务器的承受能力，在资金各方面允许的情况下，可以考虑大型的WEB服务器。因为硬件的约束，所以开发时要切实根据服务器负载能力较好的进行并发控制。 4.7 属性 4.7.1 安全性 CMHRS在使用过程中，要特别注意系统的安全性防护，一方面CMHR

15、S的数据库系统是整个城市管理系统的分布式数据库的一个站点，它的安全性涉及到整个城市其他管理系统的数据安全，对于数据库的使用权限严格界定，由专人DBA负责管理维护，并定期作数据备份工作。 另一方面，作为基于WEB的管理系统，WEB服务器的安全性不容小觑，必须设置防火墙和严格的身份审核制度，防止服务器被攻击。 4.7.2 可维护性 整个系统的各个功能高度模块化，达到高内聚低耦合的目标，实现清晰的模块接口，明确每个模块的功能，方便以后的系统维护，如果一个功能模块出现问题，不会致使整个系统瘫痪。 另外，有完整的数据库管理制度，以保证数据库的数据的完整性，安全性。 作为WEB项目，服务器端的管理维护异常

16、重要，一定要保证程序有足够的并发性能。 4.8 其它需求 4.8.1 数据库 因为CMHRS系统服务器端所依靠的数据库是作为整个A市城市管理数据库的一部分，整个数据库系统是分布式结构，CMHRS数据库只是一个站点而已，所以必须考虑与整个数据库系统的整合，在设计数据库时要和整个数据库系统的模式一致，不但本站点数据库可以使用其它站点上的数据，而且其他站点也应该可以应用本站点的数据，考虑使用相同的DBMS,尽量减少数据传输过程中的转化，提高效率。 4.8.2 操作 市民登陆报告坑洼状况时，应该使用户界面亲切友好，以简单易用为宗旨，减少不必要的操作和可能引起歧义的操作要求，尽量在最短的时间内，以最少的

17、操作步骤引导市民完成报告坑洼情况的过程，并且对于市民的报告要给予鼓励的话，以提高广大市民的城市主人翁精神。 城市规划管理人员在操作本软件时，已经具备了一定的电脑操作知识，而且对本系统有 9 了一定的认识，必须提醒管理人员注意系统的安全问题，对于登陆密码等不能轻易泄漏，保障系统的安全。 5 系统分析 5.1 数据流程图（DFD并附PSPEC） ? 第0层数据流程图： DFD0： 说明： CMHRS系统(F0)接受市民的坑洼情况举报，对坑洼进行确认，初步判断坑洼情况，将其标记并归档。此归档的坑洼信息可供市民和施工管理部门查看 CMHRS系统根据一定的划分标准将坑洼划分为不同等级，并在此基础上进行时

18、间和财力的初步判定，生成损害文件，可供施工管理部门查看。 施工管理部门将施工队当前的情况输入CMHRS系统，系统根据一定的算法进行人力物力资源的分配。并生成施工单。施工管理部门按照此施工单进行施工。 市民 管理员 10 ? 第1层数据流程图：（F0精化） 管理者 施工单格式控制 确定坑洼类型及 市民 坑洼损害文格式控制信息 (F5) 件查询 个人登录施工安排及材料 坑洼情况设备分发(F4) 坑洼损害文件报表 确定坑洼类型及 用户交互参数 施工队情况 (F1) ) 未处理损害文件( 施工单输出 已处理损害文件( ) 坑洼实际处理 坑洼情况报表 施工队 损害文件生 情况 (F3) 成 新的坑洼报表

19、评 情况报表(F2) 估 格式控制信息 损害文件格式控制 确定坑洼类型及 参数 第? 2层数据流程图：逐个bubble细化 F1:用户交互： 输入： 市民报告的详细信息 输出： 交互系统整理后的坑洼信息 简介： 市民在任意浏览器中登录CMHRS系统，报告所发现坑洼情况。 CMHRS系统建议并提示用户将其个人信息登记入热心市民信息数据库。作为市民个人信用点的组成部分。 如果数据库中有类似的坑洼记录存在，CMHRS系统提取记录返回用户，提示可能的重复报告，并表示感谢。 如果没有类似记录，CMHRS系统引导用户输入详细的坑洼信息。初步生成坑洼情况报表。 原图： 11 坑洼情况报表 (F1) 用户交互

20、 个人登录市民 坑洼情况 细化后： 市民信息数据 确定坑洼类型及 参数 个人情况 个人情况 登载市民信息 市民 (F14) 坑洼情况报告 提示用户核实引导用户填写详 (F12) 细的情况报表 (F13) 已有 查看数据库中是否 尚无 (F11) 已有类似记录 PSPEC: F11查看数据中是否已有类似记录： 接受用户输入的坑洼情况报告（概要信息），这时接受到的只是简要的信息，需要知道坑洼所在街道，及在街上的具体位置即可，F11对于接收到的坑洼信息概要进行综合分析，并与数据库中已有的坑洼情况报表进行比较，主要比较位置信息，如果发现在同一条街道的同一位置，就怀疑此坑洼是以前报告过的，则将坑洼已存在

21、的消息发送到F12，如果报告的是新的坑洼则确认此坑洼为新报告的，则发送消息到F13,引导用户进一步填写详细的情况报表。 F12提示用户核实： 如果通过F11检查，市民报告的坑洼是已报告过的，则将已有的坑洼报表信息返回给用户，要求用户进一步的确认核实。 F13 引导用户填写详细的情况报表： 如果通过F11检查，市民报告的坑洼确实为新的信息，则向市民提供更为详尽的坑洼报告单，引导用户填写详细的坑洼情况报表，这时产生的坑洼情况报表为正式报表，需要入库备份。 12 F14登载市民信息： 作为一个关心城市建设的热心市民，需要为这位市民建立个人信息，以备与城市管理系统的其他子系统联合，对于热心市民给予物质

22、或精神上的奖励，在后面的步骤中，建立坑洼损害文件时，报告坑洼的市民信息也是其中很重要的一项，显示详尽的表格给市民填写，记录其姓名，电话，地址，身份证号码等信息，并将这些信息记录入库，存储为热心市民信息表。 F2:报表评估 输入： 交互部分整理后的坑洼信息 输出： 坑洼情况报表 简介： 根据数据库中用来确定坑洼类型及参数的标准信息对照表（例如，街道地址、坑洼大小（1到10）、位置（路中或路边等）、区域（由街道地址确定）和修复的优先级（由坑洼的大小确定）等信息确定的参数），根据坑洼详细信息计算其处理优先级等参数，拟定初步处理计划。按照一定的格式，生成统一编号的坑洼报表。 原图： 细化后： Note

23、:此评估步骤，基于市民报告数据计算对坑洼第一次处理地考察）的优先级坑洼损害文件报表确定坑洼类型及 坑洼情况报表 管理者 参数处理后的损害确定坑洼类型及参数 确定坑洼类型及确定坑洼相应的参数 文件 的标准信息对照表 参数 新的坑洼和等级(F21) 损害文件生坑洼实际处理 现有坑洼情况报表损害文件分配唯一编号，生成确定坑洼类型及 参数坑洼报表(F22) 新的坑洼情况报表 （实 13 PSPEC: F21确定坑洼相应的参数和等级： 对于输入的坑洼情况报表，进行综合分析，结合数据库中以下的两项标准信息查询对照表：坑洼尺寸与大小对照表，坑洼大小与优先等级对照表。来确定坑洼的大小（1-10等级），坑洼的具

24、体位置信息（路中或路边），对坑洼进行实地调查的优先等级。在原有坑洼情况报表基础上添入以上的三项信息后，经过完善后产生坑洼情况报表，传入下一个处理。 F22分配唯一编号，声称坑洼报表： 结合数据库现有的坑洼信息报F21输入的具有完整信息的坑洼信息报表，根据正式入库，至此，坑洼情况报表的前期处表，为新的坑洼信息报表产生唯一编号， 理工作完成。 F3:损害文件生成： 输入： 坑洼情况报表 输出： 损害文件 简介：得派遣人员进行实地调查。结合坑洼报表，根据新坑洼报表的初步处理计划， 到精确的信息，修改坑洼报表。 如果不需要进一步处理，坑洼报表归档。退出。损害文件管理系统将坑洼报表按照要求的格式生成损害

25、如果需要进一步处理， 文件，状态为未处理。此时修改损害文件状态为已处当一项处理完毕后需要调用损害文件管理系统。 理，根据实际处理的情况修改相应的损害文件。并将损害文件归档。 施工管理人员可以从损害文件管理系统中查询损害文件信息。 原图： 施工队 (F3) 成 情况 情况报表 损害文件 14 细化后： Note:此处的评估是基 于实地考察的数据得 到对坑洼进行施工的 优先级 确定再次评估报表， 相应的参数和等级 (F32) 需要继 续处理 (F31) 得到坑洼确切信息新的坑洼情况 报表管理者 损害文件输出 无需继 显示 续处理 生成损害文件，状态为 格式控制信息处理文件格式控制 确定坑洼类型及)

26、(F34a) 前期(未处理归档坑洼报告。 参数 标记为无需处理 (F33) ) (未处理损害文件 完成损害文件，状态为 (F34b) 已处理（后期）坑洼实际处理 施工队 情况 PSPEC: F31 得到确切的坑洼信息： 派出城市建设管理专业人员对于经过评估的优先级最高的坑洼进行实地考察，对市民报告的坑洼情况进行核实，核实坑洼所在街道是否属实，核实坑洼尺寸是否偏离较大，实地调查坑洼状况是否有新的变化，接着利用调查到的真实信 15 息对坑洼报表进行修正，修改不正确及不精确的信息，另外，根据进行现场调研的专业人员意见，决定此坑洼是否需要做进一步处理，因为市政资金人员方面的紧缺，对于不很严重，影响不大

27、的坑洼考虑归档日后再处理，对于较严重，影响较大的坑洼则需要进一步的处理。 F32再次评估报表，确定相应的等级和参数： 经过F31的进一步调研确认后，对于确实需要处理的坑洼情况报表，再次进行评估，此次评估的内容与F21基本相同，只是此次评估依据的数据是新的准确信息，具有权威性，此时产生的是真正需要处理的坑洼情况报表。 F33归档坑洼报告，标记为无需处理： 经过F31的进一步调研确认后，对于暂时无需处理的坑洼情况报表，标记为无需处理，并且归档记录，以便今后作进一步处理 F34 生成损害文件，标记为未处理： AF32对于坑洼情况报表作了进一步的评估，得到确定后的坑洼情况报表。此处，将坑洼情况报表升级

28、为坑洼损害文件，其中需要填写的报告市民信息，修复施工队信息，材料设备信息等有待后续过程处理，此处暂为空。 F34B完成损害文件，标记为处理完成： 此处理的完成有待施工队对坑洼的修复工作完成后进行，同样是对损害文件进行处理，在修复工作完成后，具体的施工过程中到底使用了什么设备，使用了多长时间，使用了什么材料，使用了多少，施工共进行了多长时间，消耗了多少人力等等这些详细信息都将得到确切的结果，这时的损害文件是最终的完结版本。 F4:施工安排及材料分发： 输入： 损害文件 输出： 施工单 简介： CMHRS系统中存有施工队当前情况（人员调度情况，资源分配情况，资金流动情况）。施工管理队需要队这些信息

29、实时的修改。 CMHRS系统根据施工队当前情况，结合损害文件中的各种要求，实施一定算法进行规划管理，将其列入施工计划，制定施工单。 施工管理人员按照施工单安排执行。 原图： （未处理） 施工安排及材料 设备分发(F4) 施工队情况 施工单 施工队 16 细化后： 损害文件 施工队资源情况确定坑洼类型及参施工单格式控制信息确定坑洼类型及参归档，进入施工规划表 管理者根据实际情况修订 坑洼损害文件查询 施工队情况(F43) 重新设置(F43) 格式控制信息施工单格式处理数据确定坑洼类型及参数施工队 施工安排情况 (F41) 综合评估 损害文件及 施工安排 施工单生成 (F42) 施工单 施工队 (

30、F5) 数确定坑洼类型及参 数 数 PSPEC: F41施工安排情况综合评估：依据经修复等级，具体位置等信息，根据输入的损害文件中坑洼的大小， 过修订的施工队信息，结合这两方面，综合分析，得到简单的相互关系。 施工单生成：F42 得到一份有具体安排的将两方面信息联系在一起，根据分析得到的结果，并将此施工单，其中包括针对某个坑洼情况以及施工队现状的施工任务安排， 施工任务分配给施工队，以使施工任务尽快进行。 F43施工队实际情况修订： 例如过一段时间由于人事因为施工队的具体情况可能随着时间发生变化，需要现对施工队具某施工队人员出现变化等，调动，所以在进行任务分配前， 体情况进行进一步修订，得到确

31、切的施工队情况。 F5:坑洼损害文件查询： 输入： 查询条件 输出： 符合条件的损害文件 简介： CMHRS系统的一个重要功能便是实现坑洼损害文件的交互查询，城市管理人员，需要掌握坑洼修理的历史信息，进行简单的统计，以作为城市规划建设的基础。 17 主要查询依据坑洼位置，大小，修复时间，负责施工队，所耗材料，所耗人时等查询条件查询坑洼信息，施工队信息，材料设备使用状况等。 原图： 坑洼损害文件报表确定坑洼类型及 参数 细化后： 管理者管理者 查询结果返回查询结细化查询分F53）果（符合查询条件分类后的类并进行查 查询条件的损害文件(F52) 询 查询条件接受查询条(F51) 件输入 确定坑洼类

32、型及坑洼损害文件报表 参数PSPEC: 接受查询条件输入： F51 接受城市管理者输入的查询条件，例如：根据坑洼大小，位置查询坑洼损害文件，根据查询某施工队在某段时间完成的修复工作等。这里需要先做出初步的分类工作，按照不同的查询条件，细化查询动作。 F52细化查询分类并进行查询： 使一个条件查询成为将已经进行了初步细化的查询条件进一步细化分类，系统内部几个基本的查询动作的合成，按顺序调用系统内部的基础查询模块， 得到一般的查询结果。 F53返回查询结果： 再在上一步处理得到的一般查询结果的基础上，根据管理者的具体需求， 次将查询结果个性格式化，将此格式化后的查询结果返回给管理者。 18 5.2

33、 数据字典（Data Dictionary） ? 依据以上的数据流程图，将其中的数据流具体化，得到以下的相应的数据字典： 数据字典数据流名称 别名 输入（输出）坑洼情况报告概要 坑洼情况报告 输入：市民输出：F11,F12,F31,F32 输入：市民市民个人信息 输出：坑洼情况报表 新的坑洼情况报表， 输入：经过评估的坑洼情输出： 况报表 输入：施工队未处理的损害文件 处理后的损害文件 经过修正的施工队 情况 经过细化的查询条 件输入：格式控制信息 损害文件格式控制施工单格式控信息，输出： 制信息式控制信息，施工单格式控制信息坑洼具体处理情 况输出：输入：输出：输入：输出：施工队输入：施工队输出：输入：输出：管理者施工队 坑洼损害文件 施工队情况 施工单 查询条件 具体内包含关于一个坑洼的初详细信息，所在街道，寸，报告时间等包含报告坑