火车站网上售票系统需求分析

需求分析书

20122013班张佳俊组

组员何益超李轶孙忠奇张志轩

1导言

1.1目的

该文档是关于用户对于火车票网上售票系统的功能和性能的要求，重点描述了火车票网上售票系统的设计需求，将作为对该工具在概要设计阶段的设计输入。。

本文档的预期读者是：

●设计人员

●开发人员

●项目管理人员

●测试人员

●用户

1.2范围

该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决整个项目系统的“做什么”的问题。在这里，对于开发技术并没有涉及，而主要是通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。

1.3缩写说明

无

1.4术语定义

无

1.5引用标准

[1] 《企业文档格式标准》 V1.1

[2] 《需求规格报告格式标准》 V1.1

1.6参考资料

[1] 《实用软件工程（第三版）》

[2] 《需求规格报告格式标准》 V1.1

2系统定义

我们分别阐述一下项目的来源、背景和项目的目标。

2.1项目来源及背景

随着科学技术的发展，计算机领域不断取得日新月异的研究成果。计算机在代替和延伸脑力劳动方面发挥越来越重要的作用，在日常生活中随处都离不开离不开计算机。尤其是在交通发达的今天，要管理大量的车票销售，计算机优势更加体现出来。在数字化的今天，为了加强火车售票的管理必须依靠计算机，使火车售票员更好的对游客的管理更加有序、到位，基于上述种种原因，开发火车站售票系统更加显得重要，我们结合本次课程设计开发以下的火车站售票系统方案。

本系统主要为了更好地实现火车售票管理，给火车售票员提供一个井然有序的管理平台, 防止手工管理混乱，避免一些人为的错误。提供一个良好的售票环境，更好的完成售票。同时也对旅客提供一个查询客运情况。

2.2项目要达到的目标

本项目设定的目标如下：

1.系统能够提供友好的用户界面，使操作人员的工作量最大限度的减少

2.系统具有良好的运行效率，能够得到提高生产率的目的

3.系统应有良好的可扩充性，可以容易的加入其它系统的应用。

4.平台的设计具有一定的超前性，灵活性，能够适应企业生产配置的变化。

5.通过这个项目可以锻炼队伍，提高团队的开发能力和项目管理能力

2.3系统整体结构

本系统主要为了更好地实现火车售票管理，给火车售票员提供一个井然有序的管理平台,

防止手工管理混乱，避免一些人为的错误。提供一个良好的售票环境，更好的完成售票。同

时也对旅客提供一个查询客运情况。

通过对火车站售票的情况的了解：一个火车站售票系统应该包括：售票功能，查询功能，调度功能，维护功能，统计功能等模块，在本系统中增设了用户登录模块以确保信息安全，考虑到旅客需要自主客运情况，增设了无需登录只提供查询列车时刻表，售票情况等信息模块。

整个系统模块划分如下图：

3 应用环境

本项目的应用环境可以分硬件环境、软件环境和网络环境来描述。

本系统的网络运行图如图A-2，无论是客户端的应聘者还是管理端的HR 等都可以通过网络登录到本系统中。应聘者通过网络提交简历等相关信息，HR 通过网络发布职位信息，获得应聘者提供的简历信息，进行面试管理。

火车站售票系统

维护功能模块

售票功能模块

登录功能模块

调度功能模块

统计功能模块

查询功能模块

退出功能模块

3.1系统运行硬件环境

本系统的硬件环境如下：

●客户机：普通PC

?CPU：P4 1.8GHz

?内存：256MB以上

?分辨率：推荐使用1024*768像素

●WEB服务器

?CPU：P4 1.8GHz

?内存：256MB以上

●数据库服务器

?CPU：P4 1.8GHz

?内存：256MB以上

3.2系统运行软件环境

●操作系统：Microsoft Windows 7

●数据库：Microsoft Access 2013

●开发工具包：Microsoft visual studio 2005

4功能规格

我们采用面向对象分析作为主要的系统建模方法，使用UML(Unified Modeling Language)作为建模语言。UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。在UML中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映像。

