校园一卡通系统需求文档Word格式.docx
《校园一卡通系统需求文档Word格式.docx》由会员分享，可在线阅读，更多相关《校园一卡通系统需求文档Word格式.docx（14页珍藏版）》请在冰豆网上搜索。
本文件中用到的专门术语的定义和外文首字母词组的原词组。
实体—联系图（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号不能重复；
2ID号不被他人轻易知道；
3即便知道也能有快速相应的机制，予以弥补；
4有使用追踪功能，可以让用户了解，自己使用的情况。
4.4需求规定
4.4.1详细系统流程图
-------------0层-------------
-------------1层-------------
-------------2层-------------
-------------3层-------------
4.4.2IPO图
4.4.3状态变化图
4.4.4层图
4.5动态数据
动态数据包括程序运行时输入和输出的数据，具体是数据库的各个表的各个不同元组与属性值，就查阅信息。
数据库描述
本系统的实体有：
学生信息、卡信息它们之间的关系是一对一的。
卡信息和卡历史是一对多的
E-R图如下：
数据字典
1学生信息：
学生学号=[数字|字母]
卡ID=[数字|字母]
学生姓名=[汉字]
性别=[男|女|null]
电话号码=[数字]
地址=[汉字|数字|字母]
2卡信息
余额=[数字]
锁=[true|false]
3卡历史
时间=[时间格式]
款额=[数字]
操作=[存款|消费|其他]
数据元素的数据字典卡片：
学生信息
名字：
学生信息别名：
描述：
记录学生相关信息
定义：
学生信息=学生学号+卡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签字
本需求规格经过双方认可，特签字如下表Ａ－２。
表Ａ－２：
需求规格签字
用户签署信息
企业签署信息
单位名称
XXXXX
签署人姓名
ＸＸＸ
签署日期
2016.6.18
升级会员 