公交运营系统需求分析原始版.docx

1、公交运营系统需求分析原始版河北北方学院信工学院软件工程实验指导与报告书 2012 学年 第 1 学期班 级： 10级信息管理与信息系统 组 号： 22 组 长： 张馨 201043109 组 员： 王亚涛 201043127 谢永刚 201043128 实验地点： 河北北方学院 指导教师： 赵志升 信息科学与工程学院20109实验一 需求调研分析张家口市公交运营调度系统需求分析1、引言1.1编写目的编写本系统需求分析说明书的目的：该系统需求分析说明书是用来确保系统提供功能可以与用户的需求达成共识。本说明会做出一个清晰、毫无二义性的“需求”说明，降低系统开发风险，为用户提供一个功能更加完善，操作

2、更为友好的管理系统。 1.2项目背景本项目的委托单位：张家口市通泰公交总公司本项目的名称：张家口市公交运营调度系统开发单位：王亚涛、张馨、解永刚用户：公交运营商本项目的应用范围：张家口市通泰公交总公司1.3定义ZBODS：Zhangjiakou Bus Operation Dispatching System(张家口市公交运营调度系统)1.4参考资料使用软件工程（第二版） 郑人杰 殷人昆 陶永雷 清华大学出版社软件测试技能实训教程 Andy Yue（美） 金晓丰 蒋唯游 科学出版社软件测试 朱少民 人民邮电出版社2、任务概述2.1 目标该系统针对用户张家口市通泰公交总公司，其功能有：（1）登录

3、功能：司机评工作证号在公交车终端进行登录。（2）录入功能：向系统录入司机及公交汽车的基本信息。（3）查询功能：可以通过系统查询到任何司机或公交汽车的相关记录。（4）实时监控与警报功能：通过对速度与客流量的实时监控，系统可以做出拥塞警报。（5）日志生成与存储功能：系统会自动生成日常工作日志，事故处理记录，公交车检修记录。2.1条件和限制要求管理员可以熟练操作计算机，并掌握一定管理与调度能力。要求每辆公交车配有移动客户终端。要求每个司机具有统一并且唯一识别的工作证号。3可行性分析报告3.1引言编写目的利用信息技术手段，实现公交运营管理的信息化、智能化，为客户提供快捷、高效和高质量的公交服务。公交运

4、营调度系统主要用于车辆的实时监控和动态调度。预期的读者：软件的管理人员、开发人员、维护人员。背景a开发软件的名称：张家口市公交运营调度系统b任务提出者：赵志升老师；本项目的开发者：王亚涛、张馨；用户：软件的管理人员、开发人员、维护人员；实现软件的单位：张家口市通泰公交集团。c该项目与其他软件或者系统的关系：管理信息系统、车辆定位系统（GPS定位系统）为其提供信息作出相应决策。定义 ZBODS: Zhangjiakou Bus Operation Dispatching System (张家口市公交运营调度系统) 全球定位GPS技术车辆的准确定位是实现智能调度系统的关键，由于车辆处于不停的运动状

5、态，如果管理部门不能随时了解每一辆车的确切位置，就无法对其实现有效的调度。因而，只有对移动中的每一辆车实时准确定位，才能准确掌握运营线路上的车辆的运行状态，才能进行有效的监控、指挥、调度与决策，才有可能自动形成各种准确的运行报表，并及时向各电子站牌发出准确的离到站信息。3.2 可行性报告的前提要求a功能：登录功能、录入功能、查询功能、实时监控与警报功能、生成报表功能。b性能：实时性好，能快速进行车辆的实时监控和动态调度。c输出对象：日志、事故处理记录、检修信息记录。d输入:包括数据的来源以及基本信息和检修信息和油耗。e基本的数据流程和处理流程。 f在安全与保密方面的要求：对用户登录进行密码保护

