旅游消费投诉综合管理系统需求规格新版说明书.docx

旅游消费投诉管理系统需求规格说明书旅游消费投诉管理系统需求规格说明书学院： 软件与通信工程学院 课程： 软件需求分析 2016/6/13目录Part I 引言31.1文档目的31.2组织方式31.3项目范围31.4参考文献4Part II 总体描述42.1产品前景42.2产品特性52.3用户类及其特征52.4运行环境62.5设计和实现上的约束72.6假设和依赖7Part III 详细需求描述83.1对外接口需求83.1.1用户界面83.1.2硬件接口83.1.3软件接口93.2功能需求93.2.1信息流93.2.2 处理描述103.2.3 数据结构描述153.2.4 数据字典163.3 性能需求173.3.1 数据精确度173.3.2 时间特性173.3.3 适应性173.3.4 容量需求173.3.5 实时性183.3.6 负载183.4 质量属性183.4.1 完整性183.4.2 可靠性183.4.3 效率183.4.4 易用性193.4.5 可维护性193.4.6 可移植性193.5 其他需求203.5.1 安全性需求20Part I 引言1.1文档目标编写此文档目标在于深入定制系统（旅游消费投诉管理系统）开发中细节问题，方便于用户和旅行企业协调工作，关键面向读者是项目委托单位管理人员。本文档定义了相关旅游消费投诉管理系统功效需求，数据描述，运行环境等内容。本文档也可作为系统设计人员，技术支持人员，测试人员，使用人员参考资料。1.2组织方法在文档余下部分会叙述对系统总体描述，系统特征具体描述，对外接口实现和其它一系列功效需求和非功效需求描述。 文档基础上根据由总体到局部格局，首先对系统总体概要描述，以后将对对外接口进行叙述，最终将列出一系列功效需求和非功效需求。1.3项目范围表1.1项目范围软件名称旅游消费投诉管理系统预期功效有帐号管理功效，权限设置游客能够对旅游中碰到多种情况进行投诉能够向旅游企业转发投诉单数据更新和数据库备份功效能够保留历史数据非预期功效1.给出旅游企业服务优化方案2.给出游客选择旅游企业提议产品应用目标： 1. 方便游客进行对应消费投诉2. 提升旅游企业服务质量1.4参考文件需求工程-软件建模和分析 旅游消费投诉管理系统前景范围文档 旅游消费投诉管理系统问题分析过程 软件需求规格说明模板（IEEE标准）Part II 总体描述2.1产品前景伴随多年来旅游市场继续以较快趋势增加，经过管理和完善投诉系统，将会清楚自己企业不足和经营问题。立即做出调整和改革，了解用户最需要需求，使得企业适应发展时尚。再者伴随多年来网上预约等方法兴起，出现了不少消费问题，经过投诉系统能够方便用户进行维权。还有就是提升相关管理人员工作效率，节省相关管理时间和精力。从而提升企业业绩。2.2产品特征表2.1产品特征特征1二十四小时服务，任何时间全部能够提交投诉和回复用户特征2对历史投单进行定时保留，以免丢失。特征3对目前投单进行分类管理和处理。特征4对投诉问题和工作人员进行统计。特征5用户能够查询投诉进程特征6权限控制，管理员能够查询投诉者信息2.3用户类及其特征表2.2用户类及其特征用户类 关键目标 态度 关键关注点 技术能力 系统管理人员方便管理，提升工作效率对于方便工作而言，1.0版本已经足够工作轻松，高效 能够使用系统各个功效，定时进行数据维护 ，学会使用软件，定时对数据备份旅游企业管理人员 提升管理效率，提升旅游产品销售业绩 强烈要求完整版本实施提升业绩，提升游客满意度学习使用系统和灵活使用系统，对用户投诉情况有一定分析能力，能够依据系统参考给出优化管理方案 游客立即得到投诉反馈及处理方案实施完整版本服务态度和处理问题快慢无 2.4运行环境操作系统：Windows /Windows XP/UNIX Aix 软件平台：DB2，BI 2.5设计和实现上约束表2.3设计和实现上约束规章制度遵照中国旅游法硬件限制有足够大服务器供此系统运行并发操作能够多个用户同时进行投诉操作审计功效控制功效高阶语言要求（程序开发语言）Java，JavaScript ,SQL应用临界状态安全性考虑帐户安全性，数据安全性2.6假设和依靠表2.4假设和依靠假设1旅游企业拥有稳定服务器作为系统平台，和历史数据存放地假设2数据库实时更新，历史数据能够被合理备份假设3旅游企业业务量足够大，有分析历史数据能力依靠在断电情况下，保持服务器正常运转Part III 具体需求描述3.1对外接口需求 3.1.1用户界面采取Windows通用图形界面，对用户友好，对鼠标和键盘提供支持，界面设计遵照以下规则：界面含有一致性，遵照MS Windows软件界面规范；提供简单错误处理。提供投诉信息反馈，用多个信息提供用户目前软件运行状态，软件界面元件功效。操作界面简练明快，富有现代气息，用词正确，没有歧义，图形意义明朗。 3.1.2硬件接口表3.1硬件接口硬件名称交流数据类型控制信息通信协议服务器历史数据微机内部处理数据 3.1.3软件接口表3.2软件接口软件名称交换数据目标Windows/XP内部处理数据为系统提供运行平台数据库历史投诉数据存放历史数据3.2功效需求3.2.1信息流3.2.1.1 上下文图图3-1上下文图3.2.2 处理描述 3.2.2.1. 处理1图3-2处理1 n层图3.2.2.1.1输入输出数据实体表3.3处理1输入输出数据实体表输入输出投诉信息投诉信息单收到确定3.2.2.1.2处理过程先接收投诉信息，返回一个收到确定信息，以后将投诉信息处理，产生投诉信息单，将投诉信息单输出。3.2.2.1.3被影响数据实体被影响数据实体有1.1接收投诉信息，1.2产生投诉单，1.3产生收到确定信息。3.2.2.2 处理2图3-3处理2 n层图3.2.2.2.1输入输出数据实体表3.4处理2输入输出数据实体表输入输出投诉信息单分类处理后投诉信息单3.2.2.2.2处理过程先接收到投诉信息单，系统进行分类处理，再将其转化成为标准格式，最终形成份类处理后投诉信息单。3.2.2.2.3被影响数据实体被影响数据实体有：2.1接收投诉信息单，2.2进行分类，2.3进行处理转化为标准格式。3.2.2.3 处理3图3-4处理3 n层图3.2.2.3.1输入输出数据实体表3.5处理3输入输出数据实体表输入输出分类后投诉信息单个人信息不正确，审核不经过用户信息提交材料不属实，审核不经过对用户信息审核经过对投诉用户信息3.2.2.3.2处理过程输入已经分类完成投诉单进行审核，审核投诉人个人信息是否正确，反馈一个审核结果，若不正确，则输出个人信息不正确，审核不经过；若正确，则进入到下一个提交材料是否属实审核，假如不属实，输出提交材料不属实，审核不经过；假如属实，则返回审核经过投诉用户信息。3.2.2.3.3被影响数据实体被影响数据实体有：4.1审核投诉人个人信息是否正确，4.2审核投诉人所提交材料是否属实。3.2.2.4 处理4图3-5处理4 n层图3.2.2.4.1输入输出数据实体表3.6处理4输入输出数据实体表输入输出审核经过投诉信息受理成功信息被投诉者确定投诉信息七天内未收到被投诉者确定受理失败信息3.2.2.4.2处理过程系统接收到审核经过投诉信息，分配给对应投诉受理员，投诉受理员接收以后，返回一个提取确定给系统。以后，投诉受理员将投诉信息转发给被投诉者，假如被投诉者返回确定，受理员和被投诉者进行协商处理，协商成功，输出受理成功信息。假如七天内未收到被投诉者确实定或受理员和被投诉者协商失败，则受理员将投诉信息转交给当地旅游管理局，以相关法律进行处理，输出受理失败信息。3.2.2.4.3被影响到数据实体被影响实体有：6.1将审核经过对投诉信息分配给受理员，6.2受理员将信息转发给被投诉者，6.3受理员和被投诉者进行协商，6.4受理员将投诉信息交给当地旅游管理局进行相关法律处理。3.2.3 数据结构描述图3-6 0层图3.2.4 数据字典表3.2.4-1投诉单数据项名称数据类型数据长度是否关键字是否为空数据含义IDVarchar10是否编号ContentVarchar100否否内容CnameVarchar16否否投诉人Bnamevarchar16否否被投诉人表3.2.4-2游客数据项名称数据类型数据长度是否关键字是否为空数据含义UnameVarchar20是否用户名UpasswordVarchar6是否密码Phoneint11否否联络方法Addressvarchar16否否联络地址表3.2.4-3管理员数据项名称数据类型数据长度是否关键字是否为空数据含义AnameVarchar20是否用户名ApasswordVarchar6是否密码IndicationVarchar10否否管理员标识（审核员或受理员）3.3 性能需求3.3.1 数据正确度查询投诉统计时应该确保查全率，全部符合查询要求统计全部能被查找到查询时应该确保查准率，查到全部统计应该和所给查询条件完全匹配。3.3.2 时间特征 通常响应时间不能超出2秒，历史投诉数据导入和导出也应该控制在能够接收时间内完成。3.3.3 适应性 满足个人使用需求，对前面提到运行环境要求不存在困难。3.3.4 容量需求 为使系统运行效率更高，在以历史投诉数据为基础分析功效均以前一个季度数据为参考，历史数据库存放最近6个月数据，逾期数据将被系统自动删除。3.3.5 实时性从数据库导入到管理报表间隔时间不能超出1s.3.3.6 负载 许可200个用户（包含投诉审核员，投诉受理员）同时登陆系统进行投诉，受理投诉等操作。3.4 质量属性3.4.1 完整性 对数据进行实时存放，确保数据完整性，即使在断电或机器忽然损坏情况下也不会出现数据丢失。3.4.2 可靠性 通常条件下，系统含有较高可靠性，不会出现故障。 软件不应存在固有缺点，在外界违反指定接口或故障情况下也能维持在指定性能水平。3.4.3 效率进行系统中给定任何通常操作（包含登录，投诉，受理投诉，分析，账户修改等等）响应时间全部不应该超出2秒 ，给用户好响应体验，系统运行和操作时候全部应该花费尽可能少硬件和软件资源。 在系统进行后台数据处理分析时候，对CPU使用率应控制在30%以下。3.4.4 易用性系统运行过程符适用户逻辑思维。界面清楚，用词正确，是系统易于操作，用户能够在很短时间内掌握对系统全部操作。在操作系统时，用户不需要大量输入信息，大部分情况下只需要使用点击鼠标和输入部分少许验证信息和时间信息。3.4.5 可维护性 在系统发生故障，缺点时能够对其快速定位，在极短时间内发觉错误所在。在进行错误剔除过程中，能够方便对系统进行修改，扩展。对系统进行新修改，扩展为系统带来新缺点可能性应该控制在较小范围内。对修改后系统能够方便进行测试以确定修更正确性。使得维护人员能够愈加高效维护系统。3.4.6 可移植性不需采取额外方法或技巧就能适应不一样指定环境。在指定环境下只需花费极少精力对系统进行安装。 同共享资源其它系统能够很好共存，方便适应环境改变。3.5 其它需求3.5.1 安全性需求 进行任何系统使用全部必需最少以用户权限登录系统。 任何非法登入全部会被阻止，在3次用户登录失败后将对系统进行锁定，等候管理员权限进行解锁。