景区售票系统需求规格说明书95页_第1页
景区售票系统需求规格说明书95页_第2页
景区售票系统需求规格说明书95页_第3页
景区售票系统需求规格说明书95页_第4页
景区售票系统需求规格说明书95页_第5页
已阅读5页,还剩90页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、景区售票软件系统需求规格说明书Version 1.0目 录1.简介41.1编写目的41.2范围41.3参考资料41.4术语与缩写41.5阅读建议42.综合描述52.1系统的状况52.2产品功能52.3用户类和特征52.4假设和依赖62.5运行环境62.6不确定的问题63.功能需求73.1 XX功能73.N XX功能73.N+1 不支持的功能74.外部接口需求84.1用户界面84.2软件接口84.3硬件接口95.其它非功能需求105.1性能需求105.2质量属性105.3安全需求与措施105.4其它需求106.分析模型126.1用例模型126.2静态模型156.3动态模型171.简介1.1编写目

2、的.1.1 编写目的该需求规格说明书是为“伤得起”小组计划开发的“景区售票系统”所制定。“景区售票系统”, 缓解旅游景区的售检票的人力压力,提供高效的,快节的,稳定的操作。实现系统应具有实用性、可靠性、有效性及方便性。1.1.2 软件版本号软件版本号由四部分组成,第一个1为主版本号,第二个1为子版本号,第三个1为阶段版本号,第四部分为日期版本号加希腊字母版本号,希腊字母版本号共有5种,分别为:base、alpha、beta、RC、release。例如:1.1.1.051021_ alpha。1.1.3软件版本号修改规则主版本号(1):当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化

3、。此版本号由项目决定是否修改。子版本号(1):当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。 阶段版本号(1):一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。 日期版本号(110501):用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。希腊字母版本号(alpha):此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。1.2范围1.2.

4、1软件开发目的缓解旅游景区的售检票的人力压力,提供高效的,快节的,稳定的操作。实现系统应具有实用性、可靠性、有效性及方便性1.2.2 软件开发的背景随着我国城市旅游业的快速发展,人们生活水平的提高,对旅游行业形象管理方面要求不断提高。传统的人工模式已显得陈旧和落后,旅游景区的售检票系统已经不再是以前那种人工的,复杂的,工作量大的售票检票系统,而是一种电子化的新型系统。建立旅游景区售检票系统,不仅使景区的管理水平有了提高,同时也相应地完善了旅游景区的管理制度。这种系统极大的方便的管理员的管理和查询等操作。为管理者提供决策支持数据,以便及时地发现问题,合理安排日常业务工作,制定新的资金投入和计划。

5、这种电子化工作模式避免了人工操作造成的失误,提高了工作效率和质量,从而也提高了经济效益。1.3参考资料1 GB 8566 计算机软件开发规范 2 GB 8567 计算机软件产品开发文件编制指南 3 GB/T 11457 软件工程术语 4 软件工程:实践者的研究方法(第6版).作者:(美)Roger S.Pressman.2007年1月.5软件工程实用教程(计算机应用技术规划教材). 作者:吕云翔. 2011年1月.6软件工程方法与实践.作者:窦万峰.2009年5月.1.4术语与缩写本文档所涉及的全部术语和缩写词及其含义导航终端机查询系统未购票者排队等候购票或正在查询票务信息的人们已购票者已经付

6、款并获得门票管理员系统某一部分的管理人员超级BOSS系统的总管理人员Goshop网络票务销售平台1.5阅读建议本说明书适用对象: (1)软件客户,以便精确地描述他们想获得什么样的产品。 (2)软件开发者,以便准确地理解客户需要什么样的产品。 (3)项目经理,以便能够全面的掌握软件的功能与企业实际的差距,追踪软件开发的过程。(4)测试人员,以便更详细的了解软件的需求,设计良好的测试程序。(5)文档编写者,以便更加明晰软件的开发进程和文档的维护记录。2.综合描述2.1系统的状况1查询:查询当前门票种类、余量、价格、有效日期2购买门票:为游客和旅行社提供购买门票功能3统计:统计当日和历史售票记录,包

7、括售出各类门票总数量,售出未入园票数量,入园人数量,当日入园未出园人数,各类门票收入。4票务管理:修改门票种类,价格,日期,数量5实时信息提供:将今日截止至当前时间的售票量、入园人数、将要入园人数提供给接待处6检票:分为入园检票和出园检票两种状态:游客入园时将售出门票的状态转为入园状态。游客出园时将入园状态转为离开状态。7问题咨询:游客通过问题咨询功能向服务人员咨询8投诉:游客通过投诉功能向服务人员反映投诉情况9系统维护:面向系统管理人员,提供数据备份和数据恢复功能。各种用户所用到的功能情况:旅行社查询、购买团体票、问题咨询、投诉系统管理人员数据转移备份、数据恢复(备份数据拷入)财务部获取统计