6、，除了系统管理员外其他人不能登陆到系统对日志进行修改。g与软件相关的其他系统：管理信息系统、车辆定位系统（GPS定位系统）。h完成期限。目标a为乘客提供快捷、高效和高质量的公交服务；b控制精度和生产能力提高；c管理信息服务改进；d决策系统改进；e人员工作效率提高。条件、假定和限制a所建议系统运行寿命的最小值，建议系统升级时间周期为2年；b进行系统方案选择比较的时间为一个星期；c经费来源于开发者或者企业赞助；d法律和政策方面的限制：系统没有与国家或地方法律及道德标准有冲突和碰撞。e硬件方面：内部有自己的服务器和中心计算机。软件方面：配有GPS定位系统，有自己的信息管理系统。开发环境：浏览器以上；

7、如果数据涉及保密与安全问题，应由负责人输入；计算机资源：cpu：1G 以上，内存：256m 以上f该系统投入使用的最晚时间为2013年12月底。可行性研究方法 通过SWOT分析法确定研究对象的优势、劣势、及其所处的外部环境之中所处的有利的机会和不利的威胁。经过团队的共同讨论针对时下的技术、经济、等诸多因素定案。决定可行性的主要因素a对公交车速度和客流量的统计；b系统日志记录的准确性；c系统登录页面的准确性与及时性。3.3 对现有系统的分析处理流程图工作负荷公交运行经常出现堵塞，管理十分多样化，复杂化，通过人工操作所带来的效率不高，工作人员工作负荷大。费用开支现有系统的人力资源浪费严重，得不到合

8、理利用，由于在公交运行堵塞，人工的管理效率低，导致每辆车的相对调用次数大大降低，资源和资金得不到合理利用。人员原系统没什么科技含量，只需要司机和管理员即可。设备设备的科技含量比较低，几乎是人工操作，脑力和资源浪费极大。局限性原系统为人工处理系统，人工操作与计算机相比响应时间慢，数据可靠性不高，处理能力不强等，而且人工操作会使得系统复杂化，工作人员工作负荷大，人员与设备技术含量低等等一系列缺点。因此需要该系统来代替人类劳动。3.4 所建议技术可行性分析对系统的简要描述公交运营系统利用信息技术手段，实现公交运营管理的信息化、智能化，为客户提供快捷、高效和高质量的公交服务。公交运营调度系统主要运用全

9、球定位GPS技术对车辆进行实时监控，并作出相应的动态调度。公交运营调度系统的架构，按照目前流行的MVC三层结构来实现。系统结构图优越性：该系统相对于原来的人工管理方式，是利用信息技术手段，实现运营管理的信息化智能化，采用先进科学技术代替人工操作，保证了公交运行的实时性和准确性，有效利用现有资源完成高效率的工作。影响（1）对设备的影响使用GPS定位系统。（2）对现有软件的影响支持现行系统，使软件的冲突减少到最小。（3）对用户的影响要求使用者熟悉Windows的基本操作。（4）对系统运行的影响a 用户要严格按照系统要求规程操作； b对数据要按规格写入，对数据的增加、删除、修改有友好提示；c输出数据

10、按分页形式显示出来。（5）对开发环境的影响a 浏览器IE6以上；b 如果数据涉及保密与安全问题，应由负责人输入； c 计算机资源：cpu：1G 以上，内存：256m 以上。（6）对运行环境的影响要支持网络连接。（7）对经费开支的影响在硬件方面比如说缆线，终端电脑和中心服务器等会有一定的开支，软件方面，也要支付开发人员一定费用。技术可行性评价有充足的人力资源，设备充足。3.5 所建议系统经济可行性分析支出：（1）基建投资约占总资金的15%。（2）其他一次性支出GPS设备和何种软硬件设备等（3）非一次性支出公交汽车和计算机等硬件设备的维修费用和事故处理费用，工作人员的工资、奖金等等。收益：（1）一

