软件工程实践团队第二次作业——原型设计&需求分析

zq践地组 2026-10-14 22:58:20

这个作业属于哪个课程	202601福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践团队第二次作业——原型设计&需求分析
团队名称	zq践地组
这个作业的目标	完成项目需求分析、撰写符合国标规范的《软件需求规格说明书》、完成界面原型设计并进行答辩，同时在博客中展示团队分工与协作。
其他参考文献	《软件需求规格说明书（GB/T 9385-2008）》等

一、团队项目计划
1.1 整体计划安排与里程碑
1.2 关键点、难点与风险分析
关键点（核心成功要素）
难点（技术与管理挑战）
风险分析与应对策略
二、项目分工
三、成员协作方式
3.1 沟通工具与日常交流
3.2 版本仓库与文档协作
3.3 冲突处理机制
3.4 任务同步与进度管理机制
四、软件需求规格说明书链接
五、界面原型设计链接
1. PC端产品原型（三角色工作台）
2. H5学生端移动原型（便捷触达）
3. 设计规范与视觉一致性
六、需求分析PPT链接
1. 需求分析目标与过程
2. 五大核心建模成果
3. 结论与项目价值
七、界面原型答辩PPT链接
1. 设计目标与方法
2. 原型成果矩阵（14页PC端 + 6页H5端）
3. 交互、状态机与设计规范
4. 待确认项与迭代策略
5. 答辩总结

一、团队项目计划

1.1 整体计划安排与里程碑

结合目前已完成的两套高保真原型（H5学生端、多角色PC端）以及《NABCD选题分析》，项目整体划分为四个阶段，当前阶段重点聚焦于需求分析、原型设计与阶段性交付物产出。

阶段一：需求梳理、原型设计与阶段交付（第1周 - 第2周）——【本次作业核心阶段】
- 任务1：需求调研与TBD消歧：基于现有PRD和HTML原型，访谈真实用户（学生、教师、管理员），验证报名、签到、审核等核心流程。重点梳理原型中标记的黄色待确认项（如 TBD-04 密码复杂度、TBD-11 静态码代签风险、TBD-16 签到窗口终点、TBD-26 状态筛选等），并完成《软件需求规格说明书》的撰写。
- 任务2：高保真界面原型设计：完成H5学生端（登录/改密、列表、详情、报名、签到、消息）与PC端（教师端活动创建/名单/签到/看板，管理员端审核/用户/分类/全局看板）的交互与视觉设计，确保分层描述、图形符号与文字一致、样式统一。
- 任务3：汇报PPT制作：制作《需求分析报告PPT》和《界面原型设计答辩PPT》，梳理核心需求、业务闭环、系统亮点及答辩思路。
- 任务4：文档规范与云仓上传：将《需求规格说明书》（Word电子版）与两份PPT导出为PDF，统一上传至华为云仓库，确保链接可公开访问。
- 任务5：评审表与博客撰写：填写《界面原型设计评审表》和《需求分析评审表》（腾讯共享文档）；撰写博客随笔，包含作业目录、评分要点核对、所有云仓链接及团队分工说明。
- 里程碑：提交全部7项作业（1篇博客、1份原型设计、2份PPT链接、1份需求规格说明书、2份评审表），完成课堂答辩。
阶段二：系统架构与数据设计（第3周 - 第4周）
- 任务1：数据库设计与优化：设计核心表结构（用户表、活动表、报名表、签到表、消息表、分类表等），建立合理的主外键关联与索引。重点针对“报名防超额”场景设计事务处理机制（如使用乐观锁或Redis预减库存），确保数据一致性。
- 任务2：接口规范与前后端分离架构：基于RESTful风格定义API接口文档（使用Swagger/YAPI），统一响应格式（状态码、提示语、数据体）。明确前后端分离部署架构（Vue3 + SpringBoot + MySQL）。
- 任务3：权限体系与安全设计：实现基于JWT+RBAC的权限模型。完成三角色（学生、教师、管理员）的菜单动态加载与接口级越权拦截设计，制定统一的异常处理与日志记录方案。
- 里程碑：完成《系统设计说明书》、数据库ER图、API接口文档，前后端开发环境搭建完毕，核心中间件（如Redis）配置就绪。
阶段三：核心功能开发与联调（第5周 - 第7周）
- 任务1：H5学生端开发：基于Vue3+Vant实现移动端适配。包含登录/强制改密、活动列表（分类筛选、搜索、分页）、活动详情、一键报名（严格实现“资料完善→重复报名→时间冲突→名额已满”的4种拦截文案）、取消报名、扫码签到、消息中心（已读/未读状态切换与红点提示）。
- 任务2：PC教师端开发：基于Vue3+Element-Plus搭建工作台。包含活动创建（表单校验、保存草稿、提交审核）、我的活动（状态流转：草稿→待审核→已发布/已驳回）、报名名单（筛选、EasyExcel一键导出）、签到管理（投屏二维码、手动补签/签到）、基础看板（报名趋势图表）。
- 任务3：PC管理员端开发：包含活动审核（通过即发布、驳回必须强制填写原因且通知教师）、全局活动管理、用户管理（禁用/启用/重置密码）、分类管理（增删改查，含被引用时的删除保护）、全局看板（全校数据统计）。
- 任务4：后端业务与联调：实现活动状态机流转、报名并发控制、签到窗口期校验（开始前15分钟~活动结束）、站内消息推送。前后端进行接口联调，解决跨域、数据格式差异等问题。
- 里程碑：完成全部核心功能开发，前后端联调打通，H5与PC端完整业务闭环跑通，MVP版本具备试点条件。
阶段四：全面测试与推广交付（第8周 - 第9周）
- 任务1：多维测试与质量保障：
  - 功能与边界测试：覆盖所有异常流程（如名额满、越权访问、驳回无原因、重复报名等）。
  - 性能与并发测试：使用JMeter模拟热门活动高并发报名，监控系统响应延迟与数据一致性。
  - 兼容性测试：H5端适配主流手机机型与浏览器，PC端适配Chrome/Edge等主流浏览器。
