摘要        本文是笔者软件工程与方法课的课程作业，从中国网约车行业的发展历程及市场现状出发，立足于当下市场需求，以期设计一款具有市场竞争力的打车软件。本文首先对打车软件进行需求分析，然后采用SA方法及DFD描述工具进行系统建模，最后给出相应的设计方案。文章中的打车软件系统架构图、系统部署图、功能架构图、数据流图、E-R图均发布在ProcessOn模板社区，欢迎有需要的同学克隆使用！

关键词：打车软件；系统分析；设计方案；SA；DFD

随着移动互联网的发展，各行各业纷纷进行升级转型。在传统出租车行业，由于司机绕路、拒载等行为普遍存在，“打车难”、“打车贵”等问题层出不穷。因此，针对这些痛点，打车软件应运而生。打车软件，又称网约车平台，是指以互联网技术为依托构建的服务平台，通过接入符合条件的车辆和驾驶员，整合供需信息，提供非巡游的预约出租汽车服务[1]。

本文的主要工作是完成打车软件的分析与设计。为设计一款具有市场竞争力的打车软件，有必要了解当前的市场环境，因此本文首先回顾中国网约车行业的发展历程，并对网约车市场现状加以分析。

图 1 中国网约车行业发展历程[2]

根据易观的《2019中国网约车市场分析报告》[2]，中国网约车行业的发展大致分为四个阶段：探索期（2010-2015）、市场启动期（2015-2016）、高速发展期（2017-2024）以及应用成熟期（2025-），如图 1所示。

在探索期，网约车平台逐渐兴起：2010年，易到用车上线；2012年，滴滴打车和快的打车上线；2014年，Uber进入中国，同年，嘀嗒拼车成立；2015年，神州租车推出神州专车业务。

2015-2016两年间，网约车行业进入竞争激烈的市场启动期。在这一阶段，发生了两次重大的合并事件：一是滴滴打车和快的打车宣布合并，市场完成初步洗牌；二是滴滴在合并之后又将Uber中国收入囊中，市场进入寡头化。另一方面，传统车企和租赁公司也开始向网约车市场进军，首汽集团的首汽约车、吉利集团的曹操专车于2015年先后上线。

2016年7月，《网络预约出租汽车经营服务管理暂行办法》颁布，网约车的合法地位得以肯定。此后，网约车行业进入高速发展期。随着美团打车、高德地图以及汽车主机厂的纷纷入局，网约车市场的竞争持续加剧。

目前，中国移动出行市场规模快速增长，移动出行用户将近5亿人，汽车出行市场容量达3800亿元[3]。网约车服务品牌和业务模式大致分为三类：一类是C2C模式的互联网平台，如滴滴出行、嘀嗒出行；一类是B2C模式的车企和租赁公司，车企如上汽投资的享道出行、广汽投资的如祺出行、吉利的曹操出行及三大央企（长安、一汽、东风）投资的T3出行；租赁公司如首汽约车、神州专车等。此外，最近兴起的一类是B2B2C模式的互联网聚合平台，以高德和美团为代表，又被称为“平台之上的平台”，方便用户一键呼叫多个第三方平台的网约车服务。

整体而言，当前的中国网约车市场呈现“一超多强”的竞争格局。滴滴出行占据大部分市场份额，截至2018年12月31日，滴滴出行app安装渗透率达14.71%，是位列第二的神州专车的10倍以上[4]。滴滴的商业模式属于“纯平台”模式，这种模式轻量化运营、用户和数据变现前景可期，但具有较高的进入壁垒。而且由于政府对平台的监管趋严、合规压力大，运力短缺问题短期内将持续困扰“纯平台”企业[5]。在这种前有围堵（滴滴）后有追兵（合规政策）的局势下，若无颠覆性的技术和极端的政治因素出现，“纯平台”模式很难再出现有威胁的新企业。

相较“纯平台”模式，“平台+运力”模式尚有机会进入网约车市场分一杯羹。“平台+运力”的网约车公司背靠具有区域优势的租赁公司、整车厂等，受到当地政府的支持，合规化程度较高，投入相对较少，能够在盈利性和运力保障间寻求平衡。

另外，从长期来看，网约车市场整体需求将持续高涨。一是随着疫情的好转，企业相继复工，出行市场逐渐复苏，网约车市场用户规模将会恢复性增长[6]；二是随着城镇化水平提升，经济持续发展，基础设施持续完善，中国未来城镇居民出行需求将持续增长；三是由于私家车的限购及征收拥堵税，随着移动共享出行的日益成熟，共享出行将受到更多消费者的青睐。

