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

1、PAGE CMHRS系统项目需求分析说明书第01版二三年七月二十四日版本控制信息版本日期拟稿和修改说明01.002003-7-23梁峰初稿01.012003-7-25梁峰修订01.022003-7-26梁峰最终稿目录 TOC o 1-1 h z t 标题 2,2,标题 3,3 HYPERLINK l _Toc470646871范围 PAGEREF _Toc47064687 h 4 HYPERLINK l _Toc470646881.1标识 PAGEREF _Toc47064688 h 4 HYPERLINK l _Toc470646891.2系统概述 PAGEREF _Toc47064689

2、h 4 HYPERLINK l _Toc470646901.3文档概述 PAGEREF _Toc47064690 h 4 HYPERLINK l _Toc470646912引用文档 PAGEREF _Toc47064691 h 4 HYPERLINK l _Toc470646923项目概述 PAGEREF _Toc47064692 h 4 HYPERLINK l _Toc470646933.1目标 PAGEREF _Toc47064693 h 4 HYPERLINK l _Toc470646943.2用户的特点 PAGEREF _Toc47064694 h 4 HYPERLINK l _Toc

3、470646953.3假定和约束 PAGEREF _Toc47064695 h 5 HYPERLINK l _Toc470646964需求规定 PAGEREF _Toc47064696 h 5 HYPERLINK l _Toc470646974.1功能需求 PAGEREF _Toc47064697 h 5 HYPERLINK l _Toc470646984.2性能需求 PAGEREF _Toc47064698 h 6 HYPERLINK l _Toc470646994.2.1精度 PAGEREF _Toc47064699 h 6 HYPERLINK l _Toc470647004.2.2时间特

4、性要求 PAGEREF _Toc47064700 h 6 HYPERLINK l _Toc470647014.2.3灵活性 PAGEREF _Toc47064701 h 6 HYPERLINK l _Toc470647024.3输入输出要求 PAGEREF _Toc47064702 h 7 HYPERLINK l _Toc470647034.4数据管理能力要求 PAGEREF _Toc47064703 h 8 HYPERLINK l _Toc470647044.5故障处理要求 PAGEREF _Toc47064704 h 8 HYPERLINK l _Toc470647054.6设计约束 PA

5、GEREF _Toc47064705 h 9 HYPERLINK l _Toc470647064.7属性 PAGEREF _Toc47064706 h 9 HYPERLINK l _Toc470647074.7.1安全性 PAGEREF _Toc47064707 h 9 HYPERLINK l _Toc470647084.7.2可维护性 PAGEREF _Toc47064708 h 9 HYPERLINK l _Toc470647094.8其它需求 PAGEREF _Toc47064709 h 9 HYPERLINK l _Toc470647104.8.1数据库 PAGEREF _Toc470

6、64710 h 9 HYPERLINK l _Toc470647114.8.2操作 PAGEREF _Toc47064711 h 9 HYPERLINK l _Toc470647125系统分析 PAGEREF _Toc47064712 h 10 HYPERLINK l _Toc470647135.1数据流程图（DFD并附PSPEC） PAGEREF _Toc47064713 h 10 HYPERLINK l _Toc470647145.2数据字典（Data Dictionary） PAGEREF _Toc47064714 h 19 HYPERLINK l _Toc470647155.3实体关系

7、图（ERD） PAGEREF _Toc47064715 h 20 HYPERLINK l _Toc470647166运行环境规定 PAGEREF _Toc47064716 h 22 HYPERLINK l _Toc470647176.1硬件 PAGEREF _Toc47064717 h 22 HYPERLINK l _Toc470647186.2支持软件 PAGEREF _Toc47064718 h 22 HYPERLINK l _Toc470647196.3接口需求 PAGEREF _Toc47064719 h 22 HYPERLINK l _Toc470647207支持信息 PAGEREF

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

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

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

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

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

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

