企业官网建设流程全解析

简介：在线教育网系统需求分析说明书面向计划搭建校园在线教育平台的院校信息化负责人、项目管理者与开发测试人员，围绕学员管理、网上教学、校园信息发布和在线考试等核心业务，梳理从项目背景、用户环境到功能边界与技术要求的需求基线，帮助团队在开发前统一认识、控制范围。压缩包内仅含1个doc文档，整体约2.21MB，正文以需求条目、功能清单、用例描述和结构示意为主，便于直接查阅与二次整理。目前已有1588人学习。文档具体展开界面权限、角色与栏目管理，班级科目及教师管理，教学资料上传下载与进度配合，学员注册、浏览提问和答疑，以及教师/学员登录、手动或系统选题、在线考试、自动与人工改卷、成绩查询等流程；同时交代B/S架构、Windows 2000 Server、.NET Framework 2.0、Oracle 9i、IE6.0等环境约束，并说明用Rational Rose绘制UML、PowerDesigner 11.0绘制E-R图。读者可据此快速形成功能清单、用例模型和开发任务分解，作为需求评审、课程设计或项目立项的参考底稿。

1. 需求先立住：在线教育网系统为什么不能从页面清单开始

在线教育网系统的需求分析说明书，最怕写成一张功能菜单。某学校要在网络普及后补一套学习、复习、测验入口，B/S结构，学生打开浏览器就能进；可真正难的不是首页放几个栏目，而是先定清楚：学员能看哪个年级的教学内容，教师能改哪些资料，考试从组卷到查分由谁负责。若一上来就画页面，后面权限、栏目、考试流程一定会打架。

这份文档适合两类人：要交毕设或课设的学生，需要一套能讲清楚的章节骨架；要交付方案的人，需要把功能清单、用例说明、权限矩阵和验收口径对齐。我的建议是先写角色和权限，再拆网上教学与在线考试，最后补UML用例图、E-R图和版本记录。需求分析说明书不是写给开发看的“愿望清单”，而是让管理员、教师、学员三方都能对上号的操作边界。

2. 角色与权限设计：管理员、教师、学员和栏目维护者怎么分权

在线教育网系统的权限不是登录后加几个菜单那么简单。原文档把学员管理写成会员制，有相应权限才给相应功能，还拆出了模块功能管理、权限设置、角色管理、栏目管理四块。这个结构如果不在需求分析说明书里落成表，开发阶段就会出现“管理员能改一切、教师不知道自己能改哪科、学员能看到高年级内容”的扯皮。我的做法是先画角色，再画模块，最后给每个角色标数据范围。角色至少四类：管理员、栏目维护人员、教师、学员；数据范围至少三层：全站、所带班级科目、本人。权限这块最容易翻车，因为大家都觉得“先做出来再补权限”，最后补的时候每个页面都要改。

2.1 从会员制到RBAC：权限矩阵先画表再写用例

原文档写的是“对部分功能实行会员制，有相应权限才能给予相应功能”，这句话在需求里不能只停在一句描述。落到文档里，我会把它翻成一张权限矩阵：行是功能模块，列是角色，格子里写“全权、只读、本人范围、无权”。这样开发知道拦截点在哪，答辩时也能直接指着一行说“学员打不开角色管理”。权限矩阵不需要一上来就穷举所有按钮，但必须覆盖功能清单里的01模块功能管理、02权限设置、03角色管理、04栏目管理，以及网上教学和在线考试的登录、组卷、改卷、查分。

这张表不是最终版，但它能把“会员制”翻译成可检查的规则。比如学员这一列，浏览教学内容写“本年级及以下”，这是原文档明确写的；教师和管理员不受限制，也要在用例里单独说明。再往下，每个格子的“全权”还要拆成增、删、改、查四个动作，否则开发会把“管理”理解成只能看。权限设置本身也要写用例规约，不能只画一个管理员小人连到“权限设置”四个字。规约至少包含用例编号、参与者、前置条件、主流程、异常流程、后置条件。下面这个模板可以直接套：

这个规约看起来朴素，但它把“角色对模块的权限”和“功能模块管理”“角色的管理”三者的扩展关系说清楚了。原文档里02.1、02.2、02.3三条描述，最怕写成三个孤立的句子；用规约串起来，评审时就能追问“角色删除了，原有权限怎么办”。我的通常做法是：角色删除前先检查是否还有用户绑定，有绑定就先转绑或禁止删除，这条要写进异常流程，不留给开发临场发挥。

2.2 栏目管理与角色管理的边界：动态栏目不是万能后台

