移动订票平台系统
需求分析说明书
学 院 计算机学院 专 业 软件工程 年级班别 卓越工程（1）班 学 号 3114006538 学生姓名 杨斌 指导教师 殴毓毅
2016 年 6 月 20 日
1导言 ............................................................. 1 1.2 范围 ..................................................... 1 1.3 定义 ..................................................... 1 2 系统定义 .................................................... 1 2.1 项目背景 ............................................. 1 2.2 系统整体结构 ..................................... 2 3 应用环境 .................................................... 3 4 功能需求 .................................................. 3 4.1 角色定义 ............................................. 3 4.2 系统各类之间的关系 ......................... 4 5 性能需求 .................................................. 13 6 产品提交 .................................................. 14 7 实现约束 .................................................. 14 8 签字 .......................................................... 14
1导言
1.1编写目的
这个阶段的任务不是具体解决问题，而是准确确定为解决问题系统必须具备哪些功能。这个阶段的一个重要任务是用正式的文档准确地记录目标系统的需求。该文档将最终交给软件具体的开发人员进行具体的开发。
1.2 范围
该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决整个项目系统的“做什么”的问题。在这里，对于开发技术并没有涉及，而主要是通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。
1.3 定义
本文件中用到的专门术语的定义和外文首字母词组的原词组。 实体—联系图（E-R图）：包含实体（即数据对象）、关系和属性。作为用户与分析员之间有效交流的工具。
状态转换图：通过描绘系统的状态及引起系统的状态转换的事件来表示系统的行为。提供行为建模机制。
层次方框图：用树形结构的一系列多层次的矩形框描绘数据的层次结构。 输入-处理-输出图（IPO图）:方便描绘输入数据、对数据的处理和输出数据之间的关系。
2 系统定义
我们分别阐述一下项目的来源、背景和项目的目标
2.1 项目背景
校园卡管理系统是一套针对大学校园食堂饮食交费，一般消费等方面的信息管理系统，它包括了同学在校内消费各方面内容：刷卡消费、查询、存款，学生信息管理等。方便的对同学饭卡信息进行各项操作，定时进行数据的备份更新，保持数据的一致性和准确性，各方面的内容应该相互联系，最终产生各种查询统计报表，以供同学进行检查。
校园卡管理系统的主要任务就是把人们从繁琐的交费，找零工作中解放出来，
用计算机实现对销售合同资料进行存款，消费，查询、修改、删除以及存储等功能。同时，用计算机能够快速准确地完成共档案资料的统计和汇总工作，迅速地打印出各种报表资料以供使用。
进行数据库设计的首要任务是考虑信息要求，也就是数据库要存入什么样的数据。当然，创建数据库并非仅仅为了存储数据，更主要的目的是从中提取有用信息。所以除了要考虑数据库存储什么数据外，还应该考虑数据的存储方式、目的、用途以及性能要求。
2.2 系统整体结构
使用饭卡可以快速便捷的进行消费。中央电脑--数据库对饭卡的操作相应至关重要。在高峰时刻，也能保证，存款，消费无错误，并且可记录，撤销操作。
系统流程图
数据流程
3 应用环境
3.1运行的硬件环境
a. 中央电脑，要求容量大，CPU能够满足查询的。 b. 刷卡器，要求读取ID敏捷，准确。
c. 要求刷卡器与中央电脑连接。通信量要满足查询精度和速度。 d. 刷卡器上的功能建，要求显示明确，意思表达精确。
4 功能需求
4.1 角色定义
角色或者执行者（Actor）指与系统产生交互的外部用户或者外部系统
4.1.1 学生
1可通过改系统存取在一卡通里面的现金 2 记录通过一卡通进行刷卡消费
3 因意外丢失的一卡通，可通过系统进行挂失或者申请新卡 4在系统上进行个人信息管理 5 查询现有金额
4.1.2 一卡通
1 卡的表面记录学生的姓名、性别、近照、学号、卡号等信息
2 卡里面记录id、学生个人信息、余额、卡锁等信息
4.1.3 管理员
管理系统的人员
4.2 系统各类之间的关系
4.3 系统功能
a．功能：
1实现消费使用卡片扣钱（取代现金）； 2在固定保险的地方存钱； 3有消费记录功能； 4有挂失功能。
b．性能； 1刷卡消费时，要求快速，准确，可撤销；
2在查询消费记录时，达到一般的查询速度。
c. 输出： 在刷卡器上，每次消费时： 1存额 2此次消费额 3剩余额 刷卡器上，额外的信息如：
1出错信息 2锁卡信息
3剩余不多提示信息 报单：
1每学年或者每月，可选择性的（需学生主动要求）输出消费记录报单。详细程度可由使用者，自行定义。
2存款时，可选择性的（需学生主动要求）输出存款记录报单。 3注销卡时，返还剩余额（钱）。
d．输入： 刷卡器上，每次消费时： 1卡ID（可由读卡器自动读入） 2消费额 3操作符（确认，撤消，后退，计算（加减乘除），存款（有权限限制），其他功能） 数据库管理电脑上： 1输入学生信息 2学生存款额（由读卡器端输入器完成） 3查询，修改，删除功能输入
e．在安全与保密方面的要求：
1使用者之间的ID号不能重复； 2 ID号不被他人轻易知道；
3即便知道也能有快速相应的机制，予以弥补；
4有使用追踪功能，可以让用户了解，自己使用的情况。
4.4 需求规定
4.4.1 详细系统流程图
-------------0层-------------
-------------1层-------------
-------------2层-------------
-------------3层-------------
4.4.2 IPO图
4.4.3 状态变化图
冲钱，消费
4.4.4 层图
4.5 动态数据
动态数据包括程序运行时输入和输出的数据，具体是数据库的各个表的各个不同元组与属性值，就查阅信息。 数据库描述
本系统的实体有：学生信息、卡信息它们之间的关系是一对一的。卡信息和卡历史是一对多的
E-R图如下：
数据字典
1学生信息：
学生学号 = [数字|字母] 卡ID = [数字|字母] 学生姓名 = [汉字] 性别 = [男|女|null] 电话号码 = [数字]
地址 = [汉字|数字|字母] 2 卡信息
卡ID = [数字|字母] 余额= [数字] 锁=[true|false] 3 卡历史
卡ID = [数字|字母] 时间=[时间格式] 款额=[数字]
操作=[存款|消费|其他] 数据元素的数据字典卡片： 学生信息
名字：学生信息 别名： 描述：记录学生相关信息
定义：学生信息=学生学号+卡ID+学生姓名+性别+电话号码+地址 位置：数据库 卡信息
名字：卡信息别名： 描述：记录卡的信息
定义：卡信息 =卡ID+余额+锁
位置：数据库
卡历史信息
名字：卡历史信息 别名： 描述：记录卡历史的信息
定义：客户信息=卡ID+时间+款额+操作 位置：数据库
5 性能需求
5.1 精度需求
输入数据：查询最大查询范围1年内；卡ID合法性；客户信息合法性； 输出数据：余额以 213.12的形式最多小数点后两位，即到分为止显示。（小于的部分不可能出现）
5.2 响应时间需求
刷卡响应时间不超过1秒； 查询响应时间不超过5秒；
5.3故障处理需求
刷卡响应时间超过1秒后，自动提出警告。要求重新刷卡。
查询超过5秒，要显示查询时间长的提示信息。以免误认为死机。
当计算机突然死机、重启、断电时自动存储备份数据。即便没有存上。也有备份数据库，供恢复。
5.4 可靠性需求
使用饭卡可以快速便捷的进行消费。中央电脑--数据库对饭卡的操作相应至关 重要。在高峰时刻，也能保证，存款，消费无错误，并且可记录，撤销操作。
5.5 系统安全性需求
通过系统存取金额和大金额的消费（单次消费超过50）都需要进行密码输入，管理员只能对用户的个人信息进行修改，用户的金额和卡锁不能处理，挂失必须要用户的密码确认。当记录到当天短时间内用大金额消费则会停止卡消费
5.6其他专门需求
普通学生只能刷卡消费，系统管理员还可以进入管理员界面；刷卡服务员可以操作刷卡器。
界面清晰、美观，操作简单、方便。
所有数据存储在学校服务器端，数据存储安全可靠。
6 产品提交
a) b) c) d)
提交产品为： 应用系统软件包 数据库初始数据 系统开发过程文档 系统使用维护说明文档 提交方式：CD介质
7 实现约束
a 实现语言：java b 数据库 ：MySQL C 操作系统：win7
8 签字
本需求规格经过双方认可，特签字如下表Ａ－２。
表Ａ－２：需求规格签字
移动订票平台系统
需求分析说明书
学 院 计算机学院 专 业 软件工程 年级班别 卓越工程（1）班 学 号 3114006538 学生姓名 杨斌 指导教师 殴毓毅
2016 年 6 月 20 日
1导言 ............................................................. 1 1.2 范围 ..................................................... 1 1.3 定义 ..................................................... 1 2 系统定义 .................................................... 1 2.1 项目背景 ............................................. 1 2.2 系统整体结构 ..................................... 2 3 应用环境 .................................................... 3 4 功能需求 .................................................. 3 4.1 角色定义 ............................................. 3 4.2 系统各类之间的关系 ......................... 4 5 性能需求 .................................................. 13 6 产品提交 .................................................. 14 7 实现约束 .................................................. 14 8 签字 .......................................................... 14
1导言
1.1编写目的
这个阶段的任务不是具体解决问题，而是准确确定为解决问题系统必须具备哪些功能。这个阶段的一个重要任务是用正式的文档准确地记录目标系统的需求。该文档将最终交给软件具体的开发人员进行具体的开发。
1.2 范围
该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决整个项目系统的“做什么”的问题。在这里，对于开发技术并没有涉及，而主要是通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。
1.3 定义
本文件中用到的专门术语的定义和外文首字母词组的原词组。 实体—联系图（E-R图）：包含实体（即数据对象）、关系和属性。作为用户与分析员之间有效交流的工具。
状态转换图：通过描绘系统的状态及引起系统的状态转换的事件来表示系统的行为。提供行为建模机制。
层次方框图：用树形结构的一系列多层次的矩形框描绘数据的层次结构。 输入-处理-输出图（IPO图）:方便描绘输入数据、对数据的处理和输出数据之间的关系。
2 系统定义
我们分别阐述一下项目的来源、背景和项目的目标
2.1 项目背景
校园卡管理系统是一套针对大学校园食堂饮食交费，一般消费等方面的信息管理系统，它包括了同学在校内消费各方面内容：刷卡消费、查询、存款，学生信息管理等。方便的对同学饭卡信息进行各项操作，定时进行数据的备份更新，保持数据的一致性和准确性，各方面的内容应该相互联系，最终产生各种查询统计报表，以供同学进行检查。
校园卡管理系统的主要任务就是把人们从繁琐的交费，找零工作中解放出来，
用计算机实现对销售合同资料进行存款，消费，查询、修改、删除以及存储等功能。同时，用计算机能够快速准确地完成共档案资料的统计和汇总工作，迅速地打印出各种报表资料以供使用。
进行数据库设计的首要任务是考虑信息要求，也就是数据库要存入什么样的数据。当然，创建数据库并非仅仅为了存储数据，更主要的目的是从中提取有用信息。所以除了要考虑数据库存储什么数据外，还应该考虑数据的存储方式、目的、用途以及性能要求。
2.2 系统整体结构
使用饭卡可以快速便捷的进行消费。中央电脑--数据库对饭卡的操作相应至关重要。在高峰时刻，也能保证，存款，消费无错误，并且可记录，撤销操作。
系统流程图
数据流程
3 应用环境
3.1运行的硬件环境
a. 中央电脑，要求容量大，CPU能够满足查询的。 b. 刷卡器，要求读取ID敏捷，准确。
c. 要求刷卡器与中央电脑连接。通信量要满足查询精度和速度。 d. 刷卡器上的功能建，要求显示明确，意思表达精确。
4 功能需求
4.1 角色定义
角色或者执行者（Actor）指与系统产生交互的外部用户或者外部系统
4.1.1 学生
1可通过改系统存取在一卡通里面的现金 2 记录通过一卡通进行刷卡消费
3 因意外丢失的一卡通，可通过系统进行挂失或者申请新卡 4在系统上进行个人信息管理 5 查询现有金额
4.1.2 一卡通
1 卡的表面记录学生的姓名、性别、近照、学号、卡号等信息
2 卡里面记录id、学生个人信息、余额、卡锁等信息
4.1.3 管理员
管理系统的人员
4.2 系统各类之间的关系
4.3 系统功能
a．功能：
1实现消费使用卡片扣钱（取代现金）； 2在固定保险的地方存钱； 3有消费记录功能； 4有挂失功能。
b．性能； 1刷卡消费时，要求快速，准确，可撤销；
2在查询消费记录时，达到一般的查询速度。
c. 输出： 在刷卡器上，每次消费时： 1存额 2此次消费额 3剩余额 刷卡器上，额外的信息如：
1出错信息 2锁卡信息
3剩余不多提示信息 报单：
1每学年或者每月，可选择性的（需学生主动要求）输出消费记录报单。详细程度可由使用者，自行定义。
2存款时，可选择性的（需学生主动要求）输出存款记录报单。 3注销卡时，返还剩余额（钱）。
d．输入： 刷卡器上，每次消费时： 1卡ID（可由读卡器自动读入） 2消费额 3操作符（确认，撤消，后退，计算（加减乘除），存款（有权限限制），其他功能） 数据库管理电脑上： 1输入学生信息 2学生存款额（由读卡器端输入器完成） 3查询，修改，删除功能输入
e．在安全与保密方面的要求：
1使用者之间的ID号不能重复； 2 ID号不被他人轻易知道；
3即便知道也能有快速相应的机制，予以弥补；
4有使用追踪功能，可以让用户了解，自己使用的情况。
4.4 需求规定
4.4.1 详细系统流程图
-------------0层-------------
-------------1层-------------
-------------2层-------------
-------------3层-------------
4.4.2 IPO图
4.4.3 状态变化图
冲钱，消费
4.4.4 层图
4.5 动态数据
动态数据包括程序运行时输入和输出的数据，具体是数据库的各个表的各个不同元组与属性值，就查阅信息。 数据库描述
本系统的实体有：学生信息、卡信息它们之间的关系是一对一的。卡信息和卡历史是一对多的
E-R图如下：
数据字典
1学生信息：
学生学号 = [数字|字母] 卡ID = [数字|字母] 学生姓名 = [汉字] 性别 = [男|女|null] 电话号码 = [数字]
地址 = [汉字|数字|字母] 2 卡信息
卡ID = [数字|字母] 余额= [数字] 锁=[true|false] 3 卡历史
卡ID = [数字|字母] 时间=[时间格式] 款额=[数字]
操作=[存款|消费|其他] 数据元素的数据字典卡片： 学生信息
名字：学生信息 别名： 描述：记录学生相关信息
定义：学生信息=学生学号+卡ID+学生姓名+性别+电话号码+地址 位置：数据库 卡信息
名字：卡信息别名： 描述：记录卡的信息
定义：卡信息 =卡ID+余额+锁
位置：数据库
卡历史信息
名字：卡历史信息 别名： 描述：记录卡历史的信息
定义：客户信息=卡ID+时间+款额+操作 位置：数据库
5 性能需求
5.1 精度需求
输入数据：查询最大查询范围1年内；卡ID合法性；客户信息合法性； 输出数据：余额以 213.12的形式最多小数点后两位，即到分为止显示。（小于的部分不可能出现）
5.2 响应时间需求
刷卡响应时间不超过1秒； 查询响应时间不超过5秒；
5.3故障处理需求
刷卡响应时间超过1秒后，自动提出警告。要求重新刷卡。
查询超过5秒，要显示查询时间长的提示信息。以免误认为死机。
当计算机突然死机、重启、断电时自动存储备份数据。即便没有存上。也有备份数据库，供恢复。
5.4 可靠性需求
使用饭卡可以快速便捷的进行消费。中央电脑--数据库对饭卡的操作相应至关 重要。在高峰时刻，也能保证，存款，消费无错误，并且可记录，撤销操作。
5.5 系统安全性需求
通过系统存取金额和大金额的消费（单次消费超过50）都需要进行密码输入，管理员只能对用户的个人信息进行修改，用户的金额和卡锁不能处理，挂失必须要用户的密码确认。当记录到当天短时间内用大金额消费则会停止卡消费
5.6其他专门需求
普通学生只能刷卡消费，系统管理员还可以进入管理员界面；刷卡服务员可以操作刷卡器。
界面清晰、美观，操作简单、方便。
所有数据存储在学校服务器端，数据存储安全可靠。
6 产品提交
a) b) c) d)
提交产品为： 应用系统软件包 数据库初始数据 系统开发过程文档 系统使用维护说明文档 提交方式：CD介质
7 实现约束
a 实现语言：java b 数据库 ：MySQL C 操作系统：win7
8 签字
本需求规格经过双方认可，特签字如下表Ａ－２。
表Ａ－２：需求规格签字