8、信息(财务方面)决策部获取统计信息(总体)服务人员提供问题咨询接待处检票、获取实时信息票务管理获取统计信息、管理票务个体游客查询、购买门票、问题咨询、投诉 景区售票系统2.3用户类和特征【确定有可能使用该软件产品的不同用户类,并且描述它们相关的特征。往往有一些软件需求,只与特定的用户类有关。描述时,应该将该软件产品的重要用户类与非重要用户类区分开。用户不一定是软件产品的直接使用者,通过报表、应用程序接口、系统硬件接口得到软件产品的数据和服务的人、或者机构也有他们的需求。所以,应该将这些外部需求视为通过报表、应用程序接口、系统硬件接口附加给软件产品的附加用户类。】1)游客: 前来到该景点旅游的人

9、,年龄范围不限。在售票处自己选择合适的门票购买,然后拿着门票到接待处检票。交互方式:园外售票终端,通过触摸屏操作可进行的操作:a查询当前票的种类,余票量,价格,可用时间b选择并购买个体门票c问题咨询d投诉2)旅行社:通过网络接口订购团体票交互方式:通过网络接口访问本系统可进行的操作:a 查询当前票的种类,余票量,价格,可用时间b 选择并购买团体票c 问题咨询d 投诉3)接待处:接待游客,检查门票,出园时统计游客人数。负责接待游客,根据当前的票务信息,做好接待准备。如当日儿童票较多,要多准备女员工接待;当日老年票较多,要多配医护人员;当日有雨,要做好防雨准备等等。当闭园时依旧有游人未出园时,要找

10、到游客并送出大门。交互方式:通过检票射频仪器进行检票,通过液晶显示屏获取实时票务信息可进行的操作:a 检票b 获取实时票务信息4)票务管理部:对门票的种类进行设计和修改,如是个体票还是团体票,门票有效时间,价格,数量等交互方式:后台,通过直接连到系统的计算机访问,用管理员账户登陆可进行的操作:a查询当前票的种类,余票量b修改票类信息,如种类,价格,可用时间,数量5)决策部:对当前销量进行统计并分析,安排以后的门票种类价格票量与可用时间的安排。交互方式:后台,通过直接连接到系统的计算机访问,也可以通过打印的报表间接得到统计信息。可进行的操作:获取总体统计信息6)财务部:统计收入和财务分配交互方式

11、:后台,通过财务员账户直接连接到系统的计算机访问得到数据可进行的操作:获取统计信息(财务方面)7)服务人员:提供问题解答和投诉受理服务交互方式:后台,通过直接连接到系统的计算机,在系统提供的留言平台上与客户交流可进行的操作:a 解决问题咨询b 获取投诉8)系统管理人员:对售票系统进行维护交互方式:后台,直接连接到系统的计算机,用维护员账户访问可进行的操作:a 数据转移备份b 数据恢复(备份数据考入)2.4假设和依赖假设:可能会使用商业UI软件进行界面设计 客户的用户界面将符合适合于触屏的界面设定 假定用户识字,能独立完成查询买票、投诉、咨询服务 员工有一定的计算机基础知识,能够独立完成软件的学

12、习与使用软件运行在符合最低配置以上的计算机中约束:工期约束:一个月以内完成人员约束:有经验的开发者设备约束:开发机器至少能流畅的运行VS2008地理位置约束:哈工大校园内2.5运行环境1.硬件环境最低硬件配置:CPU:主频2GHz以上,双核CPU显示器:游客使用的显示器为电容触屏,其他部门使用普通液晶15寸显示器存储设备:2T以上的硬盘两个,一个作为主硬盘,一个作为冗余容错。内存:2G网络:10M网线连接推荐配置:CPU:主频2.4GHz以上,双核CPU显示器:游客使用电容触屏显示器,其他部门使用普通液晶17寸显示器存储设备:4T以上硬盘两个,一个作为主硬盘,一个作为冗余容错内存:4G网络:1

13、0M光纤连接2.软件环境:操作系统:windows vista及以上操作系统数据库系统:Mysql浏览器:IE6及以上版本3.其它与该软件有关的软件组件vcredist2005.exe2.6不确定的问题1应用服务器的选用2中间件的选用3网络软件的选用4所使用的液晶屏的品牌3.功能需求3.1 查询功能功能描述:显示当前景区的余票信息;优先级:弱于检票,处于第三级前置条件:游客到达系统售票终端;旅行社通过网络接口进行查询;后置条件:系统显示相关余票信息;主干过程:1.游客在系统的终端上选择“查询”功能(触屏)或旅行社通过网络接口选择“查询”功能;2.系统将数据库中的余票种类、数量、价格、有效日期输

14、出:(格式如下)l 门票名 门票价格 门票开始时间 门票结束时间 门票余票量 异常:系统出错,无法显示余票信息。3.2 买票功能功能描述:根据游客或旅行社的需求,系统打印出所需的门票;优先级:与检票同级,处于第一级前置条件:游客到达系统售票终端;旅行社通过网络接口选择“买票”功能;后置条件:系统打印出客户所需门票并反馈给票务数据库进行更新;主干过程:1.游客在系统终端上选择“购票”功能(或旅行社通过网络接口选择“买票”功能);2.客户在终端上输入“欲购门票种类”、“哪天”“数量”;3.系统形成购票订单;4.系统查询数据库,审核订单;5.若有票,则系统接收订单,并提示客户交纳金额,转入7;6.若

