尧图网页设计 
简介这份在线教育网系统需求分析说明书面向学校信息化建设者、软件工程专业学生及项目开发人员用于指导构建一个服务校内学生的在线教育平台。文档围绕学员管理、网上教学与校园信息管理三大模块展开涵盖会员权限分配、栏目维护、教学资料上传下载、试卷制定与成绩汇总等业务并给出界面权限、网上教学、在线考试等功能的用例图与参与者描述。压缩包内仅含1个doc文件约2.21MB完整呈现项目背景、用户环境、功能清单与需求分析细节其中B/S架构、.Net Framework 2.0、Oracle 9i及Rational Rose、PowerDesigner等工具要求均有明确说明。目前已有1583人学习适合需要撰写需求规格说明书、梳理UML建模思路或参考教育类系统功能设计的读者可据此快速理解系统边界与角色行为为后续开发与文档编写提供直接依据。1. 在线教育网系统需求分析说明书从一份文档到一套可落地的建模路径很多人拿到「在线教育网系统需求分析说明书」这个题目第一反应是去网上抄一份模板把功能列表填满就交差。但真正做过 B/S 架构在线教育项目的人都知道需求分析说明书不是写给评审看的作文而是后面数据库建表、接口定义、UML 建模、甚至 Oracle 表空间规划的唯一依据。写歪了后面全是返工。这份说明书要解决的核心问题是把「老师能开课、学生能选课、视频能播放、订单能支付、数据能统计」这些模糊诉求翻译成 B/S 架构下可验证的功能需求、可建模的用例、可落地的 E-R 结构和可查询的数据字典。它适合正在做课程设计的学生、刚接手教育类项目的后端工程师以及需要给团队定需求基线的人。下面按「先立住理论、再动手建模、最后避坑」的顺序拆开讲。2. 需求分析说明书该写什么B/S 在线教育系统的功能边界与角色划分2.1 先划边界在线教育网到底有几个端、几类角色B/S 架构的在线教育系统最容易翻车的地方不是技术而是边界没划清。我一般先把系统拆成三个端学生端、教师端、管理端。学生端负责浏览课程、下单支付、观看视频、提交作业、查看成绩教师端负责建课、上传课件、布置作业、批改、看学情管理端负责用户审核、课程上架、订单对账、数据统计。角色划分直接决定后面 UML 用例图的 Actor 数量。常见做法是学生、教师、管理员作为三个主 Actor支付网关、短信服务、视频转码服务作为外部系统 Actor。这里有个血泪经验——不要把「游客」单独列成 Actor游客能做的事浏览课程列表、查看课程详情本质上是学生用例的子集单独列会让用例图膨胀一倍评审时被追问到崩溃。功能边界还要明确「不做什么」。比如直播功能如果需求里没写低延迟互动就不要在说明书里承诺「支持万人同时在线直播」否则后面选型、压测、Oracle 连接池规划全要跟着改。需求说明书的价值一半在于写清楚做什么另一半在于写清楚不做什么。2.2 功能需求怎么写才可验证用例描述模板与优先级功能需求最忌讳写成「系统应具有良好的用户体验」这种无法验证的句子。可验证的需求必须包含触发条件、输入、处理逻辑、输出、异常分支。我通常用一张用例描述表来承载字段固定为用例编号、用例名称、Actor、前置条件、基本流程、备选流程、后置条件、优先级。以「学生选课下单」为例基本流程是学生登录 → 进入课程详情 → 点击立即购买 → 系统校验是否已购买 → 生成订单 → 跳转支付 → 支付回调 → 更新订单状态 → 写入选课记录。备选流程至少写三条余额不足、课程已下架、重复下单。优先级用 MoSCoW 法标注Must have 的是登录、选课、支付、视频播放Should have 的是作业提交、成绩查询Could have 的是课程收藏、学习时长统计。这样写出来的需求后面画 UML 用例图时一个用例对应一张表画时序图时基本流程就是消息序列建 E-R 图时订单、选课记录、课程就是实体。需求、模型、数据库三者能对上才叫落地。2.3 非功能需求B/S 架构下最容易被忽略的五个指标非功能需求在在线教育系统里不是配角。B/S 架构意味着所有压力都集中在服务端和数据库以下五个指标必须在说明书里量化指标建议目标值说明并发用户数500 在线 / 100 并发请求决定连接池和线程池大小页面响应时间普通页面 ≤ 2s视频首帧 ≤ 3s影响用户体验和 CDN 选型数据库可用性≥ 99.9%决定是否上 RAC 或 Data Guard数据一致性订单与支付最终一致决定是否引入消息队列安全要求密码加盐存储、传输加密、越权校验等保合规的基础项这些指标不是拍脑袋写的要跟后面的部署方案挂钩。比如并发 100 请求Oracle 连接池一般配 20 到 50 个连接就够配多了反而因为上下文切换拖慢响应。非功能需求写清楚运维和 DBA 才有依据做容量规划。3. 用 UML 把需求翻译成模型用例图、类图、时序图的画法与参数3.1 用例图Actor 与用例的对应关系怎么定用例图是需求分析说明书里最直观的 UML 图。画之前先把 2.1 节的角色清单拿出来每个 Actor 对应一组用例。学生 Actor 关联的用例包括注册登录、浏览课程、选课下单、支付、观看视频、提交作业、查看成绩教师 Actor 关联建课、上传课件、布置作业、批改作业、查看学情管理员 Actor 关联用户管理、课程审核、订单管理、数据统计。画用例图时注意三点第一用例名用「动词 名词」比如「提交作业」而不是「作业」第二include 用于抽取公共步骤比如「支付」include「校验订单状态」第三extend 用于可选分支比如「使用优惠券」extend「支付」。很多教程把 include 和 extend 讲反记住一句话include 是必须发生的子步骤extend 是可能发生的扩展。下面用 PlantUML 描述学生选课相关的用例关系方便直接落到文档里startuml left to right direction actor 学生 as S actor 支付网关 as P rectangle 在线教育系统 { usecase 浏览课程 as UC1 usecase 选课下单 as UC2 usecase 支付 as UC3 usecase 观看视频 as UC4 usecase 校验订单状态 as UC5 usecase 使用优惠券 as UC6 } S -- UC1 S -- UC2 S -- UC4 UC2 -- UC3 : include UC3 -- UC5 : include UC6 . UC3 : extend P -- UC3 enduml这段描述里include 表示下单必然触发支付、支付必然校验订单状态extend 表示优惠券是可选动作。参数上Actor 与用例之间用实线关联用例之间 include 用带箭头的实线extend 用带箭头的虚线。评审时如果被问「为什么支付网关是 Actor」回答它是外部系统不归本系统实现但参与交互。3.2 类图从需求名词抽出实体类、边界类、控制类类图是把需求里的名词变成对象。在线教育系统的实体类通常有User用户基类、Student、Teacher、Admin、Course、Chapter、Video、Order、Payment、Homework、Score。边界类负责与 Actor 交互比如 CourseListPage、OrderSubmitPage控制类负责业务逻辑比如 OrderController、PaymentController。类之间的关系要标清楚Student、Teacher、Admin 继承 User用空心三角箭头指向 UserOrder 与 Student 是关联关系一个学生多个订单用 1 对 * 标注Course 与 Chapter 是组合关系课程删除章节随之删除用实心菱形Order 与 Payment 是聚合关系订单可以没有支付记录未支付状态用空心菱形。startuml class User { -userId: Long -username: String -passwordHash: String login(): Boolean } class Student class Teacher class Course { -courseId: Long -title: String -price: BigDecimal -status: Integer } class Order { -orderId: Long -studentId: Long -courseId: Long -amount: BigDecimal -status: Integer create(): void } User |-- Student User |-- Teacher Student 1 -- * Order Course 1 -- * Order enduml参数说明passwordHash 存加盐哈希不存明文price 用 BigDecimal 不用 double避免金额精度问题status 用整数枚举0 待支付、1 已支付、2 已取消。类图画到这一层后面建表基本就是字段映射不会漏字段。3.3 时序图与活动图把「选课下单」这条主链路画透时序图用来验证需求的执行顺序是否闭环。以「学生选课下单」为例参与者是学生、前端、订单服务、支付服务、数据库。消息顺序学生提交订单 → 前端调用订单服务 → 订单服务校验课程状态 → 写入订单 → 调用支付服务 → 返回支付参数 → 学生完成支付 → 支付回调订单服务 → 更新订单状态 → 写入选课记录。startuml actor 学生 participant 前端 as FE participant 订单服务 as OS participant 支付服务 as PS database Oracle as DB 学生 - FE : 点击购买 FE - OS : 提交订单请求 OS - DB : 查询课程状态 DB -- OS : 课程可售 OS - DB : 插入订单记录 OS - PS : 请求支付参数 PS -- OS : 返回支付参数 OS -- FE : 返回订单号与支付参数 学生 - PS : 完成支付 PS - OS : 支付回调 OS - DB : 更新订单状态 OS - DB : 插入选课记录 OS -- PS : 确认回调 enduml活动图则适合描述带分支的流程比如「作业提交」学生上传文件 → 系统校验格式 → 格式合法则保存并通知教师格式非法则返回错误。时序图看顺序活动图看分支两者配合能把需求里的主流程和异常流程都覆盖。4. E-R 模型与 Oracle 表结构从需求实体到可执行 DDL4.1 E-R 图实体、属性、联系的抽取规则E-R 图是需求分析和数据库设计之间的桥。抽取规则很简单需求里的名词变实体名词的属性变字段动词变联系。在线教育系统的核心实体有学生、教师、课程、章节、订单、支付记录、作业、成绩、选课记录。联系类型要标清楚学生与课程是多对多通过选课记录拆解课程与章节是一对多订单与学生是多对一订单与支付记录是一对一或一对多支持多次支付尝试。E-R 图里弱实体要标注比如章节依赖课程存在用双线矩形表示。画 E-R 图时主键用下划线标注外键用虚线标注。很多同学把 E-R 图和类图混为一谈区别在于类图有方法E-R 图只有属性和联系类图面向对象E-R 图面向关系。需求说明书里两张图都要有前者给开发看后者给 DBA 看。4.2 从 E-R 到 Oracle 表字段类型、约束与索引E-R 图转 Oracle 表关键是字段类型选对。以下是在线教育系统核心表的 DDL 片段-- 课程表 CREATE TABLE course ( course_id NUMBER(19) PRIMARY KEY, title VARCHAR2(200) NOT NULL, teacher_id NUMBER(19) NOT NULL, price NUMBER(10,2) DEFAULT 0 NOT NULL, status NUMBER(2) DEFAULT 0 NOT NULL, create_time DATE DEFAULT SYSDATE NOT NULL, CONSTRAINT fk_course_teacher FOREIGN KEY (teacher_id) REFERENCES teacher(teacher_id) ); CREATE INDEX idx_course_status ON course(status); -- 订单表 CREATE TABLE orders ( order_id NUMBER(19) PRIMARY KEY, student_id NUMBER(19) NOT NULL, course_id NUMBER(19) NOT NULL, amount NUMBER(10,2) NOT NULL, status NUMBER(2) DEFAULT 0 NOT NULL, create_time DATE DEFAULT SYSDATE NOT NULL, pay_time DATE, CONSTRAINT fk_order_student FOREIGN KEY (student_id) REFERENCES student(student_id), CONSTRAINT fk_order_course FOREIGN KEY (course_id) REFERENCES course(course_id) ); CREATE INDEX idx_orders_student ON orders(student_id, status);参数说明主键用 NUMBER(19) 对应 Java 的 Long金额用 NUMBER(10,2)不用 FLOAT避免精度丢失时间用 DATEOracle 的 DATE 包含时分秒status 建索引是因为订单查询几乎都带状态过滤。注意表名用 orders 不用 orderorder 是 Oracle 保留字直接建表会报 ORA-00903。4.3 数据字典与需求追溯让每个字段都能找到出处数据字典是需求说明书的附件记录每张表、每个字段的来源。格式建议表名、字段名、类型、是否为空、默认值、说明、对应需求编号。比如 orders.status 对应需求「订单状态管理」取值范围 0 待支付、1 已支付、2 已取消、3 已退款。需求追溯矩阵则把需求编号和 UML 用例、表字段对应起来。这样评审时有人问「这个字段为什么存在」你能直接翻到需求条目开发时有人问「这个需求怎么实现」你能直接指到表和接口。没有追溯矩阵的需求说明书就是一堆散装文档改一处漏三处。5. 需求分析避坑五个让项目返工的常见问题5.1 坑一需求里写「支持高并发」但没给数字现象说明书里写「系统应支持高并发访问」开发按默认配置部署上线后 200 人同时看视频就卡死。原因高并发是形容词不是指标没有并发数、响应时间、数据量无法做容量规划。解决改成「支持 500 在线用户、100 并发请求普通接口 P95 响应时间 ≤ 2s」并据此配置 Oracle 连接池、Tomcat 线程池和 CDN。5.2 坑二UML 用例图和功能需求对不上现象用例图里画了 30 个用例功能需求只写了 20 条评审时被追问「剩下 10 个用例的需求在哪」。原因画图时凭感觉加用例没有和需求条目一一对应。解决先写功能需求表每条需求对应一个用例用例编号和需求编号绑定画图时只画表里有的多一个都不加。5.3 坑三E-R 图没标联系类型建表时多对多直接翻车现象E-R 图里学生和课程画了条线没标 1 对 1 还是多对多开发建表时在课程表里加了 student_id结果一个课程只能被一个学生选。原因联系类型缺失。解决所有联系必须标 1:1、1:N、M:NM:N 必须拆成中间表比如选课记录表student_id, course_id, select_time。5.4 坑四Oracle 字段类型照搬 MySQL 习惯现象用 VARCHAR 存金额、用 DATETIME 存时间建表报错或数据失真。原因Oracle 没有 DATETIME 类型VARCHAR 存金额无法做算术校验。解决金额用 NUMBER(10,2)时间用 DATE 或 TIMESTAMP字符串用 VARCHAR2 不用 VARCHAR主键用 NUMBER(19) 对应 Long。5.5 坑五非功能需求和安全需求写在最后当摆设现象需求说明书前 20 页写功能最后半页写「系统应安全可靠」开发直接忽略上线后被扫出越权漏洞。原因安全需求没有具体条目和验收标准。解决把安全需求拆成可验证项比如「所有涉及用户数据的接口必须校验当前登录用户 ID 与资源归属」「密码必须加盐哈希存储」「订单金额必须服务端重新计算」每条对应一个测试用例。6. 让需求说明书真正被用起来评审、追溯与迭代的三个技巧需求说明书写完只是开始能不能被用起来才是关键。第一个技巧是评审时带三样东西需求条目表、UML 模型、E-R 图逐条过每条需求问三个问题——能不能测、对应哪个用例、落到哪张表。答不上来的当场改别留到开发阶段。第二个技巧是建追溯矩阵用一张 Excel 维护需求编号、用例编号、表名、接口名、测试用例编号的映射。需求变更时顺着矩阵往下改改一处能查到影响范围。我见过太多项目需求改了但 UML 图和表结构没同步最后文档和代码完全对不上新人接手只能靠读代码猜需求。第三个技巧是给需求分版本。V1.0 只做 Must haveV1.1 加 Should haveCould have 排到 V2.0。每个版本的需求说明书独立归档别在一个文件里改来改去。Oracle 的 DDL 也按版本管理用 Flyway 或手工脚本记录每次变更回滚时有后悔药。最后一个习惯需求说明书里的每个数字都要有出处。并发数来自运营预估响应时间来自竞品体验数据量来自历史增长。拍脑袋写的数字评审时第一个被挑战。希望帮到你。本文还有配套的精品资源点击获取 在线教育系统需求分析说明书：UML建模与Oracle表结构落地指南
简介这份在线教育网系统需求分析说明书面向学校信息化建设者、软件工程专业学生及项目开发人员用于指导构建一个服务校内学生的在线教育平台。文档围绕学员管理、网上教学与校园信息管理三大模块展开涵盖会员权限分配、栏目维护、教学资料上传下载、试卷制定与成绩汇总等业务并给出界面权限、网上教学、在线考试等功能的用例图与参与者描述。压缩包内仅含1个doc文件约2.21MB完整呈现项目背景、用户环境、功能清单与需求分析细节其中B/S架构、.Net Framework 2.0、Oracle 9i及Rational Rose、PowerDesigner等工具要求均有明确说明。目前已有1583人学习适合需要撰写需求规格说明书、梳理UML建模思路或参考教育类系统功能设计的读者可据此快速理解系统边界与角色行为为后续开发与文档编写提供直接依据。1. 在线教育网系统需求分析说明书从一份文档到一套可落地的建模路径很多人拿到「在线教育网系统需求分析说明书」这个题目第一反应是去网上抄一份模板把功能列表填满就交差。但真正做过 B/S 架构在线教育项目的人都知道需求分析说明书不是写给评审看的作文而是后面数据库建表、接口定义、UML 建模、甚至 Oracle 表空间规划的唯一依据。写歪了后面全是返工。这份说明书要解决的核心问题是把「老师能开课、学生能选课、视频能播放、订单能支付、数据能统计」这些模糊诉求翻译成 B/S 架构下可验证的功能需求、可建模的用例、可落地的 E-R 结构和可查询的数据字典。它适合正在做课程设计的学生、刚接手教育类项目的后端工程师以及需要给团队定需求基线的人。下面按「先立住理论、再动手建模、最后避坑」的顺序拆开讲。2. 需求分析说明书该写什么B/S 在线教育系统的功能边界与角色划分2.1 先划边界在线教育网到底有几个端、几类角色B/S 架构的在线教育系统最容易翻车的地方不是技术而是边界没划清。我一般先把系统拆成三个端学生端、教师端、管理端。学生端负责浏览课程、下单支付、观看视频、提交作业、查看成绩教师端负责建课、上传课件、布置作业、批改、看学情管理端负责用户审核、课程上架、订单对账、数据统计。角色划分直接决定后面 UML 用例图的 Actor 数量。常见做法是学生、教师、管理员作为三个主 Actor支付网关、短信服务、视频转码服务作为外部系统 Actor。这里有个血泪经验——不要把「游客」单独列成 Actor游客能做的事浏览课程列表、查看课程详情本质上是学生用例的子集单独列会让用例图膨胀一倍评审时被追问到崩溃。功能边界还要明确「不做什么」。比如直播功能如果需求里没写低延迟互动就不要在说明书里承诺「支持万人同时在线直播」否则后面选型、压测、Oracle 连接池规划全要跟着改。需求说明书的价值一半在于写清楚做什么另一半在于写清楚不做什么。2.2 功能需求怎么写才可验证用例描述模板与优先级功能需求最忌讳写成「系统应具有良好的用户体验」这种无法验证的句子。可验证的需求必须包含触发条件、输入、处理逻辑、输出、异常分支。我通常用一张用例描述表来承载字段固定为用例编号、用例名称、Actor、前置条件、基本流程、备选流程、后置条件、优先级。以「学生选课下单」为例基本流程是学生登录 → 进入课程详情 → 点击立即购买 → 系统校验是否已购买 → 生成订单 → 跳转支付 → 支付回调 → 更新订单状态 → 写入选课记录。备选流程至少写三条余额不足、课程已下架、重复下单。优先级用 MoSCoW 法标注Must have 的是登录、选课、支付、视频播放Should have 的是作业提交、成绩查询Could have 的是课程收藏、学习时长统计。这样写出来的需求后面画 UML 用例图时一个用例对应一张表画时序图时基本流程就是消息序列建 E-R 图时订单、选课记录、课程就是实体。需求、模型、数据库三者能对上才叫落地。2.3 非功能需求B/S 架构下最容易被忽略的五个指标非功能需求在在线教育系统里不是配角。B/S 架构意味着所有压力都集中在服务端和数据库以下五个指标必须在说明书里量化指标建议目标值说明并发用户数500 在线 / 100 并发请求决定连接池和线程池大小页面响应时间普通页面 ≤ 2s视频首帧 ≤ 3s影响用户体验和 CDN 选型数据库可用性≥ 99.9%决定是否上 RAC 或 Data Guard数据一致性订单与支付最终一致决定是否引入消息队列安全要求密码加盐存储、传输加密、越权校验等保合规的基础项这些指标不是拍脑袋写的要跟后面的部署方案挂钩。比如并发 100 请求Oracle 连接池一般配 20 到 50 个连接就够配多了反而因为上下文切换拖慢响应。非功能需求写清楚运维和 DBA 才有依据做容量规划。3. 用 UML 把需求翻译成模型用例图、类图、时序图的画法与参数3.1 用例图Actor 与用例的对应关系怎么定用例图是需求分析说明书里最直观的 UML 图。画之前先把 2.1 节的角色清单拿出来每个 Actor 对应一组用例。学生 Actor 关联的用例包括注册登录、浏览课程、选课下单、支付、观看视频、提交作业、查看成绩教师 Actor 关联建课、上传课件、布置作业、批改作业、查看学情管理员 Actor 关联用户管理、课程审核、订单管理、数据统计。画用例图时注意三点第一用例名用「动词 名词」比如「提交作业」而不是「作业」第二include 用于抽取公共步骤比如「支付」include「校验订单状态」第三extend 用于可选分支比如「使用优惠券」extend「支付」。很多教程把 include 和 extend 讲反记住一句话include 是必须发生的子步骤extend 是可能发生的扩展。下面用 PlantUML 描述学生选课相关的用例关系方便直接落到文档里startuml left to right direction actor 学生 as S actor 支付网关 as P rectangle 在线教育系统 { usecase 浏览课程 as UC1 usecase 选课下单 as UC2 usecase 支付 as UC3 usecase 观看视频 as UC4 usecase 校验订单状态 as UC5 usecase 使用优惠券 as UC6 } S -- UC1 S -- UC2 S -- UC4 UC2 -- UC3 : include UC3 -- UC5 : include UC6 . UC3 : extend P -- UC3 enduml这段描述里include 表示下单必然触发支付、支付必然校验订单状态extend 表示优惠券是可选动作。参数上Actor 与用例之间用实线关联用例之间 include 用带箭头的实线extend 用带箭头的虚线。评审时如果被问「为什么支付网关是 Actor」回答它是外部系统不归本系统实现但参与交互。3.2 类图从需求名词抽出实体类、边界类、控制类类图是把需求里的名词变成对象。在线教育系统的实体类通常有User用户基类、Student、Teacher、Admin、Course、Chapter、Video、Order、Payment、Homework、Score。边界类负责与 Actor 交互比如 CourseListPage、OrderSubmitPage控制类负责业务逻辑比如 OrderController、PaymentController。类之间的关系要标清楚Student、Teacher、Admin 继承 User用空心三角箭头指向 UserOrder 与 Student 是关联关系一个学生多个订单用 1 对 * 标注Course 与 Chapter 是组合关系课程删除章节随之删除用实心菱形Order 与 Payment 是聚合关系订单可以没有支付记录未支付状态用空心菱形。startuml class User { -userId: Long -username: String -passwordHash: String login(): Boolean } class Student class Teacher class Course { -courseId: Long -title: String -price: BigDecimal -status: Integer } class Order { -orderId: Long -studentId: Long -courseId: Long -amount: BigDecimal -status: Integer create(): void } User |-- Student User |-- Teacher Student 1 -- * Order Course 1 -- * Order enduml参数说明passwordHash 存加盐哈希不存明文price 用 BigDecimal 不用 double避免金额精度问题status 用整数枚举0 待支付、1 已支付、2 已取消。类图画到这一层后面建表基本就是字段映射不会漏字段。3.3 时序图与活动图把「选课下单」这条主链路画透时序图用来验证需求的执行顺序是否闭环。以「学生选课下单」为例参与者是学生、前端、订单服务、支付服务、数据库。消息顺序学生提交订单 → 前端调用订单服务 → 订单服务校验课程状态 → 写入订单 → 调用支付服务 → 返回支付参数 → 学生完成支付 → 支付回调订单服务 → 更新订单状态 → 写入选课记录。startuml actor 学生 participant 前端 as FE participant 订单服务 as OS participant 支付服务 as PS database Oracle as DB 学生 - FE : 点击购买 FE - OS : 提交订单请求 OS - DB : 查询课程状态 DB -- OS : 课程可售 OS - DB : 插入订单记录 OS - PS : 请求支付参数 PS -- OS : 返回支付参数 OS -- FE : 返回订单号与支付参数 学生 - PS : 完成支付 PS - OS : 支付回调 OS - DB : 更新订单状态 OS - DB : 插入选课记录 OS -- PS : 确认回调 enduml活动图则适合描述带分支的流程比如「作业提交」学生上传文件 → 系统校验格式 → 格式合法则保存并通知教师格式非法则返回错误。时序图看顺序活动图看分支两者配合能把需求里的主流程和异常流程都覆盖。4. E-R 模型与 Oracle 表结构从需求实体到可执行 DDL4.1 E-R 图实体、属性、联系的抽取规则E-R 图是需求分析和数据库设计之间的桥。抽取规则很简单需求里的名词变实体名词的属性变字段动词变联系。在线教育系统的核心实体有学生、教师、课程、章节、订单、支付记录、作业、成绩、选课记录。联系类型要标清楚学生与课程是多对多通过选课记录拆解课程与章节是一对多订单与学生是多对一订单与支付记录是一对一或一对多支持多次支付尝试。E-R 图里弱实体要标注比如章节依赖课程存在用双线矩形表示。画 E-R 图时主键用下划线标注外键用虚线标注。很多同学把 E-R 图和类图混为一谈区别在于类图有方法E-R 图只有属性和联系类图面向对象E-R 图面向关系。需求说明书里两张图都要有前者给开发看后者给 DBA 看。4.2 从 E-R 到 Oracle 表字段类型、约束与索引E-R 图转 Oracle 表关键是字段类型选对。以下是在线教育系统核心表的 DDL 片段-- 课程表 CREATE TABLE course ( course_id NUMBER(19) PRIMARY KEY, title VARCHAR2(200) NOT NULL, teacher_id NUMBER(19) NOT NULL, price NUMBER(10,2) DEFAULT 0 NOT NULL, status NUMBER(2) DEFAULT 0 NOT NULL, create_time DATE DEFAULT SYSDATE NOT NULL, CONSTRAINT fk_course_teacher FOREIGN KEY (teacher_id) REFERENCES teacher(teacher_id) ); CREATE INDEX idx_course_status ON course(status); -- 订单表 CREATE TABLE orders ( order_id NUMBER(19) PRIMARY KEY, student_id NUMBER(19) NOT NULL, course_id NUMBER(19) NOT NULL, amount NUMBER(10,2) NOT NULL, status NUMBER(2) DEFAULT 0 NOT NULL, create_time DATE DEFAULT SYSDATE NOT NULL, pay_time DATE, CONSTRAINT fk_order_student FOREIGN KEY (student_id) REFERENCES student(student_id), CONSTRAINT fk_order_course FOREIGN KEY (course_id) REFERENCES course(course_id) ); CREATE INDEX idx_orders_student ON orders(student_id, status);参数说明主键用 NUMBER(19) 对应 Java 的 Long金额用 NUMBER(10,2)不用 FLOAT避免精度丢失时间用 DATEOracle 的 DATE 包含时分秒status 建索引是因为订单查询几乎都带状态过滤。注意表名用 orders 不用 orderorder 是 Oracle 保留字直接建表会报 ORA-00903。4.3 数据字典与需求追溯让每个字段都能找到出处数据字典是需求说明书的附件记录每张表、每个字段的来源。格式建议表名、字段名、类型、是否为空、默认值、说明、对应需求编号。比如 orders.status 对应需求「订单状态管理」取值范围 0 待支付、1 已支付、2 已取消、3 已退款。需求追溯矩阵则把需求编号和 UML 用例、表字段对应起来。这样评审时有人问「这个字段为什么存在」你能直接翻到需求条目开发时有人问「这个需求怎么实现」你能直接指到表和接口。没有追溯矩阵的需求说明书就是一堆散装文档改一处漏三处。5. 需求分析避坑五个让项目返工的常见问题5.1 坑一需求里写「支持高并发」但没给数字现象说明书里写「系统应支持高并发访问」开发按默认配置部署上线后 200 人同时看视频就卡死。原因高并发是形容词不是指标没有并发数、响应时间、数据量无法做容量规划。解决改成「支持 500 在线用户、100 并发请求普通接口 P95 响应时间 ≤ 2s」并据此配置 Oracle 连接池、Tomcat 线程池和 CDN。5.2 坑二UML 用例图和功能需求对不上现象用例图里画了 30 个用例功能需求只写了 20 条评审时被追问「剩下 10 个用例的需求在哪」。原因画图时凭感觉加用例没有和需求条目一一对应。解决先写功能需求表每条需求对应一个用例用例编号和需求编号绑定画图时只画表里有的多一个都不加。5.3 坑三E-R 图没标联系类型建表时多对多直接翻车现象E-R 图里学生和课程画了条线没标 1 对 1 还是多对多开发建表时在课程表里加了 student_id结果一个课程只能被一个学生选。原因联系类型缺失。解决所有联系必须标 1:1、1:N、M:NM:N 必须拆成中间表比如选课记录表student_id, course_id, select_time。5.4 坑四Oracle 字段类型照搬 MySQL 习惯现象用 VARCHAR 存金额、用 DATETIME 存时间建表报错或数据失真。原因Oracle 没有 DATETIME 类型VARCHAR 存金额无法做算术校验。解决金额用 NUMBER(10,2)时间用 DATE 或 TIMESTAMP字符串用 VARCHAR2 不用 VARCHAR主键用 NUMBER(19) 对应 Long。5.5 坑五非功能需求和安全需求写在最后当摆设现象需求说明书前 20 页写功能最后半页写「系统应安全可靠」开发直接忽略上线后被扫出越权漏洞。原因安全需求没有具体条目和验收标准。解决把安全需求拆成可验证项比如「所有涉及用户数据的接口必须校验当前登录用户 ID 与资源归属」「密码必须加盐哈希存储」「订单金额必须服务端重新计算」每条对应一个测试用例。6. 让需求说明书真正被用起来评审、追溯与迭代的三个技巧需求说明书写完只是开始能不能被用起来才是关键。第一个技巧是评审时带三样东西需求条目表、UML 模型、E-R 图逐条过每条需求问三个问题——能不能测、对应哪个用例、落到哪张表。答不上来的当场改别留到开发阶段。第二个技巧是建追溯矩阵用一张 Excel 维护需求编号、用例编号、表名、接口名、测试用例编号的映射。需求变更时顺着矩阵往下改改一处能查到影响范围。我见过太多项目需求改了但 UML 图和表结构没同步最后文档和代码完全对不上新人接手只能靠读代码猜需求。第三个技巧是给需求分版本。V1.0 只做 Must haveV1.1 加 Should haveCould have 排到 V2.0。每个版本的需求说明书独立归档别在一个文件里改来改去。Oracle 的 DDL 也按版本管理用 Flyway 或手工脚本记录每次变更回滚时有后悔药。最后一个习惯需求说明书里的每个数字都要有出处。并发数来自运营预估响应时间来自竞品体验数据量来自历史增长。拍脑袋写的数字评审时第一个被挑战。希望帮到你。本文还有配套的精品资源点击获取