企业官网建设流程全解析

简介：在线教育网系统需求分析说明书是一份面向软件开发人员、项目经理及教育信息化规划者的完整需求文档，旨在为创建B/S架构的在线教育平台提供明确依据。文档覆盖学员管理、网上教学管理、校园信息管理、在线考试系统等核心模块，并详细给出界面权限管理、班级与科目管理、教学资料管理、自动/人工改卷、成绩查询等功能的用例图与参与者行为描述。同时，文档明确了Windows 2000 Server、.NET Framework 2.0、Visual Studio.NET 2005、Oracle 9i及IE6.0以上的技术环境，以及使用Rational Rose绘制UML、PowerDesigner 11.0绘制E-R图的设计要求。压缩包共包含1个doc文档，大小2.21MB，内容结构完整，从项目背景、功能清单到用例说明均有细致阐述，可作为同类在线教育系统需求调研、设计开发的参考模板。目前已有1583人学习下载，适合需要快速梳理在线教育业务需求或撰写需求规格说明书的从业者。

1. 在线教育网的需求分析说明书，写不好就是给研发埋雷

一份“在线教育网系统需求分析说明书”，最容易出现两种结局：一种是写成几百页的文档，研发拿到后照样每天来问“这个字段到底要不要”；另一种是写完就归档，需求评审会开完三个月后，才发现需求分析漏掉了“刷课判定”这个核心规则。我在一线做教育类软件的需求分析时，经常遇到这两种情况。需求分析说明书不是写给管理者看的，是写给研发、测试、运维看的施工图。它解决的核心问题是：把“我们要做个在线教育网”这句话，拆成一套没有歧义、可以估算工作量、可以验收的行为描述。这篇文章按我实际做项目的习惯，把写这份说明书的流程、表格、参数和坑一次讲清楚。适合产品经理、项目经理和刚转行做需求分析的同学对照着用。

2. 先分清干系人和需求来源：访谈、问卷与竞品分析怎么安排

写需求分析说明书之前，最忌讳的是直接打开 Word 从“项目背景”开始编。背景谁都会写，真正决定说明书质量的是两件事：你知道这份系统要服务哪些人，你知道这些人的需求从哪里来、优先级怎么排。在线教育网系统常见的干系人并不复杂，但经常被列漏。

2.1 干系人清单：少了“教务排课岗”和“财务对账岗”，后面一定返工

我做在线教育类项目时，第一张表永远是干系人登记表，这张表决定了后续所有需求的边界。除了明面上的学生、教师、家长，还有几个角色特别容易漏：教务管理（负责排课、审核开课申请、处理退课）、财务人员（负责订单对账、发票、退款）、内容运营（负责上架课程、配置 Banner、管理课程分类）。把干系人列全，不是为了让文档显得完整，而是因为每个角色都对应一批独有的用例。教务的排课规则会直接影响课程模型的字段设计，财务的对账需求会直接影响订单号和支付回调的设计。

干系人清单的推荐字段是：角色名称、使用场景、核心诉求、参与方式、需求优先级。参与方式是指这个角色是直接操作系统，还是通过管理员代操作，这一点容易被忽略。很多在线教育网系统早期设计时，家长角色被设计成直接登录，但实际业务里家长是“看报告、代缴费”，如果说明书里把家长写成了全功能操作角色，UI 和权限设计都会跑偏。

2.2 需求获取：访谈提纲要带“假如”，问卷只能用来验证定量结论

需求获取的常规做法是“访谈 + 问卷 + 竞品分析 + 原型验证”四件套。访谈不要问“你希望系统有什么功能”，这是开放式问题，得到的答案十有八九是“越方便越好”。我一般会用场景化提问：“假如你发现学生提交的作业有抄袭嫌疑，你希望系统做什么？”这类问题能逼出真实规则：是提交时查重，还是批改时提示，还是允许教师手动标记。每一个“假如”背后，都是一条潜在的业务规则，也就是说明书里“业务规则”章节的素材。

问卷适合用来验证定量结论，比如“教师最常在几点登入系统布置作业”“家长对成绩推送的接受频次”，但问卷不适合用来挖掘未知需求。竞品分析要落到具体字段和行为上，比如对比主流课程平台，它们的课程详情页是否包含“有效期说明”、下单前是否强制勾选服务协议，这些细节最终会变成你的功能需求条目。原型验证放在需求分析的最后阶段，用线框图确认界面层级，但注意原型验证的产出不是说明书的内容，而是对说明书里“界面需求”的佐证。

2.3 从原始记录到需求条目：先写“用户故事”再转“功能需求”

