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