【软件工程】需求分析

1. 导言

1.1. 需求文档的目的

该文档是关于用户对于“学生成绩管理系统”的功能和性能的要求，重点描述了“学生成绩管理系统”的设计需求，将作为对该工具在概要设计阶段的设计输入。编写本文档的目的在于说明软件工程管理系统的业务需求内容，包括功能需求及非功能需求，并为系统设计提供基础。

1.2. 产品范围

本产品适用于普通学校的普通的期中考试以及期末考试，可以很方便地对学生成绩进行管理和查询。

2. 系统定义

2.1. 系统概述

本系统的主要功能如下：本系统分为三个用户类型——教师、学生、管理员。其中教师可以查看成绩、登记成绩并进行修改，学生可以查看成绩并且可以对自己的成绩进行申诉，管理员负责后台管理以及对学生的成绩申诉进行审核，审核通过后告知教师进行成绩重审和修改。

3. 应用环境

3.1. 系统运行网络环境

网络拓扑图如图3.1所示。

图3.1 网络拓扑图

3.2. 系统运行硬件环境

• CPU:1.8GHz

• 存储空间：450GB

• 内存：256MB以上

3.3. 系统运行软件环境

• 操作系统：Windows 11 家庭版

• 数据库：MySQL 8.0

• 集成开发环境：IntelliJ IDEA 2023.1

• 开发工具包：JDK Version 21

• 浏览器：Edge 浏览器或 Chrome 浏览器

4. 功能规格（功能性需求）

4.1. 需求概述

4.1.1. 角色定义

教师：教师可以查看所教学生的成绩、登记所教科目的成绩并进行修改。

管理员：负责后台管理以及对学生的成绩申诉进行审核，审核通过后告知教师进行成绩重审和修改。维护服务器 、收集用户反馈、管理用户账号的人员。

学生：可以查看自己的成绩并且可以对自己的成绩进行申诉。

4.1.2. 系统功能概述

简单介绍本系统的功能。本系统是为了辅助学校实现众多学生的成绩管理，方便学校和老师的教学开展。本系统分为三个用户类型——教师、学生、管理员。其中教师可以登记成绩并进行修改，学生可以查看成绩并且可以对自己的成绩进行申诉，管理员负责后台管理以及对学生的成绩申诉进行审核，审核通过后告知教师进行成绩重审和修改。

4.1.3. 系统功能详细描述

学生：作为学生成绩管理系统的主体用户，需要使用学号（作为账号），密码进行注册或登录，登陆后可以查看自己各门课的成绩。如果对成绩有很大异议，可以在写好申诉理由后向管理员申诉（申诉理由需要足够充分）。

教师：需要使用工号（作为账号），密码进行注册或登录，登录后可以看到自己所教授的这门课的学生基本信息，可以打分并上传，交由管理员审核。也可以选择修改、撤回分数。

管理员：拥有系统的最高权限，可以允许查看、删除和添加老师和学生的账户信息。其账号和密码事先给定，不允许普通用户自由注册。负责系统的日常管理与运营。可以审核老师提交的成绩信息，审核通过就正式发布，不通过就打回，顺便给出理由。可以审核学生提交的申诉信息，通过则通知老师再次核实成绩，不通过则驳回。

4.1.4. 系统的环境图

以下是系统的环境图（顶层数据流图）。

图4.1 系统顶层数据流图

4.2. 功能需求

采用SA方法或OOA方法建立系统的分析模型。

4.2.1. 功能模型

（1）管理员用例图如图4.2所示：

图4.2 系统管理员用例图

用例表1-1

用例名称：登录	执行者：管理员
1.1前置条件：计算机接入互联网
1.2后置条件：如果用例执行成功，系统进入初始界面
1.3主事件流：
1）管理员打开登陆界面，此用例开始。
2）管理员输入账号密码。
3）进入初始界面，此用例结束。

用例表1-2

用例名称：审核内容	执行者：管理员
1.1前置条件：老师上传了学生成绩
1.2后置条件：审核完成后，将学生成绩发布到各个账号
1.3主事件流：
1）管理员点击审核成绩，此用例开始。
2）审核完成后，点击发布，此用例结束。

用例表1-3

用例名称：账号管理	执行者：管理员
1.1前置条件：登陆成功并进入管理员界面
1.2后置条件：输出相应操作
1.3主事件流：
1）点击账号管理，此用例开始。
2）点击操作类型，进行操作。
3）操作成功后，此用例结束。

（2）教师用例图如图4.3所示：

图4.3 教师用例图

用例表2-1