与干系人访谈之后，手上会有一堆对话记录和笔记，不能直接把对话记录贴进说明书。常见做法是先整理成用户故事，格式是“作为某个角色，我希望系统做什么，以便达成某个目的”。用户故事的优点是把“谁、做什么、为了什么”绑定在一起，逻辑上不会散。整理完用户故事之后，再把它转成功能需求条目，因为说明书最终要面对研发，研发不关心故事，只关心“输入什么、系统做什么、输出什么”。

这一步骤需要一张“用户故事到功能需求”的映射表做中间过渡。表格至少包含：用户故事编号、角色、故事内容、对应的功能需求编号、备注。有了这张表，后续评审时如果有人问“这个功能是谁提的”，你可以一分钟内追溯回去。这张表应该写到说明书的附录里，不要放进正文。正文只放收敛后的功能需求。

当映射表里某个用户故事找不到功能需求承接时，有两种可能：要么是伪需求，要么是说明书的覆盖范围没写全，要回到访谈记录里复核。

3. 用例建模与核心业务链路：把“在线学习”拆成一张可核对的需求地图

需求分析说明书里，最容易让研发看得走神的部分就是大段的功能描述文字。一个更高效的做法是让用例图和用例规约替代部分长文本。用例图不是画了好看的，而是作为功能地图，让研发能快速找到“我的模块涉及哪些用例”；用例规约是给测试提供场景来源。在线教育网系统的核心，不外乎“选课—学习—作业—考试—成绩”这条闭环，但闭环里的分支路径远比想象中多。

3.1 用例清单：核心用例与非核心用例的边界怎么划

用例清单的推荐粒度是“一个用例对应一个可独立验收的业务目标”。以在线教育网系统为例：

优先级不要平均分配。高优先级用例如果被砍掉，系统无法上线；中优先级影响核心体验，但没有也可以在二期补；低优先级是完全不做也不影响主流程的。把优先级写清楚的另一个价值是，当开发资源紧张时，产品经理可以直接按照优先级裁剪范围，不需要重新开会讨论。这也是需求分析说明书被称为“项目管理基线”的原因。

3.2 用例规约模板：主流程带分支，测试才能写出完整用例

用例图画完之后，说明书里更关心的是用例规约。用例规约我不会只写“用户点击选课，系统提示选课成功”，这个粒度太粗。推荐的最小字段是：用例名称、执行者、前置条件、后置条件、主流程、扩展流程、业务规则。针对“学生选课报名”这个用例，我一般会写成下面这样：

• 前置条件：学生已登录且完成实名认证，课程状态为“报名中”，当前时间在报名起止日期内
• 主流程：学生进入课程详情页 → 点击“我要报名” → 系统校验课程名额 → 生成待支付订单 → 学生完成支付 → 系统锁定学位并发送报名成功通知
• 扩展流程 1：名额不足时提示“已满员”，并提供“加入候补”入口
• 扩展流程 2：支付超时未完成时，系统自动释放学位并关闭订单
• 业务规则：同一学生同一时段内最多报名 3 门课程；退款后再次报名同一课程需重新排队

测试人员拿到这张规约，直接就能生成场景用例。研发看到业务规则，也知道要在接口层做哪几类校验。很多需求说明书被诟病“看不下去”，问题往往出现在这里：写了主流程，漏了扩展流程和业务规则，研发就只能靠猜，测试也只能凭经验凑场景。

3.3 课程和学习进度的状态机：这是在线教育网系统最容易被画错的图

状态图不建议画得很复杂，但“课程生命周期”和“学生学习进度”这两个状态机必须画。课程常见状态包括：编辑中、待审核、已上架、报名中、学习中、已完结、已下架。每一个状态迁移都要有触发条件，比如“已上架”到“报名中”，需要满足开课日期已到且名额未满；“学习中”到“已完结”的触发条件是课程结束日期到达或学生完成全部必学内容。如果说明书对状态定义不清晰，后端设计数据表时会把课程状态和学习进度混在一个字段里，后面统计报表时就全乱了。

学生学习进度的状态与课程状态是两个维度。学生进度状态常见有：未开始、学习中、待考试、已完成、已过期。状态机的价值在于解决一个典型冲突：课程下架了，但学生还没学完，这时候需要新增一个“已下架但进行中”的规则，而不是直接砍掉学生访问权限。这个规则如果不写进说明书，研发大概率会简单处理成“课程下架，学生不可访问”，后面客服来投诉时才发现需求漏了。

4. 从功能条目到非功能指标：让研发拿到说明书就能开工

