成员:
1601214481 昝妍
1601214515 马银萍
日期:2017/3/12
本文档的目的旨在方便开发者更全面的分析整个教学选课系统,从各个 方面综合分析系统的需求,以便于开发有效的选课系统,规范化选课程序。 并能提供学生与教师不同使用对象的个别需求,使数据管理者与研究人员可 以进行数据建置与维护,并可让教务员进行相关的选课操作。
- 系统目标
本系统设计目标是协助学生提高选课效率以及准确性,以网页的方式呈 现学生选课系统,提供学生选课在线数字平台。
- 系统范围
由于“选课系统”须由任课教师进行课程的新增,之后由教务员开放学 生在线选课的时段,其后才由学生进行在线选课。学生在线选课结束后,由 教务员进行系统的抽签排课,之后再由学生进行选课和退补选等操作。因此 整个学生选课计划可以分为三个方面:任课教师、学生、教务员。
本需求说明书中是以上述三个部分为主要范围,建立数字选课系统,其 内容如下:
(1) 课程数据库,其中包含课程简介、课程教室及时段、课程人数上限等 信息,并提供各种数据的维护功能。
(2) 提供学生进行选课的检索及预览功能,并且以相互链接方式提供完整 的选课信息。
(3) 提供课程选修限制提醒,方便学生进行课程选修。
(4) 提供教师对课程信息的增添和修改操作。
(5) 提供教务员对学生和教师资料和权限进行修改的功能。 - 设计目标 由于人工选课的方式效率不高以及容易出错等问题,因此开发选课系统,使 用计算机选课的方式,提高效能及正确率。
修改日期 | 修改内容 | 修改成员 |
---|---|---|
03/09 | 需求文件前言、目录 | 昝妍 |
03/09 | 系统目标、范围和设计目标 | 昝妍 |
03/11 | 工作内容的分配 | 昝妍 |
03/10 | 用户描述 | 昝妍 |
03/09 | 功能性需求分析 | 马银萍 |
03/10 | 非功能性需求分析 | 马银萍 |
03/11 | 系统用例图 | 马银萍 |
- 用户描述 角色或执行者指与系统产生交互作用的外部用户或者外部系统及处理。
人员 | 角色定义 |
---|---|
学生 | 学生指使用本选课系统,主要进行学生个人的选课、课程修改、 查询课表等动作的人员。 |
教师 | 教师指在选课系统中使用开课功能的人员,并有特定权限对自 己的一项或是多项课程细节进行修改。 |
教务员 | 教务员可适度更改学生选课数据,对学生及教师基本数据做更 改变动。 |
2.功能性需求 此部分描述用户对于系统功能上的需求,并针对不同用户做需求上的纪录。
(1) 学生:
a. 系统能够处理选课和补退选情况
b. 系统能够列出课表使学生能方便知道自己目前的选课状况
c. 系统能够自动帮学生判断选课冲冲突的情况
d. 系统能够检验学分数是否超过或不足
(2) 教师:
a. 教师能新增课程
b. 教师能修改课程数据
c. 具有选课人员的筛选及人数上限设定功能
d. 教师能查询修课学生的信息
(3) 教务员:
a. 对教师和学生的基本信息和权限进行修改
b. 课程超出容纳人数时抽签
c. 本系科课程预选功能
3.非功能性需求 此部分主要描述系统软件的非功能性需求。
(1) 人机接口环境需求: 课程的选单列表应清楚、明晰、有条理,在搜索课程类别时,由于若直接把 所有课程细项以清单方式列出,会使得整个页面显得复杂而杂乱无章,因此 我们在设计课程的展示界面时,会令用户的检索由大项目逐步缩小范围至小 的项目,运用树形图的概念来引导使用者操作,以提升界面的友善性。
(2) 响应时间: 无论是客户端还是管理端,当用户登入后进行任何操作,在本校局域网络内 系统应该及时进行反应,每项功能程序需在下达指令完的一秒之内完成。系 统在其开放时间内,不论是教师填写课程或学生选修课程的时候,系统皆需 支持 24 小时的运转。若是发生故障或任何非正常状况,管理者将马上受到 警告通知,且在事后立即查出故障来源所在,迅速进行问题的修复。系统应 能监测出各种非正常情况,如网络断线无法连接数据库,以避免出现长时间 等待或无响应之状况。
(3) 可靠性需求:
系统应保证同时响应 1000 个用户的操作需求,如果超过容许上线用户数时, 对于下一个用户需要给予提示稍后再试消息的功能。
(4) 系统安全性需求: 系统需有严格的权限管理功能,各功能模块需有相对应的权限及角色方可进 入,其中管理者具有修改课程基本数据及学生身份数据的权限,而教师具有 登入使用课程管理系统的能力,学生则具有登入课程选修系统的能力。系统 须能防止各类错误操作所可能造成的威胁,用以防止非法用户获取系统及内 容信息。