Use Case描述的是“actor”(用户、外部系统以及系统处理)是如何与系统交互来完成工作的。Use Case模型提供了一个非常重要的方式来界定系统边界以及定义系统功能，同时，该模型将来可以派生出动态对象模型。

设计Use-case时，我们遵循下列步骤：

第一步，识别出系统的“actor”。Actor可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。重要的是着重从系统外部执行者的角度来描述系统需要

提供哪些功能，并指明这些功能的执行者(Actor)是谁。尽可能地确保所有Actor

都被完全识别出来。

第二步，描述主要的Use Case。可以采取不断地问自己“这个Actor究竟想通过

系统做什么？”来准确地描述Use Case。

第三步，重新审视每个Use Case，为它们下个详尽的定义。

4.2角色（Actor）定义

角色或者执行者（Actor）指与系统产生交互的外部用户或者外部系统。

4.2.1 旅客

旅客是指在这个火车票售票系统中通过客户端购买火车票的人员，这个Actor主要参与客户端的订票系统、退票系统、查询系统等功能。

4.2.2 售票员

售票员是指具体销售车票系统管理人员，这个Actor主要参与服务器端的售票员登录、售票系统管理、退票系统管理、查询系统管理、录入信息系统管理等功能。

4.2.3 站长

站长是指对售票员进行管理的的人员。

角色之间的关系：

图A-3：角色的关系图

4.2.4 E-R图

整个系统开发过程中，主要涉及到的实体有：站长，售票员，旅客，火车票。他们之间的关系是：

4.2.5 数据库

数据库是一个与系统产生交互的外部系统，这个Actor 负责系统的数据查询、增加、删

除和修改等操作。

4.3 系统主Use Case 图

火车票订票系统可以分为两个主要的组成部分，一个是客户端子系统，一个是管理端子系统。客户端子系统主要是指旅客通过登录售票网站进行操作的功能，即查询、订票、退票功能。管理端子系统是火车站售票的管理人员发布火车票信息，整理订票信息，退票信息，查询等功能。系统的主Use Case 图如图A-4所示。

M

站长

姓名

工号

所处车站

密码

管理

售票员

销售

火车票

N

N

M

N

火车票编号

价格

类型

车次

终点站

所处车厢

查询，购买，退票

旅客

N

工号

姓名

密码

修改车票表 修改退票表

图A-4：系统的主Use Case图

4.4客户端子系统

旅客通过火车站的售票网站登录到系统中进行查询、订票和退票，旅客通过它提交订单，进行订票，这就是客户端子系统的功能。在客户端用户可以看到火车票的相关信息。当点击车次时进入车次详细信息页面，如果需要订票的话，可以填写订单信息，并提交订

单。它的活动图如图A-5所示。

客户端的功能主要包括查询车次、填写订单、提交订单、查询个人订单等功能，它的用例图如图A-6。

图A-6：客户端的功能用例图

客户端管理的功能描述如下：

F-C-1：车票查询

旅客登录到售票网站可以看到火车车次列表，在车次列表中显火车车次始发站和终点站信息。当点击车次时进入车次详细信息页面，车次详细页面显示车次名称，车次所经车站列表，车次座位信息，点击订购该车次进入填写基本信息页面。

F-C-2：填写并提交订单

有个人基本信息、车次信息、座位类型、起始站—终点站信息等。

F-C-3：查询订单

查询个人订单是否与自己所填相符合，有个人基本信息、车次信息、座位类型、起始站—终点站信息等。

4.4.1车票查询

车票查询是显示目前正在出售的所有车次，以及每个车次的描述和相关信息等。具体描

述如下：

用例描述：火车售票车次选择

执行者：旅客

前置条件：旅客已登录系统；

后置条件：选择车次后，则可以填写订单；

基本路径：

a)旅客登录到车站的售票网页，显示目前的车次列表，发布的日期，销售车票数等；

b)点击任何一个车次可以浏览每个车次的详细信息，包括车次描述、起始/终点站、销售

车票数、车票类型等信息；

c)如果对该车次满意，可以点击订购车票进入填写订单信息页面，开始填写订单和提交订

