团队作业2-《需求规格说明书》

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class12Grade23ComputerScience
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class12Grade23ComputerScience/homework/13472
这个作业的目标	完成需求规格说明书，搭建 Git 仓库实现增量管理，完成项目立项与协作基础搭建

一、需求规格说明书

1. 引言

1.1 文档目的

本文档旨在详细描述大学生健康生活管理与预警系统的功能需求、技术需求和性能需求，为系统设计、开发、测试和验收提供依据。

1.2 项目背景

随着大学生健康意识的提升，传统健康管理工具无法满足个性化需求。本项目通过整合日常行为数据与体检数据，结合AI分析，为大学生提供科学的健康管理与预警服务。

2.面向用户分析

本系统的核心用户是高校在校学生，辅助用户是校医院医护人员。系统设计必须围绕学生用户的体验和需求展开，同时满足医护用户的管理与干预需求。

2.1 核心用户：在校大学生

大学生群体根据健康意识和使用动机，可进一步细分为以下几类：

A、健康关注者/自律达人

• 画像：通常有健身、跑步、健康饮食等习惯，注重个人形象和生活质量。可能是运动社团成员、健身爱好者或养生爱好者。
• 核心需求：
  系统化记录与追踪：需要一个便捷的工具来系统化记录自己的运动、饮食和睡眠数据，替代零散的备忘录或社交软件打卡。
  数据化反馈与优化：希望获得基于数据的科学分析，了解自己的健康趋势，寻求进一步的优化建议（如如何突破健身瓶颈、如何调整饮食结构）。
  成就与社区激励：享受打卡、完成目标的成就感，并可能乐于在社区中分享，获得认同。

B、健康焦虑者

• 画像：可能体测困难、体检指标异常（如超重、低血压/高血压、视力下降过快），或近期因熬夜、饮食不规律感到明显不适（如脱发、精神不振、肠胃问题）。
• 核心需求：
  风险预警与归因：系统提供的“健康风险预警”和“潜在健康风险分析”对他们价值极高。
  可落地的改善方案：需要具体、可执行、非说教式的行动建议，例如“本周建议进行3次30分钟以上的慢跑”而非“你要多运动”。
  寻求专业支持的捷径：希望便捷地了解校医院相关科室、服务时间，甚至能提前准备好自己的健康数据给医生看，提高就医效率。

C、被动尝试者/从众使用者

• 画像：大多数普通学生。健康意识一般，生活随性，可能被学校倡议、辅导员推广或身边朋友影响而使用。
• 核心需求：
  低门槛与轻量化：“熬夜提醒”、“运动打卡”等轻量化功能是关键入口。操作必须极其简单，上手快。
  游戏化与趣味性引导：需要通过勋章、排行榜、积分兑换（如兑换体育用品优惠券）等机制激发使用兴趣。
  同伴压力与社交动力：看到室友或同学在打卡运动，会产生跟随心理。小组、宿舍间的健康挑战赛对他们有吸引力。

D、特殊需求者

• 画像：有慢性疾病（如哮喘、过敏、肠胃炎）需要长期监测，或处于伤病恢复期（如运动损伤）的学生。
• 核心需求：
  长期健康数据管理：将日常症状、用药情况与生活行为关联记录，形成个人健康档案。
  紧急情况下的快速求助：可能需要更快捷的渠道联系校医院或设定紧急联系人。

2.2 辅助用户：校医院医护人员

A、医院管理者/公共卫生负责人

• 群体健康数据看板：提供各学院、各年级的肥胖率、熬夜率、常见病统计等宏观数据，用于制定公共卫生策略和资源规划。

B、门诊医生/护士

• 学生健康档案前置：在接诊前即可查看该生的历史体检数据、近期生活行为记录，快速定位潜在病因，提升诊疗效率和准确性。

2.3 用户场景与功能映射

用户场景	对应功能	用户价值
早晨起床后	推送昨日睡眠报告，生成“今日健康小目标”。	轻量化启动，培养健康意识。
食堂就餐时	扫描小票或手动记录饮食，获取“饮食均衡度”评分和即时建议。	在决策场景提供即时反馈，引导健康选择。
晚上熬夜时	触发“熬夜提醒”，告知建议睡眠时间及持续熬夜的健康风险。	在风险行为发生时进行温和干预。
收到体检报告后	系统自动同步并生成解读报告，将异常指标与日常行为关联。	明确问题根源和改善方向。
感觉身体不适时	根据症状和健康数据，智能推荐校医院对应科室，并可一键预约。	降低就医决策成本，精准对接医疗资源。
校医院医生接诊时	医生端可调阅学生的健康趋势图，结合问诊，做出更综合的判断。	提升医疗服务的精准度和效率，实现“数据赋能诊疗”。

3.功能性需求

3.1 用户认证与权限管理

