第F组 需求规格说明书.doc

票务在线客服系统需求规格说明书项目名称： 票务在线客服系统 学 院： 福建师范大学应用科技学院 专 业： 09 软 工 （4）班 项目成员: 孙立、陈海平、林新源、蔡文勇、苏信彬、陈宇文档修订记录版本编号*变化状态简要说明（变更内容和变更范围）日期变更人批准日期批准人1.0建立整体框架完成2010-1-5陈海平2.0修改完善基本框架、内容2010-4-10孙立*变化状态：1.0 建立，修改，增加，删除；完成基本框架2.0 对基本框架、内容进行初步完善文档审批信息序号审批人角色审批日期签字备注目录1引言41.1编写目的41.2项目背景41.3参考资料42需求概述52.1 总体设计目标52.2 业务模型52.3 用户的特点53 需求规定63.1 总体功能需求说明63.2功能需求73.2.1 用例描述73.3数据需求153.3.1 实体类153.2.2 实体类的描述163.4 运行需求193.4.1运行环境193.4.2开发环境193.5 其它需求193.5.1 界面需求193.5.2 性能需求193.5.3 安全需求193.5.4 操作需求204 该系统未来可增加的功能：20 1引言1.1编写目的编写该文档的目的主要是明确所要开发的系统应具有的功能、全面分析说明票务在线客服系统第一阶段中的设计考虑，包括程序系统的功能需求、数据需求、运行需求，其他需求，为程序的概要设计提供基础性能，使系统分析人员及软件开发人员能清楚地了解用户的需求，以促进后续设计与开发工作，为软件开发范围、业务处理规范提供依据，也是客户接收本系统时的验收依据。1.2项目背景随着网络的发展，互联网已经改变并继续改变着我们的学习方式、生活方式、娱乐方式和工作方式。据权威部门统计，目前，中国的网民已经超过了3亿人,人们使用网络的频率越来越多，网络客服也将成为主流。同时，随着经济的增长，人们出行的频繁程度，票务处理必然成为出行首要解决的事务。票务在线系统可以轻松解决此难题，客户只需点击鼠标和简单的语音交流就可轻松订购出门所需票务，并有票务客服人员送票上门。1.3参考资料1项目管理计划、进度和控制的系统方法（第7版）Harold Kerzner（电子工业出版社，杨爱华等译）；2计算机软件工程规范国家标准汇编2003中国标准出版社；3PMBOK-2000PMI；PMBOK-2004PMI；4成功的项目管理Trevol L Young（泰晤士报商业版，严鸿娟译）；5 本项目使用WEbBUSS的项目资源，以及文献资料 该资料由JAVA老师陈佳洵提供；2需求概述2.1 总体设计目标1 有效的充分利用计算机资源, 减轻管理员的工作量；2 通过优异的数据库设计，提高系统运行效率；3 提供人性化的界面，使用户都能一看就会用；4 提供便捷的操作，提高软件的上手度5 保证用户的信息安全2.2 业务模型票务在线客服系统前台数据库客户票务在线客服系统后台客服发送订票请求发送订单查询票务反馈查询验证订单提交订单管理员处理订单送票员送票签收分配回馈票务订购业务模型图2.3 用户的特点用户有三种，客户、客服人员、管理员l 用户：所有互联网用户。用户只需访问网站页面后，即可完成各种任务。用户只需要了解Windows操作系统和网络的基础知识；l 客服人员：服务客户人员，查询，提交订单。查询数据库和提交数据库修改请求等l 管理员：管理票务系统的人，主要职责是管理客服信息和业务信息，维护系统，保证网络的通畅。3 需求规定3.1 总体功能需求说明总体功能模块如图3.1票务在线客服系统客户客服管理员订票退票查询票务服务客户查询票务发送提交订单管理数据库管理工作员维护网络处理订单整体功能需求如表3.1所示：表3.1.2整体功能需求功能类别功能功能说明用户订票用户可以预定出门票务退票用户可以退订票务查询票务用户可以查看票务实时动态客服服务客户与客户交谈，满足客户要求查询票务查询数据库票务实时动态发送订单（客户）提交订单（库）客服订单管理员管理数据库对数据库进行增、删、改、查；进行数据库实时更新管理工作人员对客服、送票人员进行人员管理维护网络保证客服系统正常稳定的运行处理订单对客户订单进行处理3.2功能需求3.2.1 用例描述1 查询票务信息（客户）.前置条件（Pre-Conditions）在这个用例开始前，客户必须登录到系统中。.后置条件（Post-Conditions）如果这个用例成功，在系统中查询到所需票务信息，确认所需票务并且提交订票单。否则，系统的状态没有变化。.扩充点（ExtensionPoints）若确认购票并填写提交购票订单，则执行购票用例。.事件流.基流（BasicFlow）当客户登录在线购票系统时，用例启动。客户在线可自行查询当日票务信息以及自己所需票务信息，若确认在线订票则需正确填写购票订单并提交至系统。.分支流（Subflows）S-1：客户登录系统查询票务信息 检索各时段票务信息。检索各地点票务信息。检索票务其他信息。查询所需车票信息查询所需车票是否可以获得（E-2），也即查询所需车票已售出或未售出。S-2：填写购票订单。确认购票时即可自行填写票务票务订单。系统检测订单上所需项已填写。确认无误后提交订单至系统。.替代流（AlternativeFlow）E-1：登录系统连线中断，系统显示提示信息，用例终止。E-2：非法操作，系统自动关闭，用例终止。2 与客服交流2.前置条件（Pre-Conditions）在这个用例开始前，客户必须登录到系统中。2.后置条件（Post-Conditions）如果这个用例成功，客户将在系统中与客服进行咨询和交流。否则，系统的状态没有变化。2.扩充点（ExtensionPoints）没有。2.事件流2.基流（BasicFlow）当登录系统选择与客服进行交流时，用例启动。客户可在登录后与客服人员进行在线交流，咨询各类所需问题与当日票务信息，检索确认是否购票即填写购票订单。2.分支流（Subflows）S-1：客户咨询客服人员当日车票信息咨询客服在线购票的各类问题。咨询当日票务信息。咨询所需车票是否可以获得（E-2），也即咨询所需车票已售出或未售出。S-2：填写购票订单并提交确认购票即向客服索取购票订单。向客服寻求填写上的帮助。确认填写无误即可提交。2.替代流（AlternativeFlow）E-1：该时段客服系统繁忙，系统显示提示信息，用例终止。E-2：系统检测判断出该客户不需要与客服交流，系统显示提示信息，用例终止。3 与客户交流3.前置条件（Pre-Conditions）在这个用例开始前，客服人员必须登录到系统中。3.后置条件（Post-Conditions）如果这个用例成功，在系统中确认客户是否会员，并且确认客户是否订票。否则，系统的状态没有变化。3.扩充点（ExtensionPoints）没有。3.事件流3.基流（BasicFlow）当有客服人员被分配与客户进行交流时，用例启动。客服通过与客户进行交流，为在线用户提供所需的帮助，检索当日票务信息以及确认客户所需车票是否可得。若客户决定在线购票，则发送购票订单于客户，并提供填写上的帮助，直至客户填写完毕并提交。3.分支流（Subflows）S-1：在线与客户交流，为客户提供帮助。与客户交流，回答客户在线所提问题。提供当日票务信息。检索各时段票务种类。检索各地点票务种类。确定所订车票是否可以获得（E-2），也即确定所订车票已售出或未售出。S-2：发送购票订单于客户，并提供帮助。客户确认购票时即发送购票订单于客户。提供相应填写订单上的帮助。客户确认填写无误后提示客户提交。3.替代流（AlternativeFlow）E-1：客户连线中断，系统显示提示信息，用例终止。E-2：客服系统中断，系统显示提示信息，用例终止。4 查询票务信息（客服）4.前置条件（Pre-Conditions）在这个用例开始前，客服人员必须登录到系统中。票务信息系统每30分钟更新一次。4.后置条件（Post-Conditions）如果这个用例成功，客服人员在系统中查询到所需票务信息，反馈给客户。否则，系统的状态没有变化。4.扩充点（ExtensionPoints）无。4.事件流4.基流（BasicFlow）当客服人员经客户咨询，需在线检索票务信息时，用例启动。客服人员在系统中查询票务的各项信息，搜索数据库信息来反馈给客户。客服通过系统查询票务信息 ：检索各时段票务信息。检索各地点票务信息。检索票务其他信息。查询所需车票信息查询所需车票是否可以获得（E-2），也即查询所需车票已售出或未售出。4. .替代流（AlternativeFlow）E-1：客服系统连线中断，系统显示提示信息，用例终止。E-2：客户下线，系统显示提示信息，用例终止。5 判断来客地址（Judging Guest Address）5.前置条件（Pre-Conditions）在这个用例开始前，必须有Guest进入到指定页面中。5.后置条件（Post-Conditions）如果这个用例成功，在线系统管理员会根据Guest 的IP地址进行简单判断来客的物理地址。5.扩充点（ExtensionPoints）1、可以简单根据物理地址来初步判断Guest填写的购票信息真实性。2、在获取Guest物理地址时.可以显示到前台页面.用来做欢迎词。5.事件流 管理员获取Guest IP 地址管理员通过IP 地址获取对方物理地址5.基流（BasicFlow） 当Guest登陆到首页时，用例启动。5.分支流（Subflows）Guest 登陆到首页时.自动弹出显示是否需要客服帮助的对话框。5.替代流（AlternativeFlow）Guest 选着是否接受客服帮助 该用例结束。 Guest 跳转指定页面 该用例结束。6、分配客服人员（Distribute Servers）6.1.前置条件（Pre-Conditions）在这个用例开始前，Guest选择接受客服帮助。6.后置条件（Post-Conditions）这个用例成功启动后，管理员根据客服的详细情况给客户分配客服6.扩充点（ExtensionPoints）无6.事件流 管理员判断客户是否选择了接受客服帮助管理员把接受客服帮助的客户自动添加到客服中6.基流（BasicFlow） 当Guest选择接受客服帮助时，用例启动。6.分支流（Subflows）Guest 接受客服帮助时.管理员自动根据客服具体信息把客户添加到客服中。6.替代流（AlternativeFlow）Guest 选择退出客服系统 该用例结束。 Guest 退出指定页面后 该用例结束。7、统计在线客服（Add Servers）7.前置条件（Pre-Conditions）管理员每隔半小时.就要进行一次统计在线客服。7.后置条件（Post-Conditions）如果这个用例成功，当客户选择接受客服帮助时.管理员会根据客服情况给客户分配客服。7.扩充点（ExtensionPoints）无7.事件流 管理员没半小时统计在线客服管理员把统计结果存到指定数据库7.基流（BasicFlow） 没半小时该用例会自动启动。7.分支流（Subflows）无7.替代流（AlternativeFlow）无8、判断闲置客服（Judging Servers）8.前置条件（Pre-Conditions）在这个用例开始前，管理员分配客服用例启动。8.后置条件（Post-Conditions）如果这个用例成功，管理员会给闲置客服自动分配接受客服帮助的客户。8.扩充点（ExtensionPoints）无8.事件流 管理员判断客服的服务客户数量是否已满管理员判断客服是否有客户8.基流（BasicFlow） 当分配客服用例启动时，该用例自动启动。8.分支流（Subflows）无8.替代流（AlternativeFlow）无9、处理客户订单9.前置条件（Pre-Conditions）在这个用例开始前，必须有Guest提交订单。9.后置条件（Post-Conditions）如果这个用例成功，在线系统管理员会根据Guest 的订单信息分配送票人员（包括电子票务）。5.扩充点（ExtensionPoints）无9.事件流 管理员根据客户订单信息分配送票人员9.基流（BasicFlow） 当Guest提交订单信息时，用例启动。9.分支流（Subflows）无9.替代流（AlternativeFlow）分配完送票人员该用例结束。10.管理客服人员10.1前置条件（1）管理员收到注册信息或退出申请10.2后置条件如果这个用例成功品，管理员可以对客服人员进行管理10.3扩展点无10.4事件流10.4.1基流当管理员登入客服人员管理系统，用例启动：系统显示当前客服人员资料和注册消息11.管理车票数据库11.1前置条件管理员收到车次信息11.2后置条件如果用例成功，管理员可以对车票数据库进行查询，添加，删除，更新11.3扩充点无11.4事件流11.4.1基流管理员登入车票管理系统，用例启动3.3数据需求3.3.1 实体类编号实体类名说明1票务信息记录票务的基本信息2业务信息业务的详细信息3订单信息描述订单内容4投述建议信息记录客户投述与建议5管理员信息记录管理员名，密码以及其他信息6用户记录用户名，密码以及其他信息7通话记录记录用户通话详细情况8故障申告记录故障申告信息9常见问题与解答记录常见的问题与解决方法3.2.2 实体类的描述1. 票务信息编号：1实体类名：票务信息职责：保存票务的基本信息属性：车票说明：该实体类中存放保存车票的基本信息。方便查询特殊需求： 范围：每个对象约100字节； 容量：最大为1000； 更新频率：创建/删除：1次/30天，2. 业务信息编号：2实体类名：业务信息职责：保存所有的业务信息属性：业务号，业务名，业务内容说明：该实体类中存放保存业务信息特殊需求： 范围：每个对象约500字节； 容量：最大为1000； 更新频率：创建/删除：2次/月，3. 订单信息编号：3实体类名：订单信息职责：描述订单基本信息属性：订单编号说明：该实体类中存放订单的基本信息。特殊需求：无4. 投述建议信息编号：4实体类名：投述建议信息职责：保存每位用户的投述建议信息属性：信息编号，内容 说明：该实体类中存放保存每位用户的投述建议信息特殊需求： 范围：每个对象约200字节；5. 管理员信息编号：5实体类名：管理员信息记录职责：保存每位管理员信息属性：管理员名，管理员密码，用户创建日期，上次登入时间说明：该实体类中存放保存每位管理员的信息，是管理员登入的凭证。 范围：每个对象约1000字节； 容量：最大为50； 更新频率：创建/删除：1次/7天，6. 用户信息编号：6实体类名：用户信息记录职责：保存每位用户的信息属性：用户名，用户密码，用户创建日期，上次登入时间，用户等级说明：该实体类中存放保存每位用户的信息，是用户登入的凭证。 范围：每个对象约1000字节； 容量：最大为50； 更新频率：创建/删除：1次/7天，7. 通话记录编号：7实体类名：通话记录职责：记录通话信息属性：用户号，通话日期，通话时间，主叫，被叫，通话时间说明：该实体类记录通话的信息。方便用户对过去的通话情况进行查询。特殊需求： 容量：最大为10000； 更新频率：创建：每次对话都要更新，8. 故障申告编号：8实体类名：故障申告职责：保存每位用户的故障申告信息属性：信息编号，用户号，申告内容 ，日期说明：该实体类中存放每位用户的故障申告信息特殊需求： 范围：每个对象约200字节；9. 通话记