企业官网建设流程全解析

简介：这份在线教育网系统需求分析说明书面向学校信息化建设者、软件工程专业学生及项目开发人员，为构建B/S架构的在线教育平台提供完整的需求指导。文档围绕学员管理、网上教学管理与校园信息管理三大模块展开，详细梳理了权限设置、角色管理、栏目维护、班级科目创建、教学资料上传下载、在线考试与自动改卷等业务功能，并配有UML用例图与参与者描述，明确管理员、教师、学员三类角色的行为边界。资源包内含1个doc文档，约2.21MB，内容涵盖项目背景、用户环境、功能清单与需求分析，技术栈涉及.Net Framework 2.0、Oracle 9i及Rational Rose、PowerDesigner建模工具。目前已有1583人学习，适合需要撰写需求规格说明书、开展课程设计或搭建在线教育平台的读者参考，可帮助快速理解系统功能划分与用例建模思路。

1. 在线教育网系统需求分析说明书：从一份文档到一套能落地的建模范式

做过在线教育平台的人都有一个共识：真正拖慢进度的从来不是写代码，而是需求阶段没把角色、权限、课程状态机这三件事说清楚。一份合格的在线教育网系统需求分析说明书，本质上是把“谁在什么条件下能对哪门课做什么操作”翻译成 B/S 架构下可建模、可验证、可交付的技术契约。它面向的是要交付真实系统的开发团队，不是交作业的学生。热搜里 uml 用例图、uml 类图、E-R 图、Oracle 这些词频繁出现，恰恰说明大家卡在同一个地方：知道要画图，但不知道画到什么颗粒度才算够用。这篇笔记就按我实际做项目的顺序，把这份说明书从结构、建模、数据设计到评审验收整条链路拆开讲，让你拿到就能照着写。

2. 需求分析说明书该写哪几块：B/S 在线教育系统的文档骨架

在线教育系统的需求文档和普通管理系统最大的区别在于：它同时存在“内容生产”和“内容消费”两条主线，讲师侧要管课程、章节、题库、直播排期，学员侧要管选课、学习进度、订单、考试。两条线共用一套用户体系和权限模型，所以文档骨架必须先把边界划清楚，否则后面 UML 建模会互相打架。

2.1 五段式结构：从业务目标到验收标准

我一般把说明书拆成五段，每段都有明确的交付物，不写完不进入下一段：

业务概述这一段很多人写得像宣传文案，其实它只需要回答三个问题：平台服务谁、他们来干什么、平台靠什么盈利。在线教育场景下，角色至少包括学员、讲师、助教、运营、管理员五类，少一个后面权限模型就要推倒重来。功能需求按模块拆，我习惯分成用户中心、课程管理、学习中心、订单支付、考试测评、直播互动、后台运营七个模块，每个模块再往下拆用例。

非功能需求是最容易被敷衍的部分。在线教育系统有几个硬指标必须写进文档：课程视频并发播放数、直播延迟上限、订单支付成功率、考试提交的幂等性要求。这些指标直接决定后面架构选型和数据库设计，不写清楚，开发和测试都没有依据。

2.2 用例规约怎么写才不会被开发怼

用例图只是索引，真正让开发能动手的是用例规约。一个完整的用例规约包含：用例编号、名称、参与者、前置条件、基本流程、备选流程、后置条件、业务规则。以“学员选课”为例：

• 前置条件：学员已登录且账号状态正常
• 基本流程：进入课程详情 → 校验是否已选 → 校验课程容量 → 生成订单 → 跳转支付
• 备选流程：课程已满 → 提示并推荐相似课程；重复选课 → 直接进入学习中心
• 后置条件：订单记录写入，课程容量减一
• 业务规则：同一课程不可重复购买，未支付订单 30 分钟自动关闭

这里有个血泪经验：备选流程一定要写全，开发写代码时最怕的就是“这种情况怎么办”。你少写一条，联调时就多吵一次。业务规则里的数字（30 分钟、容量上限）必须和运营确认，不能自己拍脑袋。

2.3 把热搜里的 UML 图落到文档对应位置

很多人搜 uml 用例图、uml 类图、uml 中的动态结构图包括哪些，其实是想知道每种图放在文档哪个位置。我的对应关系是：

• 用例图 → 功能需求章节，每个模块一张
• 类图 → 数据需求章节，描述实体间静态关系
• 时序图 / 活动图 / 状态图 → 关键流程章节，描述动态行为
• E-R 图 → 数据需求章节，和类图互补

动态结构图在 UML 里指的就是时序图、协作图、活动图、状态图这四类，在线教育系统里最常用的是时序图（描述选课、支付、直播推流）和状态图（描述课程状态、订单状态）。状态图尤其重要，课程从“草稿→待审核→已上架→已下架”的流转，订单从“待支付→已支付→已退款”的流转，画清楚能省掉大量沟通成本。