原文档把栏目管理分成041外观样式设置和042栏目内容动态设置，这个划分很实用，但需求分析说明书必须把边界写死。栏目维护人员能改的是栏目名称、上级栏目、排序、样式模板、内容标题、图文内容、发布状态；不能碰的是角色创建、权限勾选、模块登记。否则“栏目维护”四个字会被理解成“后台什么都能改”，最后权限矩阵白做。栏目管理的数据表也要在需求里先列字段，哪怕此时不写SQL，字段清单也能让E-R图有落点。

栏目内容和角色权限分开以后，网上教学模块才不会把“课程栏目”和“教学资料”混成一锅。课程教学、学习平台、问答平台这些前台入口可以由栏目管理配置出来，但学员能不能点进去、教师能不能上传，仍由权限矩阵决定。这里有一个容易忽略的点：动态栏目删除时，已经发布的内容怎么处理。需求里通常写“下线不物理删除”或“删除前必须清空子栏目”，两种都行，但必须选一种。我一般会在栏目管理的异常流程里写“存在已发布内容时禁止删除，先下线再迁移”，这样答辩时被问到数据丢失，有说法。

2.3 权限需求的验收口径：一条权限至少对应一个可检查动作

权限写得好不好，不看文档里画了几个小人，看能不能被一条条检查。验收时我会准备四个账号：管理员、栏目维护人员、教师、学员，每个账号走一遍越权动作。学员直接输入教师管理地址，应被拦截；栏目维护人员打开角色管理，应看不到入口；教师修改非所带科目的教学资料，应提示无权限；管理员创建角色并只勾“栏目内容维护”，该角色登录后不能出现权限设置菜单。这些动作要写进需求分析说明书的验收标准，而不是等到测试阶段才想。

这一套写进文档，需求分析说明书就不再是“功能罗列”，而是能指导开发和验收的权限方案。原文档的会员制、角色管理、栏目管理三条线，也就能在同一张矩阵里对上号。

3. 网上教学模块：班级、科目、教学资料与问答如何拆成可开发需求

网上教学是在线教育网系统里最容易写虚的一块。原文档给了班级、科目创建与管理，教师创建与管理，教学资料管理，学员注册，浏览教学内容，提问发表意见，疑问解答这些功能编号，但如果没有归属关系，开发会做出“教师随便传、学员随便看”的页面。我的拆法是先定班级、科目、教师、学员四者的关系，再定教学资料挂在哪个章节和进度上，最后把提问答疑做成闭环。这样需求分析说明书里的每条功能都能追到数据范围和操作人。

3.1 班级科目与教师管理：先定归属关系再定操作

原文档写管理员可以创建班级，对班级修改删除；同理创建老师用户，修改资料，删除老师用户。这里必须补一句关系：一个班级有多门科目，一门科目在一个班级里通常由一位教师负责，但一位教师可以带多个班级的多门科目。需求里不写清多对多还是一对多，E-R图就会画错。学员注册也要绑定班级和年级，否则“浏览本年级及以下”没有判断依据。我一般会在文档里列一张归属关系表，开发照着建关联表，答辩时也能解释清楚。

班级和科目的创建、修改、删除要写异常：班级下已有学员或教学资料时，不允许直接删除；科目已有考试记录时，删除要转归档。教师删除同理，先解除授课关系，历史资料保留上传人。这些规则不写，开发为了省事可能直接物理删除，后面查历史成绩就变成黑匣子。学员注册的字段不用多，但账号状态要有“正常、停用、待审核”，会员制功能才有着力点。

3.2 教学资料管理：FLASH、视频、课件与教学进度的版本约束

原文档明确教学资料包括FLASH动画、视频、课件，还包含根据教学进度和节次需求发布教学资料。这个点很关键：资料不是孤立文件，它要挂在班级、科目、章节、教学进度上。需求分析说明书里我会给资料表加“资料类型、所属班级、所属科目、章节、教学进度、文件路径、上传人、审核状态、版本号、可见范围”。没有版本号，教师改一版覆盖一版，学员昨天看的和今天看的不一样，出了问题连后悔药都没有。通常的做法是保留版本，已发布版本对学员可见，新版本审核后替换。

教学进度管理也要单独写：进度名称、科目、章节、计划课时、开始时间、结束时间、状态。教师发布资料时选进度节点，学员浏览时按进度展开。异常流程至少写三条：上传文件类型不在允许范围时拒绝；资料未发布时学员列表不显示；教师只能修改自己上传且未被考试引用的资料。最后一条容易被忽略，考试题目如果引用了某份资料，直接删资料会让历史试卷断链。

3.3 浏览、提问、答疑：学员可见范围与教师响应闭环

原文档写学员可以浏览本年级以及以下年级的教学内容，教师或管理员不受限制；学员可以针对所浏览章节提问，教师针对疑问解答。这个规则要落成两条：列表查询带年级条件，详情页也要校验，不能只在列表挡一下。提问必须绑定章节和资料，否则教师不知道回答哪一段。问答状态我一般设“待解答、已解答、已关闭”，学员可以补充，教师回答后学员可见，管理员可关闭异常提问。

