数字离校系统需求分析教材Word下载.docx
《数字离校系统需求分析教材Word下载.docx》由会员分享,可在线阅读,更多相关《数字离校系统需求分析教材Word下载.docx(19页珍藏版)》请在冰豆网上搜索。
1.指明数据存在的数据符号,这些数据符号也可指明该数据所使用的媒体。
2.指明对数据执行处理的处理符号,这些符号也可指明该处理所用到的机器功能。
3.指明几个处理和(或)数据媒体之间的数据流的流线符号。
4.便于读、写数据流程图的特殊符号。
在处理符号的前后都应是数据符号。
数据流程图以数据符号开始和结束(除9.4规定的特殊符号外)
处理过程
功能图
是一种能全面地描述信息系统逻辑模型的主要工具,它可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况。
数据字典
所谓数据词典,是指定义和管理数据库文件(库表)的有组织的系统,其目的是方便数据库的存取和控制,加强系统的数据管理
需求提出者
需求提出者是对项目进行提出需求的用户
图例说明
是一种描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向的图表,利用它可以帮助分析人员找出业务流程中的不合流理向。
数据存储
数据存储是一种对深入挖掘用户需求,得出数据分析的存储过程。
是对整个数据的中间结果以及最终结果的存储。
数据传递
数据传递是处于整个规定了的所有数据媒体的中间产物的传递。
2.任务概述
2.1
总体目标
建设“数字离校系统”的目的是为了给毕业生提供方便、高效、一体的离校手续办理环境和服务,加强参加离校的各个部门间的数据共享、工作配合和业务协同,提高学校各相关部门的工作效率和服务质量。
2.2性能目标
应用范围:
主要用户
主要功能
管理员
离校系统参数设置、数据维护管理、离校手续制定、各部门数据导入配置管理等
部门老师
针对当前年度所有毕业生的办理
院系老师
对本院系学生办理相关的离校手续
校领导
通过统计报表及时查询毕业生的手续办理情况
1、系统通过信息门户为毕业生、图书馆、学生社区管理中心教务处、保卫处、院系、校领导等提供管理与服务的统一入口;
2、系统提供统一身份认证集成方式,对各办理环节提供安全保障
3、系统提供离校数据准备、离校现场办理、离校公告发布管理等核心业务;
4、系统提供与教务数据、一卡通数据、财务数据、及社区管理等数据的有效集成,并提供集成方案;
5、系统提供灵活的离校方案制定,方便进行不同批次不同学生类别离校方案的区分及相关管理人员管理流程的指定;
2.3
系统的特点
此数字离校系统主要包括系统管理、离校前期学生准备、离校学生手续办理和离校数据的统计分析等模块。
数字离校系统将涉及离校的财务、教务、学工等系统数据与应用服务整合到一个平台上,实现所有离校业务在同一平台办理,并采用多种统计报表对离校各类业务数据进行多方面展示,使数据更加直观易分析。
毕业生登录系统可随时查看本人离校各业务状态,系统会自动审核通过符合条件的毕业生(这部分毕业生不需要再到现场办理),“未通过”毕业生则被告知需到现场办理。
系统还向毕业生提供审核未通过的原因以及下一步手续办理流程。
在为毕业生们简化离校流程,大幅度节省手续办理时间的同时,数字离校系统采用整合技术进行自动审批也大大减轻了各部门审批过程的工作量,保证了毕业生“离校状态”的实时性,强有力地提高了各部门老师的工作效率。
3.功能需求
3.1业务流程图
图1
3.2实现功能
图2
3.1.1功能实现子模块
图3
图3中描述了系统维护的功能,其中:
1.组维护:
选择用户组,查看系统已经有的用户组和相关权限。
2.用户维护:
管理员可以通过该功能添加用户、修改用户、删除用户、用户授权、设置读写权等功能。
3.学生数据维护:
选择学生类别,系统自动列出所有该类别的学生。
对学生信息增加,删除,修改,导入和导出数据等操作。
4.教师数据维护:
选择教职工类别,系统自动列出所有该类别的教职工。
对教职工信息增加,删除,修改,导入和导出数据等操作。
5.操作日志查询:
用户可以选择操作员(用户名),操作日期段,以及IP地址段对操作日志进行查询。
6.数据备份恢复:
用户可以自定义输入备份文件名,点保存后,系统自动在应用服务器上做数据备份。
7.系统设置:
用户可以设定学校名称,启动时间,系统万能密钥(万一管理员忘记系统登录密码可以通过万能密钥当作密码登陆,注意保密性)以及当前年份。
图4
图4描述的是学生可以进行网上查看自己的信息,在线咨询关于离校的有关事宜。
图5
图5描述功能有2个角色可以实现:
1.学生:
登陆系统修改自己的密码。
2.管理员:
可以修改用户的密码
图6
图6描述学生办理离校手续:
1.部门手续办理:
根据学生类别,院系,专业和班级,年级,校区等对学生信息进行操作。
2.分院手续办理:
3.学生离校办理:
输入学号或者姓名进行查询,可以查看审核情况。
4.单个学生办理:
对单个学生进行各项审查。
5.证书发放:
对通过审核的同学进行证书发放。
图7
图8
图8中:
1.离校项目与处理:
根据学生的类别,学院,班级生成当年学生的电子离校单。
2.办理流程:
显示学生离校需要办理的手续的单位及时间,可以对这些信息进行操作。
3.新闻发布管理:
部门或者学院有通知或者信息要发布,则可以在此发布与离校相关的信息。
面向对象分为:
学生和老师以及全部。
面向老师的除了学生用户其他都能看到,面向对象为学生的(且具体到某个学院的),则只有(某个学院的)学生用户才能看到。
面向对象为全部的则所有用户都能看到。
必须填入新闻的标题。
对于发布了的新闻可以进行修改/删除操作。
4.打印方式设置:
选择系名称,学生类别,打印方式(受限制(没有审核完成不允许打印),不受限制),审核方式(手工,自动),是否允许强制审核(允许,不允许)后保存即可。
5.查看打印设置:
对4中功能进行查看。
6.上传管理文件:
可以对离校相关的管理文件进行上传,学生或者相关人员在登陆界面就可以看到该文件。
输入文件名称以及上传文件的内容,点保存即可上传。
退出界面可以查看上传的相关文件。
3.3系统用例图
图9(用例图)
3.4数据流程图
图10(数据流程图顶层)
图11
图12
图13
图14
图15
图16
校区
学生
部门
电子离校流程单:
3.5数据字典
3.5.1数据元素定义
编号
数据元素名
内部名
值域
值义
类长
E1
学生姓名
StudentName
Varchar(20)
E2
学生学号
StudentNumber
Varchar(10)
E3
学生年龄
StudentAge
Int
E4
学生性别
StudentSex
bool
E5
家庭住址
StudentAddress
Varchar(50)
E6
政治面貌
StudentFlag
E7
联系电话
StudentPhone
E8
学院名称
SdeptName
E9
就读班级
StudentClass
E10
财务处是否欠费
E11
就读专业
MajorName
E12
就读校区
CampusName
E13
学生证上缴情况
E14
还书情况
E15
图书馆欠费
E16
物品名称
GoodsName
E17
是否损坏物品
bool
E18
科目名称
ObjectName
E19
科目成绩
ObjectGrade
int
E20
毕业证发放情况
3.5.2数据流的定义
数据流名
组成
备注
L1
学生情况
E1+E3+E4+E5+E6+E7+E12
L2
学生成绩
E2+E8+E9+E11+E18+E19
L3
各门成绩
E2+E18+E19
L4
图书馆信息
E1+E2+E4+E8+E9+E11+E14+E15
L5
财务处信息
L1+E8+E9+E10+E11+E12
L6
后勤信息
L1+E8+E9+E11+E12+E16+E17
L7
教务处信息
L1+L2+E13
L8
辅导员信息
L1+L2+L3+L4+L5+L6+L8+E20
L9
统计分析
L1+L2+L3+L4+L5+L6+L8+E20
3.5.3外部项定义表
名称
输出数据流数
输入数据流数
W1
图书馆处
L4
W2
财务处
L5
W3
后勤处
L6
W4
教务处
L7
W5
辅导员处
L8
W6
学生处
W7
查询者
L9
3.5.4处理过程
输入数据
输出数据
处理前
处理后
处理逻辑
P0
学生登录
用户名和密码
查看
P1
教务处操作
查看和修改
P2
财务处操作
P3
图书馆操作
P4
后勤操作
P5
辅导员操作
P6
校领导操作
L8
查看
4.运行环境要求
4.1硬件环境
服务器端:
高性能的计算机一台,普通的双绞线作为连接。
客户端:
普通的计算机或者工作站,普通的双绞线作为连接。
4.2软件环境
安装SQLServer2008的服务器版本,安装windows2000服务器版本,配置了诺顿等必须的防毒软件。
安装SQLServer2008的服务器版本,安装了vs2010等可视化开发工具软件,安装windows2000服务器版本。
5.系统安全性要求
离校系统系统尽管功能强大,技术先进,但由于受到自身体系结构,设计思路以及运行机制等限制,也隐含许多不安全因素。
常见因素有:
数据的输入,输出,存取与备份,源程序以及应用软件,数据库,操作系统等漏洞或缺陷,硬件,通信部分的漏洞,企业内部人员的因素,病毒,“黑客”等因素。
因此,为使本系统能够真正安全,可靠,稳定地工作,必须考虑如下问题:
为保证安全,不致使系统遭到意外事故的损害,系统因该能防止火,盗或其他形式的人为破坏。
●系统要能重建
●系统应该是可审查的
●系统应能进行有效控制,抗干扰能力强
●系统使用者的使用权限是可识别的
6.风险分析
6.1主要风险评估
现有系统与待开发系统之间的整合存在一定的技术难度;
在系统开发过程中,由于各个模块是独自开发完成,最后的系统调试和测试需要详细规划,存在一定的技术风险;
销售管理模块的支持决策功能的实现对于目前开发人员来说,难度很高;
6.2风险处理策略
在系统详细设计时尽可能考虑到将来系统整合的技术问题,或者选择有相关系统开发经验的人员进行指导性的工作。
7遗留问题
本文对整个系统从功能上进行模块划分并对每个模块或功能及其性能约束进行了详细的说明,但是对于各个模块之间的通讯交流论述较少,故希望在系统设计时注意此类问题的细节。