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