3.1.1 用户注册

• 描述：学生通过学号注册，选择角色（学生/管理员）
• 基本流程：
  1. 用户输入学号、密码、选择角色
  2. 系统验证学号有效性
  3. 注册成功，跳转登录页

3.1.2 用户登录

• 描述：用户使用学号和密码登录
• 基本流程：
  1. 输入学号、密码
  2. 系统验证身份
  3. 登录成功，根据角色进入相应页面

3.1.3 权限管理

• 描述：区分学生和管理员权限
• 业务规则：
  • 学生：查看和管理个人健康数据、查看AI健康分析报告、系统推送健康预警
  • 管理员：查看和批量导出所有学生体检报告、学生健康预警同步通知管理员

3.2 生活行为数据记录

3.2.1 饮食记录

• 描述：记录三餐类型、时间及食物种类
• 基本流程：
  1. 选择餐次（早餐/午餐/晚餐/加餐）
  2. 输入食物种类和份量
  3. 记录用餐时间
  4. 保存记录
• 业务规则：支持常用食物快速选择

3.2.2 运动记录

• 描述：记录运动类型、时长、强度与时间
• 基本流程：
  1. 选择运动类型
  2. 输入运动时长（分钟）
  3. 选择运动强度（低/中/高）
  4. 记录运动时间
  5. 保存记录

3.2.3 作息记录

• 描述：记录睡眠时间
• 基本流程：
  1. 输入入睡时间
  2. 输入起床时间
  3. 系统自动计算睡眠时长
  4. 保存记录

3.2.4 情绪状态记录

• 描述：记录情绪关键词或分数（1-10分）
• 基本流程：
  1. 选择情绪关键词或输入分数
  2. 记录时间
  3. 保存记录
• 业务规则：支持情绪趋势分析

3.2.5 记录查询功能

• 描述：支持按日期查询各类行为记录
• 基本流程：
  1. 选择查询日期
  2. 选择记录类型（饮食/运动/作息/情绪）
  3. 显示该日期相关记录

3.2.6 健康预警功能

• 描述：睡眠时间严重不足、饮食严重不规律、运动严重缺少则系统提醒
• 业务规则：通过系统通知提醒

3.3 体检数据对接与管理

3.3.1 校医院数据对接

• 描述：自动同步年度体检报告数据
• 业务规则：通过标准接口同步数据

3.3.2 体检报告查看

• 描述：在线查看历年体检报告及指标解读
• 基本流程：
  1. 选择体检年份
  2. 查看各项指标数值和参考范围
  3. 查看医生建议

3.3.3 健康指标跟踪

• 描述：可视化展示关键指标的历史趋势
• 业务规则：支持BMI、血压、血糖等指标趋势图

3.4 健康数据分析与报告

3.4.1 AI健康分析

• 描述：使用扣子AI生成个性化健康分析报告
• 基本流程：
  1. 整合行为数据和体检数据
  2. 调用AI分析服务
  3. 生成健康报告
• 业务规则：
  • 识别潜在健康风险并分级
  • 提供具体可执行的改善建议

3.5 系统管理

3.5.1 个人信息管理

• 描述：维护姓名、性别、联系方式等基本信息
• 基本流程：
  1. 进入个人中心
  2. 编辑个人信息
  3. 保存修改

3.5.2 系统通知

• 描述：接收健康提醒、报告更新等系统消息
• 业务规则：支持通知类型筛选和已读标记

3.6 管理员功能

3.6.1 数据查看

• 描述：查看高风险健康学生的健康数据
• 基本流程：
  1. 登录管理员账号
  2. 设置查询条件
  3. 查看学生健康数据列表

3.6.2 批量数据导出

• 描述：支持按条件筛选并导出学生健康数据
• 基本流程：
  1. 设置导出条件
  2. 选择导出格式（Excel）
  3. 选择导出字段
  4. 生成并下载导出文件

3.6.3 同步学生健康预警功能

• 描述：当学生出现高风险健康状况时，系统自动同步预警信息至校医院管理员，便于及时干预
• 基本流程：
  1. 系统检测到学生高风险健康数据
  2. 自动生成预警通知，包含学生基础信息、预警类型、风险描述、数据来源
  3. 管理员可在详情页添加干预记录，标记预警处理状态（未处理/处理中/已完成）

4. 技术需求

4.1 后端技术栈

• 框架：Spring Boot 2
• 安全框架：Spring Security + JWT Token 认证
• 数据库：MySQL 8.0
• ORM：Spring Data JPA
• 构建工具：Maven
• 开发工具：Lombok

4.2 前端技术栈

• 框架：Vue 2
• UI 组件：Element UI
• 状态管理：Vuex
• 路由：Vue Router
• HTTP 客户端：Axios
• 图表库：ECharts
• 构建工具：Vue CLI