单等环节。

4.4.2 订单录入

如果旅客满意某个车次，就开始录入订单，订单从旅客的基本信息开始，然后起始站、终点站、车票类型、乘车人数等内容，最后开始提交订单。具体描述如下：

用例描述：订单输入

执行者：旅客

前置条件：旅客已选择订票车次；

后置条件：订单输入后，则可以提交订单

基本路径：

a)基本信息输入，包括姓名、性别、年龄、证件类型、证件号码、社会角色等信息

b)本次乘车信息输入，包括乘车起始站、终点站、乘车人数等；

4.4.3 订单查询

订单查询要求旅客已提交订单。具体功能描述如下：

用例描述：订单查询

执行者：旅客

前置条件：旅客已提交订单；

后置条件：查询订单，确认订单是否提交成功。

基本路径：

a)提交订单；

b)查询订单；

c)核对信息。

4.5管理端子系统

管理端主要是指提供售票员使用的功能部分，它的功能分为车票信息录入和发布、售票管理、退票管理、查询管理等部分，每个登录者首先经过认真安全认证然后缺陷权限，根据相应的权限现实相应的功能。

管理端的这些Use case （用例）描述如下：

F-L-1：登录管理

登录管理是负责所有的管理端的登录，管理端的人员要登录到管理端必须经过登录界面，输入自己的用户名和密码，通过判断这个用户的权限信息，不同的登录人可能具有不同的权限，根据不同的权限现实不同的功能。

F-M-1车票信息录入和发布管理：

车票信息录入和发布管理用例是管理员登录到系统，对车次车票的增、删、改的功能，及提供车次的详细信息。

F-M-2售票管理：

售票管理用例是管理员登录到系统，管理员根据车票信息中提取出来生成各种车次车票信息，并且可以对车票信息进行增、删、改的功能。

图A-7：管理端用例图

F-M-3退票管理：

退票管理用例是管理员登录到系统，录入车次及车票的订单详细描述信息，同时也可对售票管理进行增、删、改的功能。

F-M-4查询管理：

查询管理用例是售票管理人员对旅客发来的订单进行整理，并根据订单的数目信息，合理安排车次座位，同时对浏览订单的基本信息，最后确定可以确定每个旅客的座位信息，这样将所有的旅客分为订票成功、订票失败等两个状态。

4.5.1 登录管理

登录到管理端的所有人都需要通过登录界面进入相应的管理界面，不同的登录人具有不同的权限，根据登录人具有的权限将相应的功能现实在登录到的管理界面，没有权限操作的功能将在现实在这个界面上。活动视图如图A-8。

图A-8：登录管理活动视图

4.5.2 车票信息录入和发布管理

在网上售票系统中，有一套车票信息库，是由大量的车票信息组成，它是车票售票的基本组成。车票信息录入和发布管理模块主要是完成每个车票的增、删、改、查等维护功能。具体描述如下：

用例描述：车票信息录入和发布管理

执行者：售票员

前置条件：售票员已登录系统；

后置条件：如果车票信息录入和发布管理维护成功后，则数据库中的车票信息库随之变化，可以组织车票信息

基本路径：

a)进入车票信息录入和发布管理界面，首先展示目前车票信息库已有的车票信息；

b)点击每个车票信息可以详细浏览这个车票的具体内容，同时也可以对这个车票的具体内

容进行修改；

c)提供增加车票信息的按钮，增加车票信息时，首先选择车票类别，然后车票车次、车票

具体信息、确定可选人数（多个）等；

d)可以删除选择的车票。

4.5.3 售票管理

售票管理是网上售票系统的主要功能之一，管理人员根据车票信息，定期发布更新车票信息，详细描述这个车票的情况，每个车票都附有一套信息，需要旅客选择，车票是更具车次决定的，车票信息发布后，旅客通过网络可以看到车票详情，并可以订票，具体功能描述如下：

用例描述：售票管理

执行者：售票员

前置条件：售票员已登录系统；

后置条件：如果售票管理成功后，则数据库中的车票随售票信息变化，旅客可以通过网络看到新的车票详情。

