打车软件需求分析课件

打车软件需求分析简述小组成员：打车软件需求分析简述小组成员：1小组成员任务分配

由于缺乏相关专业知识，所做需求分析均由组员根据自己的理解以及相关资料进行分析并建模绘图，有诸多不合理之处，仅作参考，在此感谢各位组员认真完成任务所付诸的劳动。小组成员任务分配由于缺乏相关专业知识，所做需求分2总结4综合描述1功能性需求分析2非功能性需求分析3总结4综合描述1功能性需求分析2非功能性需求分析331.综合描述1.1产品背景随着“后PC时代”的到来，智能手机用户爆炸式的增长普及，移动互联网领域大有可为城市化的快速发展，使得打车难的问题变的日益突出，给百姓的出行带来了诸多不便，所以产生了打车软件的客观需求。

1.综合描述1.1产品背景41.综合描述1.2商业需求业务机遇：乘客打车难的问题凸显，而移动互联网和智能终端的高速发展为利用打车软件解决该问题提供了机遇。业务目标：从最初给乘客和司机提供免费、便利的打车服务从而积累用户，到最后通过软件增值服务、第三方支付平台、本地信息服务、入口价值等方式实现盈利。提供给客户的价值：解决了“打车难”及“空载”的问题。业务风险：政策的风险：除了要实时了解并符合法律法规外，要尽量让政府能够涉人其中从而减小政府打压的风险。恶性竞争的风险：软件除了要和其它同类打车软件比较相比有特色之外，还要实时关注主要竞争对手动态。

1.综合描述1.2商业需求51.综合描述1.3用户类和特征乘客（按年龄段分类）：学生群体：接受信息的方式更加多元化，容易接受新事物，所以学生更易尝试我们的软件，是我们的首批用户，但经济不宽裕，可以为其设计拼车功能。工作群体：因工作的原因对打车的需求比较大，是我们的主要用户，但对打车的速度和效率要求比较高，可以为其设计加小费打车以及申请代驾等功能。老人群体：不易学习、接受新兴事物，所以界面设计一定要简洁易用，为其设计一键叫车以及语音叫车功能。司机正规出租车司机：有营运执照，安全性有保障，但容易空跑需要提高载客效率、增加营收。私人车（黑车）司机：不正规无营运执照，不能到某些地点载客。

1.综合描述1.3用户类和特征61.综合描述1.4产品主要功能乘客：即时打车服务、预约打车服务和寻求代驾服务司机：接单载客服务、路况信息服务和收听广播服务第三方：广告推送服务、本地信息显示服务（包括餐饮娱乐及酒店宾馆）、广播服务、支付服务、地图服务、交通管理服务

各类打车/取消需求需求响应派单接收/取消订单乘客司机打车软件第三方服务1.综合描述1.4产品主要功能各类打车/取消需求需求响应派71.综合描述1.5运行环境硬件平台：智能手机等移动客户端操作系统：安卓系统（用户最广）和IOS系统（打车比例最大）共存软件：地图软件、社交软件（如微信），可以嵌入到用户群体很大的如微信、支付宝、高德地图等软件中调用打车软件，或者在打车软件中调用地图API等

1.综合描述1.5运行环境81.综合描述1.6外部接口需求用户界面：界面简洁、方便且快速。1、乘客端1）注册登陆模块2）用户设置模块

3）一键打车模块4）预约打车及申请代驾模块5）投诉与评价模块6）软件更新2.司机

1）注册登陆模块2）用户设置模块3）订单模块（抢单、预约订单）4）导航地图5）广播信息6）软件更新

重庆大学通信工程学院——软件工程1.综合描述1.6外部接口需求重庆大学通信工程学院——软件91.综合描述1.6外部接口需求硬件接口定位：移动网络（2G/3G/4G）快速定位，GPS精确定位语音输入（MIC）：用于输入用户指令信息如目的地等语音输出（听筒）：用于广播消息等语音输出取景器（摄像头）：取景用于定位、上传分享位置等触屏或者键盘：用于用户操作、发出指令、消息输入等软件接口支付API：用于连接支付系统地图API：用于调用地图信息广播API：用于广播新闻、交通管理局信息服务等广告API：用于接入广告服务本地服务API：用于显示附近餐饮娱乐、酒店宾馆等本地信息

重庆大学通信工程学院——软件工程1.综合描述1.6外部接口需求重庆大学通信工程学院——软件102.功能性需求分析2.1系统功能域分析建模

系统功能描述2.功能性需求分析2.1系统功能域分析建模 系统功能描112.功能性需求分析2.1系统功能域分析建模

系统功能描述2.功能性需求分析2.1系统功能域分析建模 系统功能描122.功能性需求分析2.1系统功能域分析建模