4.3 接口需求

• RESTful API 设计规范
• 校医院数据对接标准接口
• 扣子AI分析服务调用接口

4.4 数据存储需求

• 关系型数据库MySQL：存储用户信息、体检指标、行为记录等结构化数据
• NoSQL 数据库：考虑用于存储非结构化数据
• 数据安全：需实现定期数据备份机制，支持故障后的快速数据恢复

二、预期用户量

发展阶段	时间框架	核心目标	预期用户量（日活跃用户）	用户评估依据
试点期	第1-3个月	功能验证，收集用户反馈	50-200人	通过辅导员推送、社团合作等方式推广。
成长期	第4-9个月	全校推广	500-2000人	覆盖全校，借助开学日推广。
稳定期	第10个月起	培养习惯，实现自然增长	3000-5000人	核心用户养成习惯，形成口碑效应。
拓展期	第2年起	跨校推广	10000人以上	推广至大学城其他学校，用户规模增长。

三、系统的真实性、可用性以及价值所在

1. 真实性

• 身份验证严格：通过教务系统已存学号完成注册验证，明确学生与管理员角色，防止虚假账号接入。
• 数据来源可靠：饮食、运动、作息数据支持手动记录同步；分级权限管理使学生自主掌控数据分享范围，减少因隐私顾虑导致的虚假记录。
• 数据分析专业：对上传数据进行AI健康分析参考国家学生健康标准，心理健康测评功能选用大学生心理健康量表，避免自变量表的主观性。

2. 可用性

• 操作流程简洁：核心功能（记录、查询、报告查看）均为 3-5 步短流程，符合学生日常使用习惯，降低学习成本。
• 权限划分清晰：学生聚焦个人数据管理，管理员专注批量数据处理与风险监控，功能匹配角色需求，避免操作冗余。
• 功能贴合需求：覆盖饮食、运动、作息等学生高频健康场景，支持常用选项快速选择，提升记录效率。
• 个性化服务：根据学生体检报告、日常数据生成定制化健康建议，满足个体差异化需求。
• 可视化反馈：多维度数据可视化，健康报告对比变化，学生能够直观感知健康状态变化。
• 响应与提醒高效：核心操作响应时间≤2 秒，健康预警触发后即时推送通知，管理员同步接收风险提醒，确保信息及时触达。

3. 系统价值

• 对学生：提供一站式健康管理服务，帮助养成规律作息，合理饮食，坚持运动的习惯，通过心理健康测评实现自我认知与情绪调节，筑牢身心健康基础。
• 对校园：辅导员能通过平台查看学生健康报告，掌握群体健康态势，及时发现高风险学生，及时提供身心健康帮助，实现早发现，早干预。
• 长期价值：积累学生健康数据资产，支持群体健康趋势分析，为校园健康政策制定、健康服务优化提供数据支撑。

四、Git协作管理

GitHub地址：https://github.com/baiyehhj/college-student-health-management-system
项目issues：

五、团队项目时间安排表

阶段	任务（原有安排）	任务（校正后安排）
第九周	1. 团队组队、目标用户调研（学生/校医院） 2. 竞品分析（校园健康类工具）、系统核心需求梳理 3. 技术选型（Java+SpringBoot+Vue）、初步架构设计	1. 需求与设计（并行）：团队组建、用户调研、竞品分析、技术选型与架构设计 2. 原型与规范（并行）：数据库设计、RESTful接口规范、产品原型设计、开发环境搭建
第十周	1. 数据库设计（用户/行为/体检表）、RESTful 接口规范制定 2. 学生端/医护端原型设计（墨刀）、技术预研 3. 开发环境搭建、前后端基础框架开发、编码规范确定	1. 后端：用户认证、数据库实体、基础API 2. 前端：登录/注册、主框架页 3. 模块：饮食/运动/作息记录功能 Sprint 1 集成与测试
第十一周	1. 原型优化、WBS 任务分解与工时预估 2. 核心模块开发（一）：用户认证、饮食/运动/作息记录模块 3. 核心模块开发（二）：体检数据导入、睡眠规律分析模块	1. 后端：体检数据导入、睡眠分析算法、健康报告生成服务 2. 前端：数据导入页、睡眠分析展示、报告预览页 Sprint 2 集成与测试
第十二、十三周	1. 核心模块开发（三）：健康报告生成、风险预警算法实现 2. 辅助功能开发：熬夜提醒、数据可视化、数据导出功能	1. 功能开发：风险预警算法、熬夜提醒、数据可视化、数据导出 2. 并行工作：技术文档初稿、制定测试用例 Sprint 3 集成与测试
第十四周	1. 系统集成测试、高并发性能优化（Redis 缓存） 2. 用户体验优化、Bug 修复 3. Docker 容器化部署、Alpha 版本试运行	1. 系统测试：全面集成测试、性能压力测试（Redis缓存） 2. 优化与修复：根据测试结果修复Bug、进行用户体验优化 3. 部署上线：Docker容器化部署、Alpha环境试运行
第十五周	1. 项目总结、技术文档整理、Alpha 阶段事后分析报告撰写	1. 项目总结、技术文档整理、Alpha 阶段事后分析报告撰写