基本路径：

a)进入售票管理界面，首先展示目前正在销售的所有车票信息；

b)通过点击每个车次，可以详细浏览每个车次详细描述；

c)可以对每个车次信息进行修改

d)提供车票条件查询

e)提供车票删除

4.5.4 退票管理

对提出退票请求的旅客订单进行取消，并释放该车票，以便其他旅客订购，并通知该旅客退票成功。具体描述如下：

用例描述：退票管理

执行者：售票员

前置条件：售票员已登录系统；

后置条件：如果退票处理成功后，则车票的结果记录到数据库中。 基本路径：

a) 进入退票管理界面，显示目前的退票请求订单列表，提供查询功能； b) 点击某个旅客进入与这个旅客相应的订单详细页面； c) 将请求退票订单取消并释放车票，

d) 将释放收的车票信息录入相对于地信息库，方便其他旅客订购。

4.5.5 查询管理

旅客将订单提交之后，售票人员开始整理订单，将满足一定要求的旅客作为提交成功的被选对象，然后通过浏览其订单情况，确定可以乘坐的人员，对订票成功的人员通过电话、邮件等方式通知乘车时间，并发布网上，以便旅客查询。具体的功能描述如下： 用例描述：订单管理 执行者：售票员

前置条件：售票员已登录系统；

后置条件：订单整理完成后，则可以将旅客分为几个类别，以便为乘车取票做好准备。 基本路径：

a) 进入订单管理界面，首先展示目前的订单对应的车次列表，提供查询功能； b) 通过点击车次列表进入相应的这个车次的所有订单列表的界面；这个界面也显示了每个

旅客的名字、年龄、性别、车票信息等信息；

c) 订单列表中，通过点击一个旅客可以显示这个旅客的订单信息，这个旅客的订单详情，

可以打印订单；

d) 对订单有两种种处理结果：订票成功、订票失败；

e) 对订单的处理结果，可以采用电子邮件、电话和信件等方式通知旅客，如果采用电子邮

件通知应聘者，系统提供一个模板。

5 系统数据流图

5.1售票员数据流图

1．售票员登陆系统： （1）数据流图

售票员

身份验证

登陆系统选择

检验错误

用户名密码

密码正确

售票

退票

查询

录入新的班次

信息

选择

选择

选择

选择

授权信息表售票员信息

（2）数据词典

●数据源点及汇点描述：

①名称：售票员

简要描述：管理售票员信息

有关数据流：用户名、密码、系统选择：售票系统、退票系统、查询系统、录入信息系统

数目：1

●加工逻辑词条描述：

①加工名：身份检验

加工编号：１

简要描述：检验用户身份

输入数据流：用户名、密码

输出数据流：密码正确、身份验证错误

加工逻辑：IF 用户名为空THEN

发出“用户名为空错误”

ELSE IF 密码为空THEN

发出“密码为空错误”

ELSE IF 用户名和密码不符THEN

发出“用户名和密码不匹配错误”

ENDIF

ENDIF

ENDIF

ENDIF

●数据流名词条描述：

①数据流名：用户名

说明：售票员姓名

数据流来源：售票员

数据流去向：身份检验

数据流组成：用户名=字符型字符串

②数据流名：密码

说明：与用户名相匹配的密码

数据流来源：售票员

数据流去向：身份检验

数据流组成：密码=短整型字符串

每个数据量流通量：

③数据流名：出错信息

说明：用于指示身份验证错误的信息

数据流来源：身份检验

数据流去向：售票员

数据流组成：出错信息＝任意字符串

④数据流名：系统名称

说明：系统的名称

数据流来源：

数据流去向：选择

数据流组成：

● 数据文件词条描述：

① 数据文件名：授权信息表

简述：存放售票员信息 输入数据：

输出数据：售票员信息

数据文件组成：授权信息表由“售票员信息”组成

2．售票员相关操作（售票、退票、查询、录入）

售票员

身份验证

登陆系统选择

检验错误

用户名密码

密码正确

售票退票

查询

录入新的班次

信息

选择

选择

选择

选择

授权信息表售票员信息