11、次性收益提高了公交运行的效率。（2）非一次性收益减少了人力资源的浪费，公交资源也能得到有效的利用。收益/投资比：增大。投资回收周期：一年左右。3.6 社会因素方面的可行性法律方面的可行性开发公交运营调度系统，符合国家大力发展公共交通的政策， 可以获得政府在政策、资金等领域的支持。系统开发所采用的无线网络属于商用无线网，符合国家在无线电管理方面的法律规定。该项目为独立开发，开发环境和开发工具是购买了版权的合法共居，在法律方面不会存在侵犯专利权、侵犯版权等问题。使用方面的可行性操作便捷，满足管理的基本要求。3.7 结论经过一系列各个不同方面的可行性分析，分析员及其工作人员和使用部门 的负责人对需要

12、解决的问题取得基本一致的看法，开发方案得到批准，使用部门负责 人同意开发工程。4、数据描述4.1 数据定义 源点终点处理 公交汽车 司机 日历 登录 实时监控 动态调度 车检 数据流 数据存储 时间 司机信息 姓名 性别 出生日期 工作证号 驾驶证号 联系电话 公交汽车信息 车牌号 路别 汽车型号 监控信息 车速 客流量 事务 检修信息 油耗 日志 事故处理记录 检修信息记录4.2 数据流图4.3 数据词典（1）数据流词条数据流名：司机信息说明：记录司机的基本信息数据来源：司机数据去向：日志数据流组成：姓名+ 性别 + 出生日期 + 工作证号 + 驾驶证号 + 联系电话数据流通量：频繁数据流名

13、：公交汽车信息说明：记录公交汽车的基本信息数据来源：公交汽车数据去向：日志数据流组成： 车牌号 + 路别 + 汽车型号数据流通量：频繁数据流名：事务说明：记录公交汽车检修及油耗信息数据来源：公交汽车数据去向：检修记录数据流组成： 检修信息 + 油耗数据流通量：一般数据流名：监控信息说明：记录实时监控的公交汽车信息数据来源：公交汽车数据去向：实时监控数据流组成： 车速 + 客流量数据流通量：频繁（2）数据元素词条数据元素名：车速类型：数值型长度：10数据元素名：客流量类型：数值型长度：10数据元素名：车牌号类型：字符型长度：10数据元素名：路别类型：字符型长度：4数据元素名：司机姓名类型：字符型

14、长度：10数据元素名：司机性别类型：字符型长度：2数据元素名：工作证号类型：字符型长度：15数据元素名：驾驶证号类型：字符型长度：15（3）数据文件词条数据文件名：日志简述：存储日常工作信息，对司机、公交车的实时监控信息也进行实时记录输入数据：监控信息、时间存储方式：按时间顺序存取频率：频繁数据文件名：事故处理记录简述：存储警报信息和警报原因，处理结果输入数据：警报信息、解决方案存储方式：按时间顺序存取频率：一般数据文件名：检修信息记录简述：存储日常车间信息、汽车故障修理信息、油耗信息输入数据：事务存储方式：按时间顺序存取频率：一般（4）加工逻辑词条加工名：登录加工编号：1简要描述：对司机的信

15、息进行判定，符合登录条件后将把司机和公交车信息以及发车信息进行记录并跟踪。输入数据：司机信息、公交车信息、时间输出数据：登录信息加工名：实时监控加工编号：2简要描述：对汽车的车速和客流量进行实时监控，并判断是否发生拥塞。输入数据：车速、客流量输出数据：拥塞警报加工名：动态调度加工编号：3简要描述：对发出的警报信息进行分析并作出处理输入数据：警报信息输出数据：解决方案加工名：检修加工编号：4简要描述：对公交汽车进行日常安全检查，并对汽车进行日常维修，加油等输入数据：汽车信息输出数据：事务信息（5）源点及汇点词条名称：司机简要描述：公交汽车司机有关数据流：司机基本信息名称：公交汽车简要描述：运营中