15、无票,则系统进入异常处理,并提示客户“当前无票”,返回1;7.客户交纳金额;(自助终端接受现金;网络接口接受网银)8.系统核查金额与票额;9.若足够,则返回余额并打印门票;若不足,则提示客户并退回全额返回7; 10.系统完成交易并更新数据库信息;异常:1.系统出错,无法打印门票或收钱不出票;2.系统无票,无法完成交易;3.3 检票功能优先级:处于第一级前置条件:游客到达系统检票终端;后置条件:游客凭票出入园;主干过程:1.游客达到检票终端,出示门票(采用扫描识别门票或通过门票内置芯片识别);2.系统根据门票信息判断: 是否是门票; 是门票进入;不是门票进入异常处理并提示“出示门票”返回1 看时

16、间是否有效,有效则检票入园并记录进园人数;否则进入异常处理并提示“非当日票”返回14.游客游园结束回到检票终端,出示门票;5.系统识别门票后让游客出园并记录出园人数(识别规则类似2的-);异常:1.系统出错,无法识别门票或游客不能正常出入园;2.出现假票或非当日票;3.4 统计功能功能描述:1. 系统根据售票信息,自动结算从某一时刻到当前时刻的售票情况2. 系统统计近日或当日的售票情况,形成售票情况交给决策部成员,以便制定新的售票计划优先级:处于第一级前置条件:1每完成一次购票或退票操作;2决策部成员“售票统计”功能;3财务部“金额结算功能”;4. 当日门票供不应求时(买票的异常)自动启动;后

17、置条件:1. 系统以表格形式显示“金额结算”结果,交给财务部;2. 系统以表格形式显示“售票情况”,交给决策部成员;主干过程:1.游客完成一次有效的购票操作;2.系统根据购票信息及当前数据库售票信息统计最新售票情况:(售票信息如下) l 总售票数 总售票金额 个人票数量 个人票金额 团票数量 团票金额3财务部成员登陆系统,获得权限;4财务部成员选择“金额结算”功能;5系统以表格形式显示结果;主干过程:1决策部成员登陆系统,获得权限;2决策部成员选择“售票统计”功能;3决策部成员输入“统计条件”:如近两天、近一周、近一月等;4系统根据统计条件,搜索数据库;5系统将近两天(近一周、近一月)的售票情

18、况以表格输出;(形式如下)l 时间段 团票总数 平均价格 个人票总数 平均价格 6将第5步形成的表格交给决策部成员,以便制定新的售票计划;主干过程:1买票出现异常:供不应求;2系统自动启动“售票统计”功能;3系统“统计条件”默认为“当天”;4系统搜索数据库;5系统用表格将“当日售票情况”交给决策部成员,以便及时修改当日售票计划;3.5 维护功能功能描述:系统管理员对门票数据库进行每天2次的定时数据维护及系统故障处理;优先级:弱于统计,处于第二级前置条件:1. 到维护时间2. 系统数据库出现故障;后置条件:数据库得到维护并完成故障处理;主干过程:1. 系统管理员登陆并取得管理员权限;2. 对数据

19、库进行每日的定时维护及故障处理;3.6 管理功能功能描述:系统通过新的售票计划,修改票的种类、数量、价格、有效时间;优先级:弱于维护,处于第三级前置条件:决策部形成新的售票计划;后置条件:完成新的售票计划并更新数据库;主干过程:1. 管理模块收到新的售票计划;2. 判断售票计划的时限:3. 系统根据新的售票计划的时限修改数据库(当日立即修改;明日的明天修改);异常:数据库无法访问或更新无法正常完成;3.7 实时票情功能功能描述:系统实时统计并显示卖票数、进出园人数; 前置条件:每卖出一张票或有人进出园;后置条件:系统实时显示卖出的票数及进出园人数;主干过程:1.卖出票或有人进出园;2.系统实时

