学生学籍管理系统需求分析实施报告

学生学籍管理系统需求分析报告专业：
班级：
组别：
主要完成人：
组员：
2014.6.26
目录
目录0
1.引言 (1)
1.1编写目的 (1)
1.2工程背景 (1)
1.3定义 (2)
1.4参考资料 (2)
2.软件产品的一般性描述 (3)
2.1运行环境与资源 (3)
2.2产品的功能 (3)
2.3用户特征 (4)
2.4限制与约束 (4)
3.系统功能需求 (5)
3.1系统功能模型——用例模型 (5)
3.2相关用例的展开——活动图 (10)
3.3系统静态模型——对象类模型 (12)
3.4系统动态模型 (12)
4. 性能需求 (15)
4.1数据准确度 (15)
4.2时间特性 (15)
4.3适应性 (15)
4.4故障处理 (15)
5.系统运行要求需求 (16)
5.1用户界面 (16)
5.2硬件界面 (16)
5.3软件界面 (16)
6.其它要求 (16)
1.引言
1.1编写目的
本需求分析报告的目的是规化"学生学籍管理系统"软件的编写，旨在于提高软件开发过程中的能见度，便于对软件开发过程中的控制与管理，同时提出了本系统的软件开发过程，便于程序员与客户之间的交流、协作，明确所要开发的软件应具有的功能与性能，并作为工作成果的原始依据，同时也说明了本软件的共性，以期能够获得更大围的应用。

1.2工程背景
传统的学生学籍管理法易发生数据丧失，统计错误，劳动强度高，且速度慢，使用计算机可以高速，快捷的完成以上工作。

在计算机联网后，数据在网上传递，可以实现数据共享，防止重复劳动，规教学管理行为，从而提高了管理效率和水平。

学生学籍管理系统以计算机为工具，通过对教务管理所需的信息管理，把管理人员从繁琐的的数据计算处理中解脱出来，使其有更多的精力从事教务管理政
策的研究实施，教学方案的制定执行和教学质量的监视检查，从而全面提高教学质量。

1.3定义
[1].登录：必须是该校成功注册的用户才有；
[2].修改密码：密码丧失，或为防止个人信息泄露，时常更新密码；
[3].添加新用户：新生入校时，根本信息的添加；
[4].毕业处理：老生离校时，要删除个人信息，释放存储空间，同时修改毕业生数据库，记入档案；
[5].奖惩罚理：得到某项奖励或受到某种惩罚时，会记录在信息里；
[6].休、复学处理：因病或事休学时，后复学，需记录具体时间及原因，记入档案；
[7].退学处理：被退学或者自动退学需办理各项手续后，记入档案；
[8].学生留降级处理：因没有通过规定的考试科目或者违反校纪校规而导致留级，根本信息会被修改，同时会记入档案。

1.4参考资料
[1] 邝武，晓敏，信息系统分析与设计第三版，清华大学
[2] 禹，美琪，软件开发工具[M]，经济科学
[3] SQL SERVE 2000实用教程，清华大学
[4] 珊等，高等教育，数据库系统概论〔第四版〕
2.软件产品的一般性描述2.1运行环境与资源
（1）操作系统：Win7
（2）VS、Rational rose 2003 （3）浏览器：IE
2.2产品的功能
列表：
2.3用户特征
该软件适用于掌握计算机根底知识的用户，学生和教师可根据自己的权限进展相应操作，系统管理员要求由计算机的专业知识。

管理员：对相关容进展管理，对学生的所有信息进展相应的管理；
学生：学校里的普通学生；
教师：学校里的教师职工。

2.4限制与约束
1.由于所要设计的软件较大，设计人员较少，所需设备有限，设计时间短，设计无法完全覆盖所有用户的需求。

2.建议开发软件运行的最短寿命：5年
3.硬件、软件、运行环境和开发环境的条件和限制：安装有Windows 7的操作系统；VS下运行。

3.系统功能需求
3.1系统功能模型——用例模型
创立系统用例的第一步是确定系统的参与者。