当用例地图确认后，接下来要把需求细化到功能条目，并明确非功能指标。这一步是需求分析说明书从“业务文档”走向“技术依据”的转折点。很多说明书只写功能不写非功能需求，导致上线后一遇到高并发就出问题，然后又回来补服务器资源、改缓存策略，成本高得离谱。

4.1 功能需求条目的写法：否定句也算需求，别只写正向行为

功能需求条目建议按业务域分组编号。在线教育网系统可以分成：用户与权限域、课程与商品域、学习与进度域、作业与考试域、订单与支付域、消息通知域。每条功能的描述格式统一为：编号 + 功能名 + 功能描述 + 验收要点。功能描述里要写清楚输入、处理、输出。

• FR-3.2 查看课程剩余有效期：学生可在“我的课程”列表查看每门课程的有效期截止日期。输入为学生选中课程 ID，系统根据报名时间与课程有效时长计算剩余天数，输出为“剩余 X 天”的文本提示。验收要点：当剩余天数小于 7 天时，需在课程封面显示黄色预警图标。
• FR-4.5 批量布置作业：教师可从题库中多选题目生成作业并指定班级。输入为教师勾选的题目集合和班级列表，系统自动生成作业单并推送给学生端。验收要点：单个作业最多支持 50 题；推送延迟不超过 30 秒。

这里有一个我做需求分析时反复强调的习惯：功能描述里要有明确的数值和边界。没有数值的验收要点等于没写。还有一点，不要只写正向行为，要写“拒绝条件”。比如“当课程已下架或已过期时，禁止学生发起新订单”这种否定句，也必须写成需求条目。需求条目如果只描写正常路径，测试用例就只能覆盖正常路径，一旦出现异常场景，整个团队都会懵。

4.2 非功能需求的量化方式：不同模块的数字指标不能一样

非功能需求是需求分析说明书里最常被糊弄的章节，常规写法是“系统需具备良好的性能和高可用性”，这句话没有任何落地价值。我一般会把非功能需求拆成性能、可用性、安全、兼容性、可维护性六类，且尽量量化。在线教育网系统的指标建议参考下列初始值：

注意这些数值不一定适合所有团队，但要比“高性能”强得多。如果没有历史数据参考，在说明书里写明“此为投产前压测基线，上线后按月刷新”即可。另一点被忽视的是“数据需求”。数据需求不要写得太偏技术，而是从业务视角定义核心实体：用户、课程、班级、订单、作业、考试成绩。每个实体说明关键的属性要求就够了，比如订单必须保留支付流水号，考试成绩必须保留总分、得分明细和提交时间。

4.3 把需求说明书和原型区分开：别让研发以为你要的是高保真交互

需求分析说明书不等于设计稿。正文里可以提界面需求，但不能用大篇幅描述按钮颜色和弹窗样式。界面布局、交互细节应该落在原型或设计文档里，说明书只描述信息和操作项的必备集合。比如课程详情页，只需要写清楚这个页面必须包含课程名、讲师、有效期、学习人数、报名按钮，至于按钮放在左边还是右边、用什么颜色，不应该出现在需求分析说明书里。否则评审会变成美学会，需求边界会越来越乱。

再补充一个与功能需求相关的接口需求写法：对外对接的模块，如支付接口、短信服务、视频转码服务，说明书里要写出交互对象、触发时机和失败补偿。支付回调的失败处理尤其要写详细一点，因为支付失败时的订单状态不处理好，财务对账一定会出问题。常见的错误是先创建订单再发起支付，支付成功后回调通知更新订单状态，如果回调失败了呢？说明书必须写明“订单停留在待支付状态，由定时任务每分钟查询第三方支付结果并补偿更新”。这个规则不写，研发大概率会忽略掉幂等设计。

5. 需求说明书三大常见翻车现场：范围蔓延、口径冲突与伪需求

这个章节是写这份说明书最容易踩坑的地方。我见过太多在线教育网系统项目，需求分析做了两三个月，说明书看起来很厚，但研发一估工作量就发现没法排期，评审会上吵成一团。问题基本集中在范围、口径和需求真实性这三件事上。

5.1 范围蔓延：每加一个小功能，其实都在加整个链路

现象是需求评审会上，有人提“加个签到功能，很简单，就一个按钮”，大家觉得工作量不大就加进去了。过了两周，签到功能引发了一连串新需求：签到要不要奖励积分？积分能不能兑换课程券？课程券怎么核销？最后一个小按钮变成了一整套积分体系，关键是没有一个人在做需求分析时评估过它。

