会议管理系统需求分析.docx

上传人:b****3 文档编号:2972788 上传时间:2022-11-16 格式:DOCX 页数:14 大小:699.12KB
下载 相关 举报
会议管理系统需求分析.docx_第1页
第1页 / 共14页
会议管理系统需求分析.docx_第2页
第2页 / 共14页
会议管理系统需求分析.docx_第3页
第3页 / 共14页
会议管理系统需求分析.docx_第4页
第4页 / 共14页
会议管理系统需求分析.docx_第5页
第5页 / 共14页
点击查看更多>>
下载资源
资源描述

会议管理系统需求分析.docx

《会议管理系统需求分析.docx》由会员分享,可在线阅读,更多相关《会议管理系统需求分析.docx(14页珍藏版)》请在冰豆网上搜索。

会议管理系统需求分析.docx

会议管理系统需求分析

会议管理系统需求分析

1引言

1.1编写目的

需求分析是软件系统生存期中定义时期的最后一个步骤。

那个时期的任务不是具体解决问题,而是准确确定为解决问题系统必须具备哪些功能。

那个时期的一个重要任务是用正式的文档准确地记录目标系统的需求。

该文档将最终交给软件具体的开发人员进行具体的开发。

1.2背景

开发的软件系统的名称:

饭卡治理系统

本项目的任务提出者:

软件工程课程设计

开发者:

李杜松

实现该软件的运算站:

图书馆运算机中心

1.3定义

本文件中用到的专门术语的定义和外文首字母词组的原词组。

实体—联系图〔E-R图〕:

包含实体〔即数据对象〕、关系和属性。

作为用户与分析员之间有效交流的工具。

状态转换图:

通过描画系统的状态及引起系统的状态转换的事件来表示系统的行为。

提供行为建模机制。

层次方框图:

用树形结构的一系列多层次的矩形框描画数据的层次结构。

输入-处理-输出图〔IPO图〕:

方便描画输入数据、对数据的处理和输出数据之间的关系。

1.4参考资料

同可行性研究报告处

2.任务概述

2.1目标

要紧开发目标是能够对饭卡信息进行查询和更新治理,且具有反映灵敏准确。

2.2用户的特点

由于系统的界面清晰、美观,操作简单、方便,因此操作人员只需要具备一定的电脑操作技能即可。

治理员〔爱护人员〕不需要任何数据库专业技能知识。

本系统能够极大的提高工作效率,预期使用频度较高。

2.3假定和约束

系统的规模较小,适于Windows和操作系统,SQL数据库系统。

3.需求规定

3.1对功能的规定

(1)更准确的系统流程图

(2)更准确的数据流程图

-------------0层-------------

-------------1层-------------

-------------2层-------------

治理员通过对在校学生提供的简单信息与学生注册信息的比较,判定学生信息的一致性,确认信息后读取学生的其他信息,然后创建一个新的卡ID,卡内储存学生和饭卡的信息,同时创建饭卡信息历史记录表用以记录饭卡的使用记录和修改记录,最后全部在饭卡信息数据库中创建一个新纪录。

学生在存钱时,通过治理员的系统后台操作输入存款额,修改饭卡数据库的饭卡信息,完成存款操作,学生就可用饭卡进行消费。

消费过程中,刷卡服务员先在刷卡器中键入学生消费数额,学生刷卡,刷卡器显示器里显示卡ID,卡内余额,刷卡器响应后,自动修改饭卡信息数据库中饭卡信息,消费完成。

学生申请查询饭卡使用信息,治理员登录饭卡治理系统,输入学生信息〔条件〕,系统判定条件的合法性后执行查询操作。

系统从饭卡信息数据库中调出所查卡的信息,产生饭卡使用报表,学生可查询。

学生丢失饭卡时可申请挂失。

治理员校对挂失卡的ID和学生信息,系统判定学生简单信息的一致性,确认信息后饭卡转换为挂失状态,饭卡信息锁定,同时开始挂失计时。