20、统计卖出的票数及进出园人数;3系统将结果存储;4. 系统管理员选择“实时票情”功能;5. 系统显示实时结果异常:无法实时统计数据或显示结果;3.8 问题咨询功能功能描述:系统给客户提供相应接口,解决客户的问题或回答相应咨询;前置条件:系统提供了相关接口;后置条件:系统通过接口回答客户的问题及咨询;主干过程:1客户通过接口选择“问题咨询”功能;2客户通过接口提出问题咨询;3系统提示客户服务员“有问题咨询”;3客户服务员查看问题;4客户服务员回答问题;异常:接口不稳定,问题不能提交或回答无法显示;3.9 投诉功能功能描述:系统通过一定的接口给客户提供投诉;前置条件:系统提供相应的接口;(网络接口或

21、人机接口)后置条件:系统得到客户的投诉信息并提醒客户服务员处理;主干过程:1客户通过接口,选择“投诉”功能;2客户输入投诉内容A;3系统获取投诉内容A,并封装成信息包A;4系统将信息包A传给客户服务员并提醒其处理;5服务员将处理意见B输入系统;6系统将处理意见封装为信息包B;7系统将信息包B返回对应的投诉条目下;异常:系统出错,不响应投诉或处理意见无法回传;3.10 不支持的功能买票功能中无法完成金额的识别:原因成本过高,网银付费技术代价高,现金识别难度大;门票无法识别:模拟的系统无法针对的设计出真实的门票,无论是条形码识别或内置芯片识别对自助终端来说都成本太高或技术复杂;提供的相关接口中,网

22、络接口无法完成:作为自助系统,加上网络接口实在太过复杂,因自助系统主要考虑人机界面交互;触屏功能的实现对这个小项目而言,不但成本高且技术上难度不小,为能在有限时间及资源下做出点东西,只忍痛割爱;最后,本系统考虑到成员能力及技术要求,力争做到模拟水平,对于以上太过现实的功能实在力不从心;4.外部接口需求4.1用户界面l VC标准与网页界面标准:1 客户端界面:使用VC 2008进行用户界面的设计,力争做到界面简洁,操作便捷,输入输出明确,具有提示帮助信息;2 网络界面:使用Dreamweaver + php 进行用户界面(网页)的设计,力争做到界面简洁(主题突出),操作便捷,输入输出明确(尽量减

23、少用户的记忆信息),并具有提示帮助信息;l 用户界面1客户端界面11主界面:客户端的登录界面;具有6个功能按钮:查询、买票、投诉、咨询、管理员登录、退出;1个帮助菜单;通过鼠标完成操作;12子界面1:适用于投诉、查询;具有3个功能按钮:查询、提交、取消;3个输入文本区;查询结果用表格显示;通过鼠标、键盘完成操作;13子界面2:适用于买票;具有2个功能按钮:确定、退出;3个文本输入区和1个文本输出区;通过鼠标、键盘完成操作;14子界面3:适用于管理员登录;具有2个功能按钮:登录、取消;2个文本输入区;登录结果已弹出框显示;通过鼠标、键盘完成操作;2网络界面21主页面:是网络的主界面,适用于买票、

24、查询、投诉、咨询;拥有统一的logo和标题;具有4个对应的功能连接;结果用对应的子页面显示;综合用鼠标键盘完成操作;22子页面1:买票的界面;拥有统一的logo和标题;具有2个功能连接:买票、重置;有一个表格输入区;买票结果通过一个子页面完成,综合用鼠标键盘操作;23. 子页面3:适用于投诉、咨询;拥有统一的logo和标题;有2个功能连接:提交、重置;1个文本输入表格;结果用子页面显示;综合用鼠标、键盘完成操作;4.2软件接口本系统是自助售票系统的一个模拟,系统内部各个子系统的交互已经基本满足模拟的需求,不具有外部软件接口;4.3硬件接口由于是实际系统的模拟,不考虑与相关硬件的连接;故系统没有

25、硬件接口; 5.其它非功能需求5.1性能需求性能需求提出需求的依据同时使用系统进行编辑数据的用户数至少50个使景区的售票地点尽量灵活,可以实现异地售票,多地售票,同时使用的终端数应该尽量多,初步定于50个系统平均响应时间应控制在3秒之内,最多不能超过10秒。系统响应时间是衡量系统性能的重要指标,平均响应时间越短越有效率,响应时间过长会降低软件系统的可用性与实时系统的时间应保持一致性如果与实时系统的时间误差过大,则容易导致不同的售票终端数据发生冲突,产生误差。如果与实时系统的时间误差过大,则容易导致不同的售票终端数据发生冲突,产生误差系统支持的并发操作数量至少为50景区售票终端数量较多,这样做可

26、以提高性能,减少出现故障的几率存储器设计应包括两个2T的存储,外加一个2T的备份存储器由于景区面临的游客数量可能众多,游客的信息也可能登记复杂。一段时间进行一次备份对提高系统的个、安全性能大有助益。因此选择大容量的存储器作为存储和备份的空间系统对数据的处理出错率应低于1%景区售票系统可能面临巨大的数据流量,而且一旦出错可能会影响所有售票终端,甚至导致数据库的崩溃。应此系统应该具有一定的成熟性,减少出错。系统应在登入之时进行用户名和密码的验证保证系统的安全性图5.1.1 性能需求5.2质量属性对用户最重要的属性对开发者最重要的属性有效性高效性可维护性可移植性灵活性可重用性易用性可测试性可靠性图5

