公交运营系统需求分析原始版.docx
《公交运营系统需求分析原始版.docx》由会员分享，可在线阅读，更多相关《公交运营系统需求分析原始版.docx（19页珍藏版）》请在冰点文库上搜索。
公交运营系统需求分析原始版
河北北方学院信工学院
《软件工程》实验指导与报告书
2012学年第1学期
班级：
10级信息管理与信息系统
组号：
22
组长：
张馨201043109
组员：
王亚涛201043127
谢永刚201043128
实验地点：
河北北方学院
指导教师：
赵志升
信息科学与工程学院
2010．9
实验一需求调研分析
张家口市公交运营调度系统需求分析
1、引言
1.1编写目的
编写本系统需求分析说明书的目的：
该系统需求分析说明书是用来确保系统提供功能可以与用户的需求达成共识。
本说明会做出一个清晰、毫无二义性的“需求”说明，降低系统开发风险，为用户提供一个功能更加完善，操作更为友好的管理系统。
1.2项目背景
本项目的委托单位：
张家口市通泰公交总公司
本项目的名称：
张家口市公交运营调度系统
开发单位：
王亚涛、张馨、解永刚
用户：
公交运营商
本项目的应用范围：
张家口市通泰公交总公司
1.3定义
ZBODS：
ZhangjiakouBusOperationDispatchingSystem（张家口市公交运营调度系统）
1.4参考资料
《使用软件工程》（第二版）郑人杰殷人昆陶永雷清华大学出版社
《软件测试技能实训教程》AndyYue（美）金晓丰蒋唯游科学出版社
《软件测试》朱少民人民邮电出版社
2、任务概述
2.1目标
该系统针对用户张家口市通泰公交总公司，其功能有：
（1）登录功能：
司机评工作证号在公交车终端进行登录。
（2）录入功能：
向系统录入司机及公交汽车的基本信息。
（3）查询功能：
可以通过系统查询到任何司机或公交汽车的相关记录。
（4）实时监控与警报功能：
通过对速度与客流量的实时监控，系统可以做出拥塞警报。
（5）日志生成与存储功能：
系统会自动生成日常工作日志，事故处理记录，公交车检修记录。
2.1条件和限制
要求管理员可以熟练操作计算机，并掌握一定管理与调度能力。
要求每辆公交车配有移动客户终端。
要求每个司机具有统一并且唯一识别的工作证号。
3可行性分析报告
3.1引言
编写目的
利用信息技术手段，实现公交运营管理的信息化、智能化，为客户提供快捷、高效和高质量的公交服务。
公交运营调度系统主要用于车辆的实时监控和动态调度。
预期的读者：
软件的管理人员、开发人员、维护人员。
背景
a开发软件的名称：
张家口市公交运营调度系统
b任务提出者：
赵志升老师；本项目的开发者：
王亚涛、张馨；用户：
软件的管理人员、开发人员、维护人员；实现软件的单位：
张家口市通泰公交集团。
c该项目与其他软件或者系统的关系：
管理信息系统、车辆定位系统（GPS定位系统）为其提供信息作出相应决策。
定义
ZBODS:
ZhangjiakouBusOperationDispatchingSystem（张家口市公交运营调度系统）
全球定位GPS技术
车辆的准确定位是实现智能调度系统的关键，由于车辆处于不停的运动状态，如果管理部门不能随时了解每一辆车的确切位置，就无法对其实现有效的调度。
因而，只有对移动中的每一辆车实时准确定位，才能准确掌握运营线路上的车辆的运行状态，才能进行有效的监控、指挥、调度与决策，才有可能自动形成各种准确的运行报表，并及时向各电子站牌发出准确的离到站信息。
3.2可行性报告的前提
要求
a．功能：
登录功能、录入功能、查询功能、实时监控与警报功能、生成报表功能。
b．性能：
实时性好，能快速进行车辆的实时监控和动态调度。
c．输出对象：
日志、事故处理记录、检修信息记录。
d．输入:
包括数据的来源以及基本信息和检修信息和油耗。
e．基本的数据流程和处理流程。
f．在安全与保密方面的要求：
对用户登录进行密码保护，除了系统管理员外其他人不能登陆到系统对日志进行修改。
g．与软件相关的其他系统：
管理信息系统、车辆定位系统（GPS定位系统）。
h．完成期限。
目标
a．为乘客提供快捷、高效和高质量的公交服务；
b．控制精度和生产能力提高；
c．管理信息服务改进；
d．决策系统改进；
e．人员工作效率提高。
条件、假定和限制
a．所建议系统运行寿命的最小值，建议系统升级时间周期为2年；
b．进行系统方案选择比较的时间为一个星期；
c．经费来源于开发者或者企业赞助；
d．法律和政策方面的限制：
系统没有与国家或地方法律及道德标准有冲突和碰撞。
e．硬件方面：
内部有自己的服务器和中心计算机。
软件方面：
配有GPS定位系统，有自己的信息管理系统。
开发环境：
①浏览器ＩＥ６以上；②如果数据涉及保密与安全问题，应由负责人输入；③计算机资源：
cpu：
1G以上，内存：
256m以上
f．该系统投入使用的最晚时间为2013年12月底。
可行性研究方法
通过SWOT分析法确定研究对象的优势、劣势、及其所处的外部环境之中所处的有利的机会和不利的威胁。
经过团队的共同讨论针对时下的技术、经济、等诸多因素定案。
决定可行性的主要因素
a．对公交车速度和客流量的统计；
b．系统日志记录的准确性；
c．系统登录页面的准确性与及时性。
3.3对现有系统的分析
处理流程图
工作负荷
公交运行经常出现堵塞，管理十分多样化，复杂化，通过人工操作所带来的效率不高，工作人员工作负荷大。
费用开支
现有系统的人力资源浪费严重，得不到合理利用，由于在公交运行堵塞，人工的管理效率低，导致每辆车的相对调用次数大大降低，资源和资金得不到合理利用。
人员
原系统没什么科技含量，只需要司机和管理员即可。
设备
设备的科技含量比较低，几乎是人工操作，脑力和资源浪费极大。
局限性
原系统为人工处理系统，人工操作与计算机相比响应时间慢，数据可靠性不高，处理能力不强等，而且人工操作会使得系统复杂化，工作人员工作负荷大，人员与设备技术含量低等等一系列缺点。
因此需要该系统来代替人类劳动。
3.4所建议技术可行性分析
对系统的简要描述
公交运营系统利用信息技术手段，实现公交运营管理的信息化、智能化，为客户提供快捷、高效和高质量的公交服务。
公交运营调度系统主要运用全球定位GPS技术对车辆进行实时监控，并作出相应的动态调度。
公交运营调度系统的架构，按照目前流行的MVC三层结构来实现。
系统结构图
优越性：
该系统相对于原来的人工管理方式，是利用信息技术手段，实现运营管理的信息化智能化，采用先进科学技术代替人工操作，保证了公交运行的实时性和准确性，有效利用现有资源完成高效率的工作。
影响
（1）对设备的影响
使用GPS定位系统。
（2）对现有软件的影响
支持现行系统，使软件的冲突减少到最小。
（3）对用户的影响
要求使用者熟悉Windows的基本操作。
（4）对系统运行的影响
a．用户要严格按照系统要求规程操作；
b．对数据要按规格写入，对数据的增加、删除、修改有友好提示；
c．输出数据按分页形式显示出来。
（5）对开发环境的影响
a．浏览器IE6以上；
b．如果数据涉及保密与安全问题，应由负责人输入；
c．计算机资源：
cpu：
1G以上，内存：
256m以上。
（6）对运行环境的影响
要支持网络连接。
（7）对经费开支的影响
在硬件方面比如说缆线，终端电脑和中心服务器等会有一定的开支，软件方面，也要支付开发人员一定费用。
技术可行性评价
有充足的人力资源，设备充足。
3.5所建议系统经济可行性分析
支出：
（1）基建投资
约占总资金的15%。
（2）其他一次性支出
GPS设备和何种软硬件设备等
（3）非一次性支出
公交汽车和计算机等硬件设备的维修费用和事故处理费用，工作人员的工资、奖金等等。
收益：
（1）一次性收益
提高了公交运行的效率。
（2）非一次性收益
减少了人力资源的浪费，公交资源也能得到有效的利用。
收益/投资比：
增大。
投资回收周期：
一年左右。
3.6社会因素方面的可行性
法律方面的可行性
开发公交运营调度系统，符合国家大力发展公共交通的政策，可以获得政府在政策、资金等领域的支持。
系统开发所采用的无线网络属于商用无线网，符合国家在无线电管理方面的法律规定。
该项目为独立开发，开发环境和开发工具是购买了版权的合法共居，在法律方面不会存在侵犯专利权、侵犯版权等问题。
使用方面的可行性
操作便捷，满足管理的基本要求。
3.7结论
经过一系列各个不同方面的可行性分析，分析员及其工作人员和使用部门的负责人对需要解决的问题取得基本一致的看法，开发方案得到批准，使用部门负责人同意开发工程。
4、数据描述
4.1数据定义
源点／终点
处理
公交汽车
司机
日历
登录
实时监控
动态调度
车检
数据流
数据存储
时间
司机信息
姓名
性别
出生日期
工作证号
驾驶证号
联系电话
公交汽车信息
车牌号
路别
汽车型号
监控信息
车速
客流量
事务
检修信息
油耗
日志
事故处理记录
检修信息记录
4.2数据流图
4.3数据词典
（1）数据流词条
数据流名：
司机信息
说明：
记录司机的基本信息
数据来源：
司机
数据去向：
日志
数据流组成：
姓名+性别+出生日期+工作证号+驾驶证号+联系电话
数据流通量：
频繁
数据流名：
公交汽车信息
说明：
记录公交汽车的基本信息
数据来源：
公交汽车
数据去向：
日志
数据流组成：
车牌号+路别+汽车型号
数据流通量：
频繁
数据流名：
事务
说明：
记录公交汽车检修及油耗信息
数据来源：
公交汽车
数据去向：
检修记录
数据流组成：
检修信息+油耗
数据流通量：
一般
数据流名：
监控信息
说明：
记录实时监控的公交汽车信息
数据来源：
公交汽车
数据去向：
实时监控
数据流组成：
车速+客流量
数据流通量：
频繁
（2）数据元素词条
数据元素名：
车速
类型：
数值型
长度：
10
数据元素名：
客流量
类型：
数值型
长度：
10
数据元素名：
车牌号
类型：
字符型
长度：
10
数据元素名：
路别
类型：
字符型
长度：
4
数据元素名：
司机姓名
类型：
字符型
长度：
10
数据元素名：
司机性别
类型：
字符型
长度：
2
数据元素名：
工作证号
类型：
字符型
长度：
15
数据元素名：
驾驶证号
类型：
字符型
长度：
15
（3）数据文件词条
数据文件名：
日志
简述：
存储日常工作信息，对司机、公交车的实时监控信息也进行实时记录
输入数据：
监控信息、时间
存储方式：
按时间顺序
存取频率：
频繁
数据文件名：
事故处理记录
简述：
存储警报信息和警报原因，处理结果
输入数据：
警报信息、解决方案
存储方式：
按时间顺序
存取频率：
一般
数据文件名：
检修信息记录
简述：
存储日常车间信息、汽车故障修理信息、油耗信息
输入数据：
事务
存储方式：
按时间顺序
存取频率：
一般
（4）加工逻辑词条
加工名：
登录
加工编号：
1
简要描述：
对司机的信息进行判定，符合登录条件后将把司机和公交车信息以及发车信息进行记录并跟踪。
输入数据：
司机信息、公交车信息、时间
输出数据：
登录信息
加工名：
实时监控
加工编号：
2
简要描述：
对汽车的车速和客流量进行实时监控，并判断是否发生拥塞。
输入数据：
车速、客流量
输出数据：
拥塞警报
加工名：
动态调度
加工编号：
3
简要描述：
对发出的警报信息进行分析并作出处理
输入数据：
警报信息
输出数据：
解决方案
加工名：
检修
加工编号：
4
简要描述：
对公交汽车进行日常安全检查，并对汽车进行日常维修，加油等
输入数据：
汽车信息
输出数据：
事务信息
（5）源点及汇点词条
名称：
司机
简要描述：
公交汽车司机
有关数据流：
司机基本信息
名称：
公交汽车
简要描述：
运营中的公交汽车
有关数据流：
公交汽车基本信息
名称：
日历
简要描述：
有关数据流：
时间
4.4数据库描述
数据库名称：
张家口市公交运营调度系统
5、功能需求：
5.1功能划分
（1）登录功能
（2）录入功能
（3）查询功能
（4）实时监控与警报功能
（5）日志生成与存储功能
5.2功能描述
（1）登录功能：
司机评工作证号在公交车终端进行登录。
（2）录入功能：
向系统录入司机及公交汽车的基本信息。
（3）查询功能：
可以通过系统查询到任何司机或公交汽车的相关记录。
（4）实时监控与警报功能：
通过对速度与客流量的实时监控，系统可以做出拥塞警报。
（5）日志生成与存储功能：
系统会自动生成日常工作日志，事故处理记录，公交车检修
记录。
6、性能需求：
6.1适应性：
（1）运行环境：
客户机/服务器模式。
客户机设置于公司机房内部，每辆公交车上均安装
客户端。
（2）操作方式：
司机打卡登录，管理员在服务器端登录。
7、运行需求：
运行环境：
Winowsxp/Windows7等
CPU:
pentiumⅡ以上、内存：
512M、硬盘40G
8、其他需求：
由于本公交调度系统管理张家口市的公交运营调度，为公交管理者和公交司机提供服务，所以需要该系统具有易操作性和健壮性。
9、组内分工
张馨：
可行性分析报告。
王亚涛：
可行性分析报告（部分）、数据描述、功能需求。
谢永刚：
任务概述、系统结构图、性能需求等。
思考题
1、需求分析在软件开发中真的有那么重要吗？
2、分析系统流程图，流程图和数据流图的区别和各自的特点。
3、怎样写符合规范的数据流图和数据词典？
4、怎样组织对该工作的评审？
答：
1、软件需求分析特别重要。
在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中的一个简单步骤，但在过去十多年中越来越多的人认识到它是整个过程中最关键的一个过程。
只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。
许多大型应用系统的失败，最后均归结到需求分析的失败：
要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。
2、系统流程图：
反应主体框架
数据流程图：
反应数据走向它不考虑时序关系，是业务分析用的，用作详细设计。
流程图：
程序逻辑描述程序中控制流的情况,即程序中处理的执行顺序和执行序列所依赖的条件,图中的有向线段表示的是控制流,从一个处理走到下一个处理
3、数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。
数据流程图包括：
a．指明数据存在的数据符号，这些数据符号也可指明该数据所使用的媒体；b．指明对数据执行的处理的处理符号，这些符号也可指明该处理所用到的机器功能；c．指明几个处理和（或）数据媒体之间的数据流的流线符号；d．便于读、写数据流程图的特殊符号。
数据字典是为了规范某应用领域中的各种概念的集合
4、评审会议流程一般采取以下几个步骤：
评审会议的准备、评审会议的召开、评审会议的跟踪三大环节。
一、评审会议的准备
会议的发起人召集会议，发出评审通知（评审内容、会议时间、会议地点、参加人员等），并且将相关待评审的相关资料也发送给参加会议的评委；主要的目的有两个：
第一、让参加会议的人员对会议的内容有一定的了解，在会议前做好准备，避免盲目的参加会议而浪费自己和其他人的时间；第二、如果该评委在会议时间有其他紧急的事情，可以及早反馈给会议召集人，必便召集人重新确定评委或者评审会议改期召开。
二、评审会议的召开
一般情况下，确定一个会议主持人；其主要的职责是控制会议的进度、时间、协调会议中出现的偏差。
对于待评审的工作产品由其生产者采用“走读”的形式进行讲解，在讲解的过程中回答评委提出的问题。
会议记录人主要是记录会议中发现的所有问题，方便会后的修改完善。
SQA人员参加会议主要的关注点在于对照SQA的检查表Checklist检查评审的流程是否符合规范。
三、评审会议的跟踪
将记录的问题汇总到《评审记录表》，由项目组进行修改、完善；SQA监督所有问题是否封闭。
教师评价
升级会员 