选课平台需求分析

学生选课平台需求分析

  1. 业务需求
选课平台需求分析

1.1业务目的:

  该选课平台用于提高教务处的工作效率,方便用户之间的信息交流,简化学生的选课流程,使选课管理工作更规范化,系统化,程序化提高信息处理的速度和准确性,能够及时、准确、有效的查询和修改选课排课相关信息。本系统是对该学生选课平台的一个整体把握,以便在下一步的开发做更好的把握。

1.2业务目标:

  1. 该平台为学生提供一个简洁、方便的用户操作界面,方便于学生对课程的查询,选课和退订等。
  2. 该平台应尽量具备较大的容纳量,以便让更多的学生更加的顺畅的登录该系统进行操作。
  3. 该平台应具有良好的运行效率,以便于让学生有一个更好的体验
  4. 平台的设计应该具有一定的超前性
  5. 、灵活性和稳定性,能够很好的适应信息管理的多变性。
  6. 在平台上操作时系统的响应时间应尽量短,以便于有一个更舒适的体验。
  7. 该平台应具有良好的可扩充性,可以加入其它系统的应用。
  8. 平台应该具有较好的安全性、可靠性和可维护性。

2.用户需求

2.1学生选课系统面向对象

  1. 学生
  2. 老师
  3. 系统管理员

2.2学生选课系统用户分析

学生:

  • 可以登录系统平台进行操作
  • 选课,查询课程信息,退课
  • 查询课程成绩
  • 查询个人信息,编辑个人信息,修改个人信息

老师:

  • 可以登录系统平台进行操作
  • 课程管理,查看自己的课程信息,如选课学生名单,上课信息,录入学生成绩
  • 查询个人信息,编辑个人信息,修改个人信息

系统管理员:

  • 登录后台进行管理
  • 进行学生管理—查看学生信息,修改学生信息;添加学生,删除学生;查看学生选课信息,调整学生选课
  • 进行教师管理—查看教师信息,修改教师信息;添加教师,删除教师;查看教师上课信息
  • 进行课程管理—查看师生选课情况,修改师生选课情况;查看课程信息,修改课程信息

3.功能分析

3.1学生信息数据库主要有如下功能

  1. 用户能存储学生个人情况的有关信息。
  2. 用户能存储学生学习情况的有关信息。
  3. 用户能存储学生老师情况的有关信息。
  4. 用户能存储学生班级情况的有关信息。
  5. 用户能对上述信息进行录入、修改、删除等操作。
  6. 用户能通过多种方式对上述信息进行查询和统计。
  7. 用户能对查询和统计记过进行报表输出。

3.2数据库的逻辑结构

数据库的E-R图如下所示:

选课平台需求分析  

 

 

3.2.1E-R图向关系模型转换

在如上E-R图中1:1的关系有1个;1:n的关系有1个;n:m的关系有2个。共4个。

实体关系:

学生(学号,姓名,出生日期,所在系,年级,平均成绩)

教师(职工号,姓名,性别,职称,是否优秀班主任)

课程(课程号,课程名,学分)

班级(班级号,学生人数)

联系关系:

对于1:1联系“管理”,可在教师模式中加入班级号。

教师(职工号班级号,姓名,性别,职称,是否优秀班主任)

对于1:n联系“组成”,可在学生模式中加入班级号。

学生(学号班级号,姓名,出生日期,所在系,年级,平均成绩)

对于n:m联系“教学”,生成一个新的关系模式。

教学(学号职工号

对于n:m联系“选修”,生成一个新的关系模式。

选修(学号课程号,成绩)

整合关系模式如下:

学生(学号班级号,姓名,出生日期,所在系,年级,平均成绩)

教师(职工号班级号,姓名,性别,职称,是否优秀班主任)

教学(学号职工号

选修(学号课程号,成绩)

课程(课程号,课程名,学分)

班级(班级号,学生人数)

3.2.2数据模型优化

数据依赖:

课程关系模式存在下列数据依赖:

课程号   课程名

课程号   学分

 

选修关系模式存在下列数据依赖:

(学号,课程号)  成绩

 

学生关系模式存在下列数据依赖:

(学号,班级号)      姓名

(学号,班级号)      出生日期

(学号,班级号)      所在系

(学号,班级号)      年级

(学号,班级号)      平均成绩

 

教师关系模式存在下列数据依赖:

(职工号,班级号)    姓名

(职工号,班级号)    性别

(职工号,班级号)    职称

(职工号,班级号)    是否优秀班主任

 

班级关系模式存在下列数据依赖:

班级号      学生人数

 

学生关系模式的学号与选修关系模式的学号存在下列数据依赖:

学生.学号     选修.学号

规范化程度:

经过分析可知,学生关系存在如下决定:

(学号,班级号)      姓名,出生日期,所在系,年级,平均成绩

这个数据库表不满足第二范式,因为也存在如下决定:

班级号        (所在系,年级)

经过分析可知,教师关系属于第三范式。

经过分析可知,教学关系属于第一范式。

经过分析可知,选修关系属于第三范式。

经过分析可知,课程关系属于第二范式。

经过分析可知,班级关系属于第二范式。

确定是否分解:

在学生关系中,虽然所在系和年级可以从班级号属性中推出,但如果应用中要经常查询学生的所在系和年级,为了提高效率,可以保留数据的冗余,对关系模式不再进行进一步分解。

3.2.3设计用户子模式

在教师关系模式中定义两个外模式:

教师_学籍管理(职工号,姓名,性别,职称)

教师_课程管理(职工号,姓名,性别,班级号,是否优秀班主任)

授权学籍管理应用只能访问教师_学籍管理视图;

授权课程管理应用只能访问教师_课程管理视图;

授权教师管理应用可以访问教师表。

 

在学生关系模式中定义两个外模式:

学生_学籍管理(学号,姓名,性别,出生日期,所在系。班级号)

学生_课程管理(学号,姓名,性别,所在系,班级号,平均成绩)、

授权学籍管理应用只能访问学生_学籍管理视图;

授权课程管理应用只能访问学生_课程管理视图;

授权教师管理应用可以访问学生表。

 

在选修关系中定义一个外模式:

选修_课程选修(学号,课程号)

授权课程选修只能访问选修_课程选修视图;

授权选修管理应用可以访问选修表。

 

  1. 非功能性需求分析  

4.1可靠性

  • 当用户输入的内容为非法字符时弹框提示“您输入的内容为非法字符,请重新输入”
  • 当判断到学生在一个时间段同时选了多门课时,提示“课程时间冲突,请重新选择”
  • 正常情况下,要求系统7*24小时运行,全年持续运行故障停运时间累计不超过10小时

4.2兼容性

系统支持MAC OS,windows操作系统

4.3可用性

提供数据备份和恢复功能,使得在由于系统的错误或其他原因引起系统的数据丢失或系统的数据被破坏时,能够及时恢复和还原数据(由硬件及第三方软件提供此功能)。

4.4安全性

  • 用户只有在经过身份认证之后,才能访问在其权限内的数据和进行权限内的操作
  • 能经受来自互联网的一般性恶意攻击

4.5可维护性

从接到修改请求后,对于普通修改,在一周内完成;对于评估后为重大需求,半个月内完成。