14、使用状况等。另外还可以查询热心市民信息，做出评比等。CMHRS是一个基于WEB的管理系统，其并发程度很大程度上决定于WEB服务器和后台数据库的的并发处理能力，连接终端和同时并发用户数目控制在100。性能需求精度该系统中没有对于较高数据精度的需要，例如：市民报告坑洼情况时，对于坑洼位置精确到街道，坑洼大小给出目测的范围值即可（如0.5-1M），坑洼发现的时间精确到每日。总之，对于所有的尺度量精确到CM，日期精确到每日，人民币数目精确到元，时间长度度量精确到天。在数据存储和传输过程中与输入时相同。时间特性要求响应时间：对于用户输入的响应时间大体上决定于网络传输速度。更新处理时间：坑洼的更新信息应该

15、维持在每天。规格说明号：数据的转换和传送时间：解题时间：灵活性操作方式的变化：运行环境的变化：WEB服务器进行更新时，对于整个程序的结构应该没有太大的影响同整个城市管理系统其他部分接口的变化：因为后台数据库与整个城市管理系统是集成在一起的，采用分布式数据库，对于数据的利用达到最大化。当整个分布式数据库发生变化时，如果数据库关系模式无变化，只牵扯数据的导出和重新导入，如果模式变化，则需要进行异构数据库间的转化，较为复杂。精度和有效时限的变化：此CMHRS系统的应用时间初步定位为10年，可以考虑使用过程中的系统硬件软件升级问题。计划的变化或改进：如果出现计划变化和改进，需要小组成员协调处理。输入输

16、出要求市民信息数据类型数据项格式数值范围精度姓名*（张三）不超过8个字地址*（真南路）不超过20个字电话*长度为8位12345678身份证号码*长度为15位123456789012345数据项格式数值范围精度坑洼标识HYYMMDD*某年某月某日发现的几号街道地址 长安街不超过10个字坑洼大小 *1-101位置*路中，路边区域*坑洼状态*未处理，处理中处理完毕修理队编号G*实际参加人数*人0-20人1人修理使用时间*天1-10天一天损坏类型*严重，一般，轻微坑洼数据类型施工工具成本数据类型数据项格式数值范围精度名称*不超过8个字固定成本*￥100-500￥1￥单位成本*￥/ H10-50￥/ H

17、1￥/ H施工材料成本数据类型数据项格式数值范围精度名称*不超过8个字单位成本*￥/ 单位10-50￥/单位1￥/ 单位施工队信息数据类型数据项格式数值范围精度施工队编号G*长度固定为5个字符施工队名称*不超过10个字人数*人1-50人1人当前工作状态*工作，空闲数据管理能力要求根据A市现运行系统来看，过去的10年中，关于坑洼的记录在1万条左右，报告坑洼的市民资料因为过一段时间会清理，所以大体在1000条，而A市现有坑洼修复施工队伍20个，每个月平均的坑洼修复记录在100条左右。但随着城市发展步伐的加快，城市建设越来越重要，而且市民的主人翁精神也在增强，所以数据量大幅增长，对于系统的数据库也提

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

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

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

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

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

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

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

25、到F13,引导用户进一步填写详细的情况报表。F12提示用户核实：如果通过F11检查，市民报告的坑洼是已报告过的，则将已有的坑洼报表信息返回给用户，要求用户进一步的确认核实。F13引导用户填写详细的情况报表：如果通过F11检查，市民报告的坑洼确实为新的信息，则向市民提供更为详尽的坑洼报告单，引导用户填写详细的坑洼情况报表，这时产生的坑洼情况报表为正式报表，需要入库备份。F14 登载市民信息：作为一个关心城市建设的热心市民，需要为这位市民建立个人信息，以备与城市管理系统的其他子系统联合，对于热心市民给予物质或精神上的奖励，在后面的步骤中，建立坑洼损害文件时，报告坑洼的市民信息也是其中很重要的一项，

26、显示详尽的表格给市民填写，记录其姓名，电话，地址，身份证号码等信息，并将这些信息记录入库，存储为热心市民信息表。 F2:报表评估输入：交互部分整理后的坑洼信息输出：坑洼情况报表简介：根据数据库中用来确定坑洼类型及参数的标准信息对照表（例如，街道地址、坑洼大小（1到10）、位置（路中或路边等）、区域（由街道地址确定）和修复的优先级（由坑洼的大小确定）等信息确定的参数），根据坑洼详细信息计算其处理优先级等参数，拟定初步处理计划。按照一定的格式，生成统一编号的坑洼报表。原图：新的坑洼情况报表报表评估(F2)坑洼情况报表Note:此评估步骤，基于市民报告数据计算对坑洼第一次处理（实地考察）的优先级细化