- 任务2：系统部署与上线：配置Nginx反向代理与服务器环境，部署前端静态资源与后端服务，完成数据库初始化与线上环境测试。
- 任务3：NABCD“D（Delivery）”推广策略落地：
  - 标杆共创：联合1-2位教师，将系统免费部署进真实课堂/社团场景，与教师共同打磨流程，形成标杆案例。
  - 开箱即用：编写《学生扫码使用指南》与《教师端操作手册》，实现零培训上手。
  - 快速交付与案例复制：两周内发布可用版本，通过标杆案例定向推广到其他班级与学院，最终实现全校统一部署（SaaS化），多学院共用。
- 任务4：监控与迭代：上线后持续监控三层量化指标（业务价值指标、系统健康指标、用户行为数据），收集试点反馈，驱动后续版本迭代。
- 里程碑：系统正式上线试运行，完成试点共创反馈收集，输出最终版《软件需求规格说明书》及项目总结报告，完成项目答辩与交付。

1.2 关键点、难点与风险分析

结合NABCD选题分析及前期原型验证，本项目在落地过程中面临以下核心挑战：

关键点（核心成功要素）

构建“四段割裂”到“全流程闭环”的数字化流转：将传统的“发布、报名、签到、统计”四个独立环节，收拢为“教师创建→管理员审核→学生报名→现场签到→名单导出”的完整闭环。这是区别于问卷星、微信群接龙等替代方案的核心生态位。
校园场景业务规则的内建与防超额控制：不只是做一个通用OA，而是要内建校园特有的业务规则（如审核发布流、名额实时防超额、签到即统计）。学生端需实现“免填表、一键报名”，教师端需实现“免手工统计、一键导出”，管理员需实现“统一审核与权限管控”。
零门槛体验与快速交付落地：遵循“开箱即用”原则，学生扫码即用、零培训；教师端可视化配置（建活动、设名额、导名单），无需代码学习成本。在交付策略上，需先打通闭环四环节的MVP版本，两周内进入试点，避免“大而全拖慢落地”。
数据一致性与系统健康指标：在大规模高频使用场景下（如单场报名数百人、全校上百场活动），需重点保障报名峰值并发响应延迟、大名单导出耗时以及系统可用性，确保统计须与业务数据一致。

