《在线智能客服系统》详细需求文档.docx

《在线智能客服系统》详细需求文档.docx

《《在线智能客服系统》详细需求文档.docx》由会员分享，可在线阅读，更多相关《《在线智能客服系统》详细需求文档.docx（68页珍藏版）》请在冰豆网上搜索。

《在线智能客服系统》详细需求文档

《在线智能客服系统》需求文档

第一章前言2

1.1编写目的2

1.2开发背景2

1.3定义3

1.4参考资料3

第二章总体设计3

2.1系统设计环境3

2.2基本设计概念和处理流程3

2.3系统结构5

2.4总体功能设计.......................................................................................................................5

2.4.1用户模块功能设计介绍................................................................................................6

2.4.2后台客服管理介绍......................................................................................................6

2.4.3后台管理介绍...............................................................................................................6

2.4.4智能交流平台介绍......................................................................................................6

2.5系统总体用例分析............................................................................................................7第三章数据库设计.................................................................................................................7

3.1外部设计...............................................................................................................................7

3.1.1环境说明......................................................................................................................7

3.1.2指导.......................................................................................................................7

3.2数据库需求分析...................................................................................................................7

3.3数据库逻辑设计...................................................................................................................8

3.3.1数据实体--关系图........................................................................................................8

3.3.2数据实体描述..............................................................................................................9

3.4物理实现.............................................................................................................................11

3.4.1物理结构....................................................................................................................11

3.4.2安全设计....................................................................................................................11

3.5表结构设计.........................................................................................................................12

3.6视图设计.............................................................................................................................13

3.7数据库账号及权限说明......................................................................................................14

第四章模块功能需求15

4.1用户模块15

4.2智能回复平台17

4.3后台客服管理18

4.4后台管理员模块19

第五章功能详细设计21

5.1系统详细设计概述

5.2系统功能详细设计

第六章非功能性需求21

5.1性能需求23

5.2安全性需求24

5.3可用性需求…..............................................................25

5.4其他需求….................................................................26

第一章前言

1.1编写目的

本节描述软件产品需求规格说明书（SRS）的目的是：

定义软件总体要求，为用户和软件开发人员之间相互了解的基础；提供性能要求、初步设计和对用户影响的信息，作为软件人员进行软件结构设计和编码的基础；作为软件总体测试的依据。

1.2开发背景

在如今这个商业的年代，互联网是不可缺少的东西，互联网为广大用户提供了一个交流的平台。

在许多商业型网站中都有着聊天交互平台，为了方便用户和客服，该系统提供了一个智能的聊天平台。

在该平台中，用户可以和智能聊天平台进行简单问题的交流，在处理一些用户简单问题基础上，智能聊天平台一方面可以让用户了解大体的问题所在，另一方面就是，在用户与智能平台交流中，可以减轻客服的压力，为后台客服争取更多的时间。

譬如大型商业网站淘宝，在此系统中，智能平台可以帮助后台客服解决大部分基础的，简单的问题，这就让后台客服的工作负担不太沉重。

若没有该智能系统，后台客服将要对用户的每一个问题进行作答，哪怕是一句简单的回答也必须得认为来处理。

因此，该系统的开发是有必要的，系统适用的范围广，解决问题的能力大，减少人力的消耗。

系统应用目标：

适用于交流型网站，例如，淘宝，京东，移动，电信信息处理平台等有着交流性平台的系统。

系统使用范围：

公众

1.3定义

Workflow：

工作流

1.4参考资料

无

第二章总体设计

2.1系统设计环境

系统环境设计如下图2.1-1

环境选项

使用工具

操作系统

Windows7

Java开发环境

Java1.8

开发使用工具

Eclipse

开发使用数据库

Mysql

开发使用框架

Spring，struts，hirbenate

服务器

Tomcat8.0

图2.1-1

2.2基本设计概念和处理流程

在该系统中，系统所面对的是广大校园学生用户，用户在校园网使用中经常会碰到一系列的问题，为了方便学校解决问题，为用户提供一个好的解决方案，此系统通过智能平台帮助用户解决简单问题，也减轻后台客服管理的压力。

智能平台主要是处理用户的一些简单提问。

简单的说就是根据用户的提问，智能平台可以通过数据库匹对对用户提问语进行关键字处理，并反馈给用户相应的答复。

