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

旅游消费投诉管理系统需求规格说明书
旅游消费投诉管理系统需求规格说明书

学院： 软件与通信工程学院
课程： 软件需求分析

2016/6/13

目录
Part I 引言 3
1.1文档目的 3
1.2组织方式 3
1.3项目范围 3
1.4参考文献 4
Part II 总体描述 4
2.1产品前景 4
2.2产品特性 5
2.3用户类及其特征 5
2.4运行环境 6
2.5设计和实现上的约束 7
2.6假设和依赖 7
Part III 详细需求描述 8
3.1对外接口需求 8
3.1.1用户界面 8
3.1.2硬件接口 8
3.1.3软件接口 9
3.2功能需求 9
3.2.1信息流 9
3.2.2 处理描述 10
3.2.3 数据结构描述 15
3.2.4 数据字典 16
3.3 性能需求 17
3.3.1 数据精确度 17
3.3.2 时间特性 17
3.3.3 适应性 17
3.3.4 容量需求 17
3.3.5 实时性 18
3.3.6 负载 18
3.4 质量属性 18
3.4.1 完整性 18
3.4.2 可靠性 18
3.4.3 效率 18
3.4.4 易用性 19
3.4.5 可维护性 19
3.4.6 可移植性 19
3.5 其他需求 20
3.5.1 安全性需求 20

Part 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投诉单
数据项名称
数据类型
数据长度
是否关键字
是否为空
数据含义
ID
Varchar
10
是
否
编号
Content
Varchar
100
否
否
内容
Cname
Varchar
16
否
否
投诉人
Bname
varchar
16
否
否
被投诉人
表3.2.4-2游客
数据项名称
数据类型
数据长度
是否关键字
是否为空
数据含义
Uname
Varchar
20
是
否
用户名
Upassword
Varchar
6
是
否
密码
Phone
int
11
否
否
联络方法
Address
varchar
16
否
否
联络地址
表3.2.4-3管理员
数据项名称
数据类型
数据长度
是否关键字
是否为空
数据含义
Aname
Varchar
20
是
否
用户名
Apassword
Varchar
6
是
否
密码
Indication
Varchar
10
否
否
管理员标识（审核员或受理员）

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次用户登录失败后将对系统进行锁定，等候管理员权限进行解锁。