难点（技术与管理挑战）

并发防超额与事务一致性：报名和取消报名同时进行时，如何避免超卖或名额释放失败？这要求后端在JWT+RBAC权限体系下，实现严谨的数据库事务或乐观锁机制，实时监控名额变动。
多角色权限隔离与越权处理：基于JWT+RBAC实现学生、教师、管理员三角色的精准权限控制。难点在于细节处理，例如教师只能查看本人活动的报名名单，若越权需精准提示「当前用户无权查看该活动」。
历史数据迁移与习惯打破：用户当前使用问卷星、群接龙、Excel收集信息，虽然这些工具各管一段、数据混乱，但切换有一定认知惯性。如何让用户无痛迁移（如支持教师数据一键导出迁移、免费使用）是推广难点。
待确认项（TBD）的真实性落地：原型中标注了多处TBD（如密码复杂度规则、静态码代签风险、导出文件形式等），若在开发后期未能与真实试点教师确认，极易导致返工。

风险分析与应对策略

风险1：用户不愿离开现有替代方案。
- 分析：问卷星收集方便、微信群传播快、Excel门槛低，用户已形成习惯。
- 应对：主打“补上断点”而非“全盘替代”，以切换成本近零为切入点。依托“标杆共创”策略，联合1-2位教师做试点共创，免费部署进真实课堂/社团场景，形成标杆案例后再定向推广到其他班级与学院。
风险2：系统性能不足导致报名拥堵或签到排队。
- 分析：学期初或热门活动会出现报名峰值并发，传统人工签到导致人均排队30秒以上。
- 应对：采用二维码扫码签到实现秒级签到（预期排队↓90%+）。后端使用EasyExcel实现分钟级一键导出（预期教师统计耗时从半天降至分钟级，↓90%+）。同时建立系统健康指标（报名峰值并发响应延迟、大名单导出耗时）持续监控。
风险3：项目范围蔓延，导致交付延期。
- 分析：若试图一步到位做成“大而全”的通用OA，可能拖慢落地进度。
- 应对：严格执行MVP策略。先用两周时间打通“发布→报名→签到→导出”闭环四环节，快速交付可用版本。通过“案例复制”规模推广，最终实现全校统一部署一套（SaaS化），多学院共用。
风险4：数据孤岛与缺乏可持续壁垒。
- 分析：单纯复制功能容易，但缺乏场景理解和数据沉淀难以形成护城河。
- 应对：持续运行沉淀校园活动数据，建立“数据飞轮”。追踪三层量化指标体系：业务价值指标（报名耗时、统计耗时）、系统健康指标、用户行为数据（活动报名转化率、学生活跃度、教师使用频次），以此驱动迭代方向，构建校园场景业务know-how的核心壁垒。

二、项目分工

结合本组6名成员各自的专长以及原型的功能模块划分，具体分工与工作量比例如下：

学号	姓名	工作内容	贡献度
102400313	陈时文	项目经理、答辩演讲与汇报：统筹整体进度，主导用户访谈，组织组内评审与TBD项决策。负责课堂答辩演讲，根据PPT与原型撰写讲稿，把控汇报时间节奏（如8分钟），负责预演并应对课堂评委问答。	16.7%
102400316	兰秀楠	PPT制作：负责《需求分析报告PPT》与《界面原型设计答辩PPT》的框架梳理、内容制作、视觉美化。	16.7%
102400432	张祺	评审表与文档协同：负责组织组内外评审会议，收集修改意见。填写《界面原型设计评审表》与《需求分析评审表》，建立并维护腾讯共享文档。	16.7%
102400314	陈子涵	界面原型设计：负责H5学生端与多角色PC端的高保真原型设计与交互逻辑，包括登录改密、一键报名（含4种失败文案拦截）、扫码签到、审核驳回弹窗等完整闭环。	16.7%
102400437	甘羽潇	需求规格说明书撰写：参考国标规范撰写《软件需求规格说明书》（Word电子版），负责消歧所有TBD项，采用分层描述确保图表符号与文字一致，排版规范美观。	16.6%
102400438	梁鑫敏	博客撰写：负责撰写本次博客随笔，汇总排版，核对评分要点及上传至华为云仓库给出链接。	16.6%