在智能平台无法处理用户需求时，智能平台将会将信息交给网站客服进行解决。

这样一来，该系统就大大减轻了网站客服的压力，让他们有更多的时间处理其他事物。

具体处理流程如图2.2-1

图2.2-1

2.3系统结构

该系统采用B/S结构，适用于在网页端进行在线交流。

2.4总体功能设计

该系统主要功能模块划分为四个大的模块：

①用户模块，②后台客服管理模块，③后台管理员模块，④智能交流平台模块。

该系统由以上四个模块组成，完成系统所相应的功能。

其功能总体设计如图：

2.4-1

系统功能模块

功能描述

用户模块

用户注册，用户登录功能，用户提问功能以及用户留言功能，查看基本信息，修改基本信息

后台客服管理模块

后台客服登录，信息回复功能，用户信息查看功能，以及添加关键字和回复语功能

后台管理员模块

后台管理员登录，用户信息管理，后台客服信息管理，以及后台客服状态审核功能，查看在线人数功能，留言管理

智能交流平台模块

用户信息自动回复功能，会话交付功能

图2.4-1

2.4.1用户模块功能设计介绍

用户模块主要包括用户的登录，注册，提问功能，和留言功能。

其中用户注册时最基本操作，用户没有注册也就没有登录账号，没有之后的操作。

用户登录是其次操作，用户在没有登录的情况下无法进入聊天页面，也无法进行留言，对其系统服务进行评价。

2.4.2后台客服管理介绍

后台客服管理模块中包含着该系统中一个重要功能，即后台客服回复的功能.另外，在该模块中功能还包括后台客服登录功能，后台客服查看用户信息功能，以及添加关键字信息功能。

后台客服通过以上功能对用户的一些困难作答，解决用户困难。

在以上功能中，最基本操作就是后台客服的登录功能，后台客服没有进行登录的情况下，无法进行其他操作。

2.4.3后台管理介绍

后台管理功能在本系统中担当的后台信息管理功能，其中大体功能包括：

用户信息的管理，客服管理员的管理，以及留言板的管理。

其中最基本步骤登录是无法减少的，后台管理员在未登录的情况下无法对上述功能进行操作。

另外，对客服信息的管理也包括对客服的审核功能，客服在未经后台管理员资格审核时，后台客服管理员将是无法登录，无法就行相应操作。

2.4.4智能交流平台介绍

智能交流平台是一个中间处理功能，该模块基本功能，即核心功能就是对用户的提问进行智能回复，无需后台客服进行管理，对用户相应提问给出相应的作答。

当然，智能平台也只是一个中间平台，不能解决用户的全部困难。

这时，智能平台会将相应的会话交给空闲的后台客服，将平台不能作答的问题交给客服，让客服进行处理。

2.5系统总体用例分析

系统总体用例可分为四大类，其分别为：

一般用户用例、后台客服管理员用例、系统管理员用例以及智能平台用例。

各用例大致功能划分如下：

1一般用户：

用户注册、用户登录、用户信息管理、留言管理。

2后台客服：

登录、信息回复、用户信息查看、关键字添加、回复语添加。

3系统管理员：

登录、用户信息管理、客服信息管理、留言板管理。

4智能平台：

信息自动回复、会话交付。

一般用户用例图如下图：

2.4.5-1

图2.4.5-1

后台客服用例图如下：

2.4.5-2

图2.4.5-2

系统管理员用例图如下：

2.4.5-3

图2.4.5-3

智能平台用例图如下：

2.4.5-4

图2.4.5-4

第三章数据库设计

3.1外部设计

3.1.1环境说明

本系统采用64位MySQL数据库进行设计，运行期间首先要开启MySQL数据服务，然后打开SQLyog10.2数据库。

在数据库配置中，采用Windows764bits的操作系统，8G运行内存。

3.1.2指导

在系统开发中，若想要系统成功的部署，首先需要打开MySQL数据库服务，才能够将系统部署到tomcat服务器上，因为该系统采用SSH开发，采用面向对象查询，设计基础类需要与数据库相对应，将需要生产表的类进行映射，在数据库中生产相应的数据库表。

3.2数据库需求分析

数据库结构设计的第一个阶段也是非常重要的一个阶段是数据库需求分析。

在这个阶段主要是收集基本数据以及数据处理的流程为以后进一步设计打下基础。