用例名称：登录注册	执行者：教师
1.1前置条件：计算机连上互联网
1.2后置条件：如果此用例成功，则系统提示“注册成功”。如果执行不成功，系统状态不变，提示“注册失败”。
1.3主事件流：
1）教师登录网页点击注册，此用例开始。
2）填写自己的教工号，设置密码。
3）点击注册，系统提示操作成功，此用例结束。

用例表2-2

用例名称：查看学生成绩	执行者：教师
1.1前置条件：学生账号存在，成绩已录入。
1.2后置条件：如果此用例成功，则此教师可以看到成绩界面。如果执行不成功，系统状态不变。
1.3主事件流：
1）教师点击查看学生成绩，此用例开始。
2）查看成功，此用例结束。

用例表2-3

用例名称：查看申诉	执行者：教师
1.1前置条件：有学生申诉
1.2后置条件：如果此用例成功，则此教师可以看到学生申诉界面。如果执行不成功，系统状态不变。
1.3主事件流：
1）教师点击查看成绩申诉，此用例开始。
2）查看成功，根据实际情况调用编辑学生成绩用例，此用例结束。

用例表2-4

用例名称：编辑学生成绩	执行者：教师
1.1前置条件：登录教师账号
1.2后置条件：无
1.3主事件流：
1）教师点击编辑学生成绩，此用例开始。
2）填写完毕，此用例结束。

（3）学生用例图如图4.4所示：

图4.4 学生用例图

用例表3-1

用例名称：登录注册	执行者：学生
1.1前置条件：计算机接入互联网
1.2后置条件：如果此用例成功，则系统提示“注册成功”。如果执行不成功，系统状态不变，提示“注册失败”。
1.3主事件流：
1）学生登录网页点击注册，此用例开始。
2）填写自己的学号，设置密码。
3）点击注册，系统提示操作成功，此用例结束。

用例表3-2

用例名称：申诉	执行者：学生
1.1前置条件：学生对成绩有异议
1.2后置条件：无
1.3主事件流：
1）学生点击申诉，此用例开始。
2）点击申诉的科目。
3）系统提示操作成功，此用例结束。

用例表3-3

用例名称：查看成绩	执行者：学生
1.1前置条件：学生成绩已存在于数据库中
1.2后置条件：如果此用例成功，则此学生可以查看到自己的成绩界面。如果执行不成功，系统状态不变。
1.3主事件流：
1）学生点击“查看成绩”，此用例开始。
2）系统提示操作成功，此用例结束

4.2.2. 数据模型/对象模型

创建的系统类图如图所示：

图4.3 类图示例

表1. 各个类的属性

类与对象	属性
teacher(教师)	教工号，姓名
student(学生)	学号，姓名，性别
administrator(管理员)	管理员工号，姓名

表2. 各个类的服务

类与对象	服务
teacher(教师)	查询、编辑学生成绩，查看申诉情况
student(学生)	查询成绩，申诉成绩
administrator(管理员)	管理账号，审核成绩，维护系统

4.2.3. 动态模型

图4.4 登录界面的顺序图

图4.5 教师打分的状态图

5. 非功能性需求

逐项叙述系统的各项非功能性需求。

登陆界面：在成绩管理系统中，学生更喜欢简洁、直观的呈现方式。因此我们并没有选择美观的图案，而是采取了极简风格，不给用户增加使用时的烦赘体验。同时，我们采取用户的学号以及教职工号作为用户名，以此来和学校的学生管理相匹配。根据登陆时的用户名，将用户自动分为“教师”、“学生”和“管理员”，此后根据每个用户身份会有不同的使用界面。

5.1性能需求

1. 响应时间：基于现实考虑，因为大于3秒的响应时间会很影响使用者的使用体验，因此我们对软件的响应时间进行了约束，在本机测试中所有功能最迟响应时间为1.387秒。

2. 吞吐量：考虑到每个班级人数，我们设定为同一时间最大访问人数为50人，即允许50人同时访问网站。

5.2 安全性

权限控制：本项目的最高权限设置给管理员，此下为老师，学生权限只有查看。且未完成登记的人员不会有使用本程序的权限。

5.3 可维护性与可拓展性

模块性： 本项目所涉及的所有功能均由各个文件打包完成，整个系统被分成独立的版块，并且每个版块独立实现功能。

可复用性：在系统中我们把很多的代码进行了优化，这使得在实现各个功能时，我们可以依靠之前的代码模板，高效的进行功能的拓展。

5.4 易用性

易操作性：将系统的每个版块设计得很直观，并且系统的功能通过不同的按键来表达，直观高效，操作简单。

易学习性：系统的所有功能表达直接，并且均设置在用户容易看见的位置，使得用户并不需要使用手册也可以迅速使用系统。

用户错误防御机制：当用户错误登陆或者其他错误操作时，会有“哭脸”和提示出现，指明用户的错误操作，并且提示给用户正确做法。