27、.2-1 质量属性有效性高效性灵活性易用性可靠性有效性正正高效性正负负灵活性负易用性可靠性正负图5.2-2 选择的质量属性之间的正负关系5.3安全需求与措施安全需求应对措施身份验证1、第一次登陆的管理人员必须统一输入初始密码,更新身份信息并等待高级管理人员通过验证。2、设置安全问题以及更新至少30个字符组成的新密码(子母与数字构成)。3、每次运行系统之后要输入密码以及回答安全问题。用户特权级别1、对管理人员进行严格的级别设定。不同级别的管理人员只能访问和更改特定的数据。2、例如:“只有拥有查账员访问特权的用户才可以查看客户交易历史。”网络传输的保密性1、 针对用户输入的个人信息,如年龄,姓名,

28、身份证号进行加密。2、 对用户输入的个人信用卡、银行卡进行付款等相关信息进行严格的加密传输。3、 管理人员没有特权查看个人银行信息等。4、 终端机到数据管理中心采用专线,保证信息不被窃取。5、 系统与外界网络连接部分设置防火墙,进行入侵检测。访问控制1、通过对特定网段、服务建立的访问控制体系,将绝大多数攻击阻止在到达攻击目标之前。 备份和恢复良好的备份和恢复机制,可在攻击造成损失时,尽快地恢复数据和系统服务。图5.3.1 安全需求与措施5.4其它需求其他需求相关说明健壮性所有的规划参数都要指定一个缺省值,当输入数据丢失或无效时,就使用缺省值数据。复用性本产品可以复用已有软件,可以为其

29、他产品复用。灵活性一个具有一定经验的软件维护人员可以在半个月内添加一项新的功能。可维护性1、 具有较高的可维护性,可以简单进行软件的更改或者纠正缺陷。2、 增强系统总的可维护性:A函数调用不能超过两层深度B每一个软件模块中,注释与源代码语句的比例至少为12可移植性1、 在软件设计过程中通常采用通用的程序设计语言和运行环境支撑2、 软件可以在不同操作系统上运行(WIN,LINUX等),或者只需更改一小部分。6.分析模型6.1.1用例清单用例编号用例名称简要说明01.个体旅客查询个体旅客查询票务问题。02.个体旅客购买门票个体旅客按需购买门票,交易。03.个体旅客问题咨询个体旅客遇到售票问题及所需

30、问题的咨询,营造良好的售票环境。04.个体旅客投诉个体旅客遇到门票出错,服务质量差,纠纷等,服务人员迅速解决问题,纠纷。05.旅行社(团票)查询旅行社(团票)用户查询票务问题(包括团票可提供时间,数量,注意事项)。06.旅行社(团票)购买门票旅行社(团票)用户按需购买门票,交易。07.旅行社(团票)问题咨询旅行社(团票)用户遇到售票问题及所需问题的咨询,营造良好的售票环境。08.旅行社(团票)投诉旅行社(团票)用户遇到门票出错,服务质量差,纠纷等,服务人员迅速解决问题,纠纷。解决旅行社(团票)用户需求调整参观时间的问题09.接待处检票接待处施行旅行社(团票)用户、个体旅客的进出景点的票务检查。

31、10.接待处获取数据库实时售票信息接待处获取数据库即时反馈过来的售票情况,对客流量情况调节自己的工作模式与工作量。接待处处理旅客在景点遇到的意外情况,解决客流拥堵问题。11.决策部获取统计信息(总体)决策部获取票务管理提供的门票销售趋势的统计信息,供其参考,制定销售策略。12.财务部获取统计信息(财务方面)财务部获取票务管理提供的历史售票,当前售票,订票等一切财物数据,以统计财物数据。13.服务人员问题咨询(提供)服务人员投诉处理(提供)服务人员针对个人团体进行问题咨询的回答与解决。服务人员针对个人团体的投诉给予处理。14.票务管理获取统计信息票务管理获取服务终端的购买,订购门票信息,对各类信

32、息进行分类、统计,同时上传至数据库。15.票务管理调控票务(种类,价格,数量)票务管理接受决策部指示,对当前未售门票业务(种类,价格,数量)进行修改。16.系统管理人员数据转移备份系统管理人员定期对系统数据库进行备份转移。17.系统管理人员数据恢复(备份数据拷入)解决数据库发生数据丢失等意外情况的数据恢复与补救。6.1.2 用例模型及其详细描述 01). 个体旅客查询A用例模型B用例详细描述用例编号:01.用例名称:个体旅客查询1 描述个体旅客查询票务问题。2 涉及的参与者与关注点顾客:希望票务查询能准确迅速,购票能够方便快捷,检票能够在迅速有效良好的秩序下进行,并有良好的售后处理,咨询等服务

33、。 能享受到方便便利的一条龙顺畅服务。3主成功场景(或基本流程)常规事件流: 个体用户在主页面上点击“查询票务”, 正确确定自己所需票务查询类型并递交申请。 数据库获取查询请求,处理请求。 数据库反馈个体用户的请求(如处理有无余票等需求)并作出相应回复 个体用户获取所需回答,流程结束。返回欢迎界面。4 扩展(替代流程)替代流程: 个体用户在主页面上点击“查询票务”, 没有正确确定自己所需票务查询类型并递交申请。 数据库获取查询请求,处理。 数据库查证无此类票务,返回操作错误回复。 个体用户得到回复,返回主界面,重新操作。 重复基本流程。获取所需回复。5 前置条件使用主界面进入票务查询。6 后置