27、后：坑洼情况报表确定坑洼相应的参数和等级(F21)确定坑洼类型及参数的标准信息对照表确定坑洼类型及参数的标准信息对照表分配唯一编号，生成坑洼报表(F22)确定坑洼类型及参数的标准信息对照表现有坑洼情况报表 新的坑洼情况报表PSPEC:F21确定坑洼相应的参数和等级：对于输入的坑洼情况报表，进行综合分析，结合数据库中以下的两项标准信息查询对照表：坑洼尺寸与大小对照表，坑洼大小与优先等级对照表。来确定坑洼的大小（1-10等级），坑洼的具体位置信息（路中或路边），对坑洼进行实地调查的优先等级。在原有坑洼情况报表基础上添入以上的三项信息后，经过完善后产生坑洼情况报表，传入下一个处理。F22分配唯一编号

28、，声称坑洼报表：根据F21输入的具有完整信息的坑洼信息报表，结合数据库现有的坑洼信息报表，为新的坑洼信息报表产生唯一编号，正式入库，至此，坑洼情况报表的前期处理工作完成。F3:损害文件生成：输入：坑洼情况报表输出：损害文件简介：根据新坑洼报表的初步处理计划，派遣人员进行实地调查。结合坑洼报表，得到精确的信息，修改坑洼报表。如果不需要进一步处理，坑洼报表归档。退出。如果需要进一步处理，损害文件管理系统将坑洼报表按照要求的格式生成损害文件，状态为未处理。当一项处理完毕后需要调用损害文件管理系统。此时修改损害文件状态为已处理，根据实际处理的情况修改相应的损害文件。并将损害文件归档。施工管理人员可以从

29、损害文件管理系统中查询损害文件信息。原图：管理者施工队坑洼实际处理情况损害文件生成(F3)新的坑洼情况报表损害文件细化后：Note:此处的评估是基于实地考察的数据得到对坑洼进行施工的优先级再次评估报表，确定相应的参数和等级(F32)需要继续处理得到坑洼确切信息(F31)新的坑洼情况报表管理者损害文件输出显示无需继续处理生成损害文件，状态为未处理(前期)(F34a)格式控制信息确定坑洼类型及参数的标准信息对照表处理文件格式控制 归档坑洼报告。标记为无需处理(F33)损害文件(未处理)完成损害文件，状态为已处理（后期）(F34b)确定坑洼类型及参数的标准信息对照表坑洼损害文件报表 施工队坑洼实际处

30、理情况处理后的损害文件PSPEC:F31得到确切的坑洼信息：派出城市建设管理专业人员对于经过评估的优先级最高的坑洼进行实地考察，对市民报告的坑洼情况进行核实，核实坑洼所在街道是否属实，核实坑洼尺寸是否偏离较大，实地调查坑洼状况是否有新的变化，接着利用调查到的真实信息对坑洼报表进行修正，修改不正确及不精确的信息，另外，根据进行现场调研的专业人员意见，决定此坑洼是否需要做进一步处理，因为市政资金人员方面的紧缺，对于不很严重，影响不大的坑洼考虑归档日后再处理，对于较严重，影响较大的坑洼则需要进一步的处理。F32再次评估报表，确定相应的等级和参数：经过F31的进一步调研确认后，对于确实需要处理的坑洼情

31、况报表，再次进行评估，此次评估的内容与F21基本相同，只是此次评估依据的数据是新的准确信息，具有权威性，此时产生的是真正需要处理的坑洼情况报表。F33归档坑洼报告，标记为无需处理：经过F31的进一步调研确认后，对于暂时无需处理的坑洼情况报表，标记为无需处理，并且归档记录，以便今后作进一步处理F34a生成损害文件，标记为未处理：F32对于坑洼情况报表作了进一步的评估，得到确定后的坑洼情况报表。此处，将坑洼情况报表升级为坑洼损害文件，其中需要填写的报告市民信息，修复施工队信息，材料设备信息等有待后续过程处理，此处暂为空。 F34B完成损害文件，标记为处理完成：此处理的完成有待施工队对坑洼的修复工作