饭卡治理系统会判定挂失时刻,到时自动注销卡ID,同时注销饭卡信息数据库里面的饭卡信息,将注销信息回馈给持卡学生。

学生能够修改饭卡的信息。

登录饭卡信息治理系统后,输入饭卡ID和密码,系统判定学生信息的一致性,确认信息后,学生通过输入旧密码,然后输入新密码两次后,确认修改是否成功。

密码更换成功后,饭卡信息数据库更新饭卡信息,学生饭卡信息修改完毕。

学生利用饭卡进行进出图书馆的身份认证。

学生只要在图书馆的刷卡器上刷饭卡,系统自动核对卡ID并向图书馆数据库储备进出馆记录。

学生在进行借书还书操作时,饭卡放在刷卡器上不离开,系统核对学生身份,确认后系统后台显示学生借还书记录,然后修改借还书记录后显示修改后的结果,图书馆数据库修改借书记录,借还书成功,学生可拿卡离开。

-------------3层-------------

(3)IPO图

(4)状态变化图

(5)层图

(6)动态数据

动态数据包括程序运行时输入和输出的数据,具体是数据库的各个表的各个不同元组与属性值,就查阅信息。

数据库描述

本系统的实体有:

学生信息、卡信息它们之间的关系是一对一的。

卡信息和卡历史是一对多的。

E-R图如下:

(4)更准确的数据字典

数据字典

1学生信息:

学生学号=[数字|字母]

卡ID=[数字|字母]

学生姓名=[汉字]

性别=[男|女|null]

号码=[数字]

地址=[汉字|数字|字母]

2卡信息

卡ID=[数字|字母]

余额=[数字]

锁=[true|false]

3卡历史

卡ID=[数字|字母]

时刻=[时刻格式]

款额=[数字]

操作=[存款|消费|其他]

数据元素的数据字典卡片:

学生信息

名字:

学生信息别名:

描述:

记录学生相关信息

定义:

学生信息=学生学号+卡ID+学生姓名+性别+号码+地址

位置:

数据库

卡信息

名字:

卡信息别名:

描述:

记录卡的信息

定义:

卡信息=卡ID+余额+锁

位置:

数据库

卡历史信息

名字:

卡历史信息别名:

描述:

记录卡历史的信息

定义:

客户信息=卡ID+时刻+款额+操作

位置:

数据库

学生信息库〔student_info〕

列名

数据类型

学生学号

stu_num

int

卡ID

id

int

学生姓名

name

Char(20)

性别

male

boolean

号码

tel

Char(20)

地址

address

Char(50)

卡信息(card_info)

列名

数据类型

卡ID

id

int

余额

sum

float

lock

boolean

卡历史(card_his)

列名

数据类型

卡ID

id

int

时刻

daytime

daytype

款额

sum

float

操作

op

Char(20)

3.2对性能的规定

3.2.1精度

输入数据:

查询最大查询范畴1年内;卡ID合法性;客户信息合法性;

输出数据:

余额以213.12的形式最多小数点后两位,即到分为止显示。

〔小于的部分不可能显现〕

3.2.2时刻特性要求

刷卡响应时刻不超过1秒;

查询响应时刻不超过5秒;

3.3故障处理要求

刷卡响应时刻超过1秒后,自动提出警告。

要求重新刷卡。

查询超过5秒,要显示查询时刻长的提示信息。

以免误认为死机。

当运算机突然死机、重启、断电时自动储备备份数据。

即便没有存上。

也有备份数据库,供复原。

3.4其他专门要求

一般学生只能刷卡消费,系统治理员还能够进入治理员界面;刷卡服务员能够操作刷卡器。

界面清晰、美观,操作简单、方便。

所有数据储备在学校服务器端,数据储备安全可靠。

4运行环境规定

4.1设备

a.中央电脑,要求容量大,CPU能够满足查询的。

b.刷卡器,要求读取ID灵敏,准确。

c.要求刷卡器与中央电脑连接。

通信量要满足查询精度和速度。

d.刷卡器上的功能建,要求显示明确,意思表达精确。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 初中教育 > 学科竞赛

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1