因此，在需求旺盛且有待开垦的二线城市，“平台+运力”模式的网约车企业仍具有一定的发展空间。下文将以这样的企业为业务方，完成打车软件的系统分析与方案设计。

本节将从需求分析、系统模型两方面对打车软件进行系统分析。

需求分析主要可分为业务需求、用户需求、功能性需求、以及非功能性需求四方面。

打车软件的业务需求是：为乘客提供便捷、舒适、安全的出行服务，为司机提供公平、透明、可靠的接单途径，从而提高乘客用户与司机用户的留存率，通过合作提点、推介佣金、广告植入、广告推送、积分换购[7]等方式，实现盈利创收的目的。

打车软件的主要服务对象是乘客、司机两种角色，不同的角色对系统的需求是不同的。下面分别对这两种角色的用户需求加以分析。

2.1.2.1 乘客用户需求

打车难、安全焦虑[8]、体验差等问题仍是网约车及出租车服务面临的主要问题。虽然相比于传统的扬招打车，网约车在一定程度上解决了一些问题，但对于问题的最终解决仍有很长的路要走。不久前J.D. Power发布的中国网约车服务质量研究[3]显示，网约车行业整体PP100（每百用户抱怨数）偏高，行业平均PP100高达575，即每个用户平均抱怨5.75个问题。用户抱怨主要集中在平台效率方面，叫车过程中的PP100高达166。根据统计数据，“守时”和“高效”对于网约车平台用户留存至关重要：如果接单响应时间超过5分钟，41%的乘客用户会选择取消订单或更换平台叫车；若接单司机与乘客的距离超过10分钟路程，50%的乘客用户会选择取消该订单。此外，地图相关问题也用户抱怨较多。

上述研究通过对不同品牌和区域网约车用户进行访谈和调研，重点考察了乘客用户在打车过程的6大环节（叫车过程、上车过程、乘坐体验、下车过程、支付和管理以及安全体验）遇到的问题，能够较为全面地反映乘客用户需求。基于此，现将打车软件的乘客用户需求总结如表 1：

表 1 打车软件的乘客用户需求

序号

用户故事

需求描述

优先级

1

公司或住所位置偏僻，不好打车。

系统将用户的打车信息推送给一定数量的司机，增加用户成功打到车的机会；提供预约打车功能，使司机提前明确接送任务，保证乘客能打上车。

P0

2

雨雪天气或早晚高峰，担心出门拦不到车，耽误行程。

系统提供加价功能，激励司机接单，增大司机与乘客相互选择的空间；确实受天气或交通等客观因素限制时，系统提供其他出行方式的建议和参考。

P0

3

线下打车不划算。

系统提供顺风车、拼车功能，设立优惠券、鼓励金、积分减免等活动。

P1

4

出租车车型舒适度不够。

系统提供专车打车功能。

P2

5

携带宠物出行。

系统提供携宠打车功能。

P2

6

携带较多货物出行。

系统提供同城送货、城际送货功能。

P2

7

老弱病残孕人士出行有特殊需求。

系统提供爱心打车、无障碍打车功能。

P2

8

加班到深夜，去偏远地区，担心打车不安全。

系统提供证照信息公示、一键报警功能，保障乘车安全，增加乘客安全感。

P0

9

去外地出差或旅游，不熟悉路线，担心司机绕远，费用高。

系统提供高精度的地图导航，提供即时计费、评价反馈功能，建立诚信机制。

P0

10

平台派单时间过长，预计接单时间不准，实际等待时间比预计接单时间长很多，甚至没有司机接单。

系统提供更完善的时间预测算法和司机派单算法；在叫不到车等待时，向乘客显示等待时间、等待人次、排位顺序信息；若超出平台规定最长派单时间，提供合理的减免优惠。

P0

11

看到附近有空车打不到，接单司机距离太远，接单接驾时间长。

系统提供更完善的司机派单算法，降低“近单远接”的概率；做到车辆状态信息透明化，明确地向乘客展示车辆处于空驶或是已接单状态。

P0

12

联系接单司机浪费时间：司机接单后不主动联系，只有车辆到达地点后找不到人才联系，甚至找不到人也不联系，要不在地点等候，要不在周围绕圈（不方便停车的地方）。

系统提供通知功能，在司机接单后自动向用户发送消息告知接单司机及车辆相关信息。

P0

13

车辆到达上车点和实际位置有出入，到达上车点时间不准，导航路线不合理，预计到达目的地时间不准，到达目的地位置不准。

与高质量的地图服务第三方合作，提供更精准的地图服务。

P0

14

对司机服务或车辆不满意。

系统提供评价反馈功能。

P0

