课程设计管理系统需求规格说明书
版本:V2.0
发行日期:2010/01/04
作者：ITeam小组
修改情况一览表
版本Version
出版日期
Issue Date
修订章节
Section
Changed
修订原因
Reason for Issue
修订者
Modifier
1.02009-10-19全部章节首次发行ITeam小组1.12009-11-29全部章节细化完善ITeam小组
2.02010-1-4全部章节 1.修改了用例
2.修改了SSD图
3.新增了数据字典
ITeam小组
目录
1引言 (1)
1.1编写目的 (1)
1.2项目背景 (1)
1.3定义 (1)
1.4参考资料 (2)
2任务概述 (2)
2.1目标 (2)
2.2运行环境 (3)
3数据描述 (3)
3.1静态数据 (3)
3.2动态数据 (4)
3.3数据库介绍 (4)
3.4数据字典（部分） (4)
4功能需求 (2)
4.1功能划分 (2)
4.2功能描述 (7)
4.3领域模型（Domain Model） (40)
4.4系统顺序图（System Sequence Diagram） (41)
4.5界面原型（首页） (49)
5性能需求 (49)
5.1数据精确度 (49)
5.2时间特性 (50)
5.3适应性 (50)
5.4可维护性 (50)
6其它需求 (50)
1引言
1.1编写目的
为了使本系统的使用者和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础，明确系统需要实现的功能,确定需求边界。特编制本文档。本文档一经确认，将成为系统开发人员进行开发以及用户对系统验收的依据。
本文档的预期读者有：本系统的最终使用者、系统管理人员、本系统开发人员、本系统测试人员。
1.2项目背景
项目名称：课程设计管理平台；
项目开发小组成员：ITeam团队；
用户：厦门大学软件工程全体教师、助教以及学生；
项目开发环境：Windows XP+Sql server2005+Visual Studio2008；
1.3定义
术语定义和信息格式别名
学生信息学生明细包含学号、姓名、系别、年级以及所选的
课程等信息，用于唯一确定学生并与其它
项目信息相关联
小组明细小组信息包含小组号、小组名称以及成立时间，用
于唯一确定小组并与其它信息相关联
邀请由组长发送给未分组学生的邀请信息。包
受邀通知
含发送小组信息。
学生名单由老师提交给管理员的、要求导入系统
的、选学本门课程的学生信息。
课程信息由管理员或者老师设定或修改的有关本
门课程的有关信息，其中包括课程开设的
名称、类型以及描述。
项目信息由老师发布、修改或删除的有关所开设的
课程项目的信息，其中包括项目名字、描
述以及成立时间。
模式处理某一信息（通知等）或事件（例如分
组）的系统状态。
日志用来记录用户操作、系统异常以及错误操
作。
普通学生未分组的学生
项目约束
分组约束包括项目的最大分组数、小组内人数上
限、分组开始时间以及结束时间。
1.4参考资料
1.UML和模式应用（第三版）——机械工业出版社
2.C#高级编程（第六版）——清华大学出版社
3.Visual C#学习笔记——电子工业出版社（2008.5）
2任务概述
2.1目标
●系统的应用背景以及所要解决的问题
随着我国教育体制的不断改革，我们逐渐发现在改革之中存在的难以很快解决的问题，其中很大一部分原因在于学生与老师在教学方式和沟通方式上仍然缺少适应新时代新阶段的变化，我们的教育仍然采用“灌输式学习”的方式，虽然这在某种程度上保证了个别“目光短浅”的人所追求的“升学率”、“状元学生”。但在很大程度上阻碍了整体学生的思维与创造性的发展，从长远来看，必然对我国的青少年不利，更多我国的未来不利！
从这种现状来看，目前的“灌输式学习”方式亟待改进，我们的教育方式有必要由先前的“灌输式学习”向“问题式学习（Problem-based Learning）”过渡乃至转变。所谓“问题式学习”就是把学习设置到实际的、复杂的、有意义的问题情境中，通过让学习者合作解决真实的问题，来学习隐含于问题背后的科学知识，形成提出问题、分析问题、解决问题的技能，并形成自主学习（self-directed learning）的能力。问题式学习旨在使学习者建构起宽厚而灵活的知识基础；发展灵活的问题解决技能；发展自主学习和终生学习的技能；成为有效的倾听者、合作者；并培养学习的内部动机。这种模式的典型学过程是：学生以小组为单位，解决或改进一个实际问题；为了解决实际问题，学生往往需要获得一些必要的专业知识以及书本上没有的相关知识技能；即所谓的学习议题，学生分头查找资料获取知识,然后相互交流所获得的知识，并讨论如何用所获得的知识来促进实际问题的解决；如果在讨论的过程中；小组发现还需要研究另外一些新的学习议题，学生们就需要反复循环地产生学习议题、分头查找资料、小组交流并讨论问题解答，直到问题得到解决；问题解决后，学生们还需要对自己的学习过程进行自我反思和评价，总结所获得的知识和思维技能。在此过程中学生可以随时与老师进行有效的沟通并反馈阶段性成果，得到老师的评价和建议。老师在这个环节中起到引导、建议和解答疑问的作用，具体实现全部由学生来进行。这样一来，开发一个能够以学期时间段内教师项目管理功能为主导，为教师与学生搭建一个学期内项目管理与设计的平台，集成项目安排、分组、阶段审核、答疑与评分等功能与一体的系统平台就是相当必要的，系统可以方便教师对项目进行准确的统一的管理，同时也方便学生进行建立小组、安排分工、集中讨论等工作。提高教师与学生的工作和学习效率，节省时间，减轻工作人员劳动强度。
●平台主要的功能范围（以角色划分的主要功能范围）
角色角色相关主要功能共性功能
管理员课程管理，涉及到课程的新建、修改以及取消等功能。在论坛中发帖
以及回帖。
用户的新增、修改以及删除和角色的分配。
系统公告管理。
普通学生可新建小组，也可发送申请加入其它小组
组员可退出小组，同时也可以接手组长职责的移交。
组长小组管理，包括申请等相关业务的处理以及小组人员的变
更。
小组公告管理。
小组作业管理，涉及到小组内成员之间的作业分工，提交作
业，下载点评后的作业等。
教师课程公告管理。
项目管理，新增课程项目、修改课程项目以及取消项目。
项目作业管理，发布作业、修改以及取消作业。
助教项目管理，与教师的项目管理相比，少了删除项目以及发布
项目的权限。
项目作业管理。
匿名用户只能浏览首页以及系统公告，无其它实质性的功能操作。×2.2运行环境
操作系统：Microsoft Windows XP Professional SP3；
数据库：Microsoft SQL Server2005；
服务器：IIS5.0；
3数据描述
3.1静态数据
用户信息：管理员、教师和学生的信息（学号、工号、姓名等）。
课程信息：课程号、开课号、课程时间、上课地点等。
项目信息：开始时间、结束时间、最大小组数、每组最大人数等。
教师身份分类：教师、助教。
学生身份分类：未分组学生、小组成员、小组组长。
3.2动态数据
用户输入：用户名、密码等键盘和鼠标输入操作。
系统输入：更新数据库信息、生成系统日志和错误报告。系统输出：各种提示信息与通知。
3.3数据库介绍
数据库名称：sql server2005。
3.4数据字典（部分）
名字：课程总编号2#17-01别名：
描述：由管理员为教师开设的、进行教学活动的基本单元
定义：课程=课程编号+课程全称+课程简称+课程类型+课程描述+开设时间+上课
地点+上课时间
位置：储存在数据库中名字：项目总编号2#17-02别名：
描述：由教师开设的、用于辅助学生学习的教学环节
定义：项目=项目编号+项目全称+项目简称+项目描述+开设时间+项目约束
位置：储存在数据库中
名字：项目约束总编号2#17-03别名：项目分组限制
描述：由教师设置的、用于限定项目下学生分组活动的基本前提条件。
定义：项目约束=编号+项目分组上限+小组人数上限+分组开始时间+分组截止
时间
位置：项目名字：学生名单总编号2#17-04别名：
描述：由教师交给管理员的、选学教师所开设课程的学生明细表
定义：学生名单=学生标号+真实姓名+系别+年级
位置：储存在数据库中
名字：学生标号总编号2#17-05别名：学号
描述：唯一地标识学生名单中一个特定学生的关键域
定义：学生标号=14{数字}14
位置：学生名单名字：消息总编号2#17-06别名：
描述：用户之间传递信息的介质。
定义：消息=编号+发送人+接收人+主题+内容+发生时间
位置：储存在数据库中
4功能需求4.1功能划分
Model-1日志管理：
Model-2用户管理：
Model-3项目管理：
Model-4课程管理：
Model-5公告管理：
Model-6小组管理：
Model-7消息管理：
Model-8论坛管理：集成其他小组。Model-9作业管理：集成其他小组。
简述用例
添加用户管理员添加用户，可以单个添加，也可以从Excel文件中导入
编辑用户管理员对用户的各项信息进行修改（密码除外）
取消用户管理员删除用户
注册用户允许用户自行注册
指定角色管理员指定用户角色
导入用户由系统管理员批量导入
修改密码用户可以修改自己的密码
开设课程管理员添加课程信息，新建课程
修改课程管理员对课程的各项信息进行修改
取消课程管理员删除课程
开设项目教师添加项目信息，新建课程，教师只能增加自己课程下的项目
修改项目教师对项目的各项信息进行修改，教师只能修改自己课程下的项目
取消项目管理员或教师删除项目，教师只能删除自己课程下的项目
创建小组未加入小组的同学，在允许创建小组的情况下可以新建小组
发送邀请组长可以向未加入小组的同学发出入组邀请
发送申请未加入小组的同学可以向小组提出加入申请
处理邀请未加入小组的同学同意某小组组长发来的邀请，加入其小组
处理申请组长同意或拒绝其它人对于申请入组的请求
踢出组员组长踢出小组中的某个组员，系统给其发送通知
移交组长组长退出小组，若小组内还有其它成员，将组长权限交给其中一个组员接手小组组员在组长移交组长权限后可以接手组长权限
退出小组小组成员退出小组，系统发布小组公告
撤销小组组长解散小组，所有小组成员成为未加入分组身份
解散小组创建小组截止时间到了，有人数不合要求的小组，由教师撤销其小组查看日志管理员输入关键字，搜索相关系统日志，查看日志
删除日志管理员删除某条特定日志
清空日志管理员清空某一时间段内的系统日志
发布公告发布系统、课程、项目、小组四个级别的通知，接收范围依次递减
浏览公告查看系统、课程、项目、小组四个级别的通知，权限范围依次递减
修改公告修改系统、课程、项目、小组四个级别的通知，权限范围依次递增
取消公告删除系统、课程、项目、小组四个级别的通知，权限范围依次递增
浏览消息查看某一封消息
发送消息向特定范围或某人发送私人或公共消息
删除消息消息接收人可以删除自己接收到的消息或自己发送的消息
4.2功能描述
用例创建小组编号UC1
作者张晓东时间2009-11-18
范围：课程设计管理平台
级别：用户目标
主要参与者：普通学生
涉众及其关注点：
—普通学生：希望自己创建小组的信息能够及时地通知到相关人员（尤其是至今还未进入分组的同学）。
—管理员：希望系统能够有一定的容错性，同时，如果平台出错，能够在较短的时间内方便地完成恢复和维护。
前置条件：
1.普通学生已经登录系统。
2.还未到达分组截止时间。
成功保证：小组创建成功。
主成功场景：
1.普通学生要求创建小组；
2.系统同意并给予响应，要求添加相关小组资料；
3.普通学生填写小组资料，确认后并提交；
4.系统认证后，提示创建成功，并保存小组信息，生成日志；
扩展：
*a.平台在任意时刻失败。
1.管理员重启系统。
4a.系统认证失败。
1.系统通知普通学生失败的原因。
2.普通学生根据失败提示信息，重新填写小组资料。
3.普通学生再次确认、提交。
特殊需求：
●支持文本显示语言的国际化。
●能够支持至少300人同时访问系统。
●每一个操作时间小于0.5秒。
技术与数据变元素：
*a.登录不需要支持ID读卡器，只要求键盘输入。
发生频率：可能要不断地发生。
未决问题：无
用例发送邀请编号UC2
作者张晓东时间2009-11-18
范围：课程设计管理平台
级别：用户目标
主要参与者：组长
涉众及其关注点：
—组长：希望自己能够向满意的同学成功发送邀请。
—管理员：希望系统能够有一定的容错性，同时，如果平台出错，能够在较短的时间内方便地完成恢复和维护。
前置条件：
1.组长已经登录系统。
2.还未到达分组截止时间。
成功保证：邀请发送成功。
主成功场景：
1.组长要求浏览学生明细；
2.系统给予响应，显示所有学生明细；
3.组长选择满意的同学，发送邀请。
4.系统提示邀请发送成功，并保存相关信息；
扩展：
*a.平台在任意时刻失败。
1.管理员重启系统。
1a.组长也可以进行关键字（姓名等）查询方式，查找某位学生。
2a.学生明细支持多种查看方式，全部学生明细、已分组的学生明细和未分组的学生明细。特殊需求：
●支持文本显示语言的国际化。
●能够支持至少300人同时访问系统。
●每一个操作时间小于0.5秒。
技术与数据变元素：
*a.登录不需要支持ID读卡器，只要求键盘输入。
发生频率：可能要不断地发生。
未决问题：无
用例处理邀请编号UC3
作者张晓东时间2009-11-18
范围：课程设计管理平台
级别：用户目标
主要参与者：普通学生
涉众及其关注点：
—普通学生：希望自己能够清楚地、及时地查看受邀信息。
—管理员：希望系统能够有一定的容错性，同时，如果平台出错，能够在较短的时间内方便地完成恢复和维护。
前置条件：
1.普通学生已经登录系统。
2.还未到达分组截止时间。
成功保证：成功处理邀请信息，或将同意加入小组。
主成功场景：
1.系统提示有未处理的邀请信息。
2.普通学生要求查看全部邀请信息。
3.系统显示全部邀请信息。
4.普通学生选择具体邀请，要求查看详细内容。
5.系统返回邀请的详细内容。
6.普通学生查看后同意加入。
7.系统保持修改，生成日志，提示普通学生成功加入，并通知小组内其他成员。
扩展：
*a.平台在任意时刻失败。
1.管理员重启系统。
6a.普通小组拒绝邀请。
1.系统要求普通学生进行确认。
2.普通学生确认无误。
3.系统给予普通学生提示，并通知发送邀请的小组组长。
4.普通学生处理其他邀请。
特殊需求：
●支持文本显示语言的国际化。
●能够支持至少300人同时访问系统。
●每一个操作时间小于0.5秒。
技术与数据变元素：
*a.登录不需要支持ID读卡器，只要求键盘输入。
发生频率：可能要不断地发生。
未决问题：无
用例发送申请编号UC4
作者张晓东时间2009-11-18
范围：课程设计管理平台
级别：用户目标
主要参与者：普通学生
涉众及其关注点：
—普通学生：希望系统能够提供详细的现有项目小组的信息，并成功地加入其满意的分组。—管理员：希望系统能够有一定的容错性，同时，如果平台出错，能够在较短的时间内方便地完成恢复和维护。
前置条件：
1.普通学生已经登录系统。
2.还未到达分组截止时间。
成功保证：成功发出申请。
主成功场景：
1.普通学生要求查看现有全部小组信息。
2.系统给予响应，返回现有全部小组信息。
3.普通学生选择目标小组，发送申请。
4.系统要求确认。
5.普通学生确认无误。
6.系统发送申请，提示成功发送，并将此事件写入日志。
扩展：
*a.平台在任意时刻失败。
1.管理员重启系统。
1a.至今未有项目小组。
1.系统给出提示，并建议自建小组或稍后再来。
1b.系统支持多种查看方式，查看所有人数未达上限的小组明细、已达上限的小组明细和全部小组明细。
3a.普通学生撤销申请。
1.普通学生提出撤销要求。
2.系统撤销普通学生发送给目标小组的申请。
2a.撤销失败。
1.系统提示撤销失败并建议延期操作。
2.系统返回申请模式。
2b.撤销成功。
1.系统提示撤销成功并返回到申请模式。
2c.由于此小组可能已解散，系统找不到此小组。
1.系统发出提示信息，产生错误日志。
2.系统更新申请明细。
3.普通学生处理其他申请。
5a.普通学生觉察错误，取消操作。
1.系统返回到申请模式。
特殊需求：
●支持文本显示语言的国际化。
●能够支持至少300人同时访问系统。
●每一个操作时间小于0.5秒。
技术与数据变元素：
*a.登录不需要支持ID读卡器，只要求键盘输入。
发生频率：可能要不断地发生。
未决问题：无
用例处理申请编号UC5
作者张晓东时间2009-11-18
范围：课程设计管理平台
级别：用户目标
主要参与者：组长
涉众及其关注点：
—组长：希望自己能够清楚、及时地处理所有申请。
—管理员：希望系统能够有一定的容错性，同时，如果平台出错，能够在较短的时间内方便地完成恢复和维护。
前置条件：
1.组长已经成功登录系统。
2.还未到达分组截止时间。
成功保证：成功处理所有申请。
主成功场景：
1.系统提示有未处理的申请。
2.组长要求查看全部申请。
3.系统显示全部申请。
4.组长选择具体申请，要求查看申请详细内容。
5.系统返回申请的详细内容。
6.组长查看后，同意发送申请的普通学生的入组要求。
7.系统保存修改，生成日志，通知申请发送人和小组其他成员。
扩展：
*a.平台在任意时刻失败。
1.管理员重启系统。
6a.组长拒绝入组申请。
1.系统要求确认。
2.组长予以确认。
3.系统通知申请发送人。
4.组长处理其他申请。
特殊需求：
●支持文本显示语言的国际化。
●能够支持至少300人同时访问系统。
●每一个操作时间小于0.5秒。
技术与数据变元素：
*a.登录不需要支持ID读卡器，只要求键盘输入。
发生频率：可能要不断地发生。
未决问题：无
用例踢出组员编号UC6
作者张晓东时间2009-11-18
范围：课程设计管理平台
级别：用户目标
主要参与者：组长
涉众及其关注点：
—组长：希望自己能够成功踢出不满意的组员。
—管理员：希望系统能够有一定的容错性，同时，如果平台出错，能够在较短的时间内方便地完成恢复和维护。
前置条件：
1.组长已经成功登录系统。
2.还未到达分组截止时间。
成功保证：成功踢出不满意的组员。
主成功场景：
1.组长要求查看全部组员信息。
2.系统显示全部组员信息。
3.组长选择不满意的组员，要求踢出小组。
4.系统要求予以确认。
5.组长确认无误。
6.系统保持修改，生成日志，并提示踢出成功，通知相关组员以及其他小组成员。
扩展：
*a.平台在任意时刻失败。
1.管理员重启系统。
5a.组长察觉错误，要求取消操作。
1.系统返回到显示全部组员信息模式。
特殊需求：
●支持文本显示语言的国际化。
●能够支持至少300人同时访问系统。
●每一个操作时间小于0.5秒。
技术与数据变元素：
*a.登录不需要支持ID读卡器，只要求键盘输入。
发生频率：可能要不断地发生。
未决问题：无
用例移交组长编号UC7
作者张晓东时间2009-11-18
范围：课程设计管理平台
级别：用户目标
主要参与者：组长
涉众及其关注点：
—组长：希望自己能够成功将组长职务移交到小组其他成员手中。
—管理员：希望系统能够有一定的容错性，同时，如果平台出错，能够在较短的时间内方便地完成恢复和维护。
前置条件：
1.组长已经成功登录系统。
2.还未到达分组截止时间。
成功保证：成功移交组长权限。
主成功场景：
1.组长要求移交组长权限。
2.系统给予响应，显示小组内其他成员。
3.组长选择目标组员，将组长权限移交。
4.系统要求组长确认。
5.组长予以确认。
6.系统保存修改，生成日志，通知组长、相关组员以及小组内其他成员。
扩展：
*a.平台在任意时刻失败。
1.管理员重启系统。
5a.组长察觉错误，要求取消操作。
1.系统返回显示小组内其他成员。
特殊需求：
●支持文本显示语言的国际化。
●能够支持至少300人同时访问系统。
●每一个操作时间小于0.5秒。
技术与数据变元素：
*a.登录不需要支持ID读卡器，只要求键盘输入。
发生频率：可能要不断地发生。
未决问题：无
用例退出小组编号UC8
作者张晓东时间2009-11-18
范围：课程设计管理平台
级别：用户目标
主要参与者：组员
涉众及其关注点：
—组长：希望自己能够成功地退出现在的小组，以谋求更好的选择。
—管理员：希望系统能够有一定的容错性，同时，如果平台出错，能够在较短的时间内方便地完成恢复和维护。
前置条件：
1.组员已经成功登录系统。
2.还未到达分组截止时间。
成功保证：成功退出小组。
主成功场景：
1.组员要求退出现在的小组。
2.系统要求组员予以确认。
3.组员确认信息无误。
4.系统保存修改，生成日志，提示操作成功并通知其他组员。
扩展：
*a.平台在任意时刻失败。
1.管理员重启系统。
2a.组员察觉错误，要求取消操作。
1.系统返回到小组模式。
特殊需求：
●支持文本显示语言的国际化。
●能够支持至少300人同时访问系统。
●每一个操作时间小于0.5秒。
技术与数据变元素：
*a.登录不需要支持ID读卡器，只要求键盘输入。
发生频率：可能要不断地发生。
未决问题：无
用例接手小组编号UC9
作者张晓东时间2009-11-18
范围：课程设计管理平台
级别：用户目标
主要参与者：组员
涉众及其关注点：
—组员：希望能够快速准确地完成操作。
前置条件：
1.组员已经成功登录系统。
2.还未到达分组截止时间。
成功保证：成功退出小组。
主成功场景：
1.组员要求接手小组。
2.系统要求组员予以确认。
3.组员确认信息无误。
4.系统保存修改，生成日志，提示操作成功并通知其他组员。
扩展：
*a.平台在任意时刻失败。