大家都知道,大学不同于中学,在大学,没有固定的上课教室,老师也只是上课的时候在,这样,大家在课堂上的问题不能及时的向同学、老师求教。在大学,也不像高中那样,要选课,成绩要自己查,选修、重修、校选课等都要自己在线处理。本系统的用户是学生、教师和教学管理员。学生可以通过本系统在线问、讨论、解答问题;还可以在其他学生那儿在线购买二手物品,也可以玩一些有趣的小游戏,活动下脑袋;另外,学生与老师都可以通过系统处理自己和课程之间事务,如,选课,提问,发布资料,布置、提交作业,上传下载资料等;最后,,提供一个聊天环境,可以在此详细沟通。
1.需求描述:
对在线问答与学科管理系统要求至少提供两个方面的服务:
(1) 在线问答,负责处理学生之间问题的解答;
(2) 学科管理,负责老师、学生、学科三者关系的处理。
在在线问答方面应填写的用户需求描述如下:
(1) 学生可以在线提出、讨论、解答问题;
(2) 学生可以对问题作出相应评判,在允许的情况下,可以将问题作出转载,分享,举报等相关操作;
(3) 学生可以建立兴趣“吧”,通过建立专门的“问题集所”;
在学科管理方面应填写的用户需求描述如下:
(1) 录入与生成新学期课程表
(2) 学生选课注册
(3) 查询
(4) 成绩录入(教师端)
(5) 成绩统计与报表生成(教师端)
为保存数据,需建立相应的数据库,在此不赘述。
2.确定系统范围和边界
首先要明白业务需求和系统目标。本系统主要提供在线学习和学科管理。
3.定义用户
根据本系统用户需求描述可以确定3个参与者:学生、教师、教务管理员。
对于每一个参与者,应当明确其业务活动的内容、对系统的服务要求。
“学生”参与者使用本系统可以展开对学习问题的探究,还可以对学科的相关管理,如,选课,查询成绩等。
“老师”参与者使用本系统可以发布作业,收集作业,对学科相关资料的上传,对出勤的考察等操作。
“教务管理员”参与者主要对其他两类用户的权限控制,以及拥有对数据库的所有操作权限。
4.UseCase的获取
每一个UseCase都是一个参与者与系统在交互中执行的有关事务序列。应当根据用户需求描述,找出全部的UseCase,并从参与者的角度给出事件流,当UseCase执行时系统应提供给参与者的服务。
(1) 聊天界面:提供沟通细节环境。
(2) 问题界面:提出、讨论、解答问题,并可以对问题作出其他相关操作。
(3) 市场界面:可以通过所提供平台找到想要的二手物品信息。
(4) U&D界面:上传与下载资料
(5) 游戏界面:享受益智游戏带来的刺激
(6) 选课:学生选课
(7) 成绩:成绩查询
(8) 教师:学生与教师进行学习活动桥梁,可以做相关统计,发出公告、作业,可以收作业,请假等其他更细致的活动。
5.需求获取描述
(1)
用户需求描述 |
提供用户更细致的沟通 |
用例名 |
聊天界面 |
用例描述 |
学生与学生、学生与老师之间进行直接沟通 |
主要actor |
学生、教师 |
前置条件 |
已发起会话 |
成功后置条件 |
学生、老师发起会话 |
失败后置条件 |
权限受限 |
关联用例 |
问题界面、学科管理操作 |
(2)
用户需求描述 |
学生提出、讨论、解答问题 |
用例名 |
问题界面 |
用例描述 |
学生提出、讨论、解答问题以及其他操作 |
主要actor |
学生、教师 |
前置条件 |
问题产生 |
成功后置条件 |
对问题的操作 |
失败后置条件 |
权限受限 |
关联用例 |
聊天界面、学科管理操作 |
(3)
用户需求描述 |
可以建立相应的兴趣“集所” |
用例名 |
我的兴趣 |
用例描述 |
可以建立相应的兴趣“集所” |
主要actor |
学生、教师 |
前置条件 |
提出建立“集所”请求 |
成功后置条件 |
审批通过 |
失败后置条件 |
审批不通过 |
关联用例 |
(4)
用户需求描述 |
学生进行选课管理 |
用例名 |
学科管理 |
用例描述 |
学生进行选课管理 |
主要actor |
学生 |
前置条件 |
已开设课程且允许选 |
成功后置条件 |
学生进行选择 |
失败后置条件 |
未开设或没有选取权限 |
关联用例 |
学科管理 |
(5)
用户需求描述 |
用户可以选择一些益智游戏娱乐放松 |
用例名 |
游戏 |
用例描述 |
用户可以选择一些益智游戏娱乐放松 |
主要actor |
所有用户:学生、教师、教学管理员 |
前置条件 |
游戏上线、已下载 |
成功后置条件 |
|
失败后置条件 |
未下载 |
关联用例 |