打车软件需求分析 ppt课件

打车软件需求分析简述
小组成员：
来自百度文库
小组成员任务分配
成员 陈毅 邓礼力 文亚 周丽 王昌平
任务 收集资料并制作PPT 客户及用户需求调研 系统数据域分析建模 系统功能域分析建模 系统状态域分析建模
由于缺乏相关专业知识，所做需求分析均由组 员根据自己的理解以及相关资料进行分析并建模 绘图，有诸多不合理之处，仅作参考，在此感谢 各位组员认真完成任务所付诸的劳动。
1.综合描述
重庆大学通信工程学院——软件工程
1.6 外部接口需求 ➢ 硬件接口
• 定位：移动网络（2G/3G/4G）快速定位，GPS精确定位 • 语音输入（MIC）：用于输入用户指令信息如目的地等 • 语音输出（听筒）：用于广播消息等语音输出 • 取景器（摄像头）：取景用于定位、上传分享位置等 • 触屏或者键盘：用于用户操作、发出指令、消息输入等
乘客.预约叫车 乘客通过易打车发布预约打车信息后，可以与司机完成预约叫车的功能；
乘客.申请代驾 乘客可以发布代驾信息，实现找代驾的功能； 乘客.查看空车 乘客可以看到自己设定距离范围内的出租车信息，方便乘客主动预约出租车司 机； 乘客.查看司机信用及打分评价 查看司机的信息包括信用度，乘坐车完之后可进行打分评价
乘客.支付订单 乘客可以选择网银或者支付宝等三方支付，也可以选择现金支付，还可以让好 友及亲人代付 乘客.设置菜单 乘客可以设置快捷键、默认支付方式、个人资料、好友管理等
系统功能描述
2.功能性需求分析
2.1系统功能域分析建模
系统功能描述
2.功能性需求分析
2.1系统功能域分析建模
未接收订单登记表 F1 客户管理信息表 T1
➢ 业务机遇：乘客打车难的问题凸显，而移动互联网和智能终端的 高速发展为利用打车软件解决该问题提供了机遇。
➢ 业务目标：从最初给乘客和司机提供免费、便利的打车服务从而 积累用户，到最后通过软件增值服务、第三方支付平台、本地信 息服务、入口价值等方式实现盈利。
➢ 提供给客户的价值：解决了“打车难”及“空载”的问题。 ➢ 业务风险： • 政策的风险：除了要实时了解并符合法律法规外，要尽量让政府
需求 分类
生成 订单
打车 需求
取消打 车需求 取消订
单
申请 代驾
派单机制
派单信息
已接受取消 订单处理
司机接收订 单
司机取消订 单
司机
需求响应 消息
消息机制
用户取消 订单消息
图2.1.1打车软件系统第2层
2.功能性需求分析
2.1系统功能域分析建模
订单登记表 F1、F2 司机、客户管理表 T1、T2
打车/取消 打车需求
工作群体：因工作的原因对打车的需求比较大，是我们的主 要用户，但对打车的速度和效率要求比较高，可以为其设计 加小费打车以及申请代驾等功能。
老人群体：不易学习、接受新兴事物，所以界面设计一定要 简洁易用，为其设计一键叫车以及语音叫车功能。
➢ 司机
正规出租车司机：有营运执照，安全性有保障，但容易空跑 需要提高载客效率、增加营收。
私人车（黑车）司机：不正规无营运执照，不能到某些地点 载客。
1.综合描述
1.4 产品主要功能
➢ 乘客：即时打车服务、预约打车服务和寻求代驾服务 ➢ 司机：接单载客服务、路况信息服务和收听广播服务 ➢ 第三方：广告推送服务、本地信息显示服务（包括餐饮娱乐及酒
店宾馆）、广播服务、支付服务、地图服务、交通管理服务
乘客
需求 分类
生成 订单
打车 需求
取消打车需求
申请 代驾
取消订单
常用信息 查看
订单登记表 F1、 F2
需求响应
消息机制
用户取消 订单
司机接受/ 取消订单
司机 交互 端
乘客
打车/取消 打车需求
需求响应信 息
用户
交互 端
交互信息
司机
交互 端
派单/通知 信息
接收/取消 订单
司机
已接收订单登记表 F2 司机管理信息表 T2
图2.1.1打车软件系统第1层
2.功能性需求分析
2.1系统功能域分析建模
订单登记表 F1、F2 司机、客户管理表 T1、T2
打车/取消 打车需求
乘客
1
综合描述
2
功能性需求分析
3
非功能性需求分析
4
总结
1.综合描述
1.1 产品背景
• 随着“后PC时代”的到来，智能手机用户爆炸式的增长普及，移 动互联网领域大有可为
• 城市化的快速发展，使得打车难的问题变的日益突出，给百姓的 出行带来了诸多不便，所以产生了打车软件的客观需求。
1.综合描述
1.2 商业需求
第三方服务
乘客
各类打车/ 取消需求
需求响应
打车软 件
派单
接收/取消 订单
司机
1.综合描述
1.5 运行环境
➢ 硬件平台：智能手机等移动客户端 ➢ 操作系统：安卓系统（用户最广）和IOS系统（打车
比例最大） ➢ 共存软件：地图软件、社交软件（如微信），可以嵌
入到用户群体很大的如微信、支付宝、高德地图等软 件中调用打车软件，或者在打车软件中调用地图API 等
➢ 软件接口
• 支付API：用于连接支付系统 • 地图API：用于调用地图信息 • 广播API：用于广播新闻、交通管理局信息服务等 • 广告API：用于接入广告服务 • 本地服务API：用于显示附近餐饮娱乐、酒店宾馆等本地信息
2.功能性需求分析
2.1系统功能域分析建模
功能类别
乘客
功能
乘客.即时叫车 乘客打车下单后，司机可以看到附近的打车信息，完成即时叫车；，乘客可以 选择是否拼车还可以加价打车，打到车之后可以和司机沟通取消订单或者更改 订单。
1.综合描述
重庆大学通信工程学院——软件工程
1.6 外部接口需求
➢ 用户界面：界面简洁、方便且快速。 1、乘客端
• 1）注册登陆模块 • 2）用户设置模块 • 3）一键打车模块 • 4）预约打车及申请代驾模块 • 5）投诉与评价模块 • 6）软件更新
2.司机
• 1）注册登陆模块 • 2）用户设置模块 • 3）订单模块（抢单、预约订单） • 4）导航地图 • 5）广播信息 • 6）软件更新
能够涉人其中从而减小政府打压的风险。 • 恶性竞争的风险：软件除了要和其它同类打车软件比较相比有特
色之外，还要实时关注主要竞争对手动态。
1.综合描述
1.3 用户类和特征
➢ 乘客（按年龄段分类）：
学生群体：接受信息的方式更加多元化，容易接受新事物， 所以学生更易尝试我们的软件，是我们的首批用户，但经济 不宽裕，可以为其设计拼车功能。