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

20122013班 何益超 组 软件工程 火车票售票系统 需求分析

需求分析书
20122013班 张佳俊组
组员 何益超 李轶 孙忠奇 张志轩
1 导言
1.1 目的
该文档是关于用户对于火车票网上售票系统的功能和性能的要求,重点描述了火车票网上售票系统的设计需求，将作为对该工具在概要设计阶段的设计输入。。
本文档的预期读者是:
l 设计人员
l 开发人员
l 项目管理人员
l 测试人员
l 用户
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系统运行硬件环境
本系统的硬件环境如下：
l 客户机：普通PC
n CPU：P4 1.8GHz
n 内存：256MB以上
n 分辨率：推荐使用1024*768像素
l WEB服务器
n CPU：P4 1.8GHz
n 内存:256MB以上
l 数据库服务器
n CPU：P4 1.8GHz
n 内存：256MB以上
3.2 系统运行软件环境
l 操作系统：Microsoft Windows 7
l 数据库：Microsoft Access 2013
l 开发工具包: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图
整个系统开发过程中,主要涉及到的实体有:站长，售票员，旅客,火车票。他们之间的关系是:
M

站长
姓名
工号
所处车站
密码
管理
售票员
销售
火车票
N

N

M

N

火车票编号
价格
类型
车次
终点站
所处车厢
查询，购买，退票
旅客
N

工号
姓名
密码
修改车票表
修改退票表

4.2.5 数据库
数据库是一个与系统产生交互的外部系统,这个Actor负责系统的数据查询、增加、删除和修改等操作。
4.3 系统主Use Case图
火车票订票系统可以分为两个主要的组成部分,一个是客户端子系统，一个是管理端子系统。客户端子系统主要是指旅客通过登录售票网站进行操作的功能，即查询、订票、退票功能.管理端子系统是火车站售票的管理人员发布火车票信息，整理订票信息，退票信息，查询等功能.系统的主Use Case图如图A—4所示。
图A-4：系统的主Use Case图

4.4 客户端子系统
旅客通过火车站的售票网站登录到系统中进行查询、订票和退票，旅客通过它提交订单，进行订票,这就是客户端子系统的功能.在客户端用户可以看到火车票的相关信息。当点击车次时进入车次详细信息页面，如果需要订票的话，可以填写订单信息，并提交订单。它的活动图如图A—5所示。
图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 管理端子系统
管理端主要是指提供售票员使用的功能部分，它的功能分为车票信息录入和发布、售票管理、退票管理、查询管理等部分，每个登录者首先经过认真安全认证然后缺陷权限，根据相应的权限现实相应的功能。
图A-7：管理端用例图

管理端的这些Use case（用例）描述如下:
F-L—1：登录管理

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

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

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

F—M—2售票管理：

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

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)数据词典
l 数据源点及汇点描述：
① 名称:售票员
简要描述：管理售票员信息
有关数据流：用户名、密码、系统选择：售票系统、退票系统、查询系统、录入信息系统
数目：1
l 加工逻辑词条描述:
① 加工名:身份检验
加工编号：１
简要描述：检验用户身份
输入数据流:用户名、密码
输出数据流：密码正确、身份验证错误
加工逻辑： IF　用户名为空　THEN
　　　　　　　　发出“用户名为空错误”
　　　　　 ELSE　IF　密码为空　THEN
　　　　　　　　　　发出“密码为空错误"
　　　　　　　　　ELSE　IF　用户名和密码不符　THEN
　　　　　　　　　　　　　　发出“用户名和密码不匹配错误”
　　　　　　　　　　　　　　　ENDIF
　　　　　　　　　　　　ENDIF
　　　　　　　　　ENDIF
　　　　　　ENDIF
l 数据流名词条描述:
① 数据流名：用户名
说明：售票员姓名
数据流来源：售票员
数据流去向：身份检验
数据流组成:用户名=字符型字符串
② 数据流名：密码
说明：与用户名相匹配的密码
数据流来源：售票员
数据流去向：身份检验
数据流组成：密码=短整型字符串
每个数据量流通量:
③ 数据流名：出错信息
说明：用于指示身份验证错误的信息
数据流来源：身份检验
数据流去向:售票员
数据流组成：出错信息＝任意字符串
④ 数据流名：系统名称
说明：系统的名称
数据流来源：
数据流去向：选择
数据流组成：
l 数据文件词条描述：
① 数据文件名:授权信息表
简述:存放售票员信息
输入数据：
输出数据：售票员信息
数据文件组成:授权信息表由“售票员信息"组成
2．售票员相关操作(售票、退票、查询、录入）
(2)：数据词典：
l 数据源点及汇点描述：
名称：售票员
简要描述：管理售票员信息
有关数据流：用户名、密码
数目：1
l 加工逻辑词条描述：
加工名：身份检验
加工编号:１
简要描述：检验用户身份
输入数据流：用户名、密码
输出数据流:密码正确、身份验证错误
加工名：售票
加工编号:2
简要描述：根据所读入的操作信息，售出火车票
输入数据流：操作信息,火车票信息
输出数据流：火车票信息
加工逻辑:根据所读入的操作信息,售出火车票
l 数据流名词条描述：
数据流名：用户名
说明：售票员的姓名
数据流来源：售票员
数据流去向：身份检验
数据流组成：用户名=字符型字符串
数据流名：密码
说明：与职工名称相匹配的密码
数据流来源：售票员
数据流去向：身份检验
数据流组成：密码=短整型字符串
每个数据量流通量:
数据流名：车票信息
说明：车票信息
数据流来源：售票员
数据流去向：列车信息表
l 数据文件词条描述：
①　数据文件名:列车信息表
简述:车票信息
输入数据：车票信息
输出数据：
数据文件组成:列车信息表由“车票信息”组成
存储方式:关键码
存取频率：频繁
数据文件名：票务信息表
简述：票务信息
输入数据：票务信息
输出数据：
数据文件组成:票务信息表由“列车号、已售票、剩余票”组成
存储方式：关键码
存取频率：频繁
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
第 14 页