打车/取消打车需求需求响应信息派单/通知信息接收/取消订单交互信息未接收订单登记表F1客户管理信息表T1已接收订单登记表F2司机管理信息表T2乘客司机用户交互端司机交互端图2.1.1打车软件系统第1层2.功能性需求分析2.1系统功能域分析建模 打车/取消132.功能性需求分析2.1系统功能域分析建模

图2.1.1打车软件系统第2层打车/取消打车需求需求响应消息取消订单派单信息司机接收订单用户取消订单消息打车需求取消打车需求司机取消订单订单登记表F1、F2司机、客户管理表T1、T2乘客司机需求分类生成订单消息机制派单机制已接受取消订单处理申请代驾2.功能性需求分析2.1系统功能域分析建模图2.1.1打车软142.功能性需求分析2.1系统功能域分析建模

图2.1.1打车软件系统第3层乘客端打车/取消打车需求需求响应打车需求取消打车需求订单登记表F1、F2司机、客户管理表T1、T2乘客需求分类生成订单消息机制申请代驾取消订单常用信息查看用户取消订单司机接受/取消订单订单登记表F1、F2司机交互端2.功能性需求分析2.1系统功能域分析建模 图2.1.152.功能性需求分析2.1系统功能域分析建模

图2.1.1打车软件系统第3层司机端派单信息接收/取消订单取消订单消息未接收订单登记表F1司机消息机制派单响应机制查看司机消息查看司机管理司机管理信息表T2已接收订单登记表F2乘客交互端用户消息订单司机接收/取消订单2.功能性需求分析2.1系统功能域分析建模 图2.1.1162.功能性需求分析2.1系统功能域分析建模

抢单判定树2.功能性需求分析2.1系统功能域分析建模抢单判定树172.功能性需求分析2.2数据域分析建模（实体-关系图）

2.功能性需求分析2.2数据域分析建模（实体-关系图）182.功能性需求分析2.3行为域分析建模

下单改变主意下单成功放弃订单乘客改变主意司机抢单成功突发情况，司机无法完成该单下单失败乘客放弃无司机抢单重新尝试司机乘客定位乘客上车乘客支付支付成功图2.3.1乘客端2.功能性需求分析2.3行为域分析建模 下单改变主意下192.3行为域分析建模

图2.3.2司机端在规定时间内第一个接受订单根据乘客信息突发情况，司机无法完成该单突发情况，司机无法完成该单已经有人接受了该订单继续尝试继续尝试抢单抢单成功联系乘客抢单失败放弃订单乘客定位司机到达确认支付支付成功2.3行为域分析建模 图2.3.2司机端在规定时203.非功能性需求分析3.1性能需求

在CPU1GHz且RAM512M的安卓2.3系统上运行时，当系统有60%的空闲资源时：启动速度在0.5s以内；启动之后各项操作反应速度0.1s以内（快速的反应有利于增加用户体验度）；软件正常运行RAM占用25M以内；后台运行占用RAM资源少于6M，CPU少于1%。

3.非功能性需求分析3.1性能需求213.非功能性需求分析3.2安全性需求1)确保用户和客户端程序被标识，并且他们的身份被成功鉴别。2)确保用户和客户端程序只能获得合适授权的数据和服务。3)检测未授权用户的登录和客户端程序的入侵。4)确保通信和数据没有被蓄意破坏。5)确保与程序或组件交互的当事人无法否认所进行的交互。6)确保机密的通信和数据保持秘密性。7)确保程序和中心在攻击下仍然存活，可能以退化的模式运行。8)确保中心、组件和人员被保护，以避免被破坏、损害、偷窃、暗中替换。9)确保系统维护时不会破坏程序、组件、中心的安全机制。10)确保未授权的恶意程序没有传染程序或组件。11)使安全人员能够审计安全机制的状态和使用。

3.非功能性需求分析3.2安全性需求223.非功能性需求分析3.3软件质量属性

兼容性：

可运行于各个品牌的智能机和平板上，可在安卓 2.3.0版本及其以上版本运行。可移植性：后期可以移植到苹果IOS5.0及其以上版本的系统上易修改性：整个软件采用标准模块构建，易于后期进行修改可伸缩性：软件除了采用标准模块外，接口也要标准化，要易于

后期拓展以及删减功能模块易集成性：软件集成度高代码精简，要易于嵌入其它软件如微信

或者支付宝之中，利于后期合作推广发展可靠性：

精简代码控制软件的bug量，连续运行一周不能出现

程序未响应或闪退情况，重要功能如打车功能一定

要可靠稳定。使用性：

要易于使用、操作简洁，设置常用功能快捷键或快捷

手势，复杂功能应放入菜单中，用户的操作体验很重

要，后期要进行操作体验测试。

3.非功能性需求分析3.3软件质量属性233.非功能性需求分析3.4成本资源消耗需求