3. 用 UML 把在线教育核心流程建模：用例图、类图、时序图的画法与参数

UML 建模不是画得漂亮就行，关键是颗粒度和一致性。我见过太多文档用例图和类图对不上，开发照着做发现少字段。这一章按“先静态后动态”的顺序，把三类核心图的画法和参数讲透。

3.1 用例图：角色与用例的边界怎么划

在线教育系统的用例图我一般画三张：学员视角、讲师视角、管理视角。不画一张大图的原因是角色太多，连线会变成蜘蛛网，评审时没人看得清。

学员视角的核心用例：浏览课程、搜索课程、选课下单、支付、观看视频、做练习、参加考试、查看成绩、评价课程、申请退款。讲师视角：创建课程、编辑章节、上传视频、组卷、发布考试、查看学员数据、发起直播。管理视角：审核课程、管理用户、处理退款、配置轮播、查看报表。

画用例图有三个参数要定：

1. 用例粒度：一个用例对应一个完整的用户目标，不要拆成“点击按钮”这种操作级。
2. include 和 extend 的使用：必须执行的公共步骤用 include（如“支付”include“校验订单”），可选扩展用 extend（如“选课”extend“使用优惠券”）。
3. 角色继承：助教继承讲师的部分权限时用泛化箭头，但不要为了省事把管理员和运营合并。

注意：用例图里不要出现数据库、接口、类这些技术元素，它是业务视角的图，混入技术元素会让业务方看不懂，评审直接卡住。

3.2 类图：实体、属性、关系的设计参数

类图是后面建表的基础，属性设计错了，数据库就要改。在线教育系统的核心类包括：User（用户）、Student、Teacher、Course（课程）、Chapter（章节）、Lesson（课时）、Order（订单）、Payment（支付）、Exam（考试）、Question（题目）、AnswerRecord（答题记录）、Enrollment（选课记录）。

每个类的关键属性：

// 课程类核心字段设计 public class Course { private Long courseId; // 主键，雪花ID private String title; // 课程标题，唯一索引 private Long teacherId; // 讲师ID，外键 private Integer status; // 状态：0草稿 1待审核 2已上架 3已下架 private BigDecimal price; // 价格，精度两位小数 private Integer capacity; // 容量上限，0表示不限 private Integer enrolledCount; // 已选人数，冗余字段 private Date createTime; // 创建时间 private Date updateTime; // 更新时间 }

类之间的关系要标清楚：Student 和 Course 是多对多，通过 Enrollment 关联；Course 和 Chapter 是一对多；Chapter 和 Lesson 是一对多；Order 和 Course 是多对一；Exam 和 Question 是多对多，通过 ExamQuestion 关联。多重性标注（1、0..、1..）不能省，它直接决定外键建在哪张表。

类图里还有一个容易忽略的点：抽象类。User 可以设计成抽象类，Student 和 Teacher 继承它，公共属性（用户名、密码、手机号、状态）放父类，角色特有属性放子类。这样权限校验时统一操作 User 即可。

3.3 时序图：选课支付和直播推流两条关键链路

时序图描述对象间的消息传递顺序，在线教育系统里最值得画的两条链路是选课支付和直播推流。

选课支付的时序：学员 → 课程服务（校验课程状态和容量）→ 订单服务（创建订单）→ 支付服务（调用支付网关）→ 回调订单服务（更新订单状态）→ 课程服务（增加选课记录、容量减一）→ 通知学员。这条链路里有两个关键参数：订单超时时间（一般 30 分钟）和支付回调的幂等键（用订单号做唯一约束）。

直播推流的时序：讲师端 → 推流服务（鉴权、分配推流地址）→ 流媒体服务器 → 学员端拉流。这里要标注清楚鉴权 token 的有效期和拉流地址的过期时间，一般 token 有效期 2 小时，拉流地址 4 小时。

画时序图时，激活条（对象执行操作的时期）要画准确，它反映了对象的生命周期。消息编号建议加上，方便评审时逐条对照。返回消息用虚线箭头，异步消息用开放箭头，这些细节在软考中级 UML 建模里是考点，在实际项目里是沟通效率的保障。

4. E-R 图到 Oracle 建表：在线教育系统的数据落地

UML 类图解决的是业务对象关系，E-R 图解决的是数据库落地。两者视角不同：类图可以有继承、多态，E-R 图必须扁平化成表和字段。在线教育系统数据量增长最快的是学习记录和答题记录，设计时就要考虑分区和索引。

4.1 从类图到 E-R 图的转换规则

转换规则我总结成四条：