34、条件(成功保证)正确选择所需票务查询类型。7 特殊需求 支持文本显示的语言国际化(支持English-汉语)。 19液晶触屏显示器,文本信息可见性较强。 文字表达简洁明了,确保使用者能准确理解字面内容。8 发生频率可能不断发生,不可预料9 未解决问题数据库出错时,对用户回复不正确信息02). 个体旅客购买门票A用例模型B用例详细描述用例编号:02.用例名称:个体旅客购买门票1 描述个体旅客按需购买门票,交易。2 涉及的参与者与关注点顾客:希望票务查询能准确迅速,购票能够方便快捷,检票能够在迅速有效良好的秩序下进行,并有良好的售后处理,咨询等服务。 能享受到方便便利的一条龙顺畅服务。3主成功场景

35、(或基本流程)常规事件流: 个体用户在主页面上点击“购买门票”, 正确确定自己所需票务类型并递交申请(分团队票,与个人票,团队票需旅行社登记)。 数据库获取购买请求,处理请求。 数据库反馈个体用户的请求,更新数据库并作出相应回复 个体用户获取门票,凭条,交易结束。返回欢迎界面。4 扩展(替代流程)替代流程: 个体用户在主页面上点击“购买门票”, 没有正确确定自己所需票务类型并递交申请。 数据库获取购买请求,处理请求。 数据库反馈个体用户的请求,更新数据库并作出相应回复个体用户获取门票,凭条,交易结束。发现购票错误,转至问题咨询界面,拨打客服电话解决问题。5 前置条件使用主界面进入“购买门票”,

36、并选择个体旅客。6 后置条件(成功保证)正确选择所买门票的数量类型。7 特殊需求 支持文本显示的语言国际化(支持English-汉语)。 19液晶触屏显示器,文本信息可见性较强。 文字表达简洁明了,确保使用者能准确理解字面内容。8 发生频率可能不断发生,不可预料9 未解决问题数据库出错时,对用户回复不正确信息。出票错误时,造成旅客滞留与观光障碍。03). 个体旅客问题咨询A用例模型B用例详细描述用例编号:03.用例名称:个体旅客问题咨询1 描述个体旅客遇到售票问题及所需问题的咨询,营造良好的售票环境。2 涉及的参与者与关注点顾客:希望票务查询能准确迅速,购票能够方便快捷,检票能够在迅速有效良好

37、的秩序下进行,并有良好的售后处理,咨询等服务。 能享受到方便便利的一条龙顺畅服务。3主成功场景(或基本流程)常规事件流: 在主页面上点击“问题咨询” 在“问题咨询”界面中查询所显示的常规问题及其解决方法。 问题得到解决,退回主界面,流程结束4 扩展(替代流程)替代流程: 在主页面上点击“问题咨询” 在“问题咨询”界面中查询所显示的常规问题及其解决方法。 查询未果,转至人工服务,拨打电话,或按照地址前往服务进一步咨询问题。 服务人员通过电话,或当面解决用户问题。5 前置条件在主界面上进入“问题咨询”6 后置条件(成功保证)常规问题得到查询或人工服务及时解决7 特殊需求 支持文本显示的语言国际化(

38、支持English-汉语)。 19液晶触屏显示器,文本信息可见性较强。 文字表达简洁明了,确保使用者能准确理解字面内容。 服务人员精通国际语言,能良好的与国外游客进行沟通。 人工服务热线在工作时间内,必须开放 另设24小时的购票咨询热线8 发生频率不可预料,随时可能发生9 未解决问题遇到国际游客,语言多样化的问题没有解决。04). 个体旅客投诉A用例模型B用例详细描述用例编号:04.用例名称:个体旅客投诉1 描述个体旅客遇到门票出错,服务质量差,纠纷等,服务人员迅速解决问题,纠纷。2 涉及的参与者与关注点顾客:希望票务查询能准确迅速,购票能够方便快捷,检票能够在迅速有效良好的秩序下进行,并有良