三、成员协作方式

3.1 沟通工具与日常交流

主沟通渠道：依托微信群进行日常任务通知、进度同步、问题答疑和文件分享。群内要求“重要通知必回复”，确保信息触达率100%。
会议工具：遇需深度讨论的架构设计、需求评审或答辩预演时，通过腾讯会议开展线上语音/视频会议，共享屏幕进行实时协作。
日常沟通截图：

腾讯会议视频截图：

3.2 版本仓库与文档协作

代码与文档版本控制：统一使用华为云仓库（CodeArts/DevCloud）进行代码和核心文档的托管。项目初期已完成小组仓库的创建，并将全体成员拉入仓库协同开发。采用主干保护策略，main 分支仅用于发布，日常开发在 dev 分支或个人 feature 分支进行。
仓库创建与成员管理截图：
协作流程：成员完成模块开发或文档撰写后，通过提交 Pull Request (PR) / Merge Request (MR) 申请合并。合并前需至少一名模块相关成员进行 Code Review，确保代码质量和文档规范。
文档协同：对于评审表、分工表等需要频繁修改的轻量级文档，使用腾讯共享文档进行实时协同编辑，利用历史版本功能规避覆盖风险。

3.3 冲突处理机制

文档冲突（腾讯共享文档）：
- 预防机制：多人协作编辑前，明确“段落认领制”，避免多人同时修改同一段落；编辑完成后及时保存并留言备注（如“XX已修改”）。
- 冲突处理：若出现内容覆盖或逻辑冲突，以模块负责人（如软需文档负责人、PPT负责人）的版本为准。若差异过大，第一时间在微信群内@相关人员，附上截图比对，确认无误后再统一替换。
- 兜底方案：利用腾讯文档的“历史版本”功能，随时回滚至冲突前的稳定版本，避免数据丢失。
代码冲突（华为云仓库）：
- 预防机制：要求成员每日开工前先 git pull 拉取最新代码；坚持“小步提交、频繁合并”原则，避免单次提交代码量过大导致冲突范围扩大。
- 冲突处理：合并代码时若产生冲突，由提交PR的成员负责根据提示在本地或云端解决。解决过程中若涉及核心逻辑变动，必须在微信群内发起讨论，由对应模块开发者和项目经理共同裁决，严禁私自强行合并。
- 回滚策略：若冲突导致主干代码无法运行，立即执行 git revert 回滚至上一稳定版本，待问题排查完毕后再重新提交，确保主干随时可用。
意见分歧（技术选型/业务规则）：
- 数据驱动原则：当组员对技术选型或业务规则（如TBD项决策）产生分歧时，遵循“用户需求优先”原则，结合前期用户调研数据或原型测试结果进行论证。
- 时间盒机制：针对争议点设置15分钟讨论时间盒，若仍无法达成一致，由项目经理组织投票或参考NABCD分析进行最终定夺，确保项目推进不卡壳。
- 复盘记录：每次冲突解决后，由项目经理在群里做简要记录（如“经过讨论，决定XX方案”），并同步更新到需求文档中，避免后期重复争论。

3.4 任务同步与进度管理机制

