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

1、城市管理坑洼跟踪和修复系统需求分析说明书CMHR系统项目需求分析说明书第 01 版二oo三年七月二十四日版本控制信息版本日期拟稿和修改说明01.002003-7-23梁峰初稿01.012003-7-25梁峰修订01.022003-7-26梁峰最终稿范围1.11.21.3标识 系统概述 文档概述引用文档项目概述3.13.23.3目标 用户的特点假定和约束需求规定4.14.24.2.1功能需求 性能需求 精度 4.2.2时间特性要求4.2.34.34.44.54.64.74.7.1灵活性 输入输出要求 数据管理能力要求 故障处理要求 设计约束 属性 安全性 788994.7.24.84.8.1可维

2、护性 其它需求 数据库 .4.8.2操作系统分析105.15.25.3数据流程图（ DFD 并附 PSPEC ） 数据字典（ DATA DICTIONARY ） 实体关系图（ ERD ） 101920运行环境规定226.16.26.3硬件 支持软件 接口需求222222支持信息221 范围1.1标识QR-10-02CMHR需求分析说明书城市管理坑洼跟踪和修复系统（简称 CMHR）S1.2系统概述CMHR是一个基于web的城市坑洼跟踪和修复系统，它为一般大城市的城市管理部门提 供了高效快捷的工作方式， 主要的设计目标是为了实现城市管理电子化网络化， 使广大市民真正的参与到城市管理中来， 增强市民

3、的主人翁精神和对于城市管理的责任感， 另一方面相对于以前的档案办公， 电子化网络化的优势是极其明显的， 它不但增大了信息的储存量， 而 且大大提高了城管各部门的协调能力，使有限的人力财力资源得到了最大化的应用。1.3文档概述该文档详细描述了 CMHR系统的需求规约，为进一步的概要设计和详细设计奠定了基 础。引用文档需求文档模板（国标） CMHR系统需求分析草稿项目概述在应用于实际之后， 将大大提它将替代现有的城市坑洼管理系本软件的开发是实现城市管理网络化电子化的大胆尝试，高城市坑洼管理的效率， 真正意义上实现高效无纸化办公。 统。另外，整个系统是基于城市管理系统的，是整个管理系统的一个子系统。

4、3.2用户的特点本软件的最终用户将是广大热心市民，城市管理人员以及系统维护人员。对于广大市民只要求有基本的电脑操作知识和会浏览网页即可。 对于城市管理人员，要求了解基本的电脑操作知识，有过使用管理系统的经历最佳。 对于系统维护人员要求有管理大型数据库的能力， 另外还须对本系统有一定的了解， 够在发生普通的异常情况时，根据使用说明手册进行维护。3.3假定和约束因为现有的城市坑洼管理系统陈旧不堪，需要 CMHR尽快开发成功，政府方面要求以 3个月为期限。开发经费方面，因为是A市对于城市管理系统的初次尝试， 一切都是试探性的，所以资金投入不是很大，尽量少花钱，多办事。考虑到现有政府工作人员的计算机操

5、作水平有限， 希望开发的软件有良好的人机交互界 面，较高的可操作性。4 需求规定4.1 功能需求CMHR主要分为以下几个功能需求:市民报告坑洼信息：市民可以登陆网站并报告自己发现的坑洼，提交的坑洼概要信息包括:坑洼所在街道， 坑洼大小（大体） ，发现时间，坑洼现状。系统对于用户填写的概要信息进行处理，根据坑 洼所在位置，时间，坑洼现状等信息与数据库中现有信息进行比较，察看是否有类似记录， 如果已有类似的坑洼报告， 则提取此坑洼的详细信息， 提示用户进行核实。 如果没有类似坑 洼报告， 则引导用户填写全面详细的情况报表， 生成坑洼情况报告单。 用户报告完毕坑洼情 况后，提示用户输入自己的姓名，家