这套问答闭环的验收标准也要写清楚：学员只能看到本年级及以下已发布资料；提问必须带章节；教师只能回答所带班级科目；回答后学员端状态变化；管理员能按状态筛选。网上教学模块写到这个程度，需求分析说明书才具备可开发性，而不是一句“实现网上教学”。

4. 在线考试模块：从登录、组卷到改卷查分的流程闭环

在线考试是在线教育网系统里状态最多的一块。原文档列了用户登录、教师登录、手动选题、系统选题、在线考试、系统改卷、教师改卷、教师查分、学员查分，功能编号从01到05。只列功能不会出错，一写流程就会暴露问题：谁先组卷，试卷什么时候发布，学员中途断线怎么办，客观题和主观题怎么分开发布。我的写法是把考试拆成“登录身份、组卷规则、考试提交、改卷、查分”五个状态段，每段写清参与者和数据变化。

4.1 登录与身份：教师和学员进入考试系统的不同入口

原文档把登录分成0101用户登录和0102教师登录，说明教师和学员进入考试系统的入口或权限不同。需求分析说明书里要写：学员登录后只能看到本人可参加的考试；教师登录后看到所带班级的试卷管理、改卷、查分；管理员拥有全站查看权但不直接替教师改卷。登录用例的前置条件、失败提示、账号状态都要写。账号停用的学员不能进入考试，教师账号被停用后不能组卷。是否锁定失败次数，按学校策略在需求评审时定，不在文档里拍脑袋写死。

登录用例的异常流程要写“账号或密码错误统一提示，不暴露账号是否存在”，这是需求文档里少写但开发容易忽略的安全细节。教师登录和学员登录可以共用一个认证入口，但角色判断后进入不同工作台，这样B/S结构下浏览器端不用做两套页面。

4.2 组卷方式：手动选题与系统选题的规则表

原文档只写手动选题和系统选题，没写规则。需求分析说明书必须补组卷参数，否则“系统选题”会变成随机抓题。我一般让文档列一张组卷规则表：试卷名称、所属班级、科目、总分、考试时长、题型分布、难度分布、抽题范围、生成方式、发布状态。手动选题由教师勾题，系统选题按题型和数量随机抽取，但同一试卷内不重复，尽量覆盖章节。题目类型至少列单选、多选、判断、填空、简答，具体以学校题库为准；这个补全要写成“通常的做法”，不要伪装成原文档已有内容。

组卷完成后要有“试卷预览”和“发布”两个动作，预览时教师能改分值，发布后学员才能看到。已发布试卷如果被修改，必须走版本记录，否则先考的和后考的不一样。这个规则写进需求，答辩时被问“系统选题会不会抽到重复题”，就能直接指规则表。

4.3 改卷与查分：系统改卷、教师改卷、成绩发布的状态设计

原文档把改卷分成系统改卷和教师改卷，查分分成教师查分和学员查分。需求里要写清：客观题由系统自动判分，主观题进入教师待改列表；教师改完后成绩进入“待发布”，发布后学员才能查。成绩状态建议设“待批阅、批阅中、待发布、已发布、已归档”。已发布后如果教师修改分数，要留修改记录，不能悄悄覆盖。分数汇总和优良登记评分也要挂在这个状态上，否则统计口径和学员看到的不一致。

异常流程至少写：考试中断后是否允许续考，重复提交以最后一次为准还是禁止，成绩发布后修改如何留痕，学员查分只能查本人。教师查分范围限所带班级，管理员可查全站。在线考试模块写到这里，功能清单里的01到05才算串成闭环。

5. 文档与建模避坑：用例图、E-R图、版本记录最容易翻车的五处

需求分析说明书不是把功能清单贴进Word就完事。原文档要求用Rational Rose画UML、用PowerDesigner 11.0画E-R图，还给了文件状态、文件标识、版本历史和1.0.0当前版本。真正交作业或交付方案时，最容易翻车的往往不是功能写少了，而是图、表、编号、版本对不上。下面五条是我在同类文档里反复见到的坑，每条按现象、原因、解决写，照着排一遍能省很多返工。

5.1 用例图只画小人：参与者有了，系统边界没了

现象：用例图里管理员、教师、学员三个小人，连出十几条线到“权限设置”“教学资料管理”“在线考试”，看起来热闹，但评审一问“哪些是系统内做的、哪些是外部触发”就答不上来。原因：把用例图当成功能清单画，只关心谁点了什么，没有画系统边界，也没有给用例编号。解决：先画一个系统边界框，框内放用例，用例名用动宾短语，如“设置角色权限”“上传教学资料”“生成试卷”；参与者放框外；每个用例编号与功能清单一致。一个用例至少配一张规约，规约里的主流程写正常路径，异常流程写越权、空数据、重复提交。用例图不追求多，权限管理四个用例、网上教学三个用例、在线考试四个用例，已经够讲清楚。