多维任务看板（华为云Issues/腾讯文档）：
- 任务拆解：将“需求分析、原型设计、PPT制作、软需撰写、答辩准备”等大任务拆解为颗粒度在1-2天内的具体子任务。
- 状态流转：所有任务卡片明确划分 Todo（待办）、In Progress（进行中）、Review（待审核）、Done（已完成） 四个状态，负责人拖动卡片即可实时同步进度。
- 依赖管理：明确任务间的依赖关系（如“答辩PPT”依赖于“原型设计”和“软需文档”完成），前置任务未完成时，依赖任务自动挂起预警，避免资源空转。
多层级沟通同步机制：
- 每日站会（微信群打卡）：每日晚间在微信群进行一次简短的文字/语音打卡（约10分钟），格式为：“今日完成：XXX；明日计划：XXX；遇到阻塞：XXX”。快速同步状态，暴露问题。
- 周例会制度（腾讯会议）：每周固定时间召开一次线上例会，每人依次汇报本周完成情况、遇到的阻塞点及下周计划。会议必须形成《会议纪要》并同步至群里。
里程碑核对与红黄绿灯预警：
- 进度核对：每次周例会严格对照 1.1 整体计划安排与里程碑检查进度偏差。
- 预警机制：
  - 绿灯：进度正常，按计划执行。
  - 黄灯：进度延迟1-2天，需在周会上说明原因并提交补救计划（如周末加班加点）。
  - 红灯：进度延迟3天以上，项目经理需立即介入，重新分配资源或砍掉非核心功能，确保整体交付物（博客、PPT、文档、评审表）按计划时间节点保质保量完成。
文档与代码同步规范：
- 每次组内评审后，软需文档和原型图必须同步更新，确保版本一致。
- 所有交付物最终统一汇总至华为云仓库指定文件夹，并建立清晰的 README.md 文件说明各项交付物对应的云仓链接。

四、软件需求规格说明书链接

点击此处查看《软件需求规格说明书》（PDF版）

文档核心内容概括：

本说明书严格按照 GB/T 9385-2008《计算机软件需求规格说明规范》 编写，结合了课程Checklist要求，覆盖一期MVP版本的完整需求。文档主要包含以下核心内容：

引言与总体描述：明确了文档目的、范围（覆盖账号登录、角色权限、活动创建/审核/发布、报名/取消、二维码签到、手动签到、站内通知、名单导出和基础看板等）。阐述了产品视角（前后端分离的Web/H5应用）、用户特征（学生、教师、管理员）及系统约束（不接统一认证、后端严格校验权限、事务一致性）。
用户场景与需求模型：详细描述了“学生报名与签到”、“教师发布与管理活动”、“管理员审核与维护”三大典型用户场景。同时提供了清晰的领域类图（UML），定义了User、Activity、Registration、CheckinRecord、AuditRecord等实体关系，并附有各端界面原型展示。
具体需求（核心）：
- 外部接口：给出了登录、活动、审核、报名、签到、导出等RESTful API接口示例。
- 功能需求（FR-01至FR-13）：明确了P0（核心）与P1（建议）优先级。涵盖首次强制改密（FR-01）、RBAC角色权限（FR-02）、活动创建与审核流转（FR-03/04）、学生一键报名与时间冲突校验（FR-06）、防超额并发控制（FR-07）、签到窗口期限制（FR-09）、名单导出（FR-12）等关键功能点。
- 非功能需求：包含性能需求（响应<2秒、分页、导出不阻塞）、设计约束（Spring Boot + Vue3 + MySQL + JWT）、以及可靠性、可用性、安全性（防越权、文件校验）、可维护性等软件系统属性。
其他需求与验收标准：
- 定义了数据需求（实体字段说明）和业务规则（如同一活动仅限一条有效报名、报名截止后不可取消等）。
- 列出了异常处理矩阵（资料缺失、重复报名、时间冲突、名额满、未报名签到、越权访问等6种明确的提示文案）。
- 制定了验收验证标准表（按需求编号FR-01至FR-12逐条对应验证方式与标准）。
附录：补充了需求优先级说明（P0一期必须完成、P1一期建议完成、P2后续扩展）。

Checklist自查：✅包含引言 ✅用户场景 ✅类图 ✅界面原型 ✅功能描述 ✅验收验证标准 ✅图表/文字/样式统一且符合规范。

五、界面原型设计链接

点击此处查看手机端产品原型
 点击此处查看电脑端产品原型

原型设计核心说明：

本次界面原型设计严格依据《校园活动报名OA系统 PRD V1.0》制作，覆盖了PC端（学生/教师/管理员三角色）与H5移动端（学生），实现了从“创建→审核→报名→签到→导出”的完整业务闭环。

1. PC端产品原型（三角色工作台）