39、好的售后处理,咨询等服务。 能享受到方便便利的一条龙顺畅服务。并且针对投诉能够得到及时满意的解决。3主成功场景(或基本流程)常规事件流: 在主页面上点击“投诉”。 在“投诉”界面中填写并选择所要投诉的项目,事件并递交。 服务部接受到投诉,第一时间解决。 服务部反馈给用户,收到用户的投诉请求,并请求用户等待解决。4 扩展(替代流程)替代流程: 在主页面上点击“投诉”。 在“投诉”界面中填写投诉项目与事件不方便或发生问题。 转至人工服务,拨打电话,或按照地址前往服务进一步进行投诉诉诸服务部的投诉服务人员。 服务人员通过电话,或当面解决用户问题。5 前置条件用户进入“投诉”界面。6 后置条件(成功保

40、证)终端投诉的递交。服务人员对投诉的电话与当面受理。7 特殊需求 支持文本显示的语言国际化(支持English-汉语)。 19液晶触屏显示器,文本信息可见性较强。 文字表达简洁明了,操作简易,确保使用者能准确理解字面内容。 服务人员精通国际语言,能良好的与国外游客进行沟通。 人工服务投诉专线在工作时间内,必须开放8 发生频率不可预料,随时可以发生。9 未解决问题终端接受投诉的类型未明确。05). 旅行社(团票)查询A用例模型B用例详细描述用例编号:05.用例名称:旅行社(团票)查询1 描述旅行社(团票)用户查询票务问题(包括团票可提供时间,数量,注意事项)。2 涉及的参与者与关注点团体购票机构

41、(如旅行社):能迅速购买大量所需门票,能够方便快捷的通查团票信息,并有良好的售后处理,咨询等服务。3主成功场景(或基本流程)常规事件流: 团票用户在主页面上点击“查询票务”, 正确确定自己所需票务查询类型并递交申请。 数据库获取查询请求,处理请求。 数据库反馈团票用户的请求(如处理有无余票等需求)并作出相应回复 团票用户获取所需回答,流程结束。返回欢迎界面。4 扩展(替代流程)替代流程: 团票用户在主页面上点击“查询票务”, 没有正确确定所需票务查询类型并递交申请。 数据库获取查询请求,处理。 数据库查证无此类票务,返回操作错误回复。 团票用户得到回复,返回主界面,重新操作。 重复基本流程。获

42、取所需回复。5 前置条件使用主界面进入票务查询。6 后置条件(成功保证)正确选择所需票务查询类型。7 特殊需求 支持文本显示的语言国际化(支持English-汉语)。 19液晶触屏显示器,文本信息可见性较强。 文字表达简洁明了,确保使用者能准确理解字面内容。8 发生频率可能不断发生,不可预料9 未解决问题数据库出错时,对用户回复不正确信息06). 旅行社(团票)购买门票A用例模型B用例详细描述用例编号:06.用例名称:旅行社(团票)购买门票1 描述旅行社(团票)按需购买门票,交易。2 涉及的参与者与关注点团体购票机构(如旅行社):能迅速购买大量所需门票,能够方便快捷的通查团票信息,并有良好的售

43、后处理,咨询等服务。3主成功场景(或基本流程)常规事件流: 团体购票用户在主页面上点击“购买门票”, 正确确定自己所需票务类型及数量并递交申请(分团队票,与个人票,团队票需旅行社登记)。 数据库获取购买请求,处理请求。 数据库反馈团体购票用户的请求,更新数据库并作出相应回复。 团队共票用户获取门票,凭条,交易结束。返回欢迎界面。4 扩展(替代流程)替代流程: 团体购票用户在主页面上点击“购买门票”, 没有正确确定自己所需票务类型并递交申请。 数据库获取购买请求,处理请求。 数据库反馈个体用户的请求,更新数据库并作出相应回复个体用户获取门票,凭条,交易结束。发现购票错误,转至问题咨询界面,拨打客

44、服电话解决问题。(如数量不足,则直接继续常规基本流程即可)5 前置条件使用主界面进入“购买门票”,并选择团队购票。6 后置条件(成功保证)正确选择所买门票的数量类型。7 特殊需求 支持文本显示的语言国际化(支持English-汉语)。 19液晶触屏显示器,文本信息可见性较强。 文字表达简洁明了,确保使用者能准确理解字面内容。8 发生频率可能不断发生,不可预料。9 未解决问题数据库出错时,对用户回复不正确信息。出票错误时,造成旅客滞留与观光障碍。07). 旅行社(团票)问题咨询A用例模型B用例详细描述用例编号:07.用例名称:旅行社(团票)问题咨询1 描述旅行社(团票)用户遇到售票问题及所需问题

45、的咨询,营造良好的售票环境。2 涉及的参与者与关注点团体购票机构(如旅行社):能迅速购买大量所需门票,能够方便快捷的通查团票信息,并有良好的售后处理,咨询等服务。3主成功场景(或基本流程)常规事件流: 在主页面上点击“问题咨询” 在“问题咨询”界面中查询所显示的常规问题及其解决方法。 问题得到解决,退回主界面,流程结束4 扩展(替代流程)替代流程: 在主页面上点击“问题咨询” 在“问题咨询”界面中查询所显示的常规问题及其解决方法。 查询未果,转至人工服务,拨打电话,或按照地址前往服务进一步咨询问题。 服务人员通过电话,或当面解决用户问题。 问题得到解决,退回主界面,流程结束。5 前置条件在主界