需求分析主要解决两个问题：

①内容要求②处理要求

①内容要求：

调查应用系统用户所需要操作的数据决定在数据库中存储什么数据。

②处理要求：

调查应用系统用户要求对数据进行什么样的处理，理清数据库中各种数据之间的关系。

解决这两个问题的时候程序编制人员需要向应用系统用户详细调查保证信息收集的完整性。

否则有可能后面所有的工作都白费。

在数据库需求分析后应该得到一个数据字典文档包括3方面内容：

①数据项②数据结构③数据流

①数据项：

包括名称、含义、类型、取值范围、长度以及和其他数据项之间的逻辑关系。

②数据结构：

若干个数据项的有意义的集合包括名称、含义以及组成数据结构的数据项。

③数据流：

指数据库中数据的处理过程包括输入、处理和输出。

这个数据字典在程序的开发过程中会不断发生变化。

对于一个大型的软件开发过程一般都需要一份详尽的数据字典。

针对本系统，通过对整个系统功能和过程分析，设计的数据项和数据结构如下。

用户基本情况包括的数据项有：

用户名、姓名、密码、所在宿舍、联系电话等

客服信息：

用户名、密码、状态等

后台管理员：

用户名、密码。

关键字信息：

关键字段、回复语。

留言信息：

留言内容、用户名。

会话表信息：

用户名、会话内容、客服名称等。

有了上面的数据结构和数据项基础我们就能进行下面的数据库设计了。

3.3数据库逻辑设计

逻辑结构设计的任务：

将概念结构进一步转化为能够用某一DBMS实现永续需求的相应的数据模型。

逻辑结构设计的步骤：

①将概念结构转化为一般的关系、网状、层次模型②将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转化③对数据模型进行优化。

3.3.1数据实体--关系图

这一设计阶段是在需求分析的基础上设计出能够满足用户需求的各种实体以及它们之间的关系，为后面的逻辑结构设计打下基础。

这个阶段不用考虑所采用的数据库管理系统、操作系统类型、机器类型等问题。

这阶段可用的工具很多。

用的最多的是E-R图（Entity-Relation实体-关系图），另外还有许多计算机辅助工具ComputerAidedSoftwareEngineeringCASE可以帮助进行设计。

E-R图是描述数据实体及其关系的一种直观的描述工具。

这种图中有：

①实体②属性③关系

①实体：

用方框表示方框内为实体的名称。

②实体的各种属性：

用椭圆表示椭圆内为属性名称，使用线段将其和相应的

实体连接起来。

③实体之间的联系：

用菱形表示菱形内为联系的名称。

实体和实体之间的联系较多，比较常见的联系有1:

1、1:

n和m:

n这3种。

1:

1关系:

对于实体A构成的集合中，每个实体在实体集合B中至多只有一个实

体与之相对应，反之亦然，称实体集合A和实体集合B之间是1:

1的关系。

1:

n关系:

对于实体A构成的集合中每个实体，在实体集合B中有n（n>0）个实体

与之相对应，且对于实体集合B中的每个实体，在A中最多只有一个实体与之相对应，称实体集合A和实体集合B之间是1:

n关系。

m:

n关系:

对于实体A构成的集合中的每个实体，在实体集合B中有n（n>0）个实体与之相对应，且对于实体集合B中的每个实体，在A中有m个实体与之相对应，称实体集合A和实体集合B之间是m:

n关系。

以下是该系统中涉及的实体E-R图，以及各个实体之间的关系：

用户实体描述：

用户信息主要包括用户名，密码，姓名，所在宿舍以及联系电话等字段，其每一条信息与数据库相对应，便于用户在系统中能够更加方便，简介地解决问题。

用户基本信息E-R图如图3.3.1-1

图3.3.1-1

后台客服实体信息:

后台客服信息包括用户名，密码，以及客服状态。

后台客服信息E-R图如图3.3.1-2

图3.3.1-2

系统管理员实体：

系统管理员信息包括用户名和密码。

只是为了方便管理员登录系统进行管理。

系统管理员E-R图如图3.3.1-3

图3.3.1-3

系统关键字信息：

系统关键字信息主要包括关键字字段以及与之对应的回复语信息。

系统关键字信息E-R图如图3.3.1-4

图3.3.1-4

留言板信息：