角色切换与权限隔离：顶栏支持一键切换学生、教师、管理员视角，侧边栏菜单根据角色动态加载。严格遵循RBAC设计，教师无法查看其他教师活动的报名名单（越权时提示“当前用户无权查看该活动”）。
学生端核心流程：活动列表（支持分类/状态筛选）、活动详情（一键报名/取消报名）、我的报名、消息中心。报名与取消操作会实时反馈状态，并包含名额释放逻辑。
教师端管理闭环：我的活动（完整展示活动状态流转：草稿→待审核→已发布/已驳回/已驳回可修改再提交）、创建活动（表单必填校验、草稿保存、提交审核）、报名名单（支持Excel一键导出）、签到管理（投屏二维码、手动签到/补签）及基础看板（统计图表占位）。
管理员端管控中心：活动审核（通过即发布，驳回强制要求填写原因并留存审核记录）、全局活动管理、用户管理（禁用/启用/重置密码/批量导入）、分类管理以及全局看板（多维度数据统计）。
严谨的待确认项管理：原型中对需求文档未定义的规则均使用黄色 TBD 标记（如 TBD-04 密码复杂度、TBD-12 二维码出示方式、TBD-16 签到窗口终点、TBD-23 导出文件格式等），避免开发阶段产生歧义。

2. H5学生端移动原型（便捷触达）

移动端适配与沉浸式体验：采用手机壳包裹模拟真机演示，底部固定Tab导航（活动、我的报名、消息），符合学生高频使用手机端报名的习惯。
核心演示路径：登录 → 首次强制改密 → 活动列表浏览筛选 → 活动详情一键报名 → 截止前取消报名 → 扫码签到 → 消息中心已读/未读。
异常场景的精准打磨：在报名环节设计了交互Demo，点击报名按钮可循环演示“报名成功”以及4种失败场景（资料缺失、重复报名、时间冲突、名额已满），并输出明确的错误文案。
签到与消息联动：报名成功后才展示签到二维码入口与“扫码签到”按钮，签到窗口提示“开始前15分钟 ~ 活动结束”。消息中心支持已读/未读状态切换，底部Tab带红点角标（未读数量）。

3. 设计规范与视觉一致性

统一的设计语言：全局采用品牌蓝（#2f54eb）作为主色，成功状态使用绿色（#237804），警告使用橙色（#b25e09），错误使用红色（#cf1322）。
状态可视化与图形符号：所有活动状态、报名状态、签到状态均使用带颜色的标签进行清晰标识。界面严格使用一致的图形符号和文字描述。
符合读者立场：即使是不熟悉项目的人员，通过阅读原型说明栏（演示路径、操作提示、待确认标记），也能快速看懂系统要做什么，达到了需求规格说明书要求的“清晰完整准确”。

六、需求分析PPT链接

点击此处查看需求分析PPT

本PPT围绕“需求分析-原型设计-功能规划-验收标准”的主线，系统展示了团队从涉众诉求到软件模型的完整推导过程。

1. 需求分析目标与过程

定位：需求分析是系统工程与软件设计之间的“桥梁”，旨在准确描述三类用户（学生、教师、管理员）的真实诉求，将模糊需求转化为结构化模型，并定义可验证的验收标准。
四步闭环：展示了“现状调研（梳理问卷/群接龙/Excel断点）→ 用户访谈（确认少填表/少统计/可管控诉求）→ 文档化（产出PRD与国标SRS）→ 原型反哺（Web三端14页 + H5学生端6页，TBD显性标注）”的科学过程。

2. 五大核心建模成果

场景建模（用例图）：明确了三类参与者（学生、教师、管理员）的14项核心用例。学生端聚焦浏览、报名、签到；教师端聚焦创建、提交、名单与签到管理；管理员端聚焦审核、用户、分类与全局看板。
类建模（类图）：固化了领域结构。梳理了8个核心实体（User、StudentProfile、TeacherProfile、Activity、Registration、CheckinRecord、AuditRecord、Notification）的属性和操作，以及它们之间“拥有、创建、报名、审核”等5种核心关系。
行为建模（活动图与状态图）：
- 活动图：清晰展示了学生报名的“四层校验”（资料缺失→重复报名→时间冲突→名额满额）流程；以及教师创建活动后提交审核（通过发布/驳回重新提交）的闭环。
- 状态图：明确了活动状态（草稿→待审核→已发布/已驳回→活动结束）、报名状态（有效→已取消）和签到状态（未签到→已签到）的流转逻辑。
数据建模（ER图）：梳理了7个实体及7种联系，完成数据字典设计，可直接转化为数据库表结构。