15

个人物品落在车内。

通过系统的对话功能联系行程司机。

P0

2.1.2.2 司机用户需求

打车软件的司机用户需求与乘客用户需求之间存在关联，现将司机用户需求总结如表 2：

表 2 打车软件的司机用户需求

序号

用户故事

需求描述

优先级

1

不愿意去偏远地区接单：路程远，时间长，而且途中接不到其他单。

系统提供加价功能，激励司机接单；提供预约打车功能，使司机提前明确接送任务。

P0

2

深夜接单前往偏远地区，担心不安全。

系统提供一键报警功能，保障司机安全。

P0

3

看见附近有乘客想打车，但接不到单；系统分配的乘客距离太远，接单中途被取消订单。

系统提供更完善的派单算法，降低“近单远接”的概率。

P0

4

特殊原因暂时不方便接单（如手机即将没电）。

系统提供拒单功能，并向乘客发送拒单原因，便于司乘之间的双向选择。

P0

5

接单到地点找不到乘客。

系统提供对话功能，方便联系乘客。

P0

6

对乘客行为或平台不满意。

系统提供评价反馈功能。

P0

基于上述用户需求，本节将打车软件的功能性需求分配至乘客端与司机端。

2.1.3.1 乘客端功能性需求

乘客端主要包括如下功能性需求：

（1）注册登录：乘客使用打车软件进行打车时需要处于登录状态，新用户需要进行注册，可以选择使用手机号码与验证码进行注册，或者使用微信、QQ等第三方账号授权登录。

（2）多样化打车模式：乘客可以选择即时打车或预约打车，其中即时打车的打车模式有快车、专车、顺风车和拼车；预约打车的打车模式有快车、专车、拼车和个性化打车。多样化的打车模式满足更广大用户群体的需求。

（3）开销预算：乘客提交打车请求后，系统会根据乘客的出发地和目的地，估算出需要花费的时间及费用，方便司机与乘客。

（4）空车搜索：乘客可以查看附近车辆状态（空驶/已接单），方便乘客自选车辆打车。

（5）订单管理：乘客可以查看历史订单。在司机接单后，乘客可以查看当前订单详情，了解接单司机的相关信息，包括司机的电话号码，车牌号码、车辆型号、司机评价、司机实时位置等。在行程开始前，乘客可以取消订单。

（6）消息管理：乘客可以接收系统通知及司机消息，可以向司机发送消息进行联系，并且可以查看历史对话记录。

（7）即时计费：在乘客上车后计费开始，乘客可以实时查看当前行车路线导航、里程、时间及费用。

（8）一键报警：如若遇到危险，乘客可以通过一键报警向第三方安全中心求救。

（9）支付：到达目的地后，乘客可以选择支付宝、微信等第三方支付方式进行支付，同时可以选择使用优惠券、会员积分等获得减免。

（10）评价：支付完成后，乘客可以对司机的服务进行评价。

上述需求总结如图 2：

图 2 乘客端功能性需求

2.1.3.2 司机端功能性需求

司机端主要包括如下功能性需求：

（1）注册登录：司机在使用打车软件时需要处于登录状态，新用户需要注册，向系统提交手机号、驾驶证号、本人与车辆合照等信息，审核通过后才能进行接单。

（2）订单管理：司机在收到系统推送的订单时，可以选择接单或拒单。司机选择接单后可以查看当前订单详情，确定乘客的上车地点。另外，司机可以查看历史订单信息，方便对工作量的评估。

（3）乘客搜索：司机可以查看附近请求打车的乘客状态（未上车/已上车），方便司机自找乘客。

（4）行车导航：司机可以根据行车导航出发去接乘客，并且可以通过导航确定从乘客出发地到目的地的合适路线。

（5）消息管理：司机可以接收系统通知，与乘客对话沟通，并可以查看历史对话记录。

（6）一键报警：如若遇到危险，司机可以通过一键报警向第三方安全中心求救。

（7）评价：订单结束后，司机可以对乘客进行评价。

（8）收入查询：司机可以查看载客所收到的报酬，通过绑定银行卡提现。

上述需求总结如图 3：

图 3 司机端功能性需求

如表 3所示，打车软件不仅要实现用户的基本需求，而且在性能、安全性、软件质量属性等方面有一定的限制要求。

表 3 打车软件的非功能性需求

类型

需求描述

性能需求

业务量：系统满足多用户同时工作，保障同时在线用户数500W人，并发操作100W人的使用要求。

响应时间：在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒。

精度：地图定位精度误差不超过80米。

系统容量：满足未来5年业务数据扩展要求。

资源使用率：CPU占用率