简介《在线教育网系统需求分析说明书》是一份面向学校信息化建设者、项目负责人及开发测试人员的需求文档模板围绕在线教育平台的学员管理、网上教学、校园信息发布与在线考试等业务展开帮助团队在立项与开发前厘清功能边界、角色权限和业务流程。压缩包内仅含1个doc文件整体约2.21MB便于直接查阅、打印或作为同类项目需求说明书的编写参照。文档从项目背景、用户环境、功能清单、用例描述到界面权限、班级科目管理、教学资料管理、登录考试与改卷查分等环节给出较完整的分析并涉及B/S架构、Oracle 9i、.NET平台以及Rational Rose、PowerDesigner建模要求。已有1588人学习适合需要梳理在线教育系统需求、绘制用例图与E-R图或撰写课程设计文档的读者参考。1. 从一份被退回三次的需求文档说起功能清单之外真正要固定下来的是什么在线教育网系统需求分析说明书这类文档最容易被写成一份功能清单学员管理、网上教学、在线考试三个部分各列一遍用例图贴几张编号排整齐看着就完整了。我带过几届课程设计之后发现中期返工最多的并不是功能列得少而是参与者边界和状态流转没有定清楚——后台哪个角色能点哪个按钮、学员能看到几年级的课件、交卷之后还能不能改答案这些在需求阶段含糊过去编码阶段就得靠返工来补。这份说明书的定位很明确给一个校内 B/S 教学平台把参与者、用例编号、权限矩阵和考试流程提前固定下来让后面的建表、画 E-R 图、写接口都有据可依。适合正在做教育类毕设或课程设计、需要一份能直接照着建表和画 UML 图的需求文档的人。2. 角色与权限模型三类参与者、四个功能编号与三张授权表后台权限这块是整份文档中最容易被评审追问的部分。原文功能清单列了 01 模块功能管理、02 权限设置下含 021 角色对模块的权限、022 功能模块管理、023 角色的管理、03 角色管理031 创建、032 修改、033 删除、034 权限设置管理、04 栏目管理041 外观样式设置、042 栏目内容动态设置。这些编号不是排着好看的它们决定了后面数据库表的主键怎么定、用例图和代码怎么对得上。我一般会把编号当成贯穿全流程的线索文档里叫 021数据库里模块主键就是021答辩现场打开表一查就能对上省掉很多解释成本。2.1 用例图先画参与者边界再谈功能整个系统只有三类参与者管理员、教师、学员。后台管理用例图的参与者只画管理员一个人前台教学和考试用例图才出现教师和学员。这两张图必须分开画因为参与者的权限来源不一样——管理员进后台靠的是角色对模块的授权学员进前台靠的是班级和年级归属混在一张图里会出现“学员也能管理模块”这种明显说不通的连线评审一眼就能看出来。参与者可进入区域典型用例权限来源管理员后台全部模块模块管理、角色管理、栏目管理、班级与教师创建角色对模块的授权教师教学管理、考试管理资料上传、进度维护、手工选题、主观题改卷任课关系 角色授权学员前台学习、在线考试浏览教学内容、提问、参加考试、查分班级归属 考试发布状态这张表看起来简单实际写的时候要逐条对照原文的功能清单。比如原文写“学员可以浏览本年级以及以下年级的教学内容教师或管理员不受限制”这一句就是一条硬性的数据权限规则不是界面上的隐藏逻辑。写需求文档时如果只写“学员可浏览教学内容”开发阶段大概率会做成全量可见等到验收才发现低年级学员能翻到高年级试卷那时候改起来就是牵一发动全身。用例描述我习惯固定写三段前置条件、主流程、异常分支。以 031 创建角色为例前置条件是管理员已登录且拥有 03 模块的编辑权限主流程是填写角色名称、选择可访问模块、保存异常分支是角色名重复、未选任何模块、所选模块已被停用。异常分支这一段最容易被省略但恰恰是测试用例的直接来源写文档时多花十分钟后面写测试用例能省一小时。2.2 模块、角色、授权三张表怎么落权限模型不需要上完整的 RBAC 四层结构校内平台用“用户—角色—模块”三层就够了。核心是三张表模块表存所有可授权的功能点角色表存角色定义授权表存某个角色对某个模块有哪些操作位。下面这段是模块表的建表语句按 Oracle 9i 的语法写字段类型和原文指定的数据库版本对得上。-- 功能模块表一个模块一行主键直接沿用需求文档的功能编号 CREATE TABLE T_MODULE ( MODULE_ID VARCHAR2(10) PRIMARY KEY, -- 如 01、021、031与文档编号一致 MODULE_NAME VARCHAR2(60) NOT NULL, -- 模块名称如“角色管理” PARENT_ID VARCHAR2(10), -- 父模块编号顶级为 NULL MODULE_URL VARCHAR2(200), -- 后台入口地址用于菜单渲染 SORT_NO NUMBER(4) DEFAULT 0, -- 同级排序 STATUS CHAR(1) DEFAULT 1 -- 1 启用0 停用 );主键直接用文档里的两位或三位编号是为了让需求、设计、代码三份材料能互相索引。曾经有一次评审评审老师指着用例图问“021 这个用例在库里哪张表”当时编号和表名是两套体系翻了五分钟才找到对应关系场面很难看。从那以后我就把编号当主键用再没出过这个问题。PARENT_ID是为了支持两级菜单01 下面挂 021、022、023菜单渲染时递归一层就够不用做成无限层级。STATUS字段是给模块下线留的余地停用模块时保留授权记录重新启用后权限自动恢复比直接删行安全。授权表是权限模型的核心字段设计要能表达“能看”和“能改”的区别-- 角色模块授权表一个角色对一个模块一行记录四种操作位 CREATE TABLE T_ROLE_MODULE ( ROLE_ID VARCHAR2(20) NOT NULL, MODULE_ID VARCHAR2(10) NOT NULL, CAN_VIEW CHAR(1) DEFAULT 0, -- 查看能否看到菜单和列表 CAN_ADD CHAR2_DUMMY_PLACEHOLDER, -- 占位说明见下方文字 CAN_EDIT CHAR(1) DEFAULT 0, -- 编辑能否修改已有数据 CAN_DEL CHAR(1) DEFAULT 0, -- 删除能否删除数据 CONSTRAINT PK_ROLE_MODULE PRIMARY KEY (ROLE_ID, MODULE_ID) );上面CAN_ADD那行是排版占位实际建表时写CAN_ADD CHAR(1) DEFAULT 0即可四个操作位分别对应增、删、改、查。之所以拆成四个独立字段而不是用一个权限字符串是因为校内平台的权限粒度基本停在“这个角色能不能删数据”这一层再细就要引入数据权限超出课程设计的范围。用四个 CHAR(1) 字段查询时拼一个WHERE CAN_VIEW1就能过滤菜单实现成本最低。配套的角色表只需要角色编号、角色名称、角色描述、是否内置四个字段。内置角色是管理员和学员不允许删除防止误操作把系统锁死。这里有个细节原文 03 用例里写了“角色的修改和删除扩展了角色的创建”意思是修改和删除的前提是角色已经存在这条约束要在角色表上加外键或者在业务层校验不能只写在文档里。2.3 角色管理与栏目管理的耦合点04 栏目管理包含外观样式设置和栏目内容动态设置这两块和权限的关系容易被忽略。栏目维护人员本质上是一种受限角色他只能改自己负责的栏目内容不能碰其他栏目。如果只靠T_ROLE_MODULE授权粒度只能到“栏目管理”这个模块整体做不到“A 管理员只能维护校园动态、B 管理员只能维护师资力量”。通常的做法是给栏目单独加一张授权表T_ROLE_COLUMN字段是角色编号、栏目编号、是否可编辑和模块授权表结构平行。这样做的好处是栏目数量会随学校需求增长而模块数量相对稳定两张表分开后互不影响。代价是多一次关联查询但校内平台的并发量根本感觉不到这个开销。提示栏目外观样式设置建议只开放给超级管理员普通栏目维护人员只给内容编辑权限。样式涉及页面模板误改一次整个栏目都会变形恢复起来比改内容麻烦得多。3. 网上教学模块班级树、教学进度与资料库的绑定关系网上教学这块原文列了七个功能编号001 班级科目创建与管理、002 教师创建与管理、003 教学资料管理含 00301 教学进度管理、004 学员注册、005 浏览教学内容、006 提问发表意见、007 疑问解答。这七条不是并列关系001 和 002 是基础数据003 挂在科目和进度下面005 到 007 是学员和教师之间的互动闭环。设计时要把这个层次关系画出来否则建表会发现资料表不知道该挂班级还是挂科目。3.1 班级与科目先把树定下来再谈人班级和科目的关系是典型的多对多一个班级要学多门科目一门科目会被多个班级开设。但直接建一张中间表是不够的因为“哪个老师教哪个班的哪门课”是第三个维度。我一般会建三张表T_CLASS存班级基本信息班级编号、名称、年级、班主任、状态T_SUBJECT存科目字典科目编号、名称、所属年级、排序T_TEACHING存任课关系班级编号、科目编号、教师编号、学期。T_TEACHING这张表是后面所有权限判断的依据。教师登录后能看到哪些班级的资料、能改哪些科目的进度、能批改哪些班级的试卷全部从这张表推出来不需要在教师表上加一堆冗余字段。学员的可见范围则从T_CLASS的年级字段推出来学员所在班级的年级为 N那么他可见的教学内容就是年级小于等于 N 的科目。这条规则原文写得很清楚落到 SQL 上就是一个WHERE GRADE :studentGrade但要注意这个条件必须封装在一个统一的查询方法里不能每个页面各写一遍否则迟早有一处漏掉。年级字段建议用数字而不是字符串一年级存 1、二年级存 2比较大小直接用。如果用“一年级”“二年级”这种中文存排序和比较都要额外处理属于给自己找麻烦。科目表上的所属年级字段也一样处理。3.2 教学资料文件存磁盘元数据存库003 教学资料管理明确写了资料类型包括 FLASH 动画、视频、课件还要能根据教学进度和节次发布。这意味着资料表不能只存一个文件路径必须把“这份资料属于哪个科目、哪个章节、第几节、什么类型、谁上传的、审核状态”全部结构化。常见的错误做法是把文件名当成唯一标识文件一改名记录就全乱。-- 教学资料表文件本体存磁盘这里只存元数据 CREATE TABLE T_MATERIAL ( MATERIAL_ID VARCHAR2(32) PRIMARY KEY, -- 主键建议用序列或 UUID SUBJECT_ID VARCHAR2(10) NOT NULL, -- 所属科目 PROGRESS_ID VARCHAR2(32), -- 关联教学进度可为空表示不绑章节 MATERIAL_TYPE CHAR(1) NOT NULL, -- 1 FLASH2 视频3 课件4 其他 FILE_NAME VARCHAR2(200) NOT NULL, -- 原始文件名用于下载时显示 STORE_PATH VARCHAR2(300) NOT NULL, -- 相对存储路径不存绝对路径 FILE_SIZE NUMBER(12), -- 字节数用于上传前校验 UPLOADER_ID VARCHAR2(20) NOT NULL, -- 上传教师 AUDIT_STATUS CHAR(1) DEFAULT 0, -- 0 待审核1 通过2 驳回 UPLOAD_TIME DATE DEFAULT SYSDATE );STORE_PATH存相对路径是必须坚持的一条。绝对路径一旦写进数据库换服务器、换盘符、做测试环境迁移全部要改数据。我一般约定存储根目录由配置文件给出数据库里只存2024/05/subject03/lesson12/xxx.flv这样的相对段读取时拼接。这个习惯是从一次迁移事故里换来的当时所有资料的路径都写死了盘符测试环境部署到另一台机器上三百多条资料记录全部失效只能写脚本批量替换。AUDIT_STATUS字段原文没提但校内平台让教师直接上传资料并立即对学员可见风险不小。加一个待审核状态由管理员或科目负责人点一下通过多一道也不多多少工作量。审核不通过时保留记录并记下驳回原因教师改完重新提交比删了重传可追溯。注意文件大小字段在上传前就要校验视频类资料建议限制在 200MB 以内。限制值写在配置文件里不要写死在代码里不同科目对视频时长的要求差别很大。3.3 答疑闭环提问要绑到具体章节006 和 007 是一对学员针对所浏览章节的教学内容提问教师解答。这里的关键是问题必须绑到具体的资料或进度节点上不能只绑科目。如果只绑科目一个学期下来某门课攒了几百个问题教师根本没法按章节整理学员也搜不到自己需要的答案。问题表的结构是问题编号、提问学员、关联资料编号或进度编号、问题标题、问题内容、提问时间、状态待解答、已解答、已关闭、解答教师、解答内容、解答时间。状态字段很重要教师端可以按“待解答”筛选学员端可以看自己的问题处理到哪一步。已关闭状态留给长时间无人回答或重复提问的情况由管理员手动关闭避免列表越堆越长。解答权限要跟任课关系挂钩教师只能回答自己任教班级和科目下的问题不能跨科目回答。这条规则在文档里要明确写出来落到代码上就是解答前先查T_TEACHING表。如果偷懒只判断“是不是教师”上线后会出现教师互相答疑的混乱局面。4. 在线考试系统从选题到查分的状态流转考试模块是整份文档里状态最多的一块。功能清单列了 01 登录0101 用户登录、0102 教师登录、02 题目类型0201 手动选题、0202 系统选题、03 在线考试、04 改卷0401 系统改卷、0402 教师改卷、05 查分0501 教师查分、0502 学员查分。这些编号背后是四个状态机试卷状态、考试状态、答卷状态、成绩状态任何一个没定清楚都会在联调阶段暴露出来。4.1 手动选题与系统选题的差别不在界面0201 手动选题是教师按题型逐题勾选组卷0202 系统选题是按题型和数量随机抽题。两者在界面上看起来只是“选”和“抽”的区别但落到数据上差别很大手动选题要记录题目顺序系统选题每次抽题结果不同必须把抽中的题目固化下来否则学员刷新页面看到的是另一套题。所以不管哪种方式最终都要写一张试卷题目表T_PAPER_QUESTION字段是试卷编号、题目编号、题目顺序、每题分值。手动选题时按教师勾选顺序写入系统选题时按抽题结果写入考试时只读这张表。这样做还有一个好处同一份试卷可以被多个班级使用学员看到的题目顺序可以按学员编号做扰动防止邻座抄答案扰动逻辑在读表时做不影响原始数据。题型字典建议单独建表T_QTYPE存题型编号、题型名称、是否客观题、默认分值。客观题标记用于自动改卷原文 0401 系统改卷对应的就是这一批题型。题型不要硬编码在代码里学校不同科目对题型的要求不一样字典表可以让管理员自己增删。4.2 考试状态机与防重复交卷一场考试从创建到成绩发布状态是单向流动的草稿、已发布、进行中、已结束、已阅卷、成绩已发布。每个状态能做什么操作要定死草稿状态可以改试卷和考试时间发布后只能改结束时间不能改试卷进行中不允许任何人修改试卷已结束才能开始改卷。-- 交卷操作用状态位做条件更新天然防重复提交 UPDATE T_EXAM_RECORD SET RECORD_STATUS 2, -- 2 表示已交卷 SUBMIT_TIME SYSDATE WHERE EXAM_ID :examId AND STUDENT_ID :studentId AND RECORD_STATUS 1; -- 只有“考试中”才允许交卷 -- 影响行数为 0说明要么已经交过卷要么根本没开始考 -- 前端收到 0 行更新时提示“请勿重复提交”并跳转到成绩页这段更新的关键在于把状态判断放进WHERE条件里而不是先查再改。先查再改在并发下会出现两个请求同时查到“考试中”然后都执行更新最后交卷时间被覆盖。校内考试虽然并发不高但收卷那几分钟是集中提交的高峰这个坑值得提前堵上。数据库层面再加一个(EXAM_ID, STUDENT_ID)的唯一索引双保险。考试时间一律以数据库的SYSDATE为准不接受前端传上来的时间戳。前端时间可以改学员把本地时钟往前调就能延长答题时间。服务端在开始考试和交卷两个节点各校验一次当前时间是否在考试窗口内超时的答卷标记为“超时交卷”成绩照常计算但记录里留痕方便教师复核。4.3 系统改卷与教师改卷的边界0401 系统改卷只处理客观题比对标准答案直接算分0402 教师改卷处理主观题按题给分。两者的执行顺序是先自动后人工自动改卷在交卷后立即触发主观题进入待改队列教师按班级或按题目批改。这里要定一条规则整张试卷的所有题目都改完之后成绩才算“已阅卷”才能进入发布流程。如果允许部分题目未改就发布学员查到的分数是残缺的。实现上给答卷表加一个“待改题数”字段每改一题减一减到零时把答卷状态推到已阅卷。这个计数器比每次发布前统计一遍要可靠也方便教师端显示“还有 12 份待改”。改卷权限也要跟任课关系绑定。教师只能改自己任教班级的试卷跨班改卷要拒绝。管理员可以改所有班级但操作要记日志。这条规则如果不在需求里写清楚开发阶段很容易做成“教师能改所有卷”等到成绩出错追查起来日志里连谁改的都没有。4.4 成绩查询的权限口径0501 教师查分和 0502 学员查分看起来是同一个查询的两个入口实际权限口径完全不同。教师查分看的是本班全部学员的成绩可以按科目、按考试、按分数段筛选还能导出学员查分只能看自己的而且必须等成绩发布之后。“成绩发布”这个状态是学员查分的唯一开关。很多实现图省事答卷一改完学员就能查结果教师还在复核分数学员已经看到最终成绩后面再改分就要挨个解释。加一个发布动作管理员或科目负责人点一下所有答卷状态批量推到“成绩已发布”学员端才能查到。发布之后如果确实需要改分走“撤销发布、修改、重新发布”的流程改动记录写进日志。学员查分页面还要处理一种情况缺考。没参加考试的学员在成绩列表里显示缺考而不是 0 分这两个含义完全不同成绩统计时要分开算。答卷表里没记录就是缺考不要为了省事给每个学员预生成一条 0 分记录。5. 常见问题排查五个在评审现场最容易被问住的点5.1 权限只做了菜单隐藏接口没做校验现象用学员账号登录后手动在地址栏输入后台管理页面地址能直接打开并操作。原因权限判断写在了页面渲染层菜单不显示就以为挡住了接口层完全没有校验。解决在请求进入业务方法之前统一拦截一次拿当前登录用户的角色去查T_ROLE_MODULE没有对应操作位直接返回无权限。菜单隐藏只是体验优化不是安全边界。这一条在答辩时几乎必问因为验证成本极低打开浏览器改个地址就能试出来。5.2 教学资料只存了路径换个环境全部失效现象测试环境部署到另一台服务器教师上传的课件和视频全部打不开列表还在但点下载就报错。原因数据库里存的是绝对路径包含盘符或具体目录环境一变路径就不存在了。解决改存相对路径存储根目录放到配置文件中读取时拼接。已经入库的历史数据写一个脚本批量截取相对段。这个问题在开发机上永远不会暴露只有换环境才炸属于典型的“上线才发现”的坑。5.3 考试时间用前端传来的值现象有学员反映答题时间比别人长或者明明还没到结束时间就被强制收卷。原因开始和交卷的时间校验用了客户端时间学员改本地时钟就能绕过。解决所有时间判断以数据库SYSDATE为准前端只负责显示倒计时倒计时归零后仍然以服务端校验结果为准。服务端在开始考试时记录一次开始时间交卷时用当前时间减去开始时间超过考试时长加缓冲就判定超时。5.4 年级可见范围在某个查询里漏了条件现象抽查时发现一年级学员能浏览二年级的教学内容但大部分页面又是正常的。原因年级过滤条件散落在多个查询方法里新加的一个列表页复制了旧代码但漏掉了WHERE GRADE ?。解决把带年级条件的查询封装成统一的视图或数据访问方法所有前台教学内容的读取都走这一个入口禁止各处自己拼 SQL。需求文档里那句“本年级及以下”要单独列成一条数据权限规则而不是藏在用例描述的一句话里。5.5 用例编号和数据库主键对不上现象评审时被问“031 这个用例对应哪张表、哪个接口”翻文档翻了半天最后只能说“大概在角色管理里”。原因需求文档的功能编号是一套数据库表名和接口路径是另一套两边没有映射关系。解决模块表主键直接用功能编号接口路径里带上模块编号代码注释里标注对应用例编号。这样从文档到表到接口是一条线答辩时打开任何一处都能互相印证。这个习惯看起来笨但它在评审现场能省下的时间远超维护成本。6. 验收与答辩按用例清单逐条打勾别按页面走验收最容易犯的错是按页面走一遍首页能打开、后台能登录、考试能交卷就算通过。这样走完功能清单里那些边角用例基本测不到评审老师随便挑一条就能问住。我一般会做一张验收对照表左列是从需求文档抄下来的用例编号中间是验收点右边是通过标准和证据。验收时按编号逐条过过一条勾一条不按页面顺序。用例编号验收点通过标准证据021角色对模块授权新建角色只勾查看权限登录后只能看不能改操作录屏 授权表截图031创建角色角色名重复时提示且不写入数据库查询结果003教学资料上传上传视频后换目录部署仍可下载两台环境各下一次005学员浏览范围一年级学员看不到二年级资料两个账号对比截图0202系统选题同一试卷两次打开题目一致两次打开的题目列表03在线考试重复点击交卷只产生一条记录答卷表记录数0402教师改卷非任课教师无法进入该班改卷页越权访问截图0502学员查分成绩未发布时查询为空发布前后对比这张表还有个隐藏用途答辩时老师问“你这个权限做到什么程度”直接把表翻到 021 那一行说清楚能看不能改是怎么验证的比口头描述“做了权限控制”有说服力得多。用例编号、表主键、接口路径三者一致回答任何追溯类问题都不会卡壳。答辩陈述建议控制在十分钟以内顺序是一句话说清系统解决什么问题然后讲参与者有哪几类、权限怎么分接着挑一个最复杂的流程通常是考试从组卷到查分完整讲一遍状态怎么流转最后展示验收表。不要从技术栈开始讲.NET Framework 2.0 和 Oracle 9i 这些是环境约束不是设计亮点放在回答提问时再说。有个细节值得提前准备把 E-R 图和用例图打印出来带进答辩现场。PowerDesigner 导出的图在投影上经常看不清连线纸质版传阅反而更清楚。我带过的几次答辩里凡是把图打印出来的被追问细节时都能直接指着图解释节奏稳很多。从那以后我每次交需求文档之前都会强制走一遍“编号—表—接口”的对齐检查随便抽三个用例编号看能不能在三十秒内找到对应的表名和接口路径。找不到就说明这份文档还没到能交付的状态。希望这套结构能帮到你至少在被问到权限和数据范围的时候不用现场编。本文还有配套的精品资源点击获取