46、面上进入“问题咨询”6 后置条件(成功保证)常规问题得到查询或人工服务及时解决7 特殊需求 支持文本显示的语言国际化(支持English-汉语)。 19液晶触屏显示器,文本信息可见性较强。 文字表达简洁明了,确保使用者能准确理解字面内容。 服务人员精通国际语言,能良好的与国外游客进行沟通。 人工服务热线在工作时间内,必须开放。 另设24小时的购票咨询热线。8 发生频率不可预料,随时可能发生。9 未解决问题团队游客量大时,服务人员对待解决问题的游客安置与休息问题。08). 旅行社(团票)投诉A用例模型B用例详细描述用例编号:08.用例名称:旅行社(团票)投诉1 描述旅行社(团票)用户遇到门票出错

47、,服务质量差,纠纷等,服务人员迅速解决问题,纠纷。解决旅行社(团票)用户需求调整参观质量的问题等。2 涉及的参与者与关注点团体购票机构(如旅行社):能迅速购买大量所需门票,能够方便快捷的通查团票信息,并有良好的售后处理,咨询等服务。针对投诉能够得到及时满意的解决。3主成功场景(或基本流程)常规事件流: 在主页面上点击“投诉”。 在“投诉”界面中填写并选择所要投诉的项目,事件并递交。 服务部接受到投诉,第一时间解决。 服务部反馈给用户,收到用户的投诉请求,并请求用户等待解决。4 扩展(替代流程)替代流程: 在主页面上点击“投诉”。 在“投诉”界面中填写投诉项目与事件不方便或发生问题。 转至人工服

48、务,拨打电话,或按照地址前往服务进一步进行投诉诉诸服务部的投诉服务人员。 服务人员通过电话,或当面解决用户问题。5 前置条件用户进入“投诉”界面。6 后置条件(成功保证)终端投诉的递交。服务人员对投诉的电话与当面受理。7 特殊需求 支持文本显示的语言国际化(支持English-汉语)。 19液晶触屏显示器,文本信息可见性较强。 文字表达简洁明了,操作简易,确保使用者能准确理解字面内容。 服务人员精通国际语言,能良好的与国外游客进行沟通。 人工服务投诉专线在工作时间内,必须开放8 发生频率不可预料,随时可以发生。9 未解决问题终端接受投诉的类型未明确。09). 接待处检票A用例模型B用例详细描述

49、用例编号:09.用例名称:接待处检票1 描述接待处施行旅行社(团票)用户、个体旅客的进出景点的票务检查。2 涉及的参与者与关注点接待处:需求景区售票系统及时有效的给予票务订单与信息,并根据售票订购订单情况与实际情况相结合,为工作日的客流量工作做好准备措施。根据景区的最大限容游客量,以及各个外部团体订购需求,做出合理的反馈。团体购票机构(如旅行社):能迅速购买大量所需门票,能够方便快捷的通查团票信息,并有良好的售后处理,咨询等服务。针对投诉能够得到及时满意的解决。检票能方便安全快捷,有良好的秩序。顾客:希望票务查询能准确迅速,购票能够方便快捷,检票能够在迅速有效良好的秩序下进行,并有良好的售后处

50、理,咨询等服务。 能享受到方便便利的一条龙顺畅服务。检票能方便安全快捷,有良好的秩序。3主成功场景(或基本流程)常规事件流: 游客进入景区之前,接待处对其进行检票。 游客出景区之前,接待处对其进行检票。 通过仪器检票,仪器与数据库系统相连,确定售票与使用人数是否匹配。4 扩展(替代流程)替代流程: 接待处接待游客,并检票。 遇到天气灾害等意外情况。 召回所有旅客,并安置与公共休息区内直到意外情况结束。 重复基本流程。5 前置条件接受售票系统数据库的时时更新,数据正确无误。6 后置条件(成功保证)成功对旅客的进出景区进行检票。7 特殊需求检票仪器,与数据库相连接,检票速度较快。安全休息区,有基本

51、的供水与医疗系统。8 发生频率工作日时,意外情况,随时发生,不可预料。9 未解决问题安全区的大小,可容纳人数。10). 接待处获取数据库实时售票信息A用例模型B用例详细描述用例编号:10.用例名称:接待处获取数据库实时售票信息1 描述接待处获取数据库即时反馈过来的售票情况,对客流量情况调节自己的工作模式与工作量。接待处处理旅客在景点遇到的意外情况,解决客流拥堵问题。2 涉及的参与者与关注点接待处:需求景区售票系统及时有效的给予票务订单与信息,并根据售票订购订单情况与实际情况相结合,为工作日的客流量工作做好准备措施。根据景区的最大限容游客量,以及各个外部团体订购需求,做出合理的反馈。3主成功场景(或基本流程)常规事件流: 接待处接受次日等工作日得订票情况,并制定工作计划。 接待处接受来自售票系统数据库的数据时时更新,并对客流量进行合理的接待。4 扩展(替代流程)替代流程: 接待处接受数据库更新的错误数据。 未检修出之前,采用应急工作措施。等待修复。 维护成功后,重复常规基本流程。5 前置条件接受售票系统的数据库更新。6 后置条件(成功保证)数据库数据更新

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论