矫正计算方法：

1、依赖优化：将高度依赖的任务集中前置，形成稳定输入，避免后期返工。
2、并行工作：将无依赖或弱依赖的任务组，安排其并行执行，缩短总周期。
3、缓冲时间设置： 为高复杂度、高不确定性任务预留缓冲时间，应对风险。
4、迭代与测试前置： 测试不是最后才进行，而是与开发同步。

六、团队分工与完成情况

姓名	分工	本周任务完成情况
黄怀瑾（队长）	后端	1. 统筹团队组建，明确成员职责与沟通机制 2. 主导技术选型落地，确认Java+SpringBoot+Vue技术栈可行性 3. 完成初步架构设计，划分后端核心模块
凌紫君（PM/前端）	PM/前端	1. 主导目标用户调研（学生+校医院双群体），统筹竞品分析，重点分析一站式服务实现方式 2. 梳理系统核心需求清单，明确优先级 3. 主导产品原型设计，确定整体交互逻辑
严展桐	后端	1. 进行技术预研，参与初步架构设计，负责数据库设计初稿 2. 搭建后端开发环境，SpringBoot项目初始化、数据库连接配置
邓滢	前端	1. 参与竞品前端交互分析，协助绘制产品原型 2. 搭建前端开发基础环境，Vue脚手架、UI组件库选型
吴泓霏	前端	1. 调研学生用户健康管理需求，聚焦睡眠、饮食、运动三大核心场景 2. 参与RESTful接口规范初步制定
何珊	测试	1. 制定测试计划框架，明确第一阶段测试重点：功能可用性、兼容性 2. 参与用户调研，整理测试需求点 3. 收集校园健康系统相关规范
阿迪拉·米吉提	测试	1. 协助制定测试用例框架，按核心模块分类：用户模块、记录模块、预警模块 2. 参与竞品测试体验，记录优缺点 3. 整理编码规范参考文档

七、个人感想

• 黄怀瑾：后端开发不只是代码的堆砌，更是用技术搭建起 “数据流转的桥梁”，让学生的健康数据发挥价值，也为校医院的管理提供便利。通过合理划分模块，结合业务需求梳理实体关系，让我深刻体会到技术服务于实际需求的价值。
• 凌紫君：我深刻体会到，一个成功的校园健康产品，不仅仅是功能的堆叠，更是对用户行为与心理的精准把握。关键在于如何将“健康”这个宏大的命题，转化为一个个轻量、有趣且能提供即时正向反馈的日常互动，从而引导用户走向更健康的生活方式。
• 严展桐：进一步完善对系统功能的明确，深度挖掘该系统的真实性，可用性，以及价值所在，参与初步架构设计。这个任务也让我更加了解系统功能，看是否满足对应用户的需求和怎样使系统功能更加完善。这次任务的确定离不开团队之间的沟通和协调，让我明白，好产品是多方协同的结果
• 邓滢：综合考虑实际情况，从最初的计划严谨而线性，改进为校正后的版本，通过并行、缓冲和持续测试，为不确定性、团队协作和未知风险预留了空间。是一个能随时适应现实、引导团队稳步前进的动态系统。
• 吴泓霏：初期对 “可用性” 的理解较模糊，后来通过拆解 “操作流程、功能贴合度、响应效率” 三个维度，结合学生日常使用场景分析，才逐步理清思路。这让我明白，复杂问题可以通过 “拆解维度 + 结合实际场景” 来解决。学会了从需求中提取关键信息，掌握了 “及时同步进度、主动沟通疑问” 的重要性，对 “系统设计的真实性、可用性、价值” 有了更具体的认知，不再局限于理论，而是能结合实际功能分析落地价值。
• 何珊：今天学生 1 万、管理员 30，明天扩招到 5 万，只在 Excel 里改两个格子，容量公式、服务器台数、预算表全部自动联动；这张看似静态的三线表，其实就是整个健康平台的“伸缩手柄”。把“估算逻辑→用户数→并发”三步链用一张表打透，最大的价值不是数字本身，而是让产品、开发、运维、测试在同一页纸上达成共识。
• 阿迪拉·米吉提：担任这个项目的测试负责人，是一段充满挑战与成就感的旅程。这是有关健康的项目，我们做的每一个功能关系到同学们的健康也能帮助到他们，所以我们做的每一部分都意义非凡。看到用户人数不断增长，很期待我们的完整的项目。