留言板信息包括用户的留言信息以及与之相关联的用户名。

留言信息实体图如图3.3.1-5

图3.3.1-5

会话表信息：

会话表中包含的主要字段就是对话信息，其中还包括用户名字段和客服名称字段。

会话信息实体E-R图如图3.3.1-6

图3.3.1-6

在整个系统中，各个实体之间存在一定的关系，每个实体可能又与多个实体之间存在不同的关系。

对于用户来说，用户与留言信息之间存在一定的关系，一个用户可以与多条留言信息相对应，所以用户与留言信息存在1：

n的关系。

另外，用户需要将其会话内容存入到会话信息表中，一个用户与该表中多条信息相对应，因此，用户还与会话信息表存在1：

n的关系。

用户与其他实体之间的关系E-R图如图3.3.1-7所示

图3.3.1-7

另外，在该系统中，后台客服需要与用户进行对话。

因此，在会话信息表中，客服名将会被添入。

客服在与用户交谈中，一个客服同样需要进行多条回复。

因此，客服与会话信息表存在1：

n的关系。

客服与其他实体之间的关系E-R图如图3.3.1-8所示

图3.3.1-8

3.3.2数据实体描述

在本系统中，包含的实体对象有用户实体，后台客服实体，系统管理员实体，关键字信息实体，会话信息实体，以及留言板实体。

其对应数据库中字段名如下：

用户实体：

用户名，密码，姓名，宿舍地址，联系电话

UserInfo（username，password，name，address，phone）。

后台客服实体：

用户名，密码以及客服状态

CustomerService（C_name，C_password，C_status）

系统管理员实体：

用户名，密码

SystemAdmin（S_name，S_password）

关键字信息实体：

主键Id，关键字字段，回复语

Keyword（K_id，K_word，K_reply）

留言板信息实体：

主键Id，用户名，留言信息

Massage（M_id，username，M_massage）

会话信息实体：

主键Id，用户名，后台客服名，会话内容

Talking（T_id，username，C_name，T_content）

3.4物理设计

物理设计的任务是根据具体计算机系统的特点,为给定的数据模型确定合理的存储结构和存取方法.所谓的“合理”主要有两个含义：

一个是要使设计出的物理数据库占用较少的存储空间,另一个对数据库的操作具有尽可能高的速度.

3.4.1物理结构

在该系统中，数据库服务器设计一个数据库，一个数据库中包含所有数据库中所需要的表。

在该数据库中各表的表名为：

用户表（tb_user），后台客服表（tb_customerService）,系统管理员表（tb_systemAdmin），关键字信息表（tb_keyWord）,留言板信息表（tb_massage），以及会话信息表（tb_talking）。

这些表都被存储在同以数据库中，以供系统使用。

3.4.2安全设计

对于系统中的每一中用户，数据库都有相应的操作权限。

譬如，对于一般用户来说，用户只可以在系统中访问到数据库，不能通过其它途径对数据库进行访问。

用户在整个系统中只能够访问到有关于该用户的基本信息，不能访问到其它使用者的信息。

对于后台客服用户，客服通过自身登录后，客服可以在后台进行数据库访问，可以访问到相应用户的信息，并对相应的用户进行操作。

但是客服不能直接在数据库服务器上进行登录访问信息，此操作仅限于系统管理员。

在整个系统中，访问权限最高的就是系统管理员了，系统管理员不仅可以访问到用户的基本信息，可以访问到用户的留言信息，系统管理员还可以对客服信息进行访问，查看客服的一些相关信息。

另外，系统管理员可以直接登录到数据库服务器中，对相关内容进行操作。

3.5表结构设计

在本系统中，所涉及的表有六个，其分别为：

用户表，后台客服表，系统管理员表，关键字信息表，留言板信息表，会话信息表。

其结构设计如下：

用户信息表如下图3.5-1所示

数据库名

database

表名

Tb_user

列名

数据类型

是否为空

是否唯一

是否为主键

外键

数据长度

username

varchar

否

是

是

无

20

password

varchar

否

否

否

20

name

varchar

否

否

否

10

address

varchar

否

否

否

50

phone

varchar

否

是

否

20

图3.5-1

后台客服信息表如下图3.5-2所示

数据库名

database

表名

Tb_customerService

列名

数据类型

是否为空

是否唯一

是否为主键

外键

数据长度

C_name

var