1. 普通类转表，属性转字段，主键选无业务含义的自增或雪花 ID。
2. 一对多关系，外键建在多的一方。Course 和 Chapter，外键 chapter.course_id。
3. 多对多关系，拆中间表。Student 和 Course 拆 enrollment 表，字段为 student_id、course_id、enroll_time、progress。
4. 继承关系，两种策略：单表继承（所有角色一张 user 表加 role 字段）或类表继承（user 表存公共字段，student、teacher 表存特有字段）。在线教育系统我推荐类表继承，因为讲师和学员的特有字段差异大。

E-R 图里要标注清楚主键（PK）、外键（FK）、唯一约束（UK）和索引。课程表的 title 加唯一索引，订单表的 order_no 加唯一索引，学习记录表的 (student_id, lesson_id) 加联合唯一索引防止重复记录。

4.2 Oracle 建表脚本与关键参数

Oracle 是在线教育系统常见的选择，尤其在中大型机构。建表时几个参数必须显式指定：

-- 课程表建表脚本 CREATE TABLE t_course ( course_id NUMBER(20) NOT NULL, title VARCHAR2(200) NOT NULL, teacher_id NUMBER(20) NOT NULL, status NUMBER(2) DEFAULT 0 NOT NULL, price NUMBER(10,2) DEFAULT 0 NOT NULL, capacity NUMBER(8) DEFAULT 0 NOT NULL, enrolled_count NUMBER(8) DEFAULT 0 NOT NULL, create_time DATE DEFAULT SYSDATE NOT NULL, update_time DATE DEFAULT SYSDATE NOT NULL, CONSTRAINT pk_course PRIMARY KEY (course_id), CONSTRAINT uk_course_title UNIQUE (title) ); -- 索引：按讲师和状态查询课程列表 CREATE INDEX idx_course_teacher ON t_course(teacher_id, status); -- 注释 COMMENT ON TABLE t_course IS '课程表'; COMMENT ON COLUMN t_course.status IS '0草稿 1待审核 2已上架 3已下架';

参数说明：NUMBER(20) 用于雪花 ID，NUMBER(10,2) 用于金额保证两位小数，VARCHAR2 用字节长度还是字符长度取决于字符集，AL32UTF8 下 VARCHAR2(200) 能存 200 个字符。DATE 类型在 Oracle 里包含时分秒，不需要 TIMESTAMP 除非要毫秒精度。

分页查询是在线教育系统列表页的高频操作，Oracle 12c 之后可以用 OFFSET FETCH：

-- Oracle 12c+ 分页 SELECT course_id, title, price FROM t_course WHERE status = 2 ORDER BY create_time DESC OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY;

12c 之前用 ROWNUM 嵌套，写法繁琐且容易出错。如果项目还在用 11g，建议封装成存储过程或视图，避免每个查询都写嵌套。

4.3 学习记录表的分区与索引策略

学习记录是在线教育系统增长最快的表，一个学员看一节课就产生一条记录，日增可能几十万。这张表必须做分区，按 create_time 做范围分区，每月一个分区：

CREATE TABLE t_learn_record ( record_id NUMBER(20) NOT NULL, student_id NUMBER(20) NOT NULL, lesson_id NUMBER(20) NOT NULL, course_id NUMBER(20) NOT NULL, progress NUMBER(5,2) DEFAULT 0, last_time DATE, create_time DATE DEFAULT SYSDATE NOT NULL, CONSTRAINT pk_learn_record PRIMARY KEY (record_id, create_time) ) PARTITION BY RANGE (create_time) ( PARTITION p202401 VALUES LESS THAN (TO_DATE('2024-02-01','YYYY-MM-DD')), PARTITION p202402 VALUES LESS THAN (TO_DATE('2024-03-01','YYYY-MM-DD')) );

分区键必须包含在主键里，这是 Oracle 分区表的硬性要求。查询时带上 create_time 条件才能命中分区裁剪，否则全分区扫描。索引建在 (student_id, lesson_id) 上，用于查询某个学员某节课的记录。

提示：Oracle 中 TRUNC(SYSDATE) 常用于按天统计，TRUNC(SYSDATE, 'MM') 按月统计。学习时长统计用 SUM(progress) 配合 GROUP BY 即可，但要注意 progress 是百分比还是秒数，设计时统一成秒数更灵活。

5. 需求评审与避坑：在线教育系统文档最容易翻车的五个地方

需求评审是文档交付前的最后一道关，也是翻车最集中的环节。下面五条是我踩过的坑，每条按现象、原因、解决写。

5.1 用例图和类图对不上，开发照着做发现少字段

现象：评审时用例图里“学员评价课程”这个用例，类图里找不到评价实体，开发问评价数据存哪，当场卡住。

原因：用例图和类图分开画，画完没有交叉核对。用例图关注行为，类图关注数据，但每个用例背后都有数据支撑。