原因是在需求分析阶段没有建立变更基线。说明书的初稿完成后，凡是新增或修改需求，都必须走变更评审，给出影响分析，包括关联用例变更、工作量估算变化、测试范围变化。解决的办法是需求说明书里加一个“范围描述”章节，明确写出本版本包含的需求编号清单，以及明确不包含的需求。必要时附一张“待定事项”表，把没有定论的需求放进去，避免它们通过口头方式混进主文档。

5.2 词义口径冲突：开发、教师、教务口中的“已结课”不是一回事

现象往往在测试阶段集中爆发。测试用例里写着“课程已结课，学生端应展示结课证书”，开发完成并通过自测，但测试执行时发现课程状态根本不是开发想的那样。测试人员查了代码后才发现，开发把“结课”理解成了“课程在排课表中的结束日期到了”，而业务这边要的“结课”是“学生完成了全部必看视频、通过考试且成绩合格”。

原因大概率是需求说明书里没有建立“术语表”章节。同一词条无法统一，各角色按自己的经验理解。解决的方法很简单：在说明书最初几页放一个术语和词义对照表，把高频词都拉进去，至少应包括：报名、选课、排课、课时、结课、完成、退款、学分、有效期内、学习进度。每一条都要用一句业务描述限定其精确含义，比如“课程结课是指课程下所有必修章节的视频完成率达到100%且通过课后作业或考试”。哪怕术语表只有半页，也值得写。因为研发和测试的执行依据，就是这些词语的定义，而不是他们头脑里的印象。

5.3 伪需求：收集了所有干系人意见，做了个没人用的功能

现象是系统上线后，后台统计显示某功能使用率为 0，最典型的案例是“学员积分商城”，需求是运营负责人拍板加的，理由是竞品有。开发资源投入不少，上线半年没有任何订单，最终又排期把这个功能下线，白白消耗成本。

原因是“竞品有”不等于“用户需要”，需求有没有价值要回到两条线上验证：一是使用场景本身是不是高频，二是目标用户有没有真实的付费或使用意愿。不同的是，竞品有积分商城、而你的用户主要是报班追课的学生，积分兑换对他们并没有强吸引力，这就是典型的伪需求。解决的思路是需求分析阶段对新增功能做一次“动因评估”：这个需求是为谁解决的、解决到什么程度、用户不使用这个功能时会怎么样。如果回答不出来，就放到待定事项表里，不要直接进范围。后面想清楚了再排期。

提示：伪需求的判定不是以“有没有人提”为标准，而是以“如果不做，用户是否有替代方案、是否会明显不满”为标准。这条标准可以避免很多无效需求进入开发排期。

6. 用评审清单和需求跟踪矩阵，把说明书当“活文档”交付

写到这里，需求分析说明书本身的内容构造已经完整，但如果你把说明书当成一次性交付物，后续需求变更还是会在开发过程中击穿所有阶段。最后一章分享一招对我来说最实用的做法：用需求跟踪矩阵把说明书和开发、测试结果绑在一起，让说明书从“静态文档”变成“活版本”。

需求跟踪矩阵是一张持续维护的表，至少包含这四列：需求编号、对应功能模块、对应设计文档或接口、对应的测试用例编号。它的价值体现在两个环节：验收阶段，可以快速核对“这个需求有没有对应的测试用例覆盖”；变更阶段，可以快速定位“这个需求改了，涉及哪些设计和测试，需要同步更新”。在线教育网系统需求数量通常在 100 到 200 条之间，上了矩阵之后，评审会不再需要翻完整本说明书去核对影响范围。

评审阶段我也会准备一张需求评审检查清单，重点不是“功能全不全”，而是看需求可否测试、是否有歧义、是否有明确优先级。推荐按下表逐项打勾：

版本管理这个习惯要单独强调一下。说明书写完之后肯定要经历几轮需求变更，建议每次发布新版时，在文档开头更新一下版本号、变更日期、变更记录。每条变更记录只写三个信息：哪条需求改了、改的原因、关联影响。不出三个版本，就能看出说明书在实际项目里的生命力。另外相当关键的一点是，没有走评审的变更不要私下口头答应研发或测试，哪怕只是一个字段别名，也要回到矩阵里留痕迹，不然真上线时对不上。

我习惯在项目结项后，把这份需求分析说明书连同需求跟踪矩阵一起归档到项目知识库，它不仅是本期开发的验收证据，也是下期迭代和同类项目需求分析的底稿。在线教育网这类系统功能链路长、角色多，需求分析说明书不可能尽善尽美，但保住术语定义清晰、功能条目可测、非功能指标可验证这三条底线，项目基本不会出大的偏差。希望这个做法能帮到你。

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