3. 结论与项目价值

本PPT最终总结产出：需求分析将“报名难、统计累、监管散”的原始诉求，成功收敛为可设计、可验证的软件需求。通过场景→用例、类→领域、行为→流程、数据→ER的全维度建模，为后续的详细设计与开发奠定了坚实基础。

七、界面原型答辩PPT链接

点击此处查看界面原型答辩PPT

本PPT围绕“需求分析-原型设计-功能规划-验收标准”的主线，系统展示了从设计目标、信息架构到逐页原型、交互规范及状态机设计的完整答辩内容。

1. 设计目标与方法

五大目标：①验证闭环（创建→审核→发布→报名→签到→导出全流程可点击演示）；②三端一统（学生/教师/管理员同一套导航与状态语言，角色切换即体验另一视角）；③状态可见（活动、报名、签到状态用统一标签展示，异常有明确中文提示）；④待确认显性化（需求未定义处以黄色TBD标注占位设计，不擅自替用户作决定）；⑤双形态覆盖（PC后台三端 + H5学生端，覆盖主要访问场景）。
信息架构：三角色独立导航，公共登录/改密/通知不被任一角色独占，菜单由角色驱动（FR-02），越权项不出现亦不可访问。
核心页面流：一条主链路覆盖活动全生命周期（登录 → 创建活动 → 管理员审核 → 活动列表 → 一键报名 → 扫码/手动签到 → 名单导出）。

2. 原型成果矩阵（14页PC端 + 6页H5端）

PC端逐页展示（12页）：
- 公共：统一登录与首次强制改密（FR-01），禁用账号拦截。
- 学生端：活动列表（仅展示已发布/报名中，支持分类/状态筛选，FR-05）、活动详情（报名/取消/签到统一入口，四层校验，FR-06/08/09）、我的报名（报名与签到状态分离，截止前可取消，FR-08）、消息中心（站内通知，已读/未读，FR-11）。
- 教师端：我的活动（状态流转：草稿→待审核→已发布/已驳回，驳回闭环，FR-03/04）、创建活动（表单四区块，必填校验，可存草稿，FR-03）、报名名单（双名单导出Excel，FR-12）、签到管理（投屏二维码+手动补签双通道，进度可视，FR-10）。
- 管理员端：活动审核（通过即发布，驳回必填原因并通知教师，FR-04）、用户管理（检索/筛选/禁用/批量导入）、分类管理（活动分类统一维护）、全局看板（四大核心指标统计，FR-13）及全局活动管理（全校活动视图与导出）。
H5移动端逐页展示（6页）：手机场景优先。包含H5登录、活动列表（胶囊筛选+卡片流）、活动详情（底部固定CTA一键报名，四层校验失败提示与PRD完全一致）、我的报名、消息中心（红点标记未读）及首次修改密码。

3. 交互、状态机与设计规范

关键交互：报名四层校验（资料完整 → 防重复 → 时间冲突 → 名额满额，顺序执行），每个异常分支均给出明确中文提示。驳回弹窗必填原因、导出名单含字段清单。
状态机设计：明确定义了活动状态（草稿→待审核→已发布/已驳回→活动结束）、报名状态（有效→已取消）及签到状态（未签到→已签到）的流转规则，与《PRD》状态章完全一致。
设计规范：确定了色彩系统（主色#2F54EB、信息#13C2C2、警告#FA8C16、成功#52C41A、危险#F5222D），标签语义固化（绿=有效/已签到、橙=已驳回/待确认、红=危险/禁用、灰=只读/草稿）。组件规范包括卡片布局、表格样式、二次确认弹窗、Toast提示（2.4s自动消失）及TBD黄色虚线角标。