3.非功能性需求分析3.4成本资源消耗需求243.非功能性需求分析3.5开发进度需求3.6其它需求

打车软件服务要符合最新的法律法规，各地区以及各城市有可能有不同规定，所以需根据乘客所在城市地自动提供不同功能服务，如某些地方不允许加价行为则该功能在此城市将自动不能使用

可行性研究详细设计编码维护概要设计测试需求分析项目经理产品经理UI设计师开发工程师开发工程师项目经理测试工程师3.非功能性需求分析3.5开发进度需求可行性研究详细设计编254.总结

根据打车软件的需求调研，我们从商业需求及用户需求角度进行需求分析，并从软件的功能性需求和非功能性需求进行了分析、建模及说明，以满足客户的商业需求以及用户的功能需求。该软件能够解决乘客“打车难”及司机“空载”的问题，同时也能很好的满足客户的商业需求（盈利及移动互联入口争夺），但该软件也存在一定的风险需要规避。

4.总结26打车软件需求分析简述小组成员：打车软件需求分析简述小组成员：27小组成员任务分配

由于缺乏相关专业知识，所做需求分析均由组员根据自己的理解以及相关资料进行分析并建模绘图，有诸多不合理之处，仅作参考，在此感谢各位组员认真完成任务所付诸的劳动。小组成员任务分配由于缺乏相关专业知识，所做需求分28总结4综合描述1功能性需求分析2非功能性需求分析3总结4综合描述1功能性需求分析2非功能性需求分析3291.综合描述1.1产品背景随着“后PC时代”的到来，智能手机用户爆炸式的增长普及，移动互联网领域大有可为城市化的快速发展，使得打车难的问题变的日益突出，给百姓的出行带来了诸多不便，所以产生了打车软件的客观需求。

1.综合描述1.1产品背景301.综合描述1.2商业需求业务机遇：乘客打车难的问题凸显，而移动互联网和智能终端的高速发展为利用打车软件解决该问题提供了机遇。业务目标：从最初给乘客和司机提供免费、便利的打车服务从而积累用户，到最后通过软件增值服务、第三方支付平台、本地信息服务、入口价值等方式实现盈利。提供给客户的价值：解决了“打车难”及“空载”的问题。业务风险：政策的风险：除了要实时了解并符合法律法规外，要尽量让政府能够涉人其中从而减小政府打压的风险。恶性竞争的风险：软件除了要和其它同类打车软件比较相比有特色之外，还要实时关注主要竞争对手动态。

1.综合描述1.2商业需求311.综合描述1.3用户类和特征乘客（按年龄段分类）：学生群体：接受信息的方式更加多元化，容易接受新事物，所以学生更易尝试我们的软件，是我们的首批用户，但经济不宽裕，可以为其设计拼车功能。工作群体：因工作的原因对打车的需求比较大，是我们的主要用户，但对打车的速度和效率要求比较高，可以为其设计加小费打车以及申请代驾等功能。老人群体：不易学习、接受新兴事物，所以界面设计一定要简洁易用，为其设计一键叫车以及语音叫车功能。司机正规出租车司机：有营运执照，安全性有保障，但容易空跑需要提高载客效率、增加营收。私人车（黑车）司机：不正规无营运执照，不能到某些地点载客。

1.综合描述1.3用户类和特征321.综合描述1.4产品主要功能乘客：即时打车服务、预约打车服务和寻求代驾服务司机：接单载客服务、路况信息服务和收听广播服务第三方：广告推送服务、本地信息显示服务（包括餐饮娱乐及酒店宾馆）、广播服务、支付服务、地图服务、交通管理服务

各类打车/取消需求需求响应派单接收/取消订单乘客司机打车软件第三方服务1.综合描述1.4产品主要功能各类打车/取消需求需求响应派331.综合描述1.5运行环境硬件平台：智能手机等移动客户端操作系统：安卓系统（用户最广）和IOS系统（打车比例最大）共存软件：地图软件、社交软件（如微信），可以嵌入到用户群体很大的如微信、支付宝、高德地图等软件中调用打车软件，或者在打车软件中调用地图API等

1.综合描述1.5运行环境341.综合描述1.6外部接口需求用户界面：界面简洁、方便且快速。1、乘客端1）注册登陆模块2）用户设置模块

3）一键打车模块4）预约打车及申请代驾模块5）投诉与评价模块6）软件更新2.司机

1）注册登陆模块2）用户设置模块3）订单模块（抢单、预约订单）4）导航地图5）广播信息6）软件更新

