打车软件需求分析

司机
正规出租车司机：有营运执照，安全性有保障，但容易空跑 需要提高载客效率、增加营收。 私人车（黑车）司机：不正规无营运执照，不能到某些地点 载客。
1.综合描述
1.4 产品主要功能
乘客：即时打车服务、预约打车服务和寻求代驾服务 司机：接单载客服务、路况信息服务和收听广播服务 第三方：广告推送服务、本地信息显示服务（包括餐饮娱乐及酒 店宾馆）、广播服务、支付服务、地图服务、交通管理服务
2.司机
1.综合描述
1.6 外部接口需求 硬件接口
• • • • •
重庆大学通信工程学院——软件工程
定位：移动网络（2G/3G/4G）快速定位，GPS精确定位 语音输入（MIC）：用于输入用户指令信息如目的地等 语音输出（听筒）：用于广播消息等语音输出 取景器（摄像头）：取景用于定位、上传分享位置等 触屏或者键盘：用于用户操作、发出指令、消息输入等
2.功能性需求分析
2.1系统功能域分析建模
订单登记表 F1、F2 司机、客户管理表 T1、T2
打车/取消 打车需求
需求 分类
打车 需求
生成 订单
申请 代驾
常用信息 查看
取消打车需求
乘客
取消订单
订单登记表 F1、 F2
需求响应
用户取消 订单
消息机制
司机接受/ 取消订单
司机 交互 端
图2.1.1打车软件系统第3层乘客端
软件接口
• • • • • 支付API：用于连接支付系统 地图API：用于调用地图信息 广播API：用于广播新闻、交通管理局信息服务等 广告API：用于接入广告服务 本地服务API：用于显示附近餐饮娱乐、酒店宾馆等本地信息
2.功能性需求分析
2.1系统功能域分析建模
功能类别
乘客.即时叫车 乘客打车下单后，司机可以看到附近的打车信息，完成即时叫车；，乘客可以 选择是否拼车还可以加价打车，打到车之后可以和司机沟通取消订单或者更改 订单。 乘客.预约叫车 乘客通过易打车发布预约打车信息后，可以与司机完成预约叫车的功能； 乘客.申请代驾
打车软件需求分析简述
小组成员：
小组成员任务分配
成员 陈毅 邓礼力 文亚 周丽 王昌平
任务 收集资料并制作PPT 客户及用户需求调研 系统数据域分析建模 系统功能域分析建模 系统状态域分析建模
由于缺乏相关专业知识，所做需求分析均由组 员根据自己的理解以及相关资料进行分析并建模 绘图，有诸多不合理之处，仅作参考，在此感谢 各位组员认真完成任务所付诸的劳动。
抢单成功 根据乘客信息 在规定时间内 第一个接受订单 突发情况，司机 无法完成该单 确认支付 已经有人 接受了该订单 抢单失败 支付成功 继续尝试 放弃订单 突发情况，司机 无法完成该单 联系乘客 乘客定位 司机到达
抢单
继续尝试
图2.3.2 司机端
3.非功能性需求分析
3.1 性能需求
在CPU 1GHz且RAM 512M的安卓2.3系统上运行时，当系统有 60%的空闲资源时： • 启动速度在0.5s以内； • 启动之后各项操作反应速度0.1s以内（快速的反应有利于增加用 户体验度）； • 软件正常运行RAM占用25M以内； • 后台运行占用RAM资源少于6M，CPU少于1%。
3.非功能性需求分析
3.3 软件质量属性
• 兼容性： • • • • • 可运行于各个品牌的智能机和平板上，可在安卓 2.3.0版本及其以上版本运行。 可移植性：后期可以移植到苹果IOS5.0及其以上版本的系统上 易修改性：整个软件采用标准模块构建，易于后期进行修改 可伸缩性：软件除了采用标准模块外，接口也要标准化，要易于 后期拓展以及删减功能模块 易集成性：软件集成度高代码精简，要易于嵌入其它软件如微信 或者支付宝之中，利于后期合作推广发展 可靠性： 精简代码控制软件的bug量，连续运行一周不能出现 程序未响应或闪退情况，重要功能如打车功能一定 要可靠稳定。 使用性： 要易于使用、操作简洁，设置常用功能快捷键或快捷 手势，复杂功能应放入菜单中，用户的操作体验很重 要，后期要进行操作体验测试。
第三方服务
乘客
各类打车/ 取消需求 需求响应
打车软 件
派单
接收/取消 订单
司机
1.综合描述
1.5 运行环境 硬件平台：智能手机等移动客户端 操作系统：安卓系统（用户最广）和IOS系统（打车 比例最大） 共存软件：地图软件、社交软件（如微信），可以嵌 入到用户群体很大的如微信、支付宝、高德地图等软 件中调用打车软件，或者在打车软件中调用地图API 等
2.1系统功能域分析建模
订单登记表 F1、F2 司机、客户管理表 T1、T2
打车/取消 打车需求
需求 分类
打车 需求
生成 订单
申请 代驾
派单机制
派单信息
取消打 车需求
乘客
取消订 单
已接受取消 订单处理
司机接收订 单 司机取消订 单
司机
需求响应 消息
消息机制
用户取消 订单消息
图2.1.1打车软件系统第2层
3.非功能性需求分析
3.2 安全性需求
• • • • • • • • 1)确保用户和客户端程序被标识，并且他们的身份被成功鉴别。 2)确保用户和客户端程序只能获得合适授权的数据和服务。 3)检测未授权用户的登录和客户端程序的入侵。 4)确保通信和数据没有被蓄意破坏。 5)确保与程序或组件交互的当事人无法否认所进行的交互。 6)确保机密的通信和数据保持秘密性。 7)确保程序和中心在攻击下仍然存活，可能以退化的模式运行。 8)确保中心、组件和人员被保护，以避免被破坏、损害、偷窃、 暗中替换。 • 9)确保系统维护时不会破坏程序、组件、中心的安全机制。 • 10)确保未授权的恶意程序没有传染程序或组件。 • 11)使安全人员能够审计安全机制的状态和使用。
功能
乘客
乘客可以发布代驾信息，实现找代驾的功能； 乘客.查看空车
乘客可以看到自己设定距离范围内的出租车信息，方便乘客主动预约出租车司 机； 乘客.查看司机信用及打分评价
查看司机的信息包括信用度，乘坐车完之后可进行打分评价 乘客.支付订单 乘客可以选择网银或者支付宝等三方支付，也可以选择现金支付，还可以让好 友及亲人代付 乘客.设置菜单 乘客可以设置快捷键、默认支付方式、个人资料、好友管理等
2.功能性需求分析
2.1系统功能域分析建模
未接收订单登记表 F1
派单
司机管理信息表T2
派单信息
查看司 机管理 响应机 制
消息机制
查看司机消息
已接收订单登记表 F2
接收/取消订单
司机
乘客交 互端
用户消息订单 司机接收/取 消订单
取消订单消息
图2.1.1打车软件系统第3层司机端
2.功能性需求分析
2.1系统功能域分析建模
1.2 商业需求
业务机遇：乘客打车难的问题凸显，而移动互联网和智能终端的 高速发展为利用打车软件解决该问题提供了机遇。 业务目标：从最初给乘客和司机提供免费、便利的打车服务从而 积累用户，到最后通过软件增值服务、第三方支付平台、本地信 息服务、入口价值等方式实现盈利。 提供给客户的价值：解决了“打车难”及“空载”的问题。 业务风险：
1.综合描述
重庆大学通信工程学院——软件工程
1.6 外部接口需求 用户界面：界面简洁、方便且快速。 1、乘客端
• • • • • • • • • • • • 1）注册登陆模块 2）用户设置模块 3）一键打车模块 4）预约打车及申请代驾模块 5）投诉与评价模块 6）软件更新 1）注册登陆模块 2）用户设置模块 3）订单模块（抢单、预约订单） 4）导航地图 5）广播信息 6）软件更新
30,000.00
80,000.00 5,000.00 4,000.00 1,000.00
4
1 10 15 20
120,000.00
80,000.00 50,000.00 60,000.00 20,000.00
UPS电源
其他附件
提供电源
100,000.00
10,000.00
1
100,000.00
10,000.00
4.总结
3.非功能性需求分析
3.5 开发进度需求
可行性研究 需求分析 概要设计 详细设计 编码 测试 维护
项目经理
产品经理
1周
UI设计师 开发工程师 开发工程师 测试工程师 项目经理
2周 4周 3周 2周 长期
1周
3.6 其它需求 打车软件服务要符合最新的法律法规，各地区以及 各城市有可能有不同规定，所以需根据乘客所在城市地 自动提供不同功能服务，如某些地方不允许加价行为则 该功能在此城市将自动不能使用
1 2 3 4
综合描述 功能性需求分析
非功能性需求分析
总结
1.综合描述
1.1 产品背景
• 随着“后PC时代”的到来，智能手机用户爆炸式的增长普及，移 动互联网领域大有可为
• 城市化的快速发展，使得打车难的问题变的日益突出，给百姓的 出行带来了诸多不便，所以产生了打车软件的客观需求。
1.综合描述
• 政策的风险：除了要实时了解并符合法律法规外，要尽量让政府 能够涉人其中从而减小政府打压的风险。 • 恶性竞争的风险：软件除了要和其它同类打车软件比较相比有特 色之外，还要实时关注主要竞争对手动态。
1.综合描述
1.3 用户类和特征 乘客（按年龄段分类）：
学生群体：接受信息的方式更加多元化，容易接受新事物， 所以学生更易尝试我们的软件，是我们的首批用户，但经济 不宽裕，可以为其设计拼车功能。 工作群体：因工作的原因对打车的需求比较大，是我们的主 要用户，但对打车的速度和效率要求比较高，可以为其设计 加小费打车以及申请代驾等功能。 老人群体：不易学习、接受新兴事物，所以界面设计一定要 简洁易用，为其设计一键叫车以及语音叫车功能。
系统功能描述
2.功能性需求分析
2.1系统功能域分析建模
功能类别 司机 司机.接单 乘客提交打车申请后，在司机端会立即显示乘客的目的地和联系方式，方便司机接单和与乘客进行联系， 在完成订单后车费会打入默认网银或支付宝等第三方账号。 司机.查看订单 乘客提交预约以及代驾信息后，会在司机客户端有提醒，方便司机查看预约以及代驾乘客的信息，也可以 进行筛选 司机.客户管理 司机可以查看和管理经常联系的老顾客电话号码等信息，方便司机的操作。 司机.查看路况 司机可以查看实时路况信息，在地图上显示路况信息的同时可以语音提示重要路况信息，如某地点堵车建 议绕行。 司机.收听广播 收听广播信息以及新闻等 司机.公共电台 建立类似公共电台服务，本地司机之间可以在里面分享信息，如某地方发生劫车事件呼叫附近师傅围追堵 截。 司机.设置菜单 第三方机构 设置常用快捷键、默认第三方收费账号、个人资料、好友管理等。 支付接口 如网银、支付宝、微信等第三方支付公司 地图接口 使用第三方地图显示位置信息、路况信息和本地服务信息等，如高德、百度等。 广告及本地服务接口 推送广告以及本地服务如酒店、KTV、餐饮等信息。 广播 功能
Байду номын сангаас概要设计
详细设计 编码 测试 设备用途
2周
4周 3周 2周 设备单价
10,000.00
20,000.00 10,000.00 10,000.00 设备数量
10,000.00
240,000.00 50,000.00 15,000.00 设备总价
服务器
磁盘阵列 交换机 笔记本电脑 智能终端
软件及数据库
数据存储 网络搭建 编码、测试 项目测试
•
3.非功能性需求分析
3.4 成本资源消耗需求
所需人员(数量） 工作任务
项目经理（1） 产品经理(3) 可行性研究 需求分析
工作时间
1周 1周
单位薪金（元） 总薪金（元）
20,000.00 20,000.00 5,000.00 15,000.00
UI设计师(2)
总设计师(3) 开发工程师（6） 测试工程师（3） 所需设备
系统功能描述
2.功能性需求分析
2.1系统功能域分析建模
未接收订单登记表 F1 客户管理信息表 T1
打车/取 消打车需 求 需求响应信 息
乘客
用户 交互 端
交互信息
司机 交互 端
派单/通知 信息 接收/取消 订单
司机
已接收订单登记表 F2 司机管理信息表 T2
图2.1.1打车软件系统第1层
2.功能性需求分析
抢单判定树
2.功能性需求分析
2.2数据域分析建模（实体-关系图）
2.功能性需求分析
2.3行为域分析建模
改变主意 下单
放弃订单
支付成功 乘客支付
乘客改变主意
司机乘客定位 司机抢单成功 乘客放弃 无司机抢单 重新尝试
下单成功
乘客上车
突发情况，司机无法完 成该单
下单失败
图2.3.1 乘客端
2.3行为域分析建模