共建智慧的城市智慧公交V10.docx
《共建智慧的城市智慧公交V10.docx》由会员分享，可在线阅读，更多相关《共建智慧的城市智慧公交V10.docx（22页珍藏版）》请在冰豆网上搜索。
共建智慧的城市智慧公交V10
共建智慧的城市
智慧公交
2013年5月10日
目录
一、引言4
1.1、文档目的4
1.2、文档约定4
1.3、读者对象和阅读建议5
1.3.1、公司人员代表5
1.3.2、客户代表5
1.3.3、软件开发人员5
1.3.4、系统测试人员5
1.3.5、大众读者5
1.4、项目范围6
1.5、参考资料6
二、系统概述7
2.1、产品前景7
2.2、产品特征7
2.2.1、系统特征7
2.2.2、“智慧”公交7
2.2.3、智慧公交系统架构网络图8
2.2.4、用例图9
2.3、运行环境9
2.4、设计和实现上的约束10
2.5、用户文档11
三、外部接口需求11
3.1、硬件接口11
3.2、软件接口13
3.3、通信接口14
3.3.1、手机客户端通讯接口14
3.3.2、GPRS通讯模块14
四、其他非公能性需求15
4.1、性能（PE）要求15
4.1.1、公交信息录入15
4.1.2、系统响应15
4.1.3、系统负载15
4.2、安全性（SE）需求16
4.2.1、系统安全性16
4.2.2、数据安全性16
4.3、防护性需求16
4.4、软件质量属性17
4.4.1、可用性战术17
4.4.2、可修改性战术17
4.4.3、性能战术17
5.4.4、安全性战术17
4.4.5、可测试性战术17
4.4.6、易用性战术17
五、其他需求18
5.1、附录A术语表18
5.2、附录B分析模型18
一、引言
1.1、文档目的
本规格说明，描述了“智慧公交”系统项目的要求，并且作为各方面沟通的依据，也为下一步工作提供基准。
软件开发小组的每一位成员应该阅读本需求说明，以明确项目最后要求完成的产品的特点。
经使用方认可的需求说明将作为产品特征评价、仲裁的重要参考。
本文档主要描述“智慧公交”系统的业务需求，并定义需要系统所支撑的功能和非功能性需求。
文档中同时也给出了系统各个模块的具体操作方式与流程，罗列了各种情况下的具体操作，为用户提供了使用指南。
1.2、文档约定
本文档采用Word编写，请使用2003及以上版本或兼容软件读取，文档中所用图表使用Visio2007作图。
打印请使用标准A4纸张。
本文档中各主要功能需求均有明确定义的优先级，各主要功能需求下若存在子需求，则子需求继承父需求优先级。
1.3、读者对象和阅读建议
1.3.1、公司人员代表
请从头开始仔细阅读，理解“智慧公交”系统的系统背景、运行环境和使用方式，能够确保系统正常运行和日常维护工作。
并结合自身企业特点，给出异常情况发生时的处理意见。
尤其注重第三章各功能模块，在员工、客户等使用人员有疑惑时能够给予帮助。
1.3.2、客户代表
可按照自身实际需要阅读，尤其需要注意硬件平台、数据库集群、服务器和手机移动平台，以便于了解用户从查询最佳路线，查询如何换乘和站台信息的全过程，以及公交信息传输的全过程，方便日常使用。
同时希望能够结合自身实际情况提出需求和改进意见。
1.3.3、软件开发人员
请通篇阅读本文，阅读完一、二章后可先行阅读第六章术语表和数据字典部分，再顺序阅读三、四、五章。
希望根据自身专业知识对本文所涉及的内容进行思考并提出改进意见。
1.3.4、系统测试人员
同软件开发人员。
1.3.5、大众读者
自行选择感兴趣的部分阅读。
推荐全文按顺序阅读。
如果有任何意见或是建议，请与作者联系。
1.4、项目范围
“智能公交”系统作为查询与调度平台不仅支持普通用户在平台上实现公交线路、换乘和站点等查询功能，还支持调度中心的用户通过实时的公交信息系统实现公交调度与调度支援（修理或拖运），详细的项目描述请参见“智能公交”系统前景和范围文档。
文档中这一部分的标题为“项目范围与限制”，列出了按照进度计划在这一版本中实现的全部或者部分特性。
1.5、参考资料
[1]IEEE,IEEE830-1998[Z],1998
[2]KarlE.Wiegers.SoftwareRequirements[M].刘伟琴，刘洪涛，译.北京：
清华大学出版社，2012.
[3]ErichGamma,RichardHelm,RalphJohnson,JohnVlissides.DesignPatterns[M].李英俊等,译.北京：
机械工业出版社.2012.
[4]谭云杰.大象：
ThinkinginUML（第二版）[M].北京：
中国水利水电出版社.2012.
[5]张湘辉.软件开发的过程与管理[M].北京:
清华大学出版社.2005.
[6]金芝.软件需求工程：
原理和方法[M].北京：
科学出版社.2008.
[7]《数据、模型与决策·管理科学篇》[M]，戴维R·安德森、丹尼斯J·斯维尼、托马斯A·威廉斯、基普·马丁著，侯文华等译，机械工业出版社，原书第十二版。
[8]《云计算实践之道：
战略蓝图与技术架构》[M]，虚拟化与云计算小组著，电子工业出版社。
[9]《智慧城市建设思路与规划》[M]，李林著，东南大学出版社。
[10]《国内外快速公交系统发展实践》[M]，郭继孚著，中国建筑工业出版社。
二、系统概述
2.1、产品前景
当前，城市居民对公共交通系统最大的不满主要就是公交服务水平底，例如公交出行速度慢、舒适性差、换成困难等方面。
在传统公交系统建设模式下，改善上述问题需要巨额建设经费的支持，其建设成效还要受到城市交通整体环境的影响。
与之相对应，智能公交系统则是实现的最有效的途径之一。
当前公交领域存在的问题主要包括两个方面：
公交数据获取渠道的不完善及不畅通，公交数据转换成信息的生硬性与静态性。
由我们设计实现的“智慧公交”针对公交领域的这些问题，提供解决方案和演示系统。
2.2、产品特征
2.2.1、系统特征
1）自主运行的公交情景感知元件收集公交实时数据并定时上传到系统服务器，为整个系统提供最原始的数据。
除传统的GPS数据，该数据同时包含从未获取过的人流数据、空气质量数据等。
2）服务器端改进相似度匹配算法、机器学习算法以适应出行预测，通过比对数据库中的历史数据与当日上传的实时数据得到有效准确的预测信息。
该预测信息包括所等公交车何时到站，到站公交是否已经满员，上车后何时能够有座位，整个换乘方案需要的实际总耗时。
3）系统考虑乘坐公交出行人群的舒适度（有座位的概率），给出高舒适度的出行方案的推荐，并显示该方案线路上的实时环境因素（温湿度、空气质量等）。
4）该系统包含自主运行的硬件元件，自主架设的分布式服务器，提供客户端下载，因而可以应用于全国任何城市的公共交通领域并具有良好的可扩展性。
同时，解决方案的设计思想可以应用于其他公共交通设施，如火车晚点查询。
2.2.2、“智慧”公交
1）预测下一辆车的到站时间
本系统以较高频率的GPS作为硬件基础，建立合理的预测模型，不仅依据当前位置、实时车速，还根据天气状况、时间段、途中路段等影响到路况和行驶速度的信息，通过机器学习的方法对历史记录分析来预测当前状况下需要的时间花费，提供给用户与当前情况更贴近、更准确的到站时间预测。
2）预测下一辆车的拥挤程度
本系统以高精度的客流计数器作为硬件基础，经过一段时间的试运行收集了一定量的数据后，对于每个时间段、路段等特定情境下的可搭乘几率，通过比对历史记录中最相似的记录进行事件预测，通过本系统基于人流量的智能推荐，用户可得到考虑了可搭乘几率的排序结果，在一定程度上可以平均各条相似线路上的载客量。
3）预测到达目的地需花费的时间
本系统根据线路时间计算模型，考虑车况、路况、换乘次数等多种因素综合分析，计算出从出发地到目的地所需要的时间，并提供多种线路选择，可根据最少时间，最少换乘，最舒适，最快上车等条件排序。
4）帮助用户获得公交线路沿途的重要环境信息
在车载设备中加装PM0.8、PM2.5和PM10的空气质量感应器，还有湿度感应器和温度感应器，用来采集车辆里或周围的环境数据，为乘客提供车辆环境信息，并提供出行提醒。
2.2.3、智慧公交系统架构网络图
2.2.4、用例图
2.2.4-1智能公交系统
2.2.4-2手机APP
2.2.4-3服务器总体架构
2.2.4-4Service-调度中心
2.3、运行环境
OE-1：
服务器端运行环境：
名称
要求
硬件
PIII400主频
INTELXEON2.0GHzCPU
2GDDR2或更高
10G硬盘
集成双千兆网卡
光盘刻录或磁带备份设备
操作系统
Windows操作系统（Win2000/WinXP/Win2003/Vista/Win7）
软件平台
Jdk1.6,Eclipse（J2EE运行环境）
Web服务器
GlassFish3.1
数据库
MySQL6.0
空间大小
初次安装至少100M可用空间
连接带宽要求
2Mbps共享或更高
OE-2：
客户端运行环境：
名称
要求
硬件
512M内存或更高
1G以上存储空间
普通个人PC、平板、智能手机
操作系统
Windows操作系统（Win2000/WinXP/Win2003/Vista/Win7）
移动平台Android,IOS手机操作系统
浏览器
IE7及以上、FireFox2或以上、Chrome
连接带宽要求
128Kbps或更高
2.4、设计和实现上的约束
CO-1：
软件开发人员提供相应的开发阶段文档，用户提供相适应的行业标准，使软件开发与典型实例考核相结合。
CO-2：
操作员与用户要按照操作规程运行本系统，不得进行恶意破坏性操作。
CO-3：
用户必须提供相关运行软件有效的数据库接口标准，并在改动的过程中及时通知本软件开发商，以保证从中正确读取预决算参数，进行成本预算。
CO-4：
本项目的开发经费不超过30万元；
CO-5：
开发期：
9个月；
CO-6：
在管理方针，硬件的限制，并行操作安全和保密方面无约束。
2.5、用户文档
UD-1：
系统将提供一个分层的和跨链接的HTML联机帮助系统，它描述并展示了所有系统功能
UD-2：
如果一个新用户第一次使用该系统，系统可以根据用户的要求，提供一个联机教程，该用户可使用静态教程菜单来具体实际实践如何查询车站/路线信息。
系统不会将采用这一模板的查询操作存储到数据库中，也不会将这种查询提交到系统服务中。
三、外部接口需求
3.1、硬件接口
HI1：
车载硬件设备
图HI1-1车载硬件设备结构图
图HI1-2车载硬件设备实物图
车载硬件设备是智能公交中，最重要的硬件设备之一。
是公交实时信息的接收器。
所有的公交信息都来源此。
如图，HI1-1可知，设备中包含有，客流计数器，中央处理电路板，GPS芯片，温度湿度感应器，空气质量感应器/PM2.5感应器，GPRS通讯模块等电子元器件。
3.2、软件接口
SI-1:
SOCKET数据接收器
SI-1.1:
可以将接受的信息存入集群数据库。
SI-1.2:
可以接受从电信基站传过来的公交信息。
SI-1.3:
SOCKET数据接受器可以过滤公交的信息。
将错误或失效的信息屏蔽掉。
SI-2:
智能算法处理组件
SI-2.1:
允许获取公交线路信息。
SI-2.2:
允许获取道路信息。
SI-2.3:
允许获取公交信息。
SI-2.4:
智能分析数据。
SI-2.5:
智能计算最舒适路径。
SI-2.6:
生成结果。
SI-3:
调度子系统。
SI-3.1:
调度员通过登录调度系统后，可查询车辆信息；查询线路信息；查询路况信息等。
SI-4:
基础信息管理子模块。
SI-4.1:
系统维护人员运行进行班组管理，车辆管理和员工管理。
SI-4.2:
普通用户只能进行简单的查询，如：
班组查询、线路查询、车辆查询和员工查询。
SI-4.3:
公司管理人员拥有与系统维护人员相同的管理权限。
SI-5公交记录仪。
SI-5.1：
允许记录车辆信息。
SI-5.2：
允许记录车辆行车信息。
SI-5.3：
允许记录车辆内部信息。
3.3、通信接口
3.3.1、手机客户端通讯接口
该通讯接口主要是用于手机端“智能公交查询”系统的App的通讯及应答。
“智能公交查询”系统将开发包括ios版，android版的手机全功能应用，以方便“智能公交查询”系统用户随时随地查询公交相关信息。
3.3.2、GPRS通讯模块
它是GSM移动电话用户可用的一种移动数据业务。
GPRS可说是GSM的延续。
GPRS和以往连续在频道传输的方式不同，是以封包（Packet）式来传输，因此使用者所负担的费用是以其传输资料单位计算，并非使用其整个频道，理论上较为便宜。
GPRS的传输速率可提升至56甚至114Kbps。
利用这种制式，可以完全满足公交车移动，持续和通讯稳定的要求。
四、其他非公能性需求
4.1、性能（PE）要求
4.1.1、公交信息录入
PE-1：
公交信息录入，需要采用workflow。
第一次通信时，将公交的基本信息，如：
汽车号牌，运行状态等信息提交到服务器。
再接下来的工作流中，实时的传输其他的动态信息。
信息规定如下：
格式为XML。
采用压缩机制，内容为：
位置、温湿度、空气质量、人数等。
4.1.2、系统响应
PE-2：
用户（平板/PDA/iphone/android手机）系统生成的所有页面，在2.5G通信制式的网络环境下不超过20秒（3G或wifi不超过3秒）的时间内全部显示在客户端。
PE-3：
用户提交查询后，对查询的响应时间在2.5G通信制式的网络环境下不超过20秒（3G或wifi不超过1秒），并显示查询结果。
PE-4：
用户提交的其他操作，系统处理时间在2.5G通信制式的网络环境下不超过20秒（3G或wifi不超过1秒），并显示操作反馈。
4.1.3、系统负载
PE-5：
公交信息录入，在1000辆公交车并行录入时。
SOCKET数据接收器的接收响应时间，不能超过0.3秒。
且接收率为99.999%。
PE-6：
系统必须支持3万人以内的同时在线，当人数在1000人以上时，PE-4，PE-3的响应时间相应提高0.5秒，当人数在2000人以上是，响应时间可再此提高0.5秒。
4.2、安全性（SE）需求
4.2.1、系统安全性
SE-1：
所有注册本系统（PHP客户端响应服务器）的潜在用户均需填写手机并获取认证，系统会自动匹配用户手机回复的验证信息。
SE-2：
（PHP客户端响应服务器）中，所有注册用户的初始权限均为普通用户，用户必须使用用户名和密码登陆，并设置权限后才可以执行信息修改。
SE-3：
（PHP客户端响应服务器）中，所有用户都有部分相关信息发布和查询的权限。
4.2.2、数据安全性
SE-4：
数据库使用数据冗余形式备份数据，以一周作为间隔备份当前完整数据库。
SE-5：
本系统由用户信息系统中导入的数据操作前应保证数据的有效性。
SE-6：
任何由公交车传过来的数据，不能因为其数据量大，或数据错误，而影响数据库当机，或出错。
4.3、防护性需求
DE-1：
如果交易的次数频繁，系统应该向用户警告或提示。
DE-2：
如果在系统使用非法信息或数据，系统应该立即警告此用户。
DE-3：
如果用户登录后半小时未进行任何操作，系统保存用户此时界面，然后提醒用户重新登录才可显示上次界面，并继续操作。
4.4、软件质量属性
4.4.1、可用性战术
本系统要求对于用户的请求应在提交请求后给出正确的相应即提供及时有效的服务。
系统开通之后，应一直可以使用，即提供7*24小时服务。
4.4.2、可修改性战术
系统上线后，应当能够进行相应的维护及版本升级。
4.4.3、性能战术
本系统需要采用分布式计算，已保证各个数据库的负载均衡。
且保证大数据量通信时，各个数据库和系统的运行稳定。
5.4.4、安全性战术
本系统要保证用户的个人和公交信息的数据的安全，不丢失，不外泄，不被篡改。
4.4.5、可测试性战术
在系统特性中，保证可测试性描述。
在系统上线后，对系统在不同性能指标中进行测试。
以确保程序运行无故障。
4.4.6、易用性战术
本系统中，用户在使用手机（或移动设备）进行查询公交线路或查询公交驶入情况中，应给用户提供通过智能分析处理后的数据。
不应将难懂的基本数据提供给用户。
4.4.7、选择性战术
本系统中，不可能把所有的功能都考虑进去。
在选择时，我们会主要把车载设备这块的功能考虑比较多。
并将基本上所有的公交信息都过去到了。
这是因为考虑到升级硬件，尤其是升级车载设备的硬件，是比较麻烦的，且成本较高。
所以在功能方面车载设备的功能是比较全的。
所以可以在发回的信息中可以看到，汽车的内部和外部环境。
当然这些信息有可能不会作为本系统现在的信息功能所利用。
但是可以作为扩展信息，为以后的功能服务。
五、其他需求
5.1、附录A术语表
JI公交
本系统的名称，用于解决目前公交出行领域存在的诸多问题，实现的“实时情景感知与搭乘线路优化系统”。
公交情景感知子系统
基于GPS定位设备、温湿度感应器、空气质量感应器、人流计数器、供电设备等多种设备搭建可以自主运行的公交情景感知元件，安装在公交上用来收集位置、温湿度、空气质量、人数等公交的实时数据，并通过自定义的传输协议定时上传至服务器的系统。
人流计数器
通过感应器（安装在公交车上的感应设备）统计上车和下车的人数，并计算得出途径每个站点的车上乘客数。
出行方案
包括系统优化后的出行线路，简明准确公交信息（如乘客人数、拥挤程度、路况信息等），以及线路匹配策略（如最快路线，乘客最少，空气质量最好）
出行预测
在给出确定的出行方案的基础上，通过比对数据库中的历史数据与当日上传的实时数据得到有效准确的预测信息（如预估时间、乘客人数、空气质量、实时路况等）。
分布式服务器
数据和程序可以不位于一个服务器上，而是分散到多个服务器，以网络上分散分布的地理信息数据及受其影响的数据库操作为研究对象的一种理论计算模型服务器形式。
可扩展性
可扩展性是软件设计的原则之一，它以添加新功能或修改完善现有功能来考虑软件的未来成长。
可扩展性是软件拓展系统的能力。
5.2、附录B分析模型
图B.1“智慧交通”系统顶层数据流
图B.2“智慧交通”系统第一层数据流
升级会员 