6、庭住址，联系电话，身份证号码等个人信息，记录入热 心市民信息数据库。坑洼信息报表评估（信息详化）坑洼情况报告单输入， 根据坑洼类型及参数标准信息对照表， 加入新的更为详尽的信息， 包括：a.根据坑洼大小和尺寸对照表，确定坑洼大小等级（ 1-10 ）; b.根据城市街道区域图路中或和报告单中的街道地址， 确定坑洼所在区域。C.根据坑洼现状描述，确定所在位置路边等）。D.根据坑洼大小和坑洼所在区域，位置（生活区，工业区，商业区等的优先等级 可能有所不同） ，确定坑洼修复的优先等级。按照数据库现有坑洼信息报表，为此新坑洼分 配一个唯一编号，生成最终的坑洼信息报表。坑洼损害文件生成:按照坑洼信息报表，

7、 安排调查人员实地考察一一核实坑洼信息报表中的各项， 对于不准确的信息给于精化， 对于不正确的信息给予纠正， 并且全面衡量各种信息（坑洼等级， 所处 地段，坑洼带来的危害等） ，最终确定是否需要对于此坑洼作进一步处理，如此坑洼暂时无 需处理，则给予无需处理标记， 将此信息报表备份归档。 如需继续处理，则给予需要处理且 未处理标记。未处理坑洼的施工分配:检索未处理的坑洼损害文件， 并从数据库中提取施工队的当前情况， 依据坑洼的处理优 先等级和施工队的当前状况， 将优先等级较高的坑洼分配给近期无施工任务的施工队或施工 任务较轻的施工队（此处需要一定的匹配算法） 。根据坑洼的大小，严重情况，所处地段

8、， 施工需要等信息， 从仓库中分发施工材料以及所需装备给此施工队， 最终根据这三方面信息产生施工单。向施工队分配施工任务。施工完毕后对于损害文件的处理：施工完毕后根据施工队施工过程中所消耗材料， 工作日， 人数等信息， 关联施工队的简 单信息和报告市民的信息后产生损害文件，备份入库，以备查询。交互查询：主要依据坑洼位置，大小，修复时间，负责的施工队，所耗材料，所耗人时等查询条件 查询坑洼信息， 施工队信息，材料设备使用状况等。另外还可以查询热心市民信息，做出评 比等。CMHR是一个基于WEB勺管理系统，其并发程度很大程度上决定于 WE冋艮务器和后台数 据库的的并发处理能力，连接终端和同时并发用

9、户数目控制在 100。4.2性能需求4.2.1精度该系统中没有对于较高数据精度的需要， 例如： 市民报告坑洼情况时， 对于坑洼位置精 确到街道，坑洼大小给出目测的范围值即可（如 0.5-1M ），坑洼发现的时间精确到每日。总 之，对于所有的尺度量精确到 CM日期精确到每日，人民币数目精确到元，时间长度度量 精确到天。在数据存储和传输过程中与输入时相同。4.2.2时间特性要求响应时间：对于用户输入的响应时间大体上决定于网络传输速度。更新处理时间： 坑洼的更新信息应该维持在每天。规格说明号：数据的转换和传送时间： 解题时间：4.2.3灵活性操作方式的变化：运行环境的变化：WEB服务器进行更新时，对

10、于整个程序的结构应该没有太大的影响 同整个城市管理系统其他部分接口的变化： 因为后台数据库与整个城市管理系统是集成在一起的， 采用分布式数据库， 对于数 据的利用达到最大化。 当整个分布式数据库发生变化时， 如果数据库关系模式无变 化，只牵扯数据的导出和重新导入， 如果模式变化， 则需要进行异构数据库间的转 化，较为复杂。精度和有效时限的变化: 此CMHR系统的应用时间初步定位为 10年，可以考虑使用过程中的系统硬件软件 升级问题。计划的变化或改进: 如果出现计划变化和改进，需要小组成员协调处理。4.3输入输出要求市民信息数据类型数据项格式数值范围精度姓名* （张三）不超过8个字地址* （真南

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

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

13、人翁精神也在增强， 了挑战，为了做长远打算，要求数据库有 能够胜任，例如 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系统服务器端