重庆大学通信工程学院——软件工程1.综合描述1.6外部接口需求重庆大学通信工程学院——软件351.综合描述1.6外部接口需求硬件接口定位：移动网络（2G/3G/4G）快速定位，GPS精确定位语音输入（MIC）：用于输入用户指令信息如目的地等语音输出（听筒）：用于广播消息等语音输出取景器（摄像头）：取景用于定位、上传分享位置等触屏或者键盘：用于用户操作、发出指令、消息输入等软件接口支付API：用于连接支付系统地图API：用于调用地图信息广播API：用于广播新闻、交通管理局信息服务等广告API：用于接入广告服务本地服务API：用于显示附近餐饮娱乐、酒店宾馆等本地信息

重庆大学通信工程学院——软件工程1.综合描述1.6外部接口需求重庆大学通信工程学院——软件362.功能性需求分析2.1系统功能域分析建模

系统功能描述2.功能性需求分析2.1系统功能域分析建模 系统功能描372.功能性需求分析2.1系统功能域分析建模

系统功能描述2.功能性需求分析2.1系统功能域分析建模 系统功能描382.功能性需求分析2.1系统功能域分析建模

打车/取消打车需求需求响应信息派单/通知信息接收/取消订单交互信息未接收订单登记表F1客户管理信息表T1已接收订单登记表F2司机管理信息表T2乘客司机用户交互端司机交互端图2.1.1打车软件系统第1层2.功能性需求分析2.1系统功能域分析建模 打车/取消392.功能性需求分析2.1系统功能域分析建模

图2.1.1打车软件系统第2层打车/取消打车需求需求响应消息取消订单派单信息司机接收订单用户取消订单消息打车需求取消打车需求司机取消订单订单登记表F1、F2司机、客户管理表T1、T2乘客司机需求分类生成订单消息机制派单机制已接受取消订单处理申请代驾2.功能性需求分析2.1系统功能域分析建模图2.1.1打车软402.功能性需求分析2.1系统功能域分析建模

图2.1.1打车软件系统第3层乘客端打车/取消打车需求需求响应打车需求取消打车需求订单登记表F1、F2司机、客户管理表T1、T2乘客需求分类生成订单消息机制申请代驾取消订单常用信息查看用户取消订单司机接受/取消订单订单登记表F1、F2司机交互端2.功能性需求分析2.1系统功能域分析建模 图2.1.412.功能性需求分析2.1系统功能域分析建模

图2.1.1打车软件系统第3层司机端派单信息接收/取消订单取消订单消息未接收订单登记表F1司机消息机制派单响应机制查看司机消息查看司机管理司机管理信息表T2已接收订单登记表F2乘客交互端用户消息订单司机接收/取消订单2.功能性需求分析2.1系统功能域分析建模 图2.1.1422.功能性需求分析2.1系统功能域分析建模

抢单判定树2.功能性需求分析2.1系统功能域分析建模抢单判定树432.功能性需求分析2.2数据域分析建模（实体-关系图）

2.功能性需求分析2.2数据域分析建模（实体-关系图）442.功能性需求分析2.3行为域分析建模

下单改变主意下单成功放弃订单乘客改变主意司机抢单成功突发情况，司机无法完成该单下单失败乘客放弃无司机抢单重新尝试司机乘客定位乘客上车乘客支付支付成功图2.3.1乘客端2.功能性需求分析2.3行为域分析建模 下单改变主意下452.3行为域分析建模

图2.3.2司机端在规定时间内第一个接受订单根据乘客信息突发情况，司机无法完成该单突发情况，司机无法完成该单已经有人接受了该订单继续尝试继续尝试抢单抢单成功联系乘客抢单失败放弃订单乘客定位司机到达确认支付支付成功2.3行为域分析建模 图2.3.2司机端在规定时463.非功能性需求分析3.1性能需求

在CPU1GHz且RAM512M的安卓2.3系统上运行时，当系统有60%的空闲资源时：启动速度在0.5s以内；启动之后各项操作反应速度0.1s以内（快速的反应有利于增加用户体验度）；软件正常运行RAM占用25M以内；后台运行占用RAM资源少于6M，CPU少于1%。

3.非功能性需求分析3.1性能需求473.非功能性需求分析3.2安全性需求1)确保用户和客户端程序被标识，并且他们的身份被成功鉴别。2)确保用户和客户端程序只能获得合适授权的数据和服务。3)检测未授权用户的登录和客户端程序的入侵。4)确保通信和数据没有被蓄意破坏。5)确保与程序或组件交互的当事人无法否认所进行的交互。6)确保机密的通信和数据保持秘密性。7)确保程序和中心在攻击下仍然存活，可能以退化的模式运行。8)确保中心、组件和人员被保护，以避免被破坏、损害、偷窃、暗中替换。9)确保系统维护时不会破坏程序、组件、中心的安全机制。10)确保未授权的恶意程序没有传染程序或组件。11)使安全人员能够审计安全机制的状态和使用。

3.非功