学生学籍管理系统的参与者包含以下三种：
管理员，管理员是学校的工作人员，他们为学校的学生执行添加、修改、删除学生信息等操作；学生，学生是该系统中数量最多，也是最重要的参与者。

学生可以选课和查看自己的各类信息；教师，教师也是学校的工作人员，他们为学校的学生提供选课科目，录入成绩的操作。

用例是指对系统角色的交互进展响应，并产生一个可见的结果所进展的一系列动作，它描述了系统的一个完整的功能需求。

本系统中的用例模型如下所示：(1)管理员用例图
3-1管理员用例图
管理员用例描述：
(2)教师用例图
3-2教师用例图教师用例描述：
(3)学生用例图
3-3学生用例图学生用例描述：
3.2相关用例的展开——活动图
活动图用于描述满足用例要求所要进展的活动及活动间的约束关系，有利于识别并行活动，在本学籍管理系统中，主要有活动图如下：
(1)管理员修改信息活动图
A.进入系统界面，显示登录窗口；
B.输入管理员身份的用户名和密码并提交，验证是否正确；
C.如果正确，进入主界面，反之，重新登录；
D.验证正确后，选择修改的工程，修改完成时，；
E.确定修改后，判断是否需要继续修改，如果是，那么继续，否那么不继续；
F.更新数据库，完毕修改。

根据上述过程，创立的活动图如图3-4所示：
3-4管理员修改信息活动图
(2)教师成绩管理活动图
A.进入系统界面，显示登录窗口；
B.输入教师身份的用户名和密码并提交，验证是否正确；
C.如果正确，进入主界面，反之，重新登录；
D.进入系统后，选择科目和录入成绩的班级，确定导入数据完成；
E.完成后，判断是否继续导入，如果是，那么选择录入成绩的班级继续导入，否那么不继续；
F.完成导入数据，更新数据库。

根据上述过程，创立的活动图如图3-5所示：
3-5教师成绩管理活动图
(3)学生选课活动图
A.进入系统界面，显示登录窗口；
B.输入学生身份的用户名和密码并提交，验证是否正确；
C.如果正确，进入主界面，反之，重新登录；
D.进入选课界面，选择已有的可选择的科目，确定选课；
E.判断选课人数，假设人数已满，那么重新选择，否那么人数未满，可以完成选课；
F.选课完毕，更新数据库，教师可查看选课信息。

根据上述过程，创立的活动图如图3-6所示：
3-6学生选课活动图
(4)学生成绩查询活动图
在学生成绩查询的活动图中，创立了三个泳道，分别是管理员对象、教师对象和学生对象，具体的活动过程描述如下：
A.进入系统界面，显示登录窗口；
B.输入学生身份的用户名和密码并提交，验证是否正确；
C.如果无误，查看完毕；
D.如果正确，进入主界面，反之，重新登录；
E.进入成绩查询界面，选择需要查询的学年，查看成绩；
F.如果成绩有误，通知管理员，管理员联系任课教师核对；
G.核对后，教师修改成绩，提交；
H.更新数据库。

根据上述过程，创立的活动图如图3-7所示：
3-7学生成绩查询活动图
3.3系统静态模型——对象类模型
根据系统需求，创立静态系统类图。

我们可以识别系统中存在的主要实体类：管理员，教师和学生。

根据系统划分的三类包图，分别讨论人员信息，接口和事务。

其中，人员信息包含学生，教师和管理员三个类；接口包含系统设置、用户登录、管理员管理模块、教师管理模块、学生管理模块五个接口模块类；事务包含教师成绩管理、用户登录、管理员系统管理、学生选课管理、学生成绩管理、学生信息管理留个事务类。

类图包括类的属性和行为，用户接口及联系等面的信息。

本学籍管理系统的主要类图及关系如以下列图所示：
(1)人员信息类图
3-8人员信息类图
(2)接口类图
3-9接口类图
(3)事务包类图
3-10事务包类图
3.4系统动态模型
系统的动态模型可以使用交互作用图、状态图和活动图来描述。