解决：画完类图后，逐个用例检查是否有对应实体。评价用例对应 Evaluation 类，字段包括 evaluation_id、student_id、course_id、score、content、create_time。建立一张“用例-实体对照表”，评审时逐行过。

5.2 订单状态机没画，支付回调把订单改成错误状态

现象：支付成功后订单状态变成“已支付”，但退款回调又把状态改成“已退款”，而实际退款还没到账，学员看到状态混乱。

原因：订单状态流转没有用状态图定义清楚，开发各自为政，回调逻辑互相覆盖。

解决：用状态图定义订单全生命周期：待支付 → 已支付 → 已退款 / 已关闭。每个状态转换标注触发事件和守卫条件。支付回调只能把“待支付”改成“已支付”，退款回调只能把“已支付”改成“已退款”，其他转换一律拒绝。状态字段加版本号做乐观锁，防止并发覆盖。

5.3 课程容量并发扣减超卖

现象：课程容量 100，实际卖出 105 份，运营发现后紧急下架。

原因：需求文档只写了“校验课程容量”，没写并发场景下的扣减策略。开发用“先查再改”的写法，两个请求同时查到容量剩 1，都判断可以选，都扣减。

解决：文档里明确写“容量扣减必须用数据库原子操作”。实现上用UPDATE t_course SET enrolled_count = enrolled_count + 1 WHERE course_id = ? AND enrolled_count < capacity，根据影响行数判断是否成功。或者用 Redis 预扣减加消息队列异步落库。这个规则必须写进非功能需求章节。

5.4 Oracle 监听服务起不来，开发环境集体瘫痪

现象：早上到公司，开发环境连不上 Oracle，报 ORA-12541 TNS 无监听程序。

原因：服务器重启后监听服务没自启，或者 listener.ora 配置被改。热搜里 oracle 监听服务无法启动是高频问题。

解决：文档里加一节“环境部署说明”，写明监听服务自启配置。Linux 下用lsnrctl start启动，检查lsnrctl status。如果是端口被占，用netstat -tlnp | grep 1521排查。修改默认监听端口后要同步更新 tnsnames.ora 和客户端的连接配置。这类环境问题写进文档，能省掉新成员大量排查时间。

5.5 需求文档没写数据权限，学员能查到别人成绩

现象：测试时发现学员 A 通过改 URL 参数能查到学员 B 的考试成绩。

原因：功能需求只写了“查看成绩”，没写数据权限规则。开发只做了功能鉴权（是否登录），没做数据鉴权（只能看自己的）。

解决：文档里每个查询类用例都要加“数据权限”一栏。查看成绩的数据权限规则是“仅本人”，查看班级报表的是“仅本班讲师”，查看全平台报表的是“管理员”。实现上在 SQL 里强制拼 student_id 条件，或者在服务层做统一拦截。这条规则不写，等保测评和渗透测试都会挂。

6. 让说明书真正被用起来：一个可复用的评审清单和迭代习惯

文档写完不是终点，能被开发、测试、运维持续引用才是。我现在的习惯是给说明书配一份评审清单，每次迭代前过一遍，迭代后更新一次。清单分四块：业务完整性、模型一致性、数据可落地性、非功能可测性。

业务完整性检查角色是否覆盖全、每个角色的核心用例是否都有规约、备选流程是否写全。模型一致性检查用例图和类图是否对得上、时序图的消息是否都有对应方法、状态图是否覆盖所有状态转换。数据可落地性检查每个实体是否有建表脚本、索引是否覆盖高频查询、分区策略是否明确。非功能可测性检查每个指标是否有具体数值、是否有对应的测试方法。

这份清单我一般做成表格，评审时逐项打勾，有问题的当场记录负责人和截止时间。迭代结束后，把本次新增的用例、实体、状态转换补进文档，保持文档和代码同步。文档一旦和代码脱节，下次就没人看了。

还有一个具体技巧：把 E-R 图和建表脚本放在同一章节，图下面紧跟 DDL，评审时对照着看，发现字段对不上当场改。Oracle 的字段类型和 Java 类型映射也列一张表，NUMBER(20) 对应 Long，NUMBER(10,2) 对应 BigDecimal，VARCHAR2 对应 String，DATE 对应 java.util.Date 或 LocalDateTime。这张表能避免很多类型转换的 bug。

我自己的教训是：早期做项目时觉得需求文档是走形式，结果开发到一半发现订单状态没定义清楚，返工两周。后来老老实实把状态图、时序图、E-R 图画全，评审时拉着开发和测试一起过，反而一次通过。文档的价值不在于写得多漂亮，而在于每个看图的人都能找到自己需要的答案。希望帮到你。

本文还有配套的精品资源，点击获取