软件需求规格说明
1. 引言
1. 1目的
1. 2文档约定
1. 3预期的读者和阅读建议
1. 4产品的范围
1. 5参考文献
2. 综合描述
2.1产品的前景
2.2产品的功能
2.3用户类和特征
2.4运行环境
2.5设计和实现上的限制
2.6假设和依赖
3. 外部接口需求
3. 1用户界面
3. 2硬件接口
3.3软件接口
3.4通信接口
4.系统特性
4.1说明和优先级
4.2激励/响应序列
4.3功能需求
5.其它非功能需求
5.1性能需求
5.2安全设施需求
5.3安全性需求
5.4软件质量标准属性
5.5业务规则
5.6用户文档
6.其它需求
6.1行业相关标准或协定需求
6.2数据保存的需求
附录A:词汇表
附录B：分析模型
上下文图
0层图
0层图（补充）
1层图
2层图
微规格说明
用例图
类图
顺序图
附录C:待确定问题的列表
15组
智慧校园数据管理系统
1. 引言
此文档为软件需求工程与UML建模课程第15组的软件需求工程文档，小组的选题为智慧校园数据管理系统。
1. 1目的
本文档的目的是详细地介绍智慧校园数据管理系统所包含的需求，以便客户能够确认产品的确切需求以及开发人员能够根据需求设计编码，以下叙述将结合描述智慧校园数据管理系统的功能、性能、用户界面、运行环境、外部接口以及针对用户操作给出的各种响应。本文档的预期读者有客户、项目经理、开发人员以及跟该项目相关的其他竞争人员。该项目旨在帮助学校中的老师学生更加高效地工作学习。
1. 2文档约定
本文档按以下要求和约定进行书写：
- 文档应按照IEEE 830 标准进行编写。
- 标题字体和正文字体均为宋体小四号。
- 无特殊情况下，字体颜色均采用黑色。
1. 3预期的读者和阅读建议
甲方：阅读此文档全部的内容，以便了解项目的进展及提出修改意见。
系统开发者：在设计系统前应阅读文档的全部内容，以便开发出符合甲方要求的系统。
文档编写人员：应阅读并遵守文档的编写约定。
系统测试人员：详细阅读此文档，以便做出更稳定的系统。
用户：可以粗略阅读文档的功能部分，以便更好地使用文档。
1. 4产品的范围
本系统旨在帮助学校实现对数据的全面管理和有效利用。在详细了解甲方需求的基础上，本系统对学校业务范围内的结构化、半结构化和非结构化数据进行了集中梳理和管控，包括但不限于学生档案、教师档案、学生成绩、教学计划、课程表、考试安排、图书馆借阅记录等。同时，本系统为学生、教师和管理人员提供相应的数据服务，包括数据查询、统计、分析等功能，以及数据可视化展示等。通过本系统，学校的各部门可以快速、便捷地获取和处理所需的数据信息，提高数据的使用效率和管理水平，进一步提升学校的教学、科研和管理水平。
1. 5参考文献
[1]窦万峰.软件工程方法与实践(第三版).北京：机械工业出版社，2016
[2]普莱斯曼.软件工程：实践者的研究方法(原书第8版).北京：机械工业出版社，2016
[3] 软件设计文档国家标准IEEE 830
2. 综合描述
2.1产品的前景
随着学生人数日益增多，校园管理方面与为学生提供服务的难度日益增大，在传统的校园管理方法中，要管理数量如此庞大的学生，必然会消耗非常多的人力物力。在这种情况下，智慧校园数据管理系统项目的研发就显得尤为重要。全国各地学校众多，需求量大，项目前景好。随着我国校园的信息化建设投入不断增加，智慧校园市场规模稳步增长，其渗透率不断上升。数据显示，2015年我国智慧校园行业市场规模为333.62亿元，到2019年我国智慧校园市场规模达563.89亿元，5年复合增长率为14.02%，预计到2025年我国智慧校园市场规模将达914.98亿元，逼近千亿大关。
学校内部的人员对于智慧校园数据管理系统有着很大的需求：管理人员（如校长、院长、教学干事等）想要使用系统来管理学校的各项行政事务：包括学生信息管理、教职工信息管理、教学资源管理、教学评价管理、学生行为管理、校园设备管理、财务管理等；教师想要使用系统来管理自己的课程信息、学生信息、成绩信息等，使用系统进行教学资源的共享、课程评估。学生想要通过系统查看自己的个人信息、课程表、课程成绩、考试安排等，并使用系统进行选课、教学评价等。在这些需求的推动下，本小组受甲方委托进行对系统的研究与开发。最终的产品要覆盖以上提到的各种需求。
经过整理，系统可以用具体的功能实现甲方的以下需求：
BR1：管理学生信息，包括学生的基本信息（如姓名、学号、学籍、专业等）、课程表、课程成绩、获得荣誉等。
BR2：管理学生行为，包括学生上网日志、登录认证日志、考勤记录、借阅图书记录等。
BR3：管理教职工信息，包括教职工的基本信息、职务信息、考核信息，包括教学评估、学生评教等。
BR4：管理教学资源，包括培养方案、教学PPT、教学视频、试卷、习题集等。
BR5：管理校园设备，主要指教室、实验室、图书馆等设备的信息登记、使用情况等。
BR6：管理财务，包括学生缴费、教职工工资、经费支出等。
2.2产品的功能
为全校师生提供功能完备的教务管理系统，为学生提供课表查询，选课退课，成绩查询等功能，为老师提供学生信息管理，学生成绩录入等功能，有利于推进教学事务的数字化。
为全校师生提供功能完备的校园事务管理系统，为全校学生提供请假销假，场地预约等功能，为相关管理者提供相应后台管理功能，能够大幅提高校园事务的处理效率，便利全校学生的校园生活。
为全校学生提供有效的教学资源，包含教学PPT、教学视频、试卷、习题集等。
为全校学生提供教学评价功能，对老师的教学工作进行评价，并合理地提出自己的建议
为全校师生提供校园实时状态监测系统，监测教室、实验室、图书馆等使用信息，有利于防止校园堵塞现象出现，提高使用者的时间利用效率与出行体验。
智慧校园数据管理系统能够帮助全校师生更加智能化地完成日常中的教学工作，有效地节省了学校对全校师生数据进行管理的时间。
2.3用户类和特征
作为智慧校园数据管理系统，其面向的用户为学校的各类人员：
| 涉众 | 特征 |
| 学生 | 学生需要使用系统来查询课程相关内容，个人与教学信息等。每天多次使用系统，主要使用的功能有个人课表查询，已完成课程的成绩查询，相关考试安排，个人信息查询等，同时每学期也会使用选课系统，教评系统，考试，竞赛报名等系统，虽然使用的频率不高，但在同一时间段可能有大量用户使用。 |
| 教师 | 教师需要使用系统来保证线上教学的顺利进行，辅助线下教学。每天多次使用系统，在系统中发布课程教学安排，上传课程的相关资料，布置作业，查看选课信息和学生的考勤状况。同时，每学期也需要使用系统上传学生的考试成绩，查看学生教评及教学改善意见等。由于部分教师对电脑系统的使用并不熟练，所以需要尽可能简化使用频率高的功能。 |
| 管理人员 | 管理人员需要使用系统管理校内的各项事物，比如学生信息管理，教职工信息数据管理，校园设备管理，财务数据管理等。数据的数量庞大，系统内需要设置数据整理统计功能，方便用户直观的看到数据的变化。同时，管理人员对相关计算机技术了解有限，需要设置方便准确的查询系统，能快速查询相关内容。 |
| 涉众 | 主要目标 | 态度 | 主要关注点 | 约束条件 |
| 学生 | 可以更加方便的查询课程信息，下载课程资料。使用教评，选课，考试与竞赛报名，缴费等系统。节约时间，更加方便。 | 使用系统方便自己的学习生活，积极支持系统的建立与更新。 | 使用操作简单便捷，支持数据导出。 | 使用校园内部网络。 |
| 教师 | 发布通知，上传课程资料，提高教学效率，方便与学生交流。 | 通过系统实现线上教学，辅助线下教学，线上与线下同步进行，实现更好的教学效果，积极支持系统的建立。 | 发布的信息能否及时更新，保证工作的顺利进行。 | 使用校园内部网络。 |
| 管理人员 | 从总体上直观看到学校数据改变情况，并做出相应的政策调整，做出合理的安排。 | 积极支持系统的建立。 | 开发系统，维护系统所需的费用。保障数据的安全。 | 无。 |
| 用户群体 | 群体数量 | 优先级 |
| 学生 | 27678 | 1 |
| 教师 | 3376 | 2 |
| 管理人员 | 586 | 3 |
2.4运行环境
系统分为PC端和移动端，各自的要求如下：
(1) 移动端：
硬件平台：安卓移动终端设备以及支持安卓系统的模拟器。
操作系统：Android 4.0及以上版本。
处理器：双核2GHz及以上。
机身内存：4G以上。
存储空间：32G以上。
屏幕分辨率：1920×1080及以上。
其他要求：能够运行安装主流浏览器，如UC、夸克等。
(2) PC端：
硬件平台：装载以x86架构或ARM架构的芯片的PC设备。
操作系统：window10及以上版本。
处理器：双核2GHz及以上。
机身内存：8G以上。
机身RAM：32G以上。
屏幕分辨率：1920×1080及以上。
其他要求：能够运行主流浏览器，如edge、Firefox、Chrome等。
2.5设计和实现上的限制
开发环境与编程语言：没有特定的编程语言和平台/系统的限制，但该系统具有良好的可维护性和可扩展性，并且能够适应未来可能的技术变化和需求变化。可使用通用的编程语言和开发平台，如Java、Python、Node.js、.NET等，同时可以根据实际情况选择适合的数据库管理系统、操作系统等基础设施。
人力和时间约束：由于课程设计的要求，本系统的设计实现要在5天之内完成。
技术发展的约束：计算机技术和发展的日新月异，将会给信息处理带来更多手段，同时也会带来更加丰富的信息表达形式，例如现在发展起来的chatGPT等等，这就要求软件在设计时要考虑技术变化的可能性，为可能的变化预留一定的处理能力。
2.6假设和依赖
(1)假设学校能为项目的开发提供所需要的数据，比如学生基本信息、教师基本信息、课程信息等数据。
(2)假设系统设计中的每一个最基本的操作都是可以进行编程实现的(即都是图灵可判定问题)。
3. 外部接口需求
3. 1用户界面
- 主页面：主页面是系统的入口，包含了系统的登录注册界面。用户首先需要进行注册，并被赋予一个唯一的身份标识，以便于系统进行身份区分。在登录时，用户需要输入用户名和密码，以及选择自己的身份，系统会根据身份的不同，显示对应的功能模块。
- 学生页面：学生登录后，可以访问多个不同的功能模块。本硕博一体化系统可以让学生查询自己的考试信息和课程安排，以及获取学术信息。教务处系统则提供了成绩查询和评教功能，方便学生对自己的学习情况进行了解和反馈。选课系统可以让学生自主选择自己的课程，以便于更好地满足个人的学术需求。场地预约系统可以让学生预约校内的场地，方便进行各种活动。
- 教师页面：教师登录后，可以使用多个不同的功能模块进行教学管理。教师可以管理学生信息，包括学生的基本信息、课程信息、成绩信息等。教师可以录入学生成绩，进行请假销假审批，发布教学安排、课件和考试安排，以便于更好地管理教学工作。
- 管理人员页面：管理人员可以使用多个不同的功能模块进行管理工作。用户管理可以让管理员对系统中的用户进行管理，包括用户信息的增删改查等操作。管理财务可以让管理员对学校的财务情况进行管理，包括财务报表的生成和管理。管理校园资源可以让管理员对学校的场地、设备等资源进行管理和分配，以便于更好地支持教学和学生活动。
3. 2硬件接口
使用专用服务器来管理用户数据，支持主流键盘鼠标显示器等输入输出设备，支持SATA、SATA-E、mSATA、M.2、U.2、PCI-E接口的存储盘。
3.3软件接口
系统提供API接口，用户可以通过调用API接口来实现与系统的交互，比如获取数据、提交数据等操作。
与校园内的其他系统建立接口，如教务管理系统、学生管理系统、人事管理系统等，以及与外部的系统进行数据交换，如政府数据统计系统、行业管理系统等。
3.4通信接口
使用网络协议：TCP/IP
4.系统特性
SF1：数据采集
SF2：数据存储
SF3：数据处理
SF4：数据分析
SF5：数据共享
4.1说明和优先级
| SF1 数据采集 | 说明: | 采集学生、教师、课程、成绩等多种数据，通过手动录入、批量导入、接口对接等方式获取数据。 |
| 优先级: | 高 | |
| 利益： | 系统的基本架构，没有此特性就无法实现系统。 | |
| 风险: | 可能会录入错误的数据或者重复的数据。 |
| SF2 数据存储 | 说明: | 将采集到的数据存储到数据库中，保证数据的安全性和完整性。可以选择使用关系型数据库、非关系型数据库等存储方式。 |
| 优先级: | 高 | |
| 利益： | 系统的基本架构，没有此特性就无法实现系统。 | |
| 风险: | 数据可能会被黑客窃取或篡改 |
| SF3 数据处理 | 说明: | 对采集到的数据进行清洗、去重、转化等处理，确保数据的准确性和一致性。 |
| 优先级: | 中 | |
| 利益： | 若SF1操作得当，可以直接实现此特性，因此优先级降一级 | |
| 风险: | 有可能进行错误的转化。 |
| SF4 数据分析 | 说明: | 对采集到的数据进行分析，提取有价值的信息。可以使用数据分析工具、可视化工具等进行数据分析和展示。 |
| 优先级: | 低 | |
| 利益： | 此特性可简便人员操作，但无此特性也可实现系统，故优先级最低 | |
| 风险: | 若数据出错会得到错误的分析 |
| SF5 数据共享 | 说明: | 将数据共享给相关人员，支持不同权限的数据访问。可以通过应用程序接口（API）、数据共享平台等方式进行数据共享，通过不同的权限，可以数据进行不同的增删改查操作。 |
| 优先级: | 高 | |
| 利益： | 系统的基本架构，没有此特性就无法实现系统。 | |
| 风险: | 若api设置不当可能会出现漏洞，给黑客可乘之机 |
4.2激励/响应序列
功能按钮 用户点击后跳转到对应的功能设置，设置完成后返回会自动保存。
返回按钮 用户点击后，系统返回到上一级页面。
4.3功能需求
FR1：学生信息管理
对学生的基本信息（如姓名、学号、学籍、专业等）、课程表、课程成绩、获得荣誉等进行管理。
FR2：学生行为管理
对学生上网日志、登录认证日志、考勤记录、借阅图书记录等进行管理。
FR3：教职工信息管理
对教职工的基本信息、职务信息、考核信息，包括教学评估、学生评教信息进行管理。
FR4：教学资源管理
对培养方案、教学PPT、教学视频、试卷、习题集信息进行管理。
FR5：校园设备管理
对教室、实验室、图书馆等设备的信息登记、使用情况信息进行管理。
FR6：财务管理
对应BR6，学生缴费、教职工工资、经费支出信息进行管理。
5.其它非功能需求
这部分列举出了所有非功能需求，而不是外部接口需求和限制。
5.1性能需求
实时数据处理需要在数据产生后立即进行处理，数据传输和处理的时间限制一般为几秒钟到几分钟，取决于实时性要求和数据量大小。
批量数据处理需要将数据按照一定的批次进行处理，时间限制一般为几分钟到几小时，取决于数据量大小和处理算法复杂度。
数据存储需要在数据产生后及时进行存储，时间限制一般为几秒钟到几分钟，取决于数据量大小和存储系统的性能。
在进行数据转移和处理时，需要根据具体的数据操作和需求，确定合理的时间限制和处理方式，确保数据处理的准确性和及时性。同时，需要考虑数据安全和可靠性，采用有效的数据备份和恢复策略，保证数据的安全和可靠性。
系统至少要能支持一个年级的全部学生同时使用，也就是三千人以上。
5.2安全设施需求
需要定期进行数据备份和恢复，时间限制一般为几小时到几天，取决于数据量大小和备份策略。
5.3安全性需求
- 用户身份认证：系统必须能够准确、及时地识别和验证用户身份，防止未经授权的访问和使用。
- 数据保护：系统必须保证所有的数据都是加密的，并且只有被授权的用户才能够访问和修改数据。
- 访问控制：系统必须能够对不同的用户分配不同的权限，以保证用户只能访问和修改自己被授权的数据。
- 系统备份和恢复：系统必须能够自动备份数据，并在发生故障时及时恢复数据，以保证数据的完整性和可靠性。
- 实时监控：系统必须能够实时监控所有的活动，包括用户登录、数据访问、修改等，以及及时发出警报和报告。
- 安全审计：系统必须记录所有的用户活动和事件，并能够生成详细的安全审计报告，以帮助管理员及时发现和处理安全问题。
- 防火墙和反病毒：系统必须具备强大的防火墙和反病毒功能，以保护系统免受各种网络攻击和病毒的侵害
5.4软件质量标准属性
系统应该能够记录用户的操作日志和事件日志，以便追踪和审计用户的行为。
系统具有多平台开发能力和移植性，以便在不同的操作系统和硬件平台上运行，从而提高系统的灵活性和适用性。
5.5业务规则
系统应该能够对用户进行身份验证和授权，只有经过授权的用户才能够访问系统的程序和数据。
例如：
只有教师及管理员可以修改学生成绩，学生不可以修改，只能进行查看。
只有白名单的人员可以预约场地，黑名单人员不可预约。
只有管理人员可以对系统数据库进行相关具体操作。
5.6用户文档
无
6.其它需求
6.1行业相关标准或协定需求：
智慧校园数据管理系统能够符合相关的行业标准和协定，以保证系统的可靠性、安全性和合规性。具体而言，系统能够符合国家和地方相关的法律法规、信息安全标准、数据隐私保护标准等，如《网络安全法》、《个人信息保护法》等，同时也希望系统能够符合教育行业相关的标准和协定，如《教育信息化标准》、《校园信息化规划标准》等。系统还要能够符合国际上通用的信息安全标准和最佳实践，如ISO 27001信息安全管理标准、OWASP安全标准等。
6.2数据保存的需求：
短期数据保存：保存几分钟到几小时的数据。在需要快速分析实时数据的场景下，一般需要保存较短时间的实时数据，比如教室课程安排、图书馆座位信息等。
中期数据保存：保存几天到几个月的数据。在需要对一段时间内的实时数据进行分析和比较的场景下，需要保存较长时间的实时数据，比如教学资源、评教信息等。
长期数据保存：保存几年甚至几十年的数据。在需要对历史数据进行长期分析和研究的场景下，需要保存更长时间的实时数据，比如学生信息、人事变动等。
在确定实时数据的保存规模时，需要考虑数据的实时性、分析需求和存储资源，选择合适的存储方式和策略，保证数据的准确性和可靠性。同时，需要考虑数据的保密性和隐私性，采用有效的数据安全措施，保护数据的安全和隐私。
附录A:词汇表
| 名称 | 姓名 |
| 别名 | 名字，名号，称谓 |
| 使用地点与方法 | 能查出来你叫什么 |
| 描述 | 就是人叫什么 |
| 格式 | 0~8个汉字 |
| 名称 | 学号 |
| 别名 | 学生编号，学生号码 |
| 使用地点与方法 | 查询当键 |
| 描述 | 就是每个人有不一样的号 |
| 格式 | 学院号码（2）+入学年份（4）+%d（4） |
| 名称 | 工号 |
| 别名 | 老师编号，老师号码 |
| 使用地点与方法 | 查询当键 |
| 描述 | 就是每个人有不一样的号 |
| 格式 | 学院号码（2）+入职年份+（4）%d（4） |
| 名称 | 课程编号 |
| 别名 | 课程号码 |
| 使用地点与方法 | 查询当键 |
| 描述 | 就是每个课程一样的号 |
| 格式 | 学院号码（2）+开课年份+（4）%d（4） |
| 名称 | 关键字 |
| 别名 | 关键词 |
| 使用地点与方法 | 查询用 |
| 描述 | 知道你要查什么 |
| 格式 | KeyWordsFormData（String 0~16） |
| 名称 | 指令 |
| 别名 | 指示，命令 |
| 使用地点与方法 | 办理事务用 |
| 描述 | 告诉系统要办什么事情 |
| 格式 | InstructFormData（Lamda 0~16 line） |
| 名称 | 权限 |
| 别名 | 权力，power |
| 使用地点与方法 | 判断账号能否查看或修改某些数据 |
| 描述 | 就是力所能及的范畴 |
| 格式 | AuthorityFormData（BoolThrd 1） |
附录B：分析模型
结构化分析
上下文图：
0层图：
0层图（补充）：
1层图：
2层图：
微规格说明
1.1
INPUT:LoginAccount,Search,Operation
WHEN LoginAccount LOGIN
IF (AccountKind == Student)
DO Match UNTIL LoginAccount == Student[n] Authority = Student[n]
IF (AccountKind == Teacher)
DO Match UNTIL LoginAccount == Teacher[n] Authority = Teacher
IF (AccountKind == Manager) Authority = Manager
SearchInformation = Search
OperationInformation = Operation
OUTPUT: Authority, SearchInformation, OperationInformation
3.1
INPUT:KeyWords
SELECT CASE
CASE 1 KeyWords == SelfInformation
Key = StudentNumber
CASE 2 KeyWords == ExamResult
Key = StudentNumber,Lesson
CASE 3 KeyWords == Postgraduate
Key = StudentNumber,SchoolNumber
……
END CASE
4.2
INPUT:Instruct
IF(InstructKind == Student)
GET StudentInformation FROM F1
Backups = StudentInformation
IF(InstructKind == Teacher)
GET TeacherInformation FROM F1
Backups = TeacherInformation
OUTPUT: Backups
4.3
INPUT:Instruct,Boolean isBackups
IF(isBackups == TRUE)
IF(InstructKind == Student)
InformationG = StudentInformationG
IF(InstructKind == Teacher)
InformationG = TeacherInformationG
ELSEIF(isBackups == FALSE)
THROW ERROR(“Failed to back up server data.”)
OUTPUT: InformationG
ER图：
面向对象分析
用例图：
学生：
老师：
管理人员：
类图：
顺序图:
附录C:待确定问题的列表
- 如果突发事故造成服务器停电等事故有可能会造成一定损失。
- 用户的设备可能达不到系统客户端运行的需求，从而可能出现错误。