32、完成后进行，同样是对损害文件进行处理，在修复工作完成后，具体的施工过程中到底使用了什么设备，使用了多长时间，使用了什么材料，使用了多少，施工共进行了多长时间，消耗了多少人力等等这些详细信息都将得到确切的结果，这时的损害文件是最终的完结版本。 F4:施工安排及材料分发：输入：损害文件输出：施工单简介：CMHRS系统中存有施工队当前情况（人员调度情况，资源分配情况，资金流动情况）。施工管理队需要队这些信息实时的修改。CMHRS系统根据施工队当前情况，结合损害文件中的各种要求，实施一定算法进行规划管理，将其列入施工计划，制定施工单。施工管理人员按照施工单安排执行。损害文件（未处理）原图：施工安排及材

33、料设备分发(F4)施工队情况施工单施工队细化后：施工队情况施工队根据实际情况修订(F43)损害文件施工安排情况综合评估(F41)确定坑洼类型及参数的标准信息对照表施工队资源情况 重新设置(F43)损害文件及施工安排确定坑洼类型及参数的标准信息对照表施工单格式控制信息施工单生成(F42)格式控制信息确定坑洼类型及参数的标准信息对照表施工单格式处理数据 施工队施工单确定坑洼类型及参数的标准信息对照表归档，进入施工规划表PSPEC:F41施工安排情况综合评估：根据输入的损害文件中坑洼的大小，修复等级，具体位置等信息，依据经过修订的施工队信息，结合这两方面，综合分析，得到简单的相互关系。F42施工单生

34、成：根据分析得到的结果，将两方面信息联系在一起，得到一份有具体安排的施工单，其中包括针对某个坑洼情况以及施工队现状的施工任务安排，并将此施工任务分配给施工队，以使施工任务尽快进行。F43施工队实际情况修订：因为施工队的具体情况可能随着时间发生变化，例如过一段时间由于人事调动，某施工队人员出现变化等，所以在进行任务分配前，需要现对施工队具体情况进行进一步修订，得到确切的施工队情况。 F5:坑洼损害文件查询：输入： 查询条件输出：符合条件的损害文件简介：CMHRS系统的一个重要功能便是实现坑洼损害文件的交互查询，城市管理人员，需要掌握坑洼修理的历史信息，进行简单的统计，以作为城市规划建设的基础。主

35、要查询依据坑洼位置，大小，修复时间，负责施工队，所耗材料，所耗人时等查询条件查询坑洼信息，施工队信息，材料设备使用状况等。原图：坑洼损害文件查询(F5)管理者确定坑洼类型及参数的标准信息对照表坑洼损害文件报表 细化后：管理者管理者查询条件查询结果接受查询条件输入(F51)细化查询分类并进行查询(F52)返回查询结果（F53）符合查询条件的损害文件分类后的查询条件确定坑洼类型及参数的标准信息对照表坑洼损害文件报表 PSPEC:F51接受查询条件输入：接受城市管理者输入的查询条件，例如：根据坑洼大小，位置查询坑洼损害文件，根据查询某施工队在某段时间完成的修复工作等。这里需要先做出初步的分类工作，按

36、照不同的查询条件，细化查询动作。F52细化查询分类并进行查询：将已经进行了初步细化的查询条件进一步细化分类，使一个条件查询成为系统内部几个基本的查询动作的合成，按顺序调用系统内部的基础查询模块，得到一般的查询结果。F53返回查询结果：在上一步处理得到的一般查询结果的基础上，根据管理者的具体需求，再次将查询结果个性格式化，将此格式化后的查询结果返回给管理者。数据字典（Data Dictionary）依据以上的数据流程图，将其中的数据流具体化，得到以下的相应的数据字典：数据字典数据流名称别名输入（输出）具体内容坑洼情况报告坑洼情况报告概要输入：市民输出：F11,F12,F31,F32包含关于一个坑洼的初步详细信息，所在街道，尺寸，报告时间等。市民个人信息输入：市民输出：F14包含报告坑洼的热心市民的个人信息，姓名，地址，联系