交互作用图包括序列图和协作图。

序列图描绘了系统中的一组对象在时间上交互的整体行为，协作图描绘的是系统中一组对象的交互行为。

创立顺序图：
在学生学籍系统中，通过系统用例的描述，可以获得以下交互行为。

学生〔教师、管理员〕登录本系统；
学生通过管理员查看个人信息或者成绩；
管理员修改教师信息；
学生通过教师选择课程；
教师录入学生成绩。

时序图用于显示对象之间动态合作关系，它强调对象之间发送消息的顺序，同时显示对象之间的交互。

在本学籍管理系统中，需要建立学生选课时序图和教师录入成绩时序图。

(1)学生选课时序图
A.学生想通过系统进展某一项操作；
B.学生启动系统，并在登录界面输入用户名和密码，系统验证学生的用户名和密码是否正确，如正确，创立系统主界面；
C. 根据选择，进入选课界面，可查看可选课程，成功选课后，保存选课信息；
D.选课成功，更新选课数据库，退回选课界面。

根据根本流程，银行职员登录银行系统的顺序图如图3-11所示。

3-11 学生选课时序图
(2)教师录入成绩时序图
A.教师想通过系统进展某一项操作；
B.教师启动系统，并在登录界面输入用户名和密码，系统验证教师的用户名和密码是否正确，如正确，创立系统主界面；
C. 根据选择，进入成绩录入界面，可添加、修改、查询成绩，完成后，保存成
绩信息；
D.成绩录入成功，更新成绩数据库，退出系统。

3-12教师录入成绩时序图
（3）学生查看个人信息时序图
A.学生想通过系统进展某一项操作；
B.学生启动系统，并在登录界面输入用户名和密码，系统验证学生的用户名和密码是否正确，如正确，创立系统主界面；
C. 根据选择，进入查询信息界面，输入学号，假设存在那么查询个人信息，否那么重新返回查询界面；
D.查询信息成功，显示要查询的信息。

3-13 学生查看信息时序图
(4)管理员修改教师信息时序图
A.管理员想通过系统进展某一项操作；
B.管理员启动系统，并在登录界面输入用户名和密码，系统验证管理员的用户名和密码是否正确，如正确，创立系统主界面；
C. 根据选择，进入教师信息查询界面，可查询教师信息，查询成功那么输入修改命令进展修改，查询失败那么返回；
D.教师信息修改成功，更新教师信息数据库。

3-14 管理员修改教师信息时序图
(5)新生注册时序图
A.学生想通过系统进展某一项操作；
B.学生启动系统，并在登录界面选择注册，进入注册界面；
C. 填写注册信息后，判断是否已经注册过，假设已注册那么返回，否那么注册成功，点击完成；
D.注册成功，更新学生数据库，返回注册界面。

3-15 新生注册时序图
4. 性能需求
4.1数据准确度
要按照格的数据格式输入，否那么系统不给予响应进展处理。

查询时要保证查全率，所有相应域包含查询关键字的记录都应能查到。

4.2时间特性
响应时间，更新处理时间都比拟快且迅速，完全满足用户要求。

4.3适应性
系统具有较高的可靠性,可恢复性，有良好的可扩展性，允管理员随时对其进展更新和维护。

当用户需求，如操作式，运行环境，结果精度等发生变化时，设计的软件要做适当调整,灵活性较好。

4.4故障处理
系统失效后能给出错误信息，提示用户采取适当手段处理故障并保障用户数据信息不能丧失。

5.系统运行要求需求
5.1用户界面
人性化界面，全新感觉，操作简便，一目了然，对用户友好
5.2硬件界面
普通PC机
5.3软件界面
简便易用，突出重点，容错高
6.其它要求
平安性、复用性、灵活性、易用性、可维护性、可移植性等。

指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植优于有效性。

普通用户的需求：对于只有查看权限的用户，一般是通过上网浏览学校网页来查看数据；各教务管理员：能够对系统进展设置，以适应不同用户的需求。