16、的公交汽车有关数据流：公交汽车基本信息名称：日历简要描述：有关数据流：时间4.4 数据库描述数据库名称：张家口市公交运营调度系统5、功能需求：5.1功能划分（1）登录功能（2）录入功能（3）查询功能（4）实时监控与警报功能（5）日志生成与存储功能5.2功能描述（1）登录功能：司机评工作证号在公交车终端进行登录。（2）录入功能：向系统录入司机及公交汽车的基本信息。（3）查询功能：可以通过系统查询到任何司机或公交汽车的相关记录。（4）实时监控与警报功能：通过对速度与客流量的实时监控，系统可以做出拥塞警报。（5）日志生成与存储功能：系统会自动生成日常工作日志，事故处理记录，公交车检修 记录。6、性能

17、需求：6.1 适应性：（1）运行环境：客户机/服务器模式。客户机设置于公司机房内部，每辆公交车上均安装 客户端。（2）操作方式：司机打卡登录，管理员在服务器端登录。7、运行需求：运行环境：Winows xp / Windows 7等CPU:pentium 以上、内存：512M、硬盘40G8、其他需求： 由于本公交调度系统管理张家口市的公交运营调度，为公交管理者和公交司机提供服务，所以需要该系统具有易操作性和健壮性。9、组内分工 张馨：可行性分析报告。王亚涛：可行性分析报告（部分）、数据描述、功能需求。谢永刚：任务概述、系统结构图、性能需求等。思考题1、需求分析在软件开发中真的有那么重要吗？ 2

18、、分析系统流程图，流程图和数据流图的区别和各自的特点。 3、怎样写符合规范的数据流图和数据词典？ 4、怎样组织对该工作的评审？ 答：1、软件需求分析特别重要。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中的一个简单步骤，但在过去十多年中越来越多的人认识到它是整个过程中最关键的一个过程。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。许多大型应用系统的失败，最后均归结到需求分析的失败：要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好

19、，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。2、系统流程图：反应主体框架数据流程图：反应数据走向 它不考虑时序关系，是业务分析用的，用作详细设计。流程图：程序逻辑 描述程序中控制流的情况,即程序中处理的执行顺序和执行序列所依赖的条件,图中的有向线段表示的是控制流,从一个处理走到下一个处理3、数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。 数据流程图包括： a指明数据存在的数据符号，这些数据符号也可指明该数据所使用的媒体；b指明对数据执行的处理的处理符号，这些符号也可指明该处理所用到的机器功能；c指明几个处理和（或）数据媒

20、体之间的数据流的流线符号；d便于读、写数据流程图的特殊符号。 数据字典是为了规范某应用领域中的各种概念的集合4、评审会议流程一般采取以下几个步骤：评审会议的准备、评审会议的召开、评审会议的跟踪三大环节。 一、 评审会议的准备会议的发起人召集会议，发出评审通知（评审内容、会议时间、会议地点、参加人员等），并且将相关待评审的相关资料也发送给参加会议的评委；主要的目的有两个：第一、让参加会议的人员对会议的内容有一定的了解，在会议前做好准备，避免盲目的参加会议而浪费自己和其他人的时间；第二、如果该评委在会议时间有其他紧急的事情，可以及早反馈给会议召集人，必便召集人重新确定评委或者评审会议改期召开。二、 评审会议的召开一般情况下，确定一个会议主持人；其主要的职责是控制会议的进度、时间、协调会议中出现的偏差。对于待评审的工作产品由其生产者采用“走读”的形式进行讲解，在讲解的过程中回答评委提出的问题。会议记录人主要是记录会议中发现的所有问题，方便会后的修改完善。SQA人员参加会议主要的关注点在于对照SQA的检查表Checklist检查评审的流程是否符合规范。三、评审会议的跟踪将记录的问题汇总到评审记录表，由项目组进行修改、完善；SQA监督所有问题是否封闭。教师评价