5.2 E-R图字段拍脑袋：考试和教学资料的数据关系对不上

现象：E-R图里学员、教师、班级、科目、试卷都有，但教学资料挂在谁下面、考试成绩关联哪张试卷、题目属于哪个科目，图上没有外键，开发建表时只能猜。原因：先画图后想字段，实体之间只连了线，没有确定主键和外键。解决：先列实体清单，再列每个实体的主键和关键字段，最后用PowerDesigner 11.0生成关系图。至少覆盖学员、教师、班级、科目、教学资料、教学进度、题目、试卷、考试记录、成绩、栏目、角色、权限。关系上要写清：班级一对多科目；教师与班级科目多对多；试卷一对多题目；考试记录关联学员和试卷；成绩关联考试记录。图后附字段表，评审时能逐项对。

5.3 版本记录写成流水账：1.0.0正在修改却找不到变更点

现象：文档封面写着文件状态“正在修改”、当前版本1.0.0，版本历史里只有一行日期和“修改”，谁改的、改了哪章、为什么改，全找不到。原因：把版本记录当形式，只写日期不写变更点。解决：版本历史表至少五列：版本、状态、修订人、修改日期、备注。备注写具体，如“新增在线考试组卷规则；补充权限矩阵；调整教学资料版本字段”。文件标识也要稳定，不能今天一个名明天一个名。答辩前用“版本记录—变更点—正文位置”三列自查，确保每条变更都能在正文找到落点。

5.4 需求编号乱：功能清单和用例说明对不上号

现象：功能清单用01、02、03，用例说明用001、002，考试模块又用0101、0201，评审时指着一个用例问对应哪条功能，翻半天对不上。原因：编号规则没有统一，各章各写各的。解决：用“模块前缀+两位序号”，如PERM-01、TEACH-03、EXAM-02，功能清单、用例规约、验收检查表共用同一编号。功能清单里写“PERM-02权限设置”，用例规约标题也写“PERM-02设置角色对模块的权限”，验收表里还写PERM-02。这样改一处能追三处，需求分析说明书才有可维护性。

5.5 非功能需求空着：B/S环境、浏览器和数据库不能只写名字

现象：用户环境只写Windows 2000 Server、.Net Framework 2.0、Visual Studio.NET 2005、Oracle 9i、IE6.0或以上，其他要求只写Rational Rose和PowerDesigner 11.0，正文没有说这些约束影响什么。原因：把环境清单当非功能需求，以为列了软件名就够。解决：分兼容性、性能、安全、备份、日志五类写。兼容性写清浏览器最低版本和分辨率；性能按学校规模在评审时填并发和响应时间，不编造具体数字；安全写账号停用、越权拦截、成绩修改留痕；备份写数据库备份频率；日志写登录、权限变更、成绩发布三类操作留痕。原文档的技术栈是历史约束，如果实际环境升级，要在版本记录里写明，不要正文一套、演示一套。

6. 验收与答辩：把需求分析说明书讲成一条可检查的交付链

答辩时最怕从头念目录。评审想听的不是“我写了第一章第二章”，而是“这份需求分析说明书能不能指导开发、能不能验收”。我的做法是准备三张表：功能清单与用例规约对照表、权限矩阵检查表、E-R实体字段表。三张表能互相对上，文档就立住了。现场演示按角色走，不从登录页念起：先用管理员创建角色并只勾栏目内容维护，再用该角色登录证明看不到权限设置；接着教师上传一份课件并发布到教学进度，学员登录只能看到本年级已发布资料；最后教师组一套试卷，学员提交，系统改客观题，教师改主观题，发布后学员查本人成绩。这条链走完，评审自然知道每个模块的边界在哪。

答辩问题通常集中在三处：为什么学员只能看本年级及以下，为什么栏目维护人员不能改角色，系统选题怎么避免重复。回答时不要背功能名，直接指规则：学员范围写在浏览教学内容用例的异常流程里；栏目维护和角色管理在权限矩阵里是两列；系统选题在组卷规则表里写了同一试卷题目不重复。成绩发布后修改怎么留痕，也要能指到状态表和版本记录。最后提醒一句，文档里的版本号、文件状态、修订记录要跟正文一致，别封面写1.0.0，正文还留着上一版的章节名。

从那以后我每次写需求分析说明书，都强制先填权限矩阵，再画用例图，最后才动正文；答辩前一定用学员、教师、栏目维护、管理员四个账号各走一遍越权动作。希望帮到你。

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