票务信息表

车票信息

车票信息

列车信息表

车票信息

车票信息

(2):数据词典：

● 数据源点及汇点描述：

○

1 名称：售票员 简要描述：管理售票员信息

有关数据流：用户名、密码 数目：1

● 加工逻辑词条描述： ○

1加工名：身份检验 加工编号：１

简要描述：检验用户身份 输入数据流：用户名、密码

输出数据流：密码正确、身份验证错误 ○

2加工名：售票 加工编号：2

简要描述：根据所读入的操作信息，售出火车票

输入数据流：操作信息，火车票信息

输出数据流：火车票信息

加工逻辑：根据所读入的操作信息，售出火车票

●数据流名词条描述：

○1数据流名：用户名

说明：售票员的姓名

数据流来源：售票员

数据流去向：身份检验

数据流组成：用户名=字符型字符串

○2数据流名：密码

说明：与职工名称相匹配的密码

数据流来源：售票员

数据流去向：身份检验

数据流组成：密码=短整型字符串

每个数据量流通量：

○3数据流名：车票信息

说明：车票信息

数据流来源：售票员

数据流去向：列车信息表

●数据文件词条描述：

①数据文件名：列车信息表

简述：车票信息

输入数据：车票信息

输出数据：

数据文件组成：列车信息表由“车票信息”组成

存储方式：关键码

存取频率：频繁

○2数据文件名：票务信息表

简述：票务信息

输入数据：票务信息

输出数据：

数据文件组成：票务信息表由“列车号、已售票、剩余票”组成

存储方式：关键码

存取频率：频繁

5.2旅客数据流图

（1）数据流图

旅客

登录系统选择

选择

选择

选择

订票退票查询

(2)数据词典：

●数据源点及汇点描述：

名称：旅客

简要描述：订票，退票，查询

有关数据流：系统选择：订票系统、退票系统、查询系统

●数据流名词条描述：

⑤数据流名：系统名称

说明：系统的名称

数据流来源：

数据流去向：选择

数据流组成：

6性能需求

根据用户对本系统的要求，确定系统在响应时间、可靠性、安全等方面有较高的性能要求。

6.2界面需求

系统的界面要求如下：

１）页面内容：主题突出，站点定义、术语和行文格式统一、规范、明确，栏目、菜单设置和布局合理，传递的信息准确、及时。内容丰富，文字准确，语句通顺；专用术语规范，行文格式统一规范。

２）导航结构：页面具有明确的导航指示，且便于理解，方便用户使用。

３）技术环境：页面大小适当，能用各种常用浏览器以不同分辨率浏览；无错误链接和空链

接；采用CSS处理，控制字体大小和版面布局。

４）艺术风格：界面、版面形象清新悦目、布局合理,字号大小适宜、字体选择合理，前后一致，美观大方；动与静搭配恰当,动静效果好；色彩和谐自然,与主题内容相协调。

6.3响应时间需求

无论是客户端和管理端，当用户登录，进行任何操作的时候，系统应该及时的进行反应，反应的时间在5秒以内。系统应能监测出各种非正常情况，如与设备的通信中断，无法连接数据库服务器等，避免出现长时间等待甚至无响应。

6.4可靠性需求

系统应保证7X24内不当机，保证20人可以同时在客户端登录，系统正常运行，正确提示相关内容。

6.5开放性需求

系统应具有十分的灵活性，以适应将来功能扩展的需求。

6.6可扩展性需求

系统设计要求能够体现扩展性要求，以适应将来功能扩展的需求。

6.7系统安全性需求

系统有严格的权限管理功能，各功能模块需有相应的权限方能进入。系统需能够防止各类误操作可能造成的数据丢失，破坏。防止用户非法获取网页以及内容。

7产品提交

提交产品为：

a)应用系统软件包

b)数据库初始数据

c)系统开发过程文档

d)系统使用维护说明文档

提交方式：CD介质

8实现约束

系统的实现约束如下：

a)操作系统为Microsoft tWindows 7

b)开发平台为：Microsoft visual studio 2005

c)数据库为 : Microsoft Access 2013