企业官网建设流程全解析

简介：《软件工程实验报告——需求分析.doc》围绕酒店管理系统，详细演示了需求分析阶段的完整过程，适合软件工程课程设计、实验报告撰写及建模入门者参考。内容涵盖系统需求概述、部门划分与子系统功能，随后重点讲解用例建模，包括参与者、用例列表、用例规格说明与辅助需求；对象建模部分列出了客房管理、用户管理、财务管理等五个管理类和三个实体类的属性与关联；动态建模部分则用顺序图和状态图描述登录、入住、退宿等流程，并附有总结与反思。资源为 1 个 doc 文件，压缩包约 289KB，轻量易用，方便直接打开学习；目前已有 78 人学习浏览。通过这份报告，读者既能掌握需求分析文档的章节结构和写作方法，也能学会如何将用例图、类图、顺序图、状态图应用到实际系统建模中，是一份内容完整、结构清晰的实验报告范例。

1. 需求分析实验报告：为什么越像“需求清单”越容易翻车

带过几届软件工程课设之后，我发现一个规律：那些被退回重写的需求分析实验报告，几乎不是“没写够字数”，而是“写成了需求清单”。功能点列了三十多条，每条都说“用户能登录、能查询、能导出”，但评审人问一句“谁能登录、查询什么、导出给谁用、不做行不行”，报告里一个字都答不上来。这不是写作能力问题，而是需求分析这门课最核心的那一步——把模糊的业务意图转成有边界的、可验证的软件行为——没有走完。

这份 .doc 的实验报告，本质上是在回答四个问题：这个系统为谁解决什么问题；它必须做什么、不做什么；怎么证明“做对了”；以及你作为分析师是怎么从零摸到这些结论的。这篇文章就沿着这条链路，把报告从空白文档写到能过评审。适合正在写课设报告的学生，也适合刚接手需求文档、想理顺分析方法的初级开发。

2. 实验报告骨架：从评审视角倒推一份需求文档的结构

2.1 实验报告与真实需求文档的差异：一份报告有三层读者

需求分析实验报告和公司里那种几十页的《软件需求规格说明书》（SRS）不是一个物种。SRS 是给后续设计、开发、测试当契约用的，每一条都得抠到“按钮在窗体右上角”或者“响应时间小于 2 秒”这种粒度。实验报告是给导师看的，目的是证明你掌握了需求分析的方法和过程，而不是证明你写出了可交付的商业文档。

我一般把实验报告的读者拆成三层：第一层是导师，他看的是方法对不对、结构全不全、有没有自己的思考；第二层是模拟的甲方，也就是场景里的业务方，报告里的用例、原型、词汇表要让他能看懂、能确认；第三层是自己，过两个月回来看这份报告，能不能想起来当时为什么这么定边界。很多报告翻车就是因为只盯着第一层，把 UML 图画得花团锦簇，但图和数据流对不上，业务规则含糊，用例之间互相矛盾，导师一眼就看出是拼凑的。

所以写报告前先问自己一个问题：如果我不是作者，而是一个没参与过这个项目的评审，拿到这份文档，我能不能照着它判断“这个系统值得做、能做、做出来能用”？如果答案是否定的，那结构肯定有问题。

2.2 从用例到验收标准：一份 30 页报告的内容排布

实验报告没有强制模板，但按软件工程教材的习惯，一份能站住的需求分析报告通常包含七个部分：项目背景与目标，明确问题域和系统边界；用户角色定义，列出每类角色及其权限；功能需求，用用例图和用例规约表达；数据需求，用类图或 ER 图表达；非功能需求，包括性能、安全、可用性；验收标准，把每条需求映射到可验证的指标；附录，包括访谈记录、问卷结果、词汇表。

我建议按“从粗到细”排布，每章之间用需求编号建立索引。示例如下：

1. 项目背景 1.1 现状与问题 1.2 项目目标 2. 角色定义 2.1 角色清单与职责 2.2 权限矩阵 3. 功能需求 3.1 用例图 3.2 用例规约（UC-xx） 4. 数据需求 4.1 类图 4.2 关键数据结构 5. 非功能需求 6. 验收标准 7. 附录 7.1 访谈记录 7.2 需求追溯表

注意一个细节：背景部分不要写“随着信息化的发展”这种空话，直接写“当前某学院课程选课依赖 Excel 表，存在三大问题：……”。问题越具体，后面的需求越站得住。很多报告的背景和需求是两张皮，背景说“效率低”，需求里却没有任何一条是和效率相关的指标，这就叫脱节。

2.3 用需求条目编号把全文串起来

实验报告最容易被扣分的地方是内部不一致。用例图里画了“修改密码”，用例规约却没有这条；类图里有“订单”实体，数据需求里却没有订单表结构；非功能需求说“支持 100 人并发”，验收标准里根本没有压测指标。解决这个问题最土也最有效的办法，是给每条需求一个唯一编号，全文所有图表和文字都引用这个编号。

编号规则我用的是三层结构：FR（Functional Requirement） 表示功能需求，NFR 表示非功能需求；前缀加模块名缩写；后缀是序号。比如教务系统里“学生登录”可以记为FR-AUTH-001，含义是“认证模块功能需求第 1 条”。在用例图的参与者说明里写“学生（见 FR-AUTH-001）”而不是写“学生可以登录”；在验收标准里写“FR-AUTH-001 通过标准：登录失败时提示语可读且不泄露账号是否存在”。这个编号会一直贯穿到需求追溯表，是全文的骨架。

3. 需求获取：别坐在电脑前编需求

3.1 访谈、问卷与现场观察：三类获取手段怎么选

需求获取最忌讳的是拍脑袋。实验场景里没有真实甲方，但模拟项目也必须走获取流程。常见做法是三类手段组合：第一类是访谈，约谈两三位业务角色，每人准备 8-10 个开放式问题，比如“你每天最烦的处理动作是什么”“这个数据填错了后面会有什么连锁反应”；第二类是问卷，覆盖更大范围的使用者，收集频率、痛点、功能期望的量化数据；第三类是现场观察或文档分析，去实际盯半小时业务流转，看表单、看台账、看在途流程。

选型逻辑很简单：访谈解决“为什么”，问卷解决“有多少”，观察解决“实际上是怎么做的”。三者产出不同，报告里都要体现。我见过一份写超市收银系统的报告，只做了一个问卷就说“80% 的人希望支持扫码支付”，这就是典型的方法缺陷——问卷只能说明大家想要，说明不了收银台空间、扫码枪型号、网络环境是否允许。现场观察才能暴露这些物理约束。

这三类手段在报告里要写成“做了什么、得出什么结论、如何影响需求”三段式，不要只贴一份空白问卷充数。每类手段至少对应两条需求依据，导师看的时候能顺着“问卷第 5 题 → 需求 FR-XXX-002”的路径查下去，报告的可信度会高很多。

3.2 从对话原话到需求条目：四条转换规则

访谈做完，最难的步骤是把对话转成需求。我总结了四条规则，按顺序执行，基本不会漏。

第一，去掉情绪词，只留事实。甲方说“系统太卡了”，这是情绪，转成需求就是“列表页加载时间不超过 3 秒”或者“支持 100 条以上的数据列表分页展示”。第二，区分“要什么”和“怎么实现”。甲方说“我要一个红头文件一样的打印模板”，这是实现方案，真实需求是“打印出的文件包含发文机关标志、标题、正文、落款四部分，格式符合公文规范”。第三，把隐含主语补全。甲方说“要能导出 Excel”，谁导出、导出什么数据、Excel 的哪些字段、什么触发时机，全部要明确。第四，识别非功能属性。对话里出现的“快”“稳”“安全”“随时”都是非功能需求的来源，但要落到可验证的指标上，比如“随时”要变成“7x24 小时可用，计划内维护窗口除外”。

为了不让转换过程变成黑匣子，报告里可以放一个“需求来源映射表”。表的字段包含：编号、来源（访谈记录第几条/问卷第几题/观察记录第几段）、原话摘要、分析过程、所生成的需求编号。这张表是报告里最容易被忽视、但最容易被导师认可的内容，因为它展示了你“怎么想”的过程，而不是只有结果。

3.3 用 PlantUML 画业务流程图：让流程比文字更早暴露矛盾

需求获取阶段画业务流程图有个额外好处：画图的过程就是检查矛盾的过程。文字写“采购申请由部门经理审批，超过 5000 元还需要分管领导审批”，这句话看不出问题；画成流程图就会发现一个分支缺口——5000 元整怎么算？审批不通过要不要通知申请人？这些分支必须在图里显式画出来，画不出来的地方就是需求询问表里下一轮要问的问题。

报告里流程图可以用 PlantUML 代码生成，方便修改且能保证逻辑一致性。示例代码如下：

@startuml start :提交采购申请; if (金额 <= 5000) then (是) :部门经理审批; else (否) :部门经理初审; :分管领导审批; endif if (审批通过?) then (是) :生成采购单; stop else (否) :通知申请人并附原因; stop endif @enduml

这段流程图的逻辑说明：分支条件的边界要在文字需求里写清，比如“金额大于 5000 元（不含）时触发分管领导审批，等于 5000 元时仅部门经理审批”；审批不通过的通知路径必须单独成一条，因为很多报告在这里漏掉了节点，导致流程图中“审批不通过”之后没有任何活动，这本身就是需求缺陷。PlantUML 的好处是改条件后图自动重新布局，不会出现文档里图和文字对不上的尴尬。

4. 需求建模：用例图、类图与时序图的实验报告画法

4.1 用例图：边界、主角色与用例的粒度控制

用例图是需求分析报告里曝光率最高的图，也是被画得最稀烂的图。三个高频问题：第一，系统边界框里塞了大量非功能内容，有把“登录时加密传输”画成用例的；第二，用例粒度忽大忽小，既有“下单”又有“输入收货地址”；第三，参与者关系乱画，把“管理员”和“超级管理员”画成泛化关系但实际只是角色权限不同。

我的做法是三个原则。其一，用例必须是“参与者通过系统获得一个可观察、可衡量的结果”，像“登录”只是前置条件不是结果，但如果系统有“找回密码”的独立流程，那“找回密码”可以是用例。其二，同一份报告里用例粒度要保持在同一层级，要么都按业务事件分（提交申请、审批通过、导出报表），要么都按子系统功能分（订单管理、库存管理），不要混着来。其三，参与者只画直接与系统交互的角色，不画部门，不画外部系统。类似“短信服务商”这样的外部系统，建议用actor标注还是component，报告里第一次出现时要统一说明。

用例图画完后，必须配一份参与者说明表，包含参与者名称、身份描述、使用系统的目标、主要用例编号。这张表能解释“为什么这个参与者存在”，是评审时最容易问到的点。

4.2 类图：从需求名词中筛出实体与属性

类图画得不好的报告，共性问题是把类图画成了数据库表结构图，光秃秃地罗列字段，毫无行为。实验报告里的类图是要展示“需求里有哪些数据实体、实体间什么关系”，不是给开发看的物理设计。

做法是从用例规约的“基本事件流”里提取名词，然后做三轮筛选：第一轮删掉角色名词（学生、管理员），这些是参与者不是实体；第二轮删掉系统组件名词（界面、按钮、页面），这些是实现概念；第三轮合并同义词（“用户”和“账户”合并为“用户”实体）。剩下的名词对照用例的事件流判定：如果一个名词既会被创建/修改，又会被查询，基本可以确定是实体；如果只出现在某一个用例里且没有属性，大概率是该用例的一个输入参数，不是独立实体。

类图里每对关联关系都要能回答“为什么需要这个关联”。双向关联慎用，实验报告里十有八九只需要单向导航。比如“订单”知道“客户”，但“客户”不需要知道“订单”的全部细节，那就在订单类这边画箭头指向客户类即可，不要为了对称画双向。属性列不要贪多，每个类列 3-5 个核心属性就够了，重点是关联和多重性的表达。

4.3 时序图：只画三条关键路径，别贪多

很多报告里的时序图是灾难现场：一张图塞了十几个对象、二十多条消息，箭头缀成蛛网，评审根本没法看。实验报告不要求覆盖所有流程，只挑最能体现系统交互逻辑的三条路径即可：一条主业务路径，比如“用户提交申请到审批通过”；一条异常分支，比如“库存不足时如何处理”；一条跨角色路径，比如“学生选课与教学秘书排课之间的数据交互”。

时序图的作用是验证用例规约里的事件流是否完备。画图时按“顺序从左到右：边界对象 → 控制对象 → 实体对象”排列消息，能明显看出职责分配是否合理。如果消息全部在一个对象上进出，说明控制逻辑全堆在界面层，需求分析报告里就要提示后续设计阶段注意。

画时序图的 PlantUML 代码示例如下：

@startuml actor 学生 participant "选课界面" as UI participant "选课控制器" as CTL participant "课程" as Course student -> UI: 提交选课申请 UI -> CTL: 校验选课资格 CTL -> Course: 查询剩余名额 Course --> CTL: 返回剩余容量 alt 名额不足 CTL --> UI: 返回容量不足提示 else 名额充足 CTL -> Course: 扣减名额 CTL --> UI: 选课成功 end @enduml

代码对应的逻辑说明：alt 分支是时序图里最容易出错的地方，分支条件必须在用例规约中显式写明，不能只画图不写条件。上例中“校验选课资格”这步在校验什么、不通过怎么办，时序图里只画了一个 message，文字部分要补全。时序图中不建议出现超过六个参与者的场景，参与者的职责说明放在图下方的表格里。

5. 避坑：需求分析报告常见的五个翻车现场

5.1 把“点击按钮”写成需求

现象：需求条目写成“用户点击查询按钮，系统显示结果列表”，全文找不出一个非功能指标，也没有业务规则。

原因：把用户界面操作直接当成需求，混淆了“界面交互”和“系统能力”。这类报告通常没有参与流程图，也没有用例规约，靠想象写界面行为。

解决：把需求改写成“用户输入查询条件后，系统返回符合条件的结果列表，结果按记录编号升序排列；查询条件为空时提示用户输入至少一个筛选字段”。如果实验要求包含界面原型，原型里画按钮没问题，但需求条目里写的是系统能力和约束，不是按钮坐标。

5.2 功能需求与界面混淆，导致需求无法验证

现象：验收标准写成“登录页面美观大方”“界面简洁易用”，导师问怎么量化，答不上来。

原因：需求分析报告里把“设计偏好”写进了功能需求。美观是主观感受，且和后端实现无关。

解决：把这类描述移入非功能需求中的“可用性”类别，并量化。比如“登录页面的核心操作（输入账号、输入密码、点击登录）必须在一次屏幕高度内完成”“常用操作不超过三级菜单”。如果实在量化不了，就删掉，不要凑数。验收标准里只留可验证的指标。

5.3 用例图中参与者缺失，角色与用例对不上

现象：用例图里学生能“查看成绩”“打印成绩单”“申请复查”，但参与者只画了学生一个，没有教务处角色；或反过来说，图上画了“系统管理员”，但所有用例里管理员只是“维护用户信息”，没有和业务流产生互动。

原因：参与者集是从现成用例反推的，没有回到业务现场看角色分工。

解决：重新对照业务流程图，给每一条关键业务路径列一遍角色清单。一个角色只要在任一路径中执行动作、接收结果或承担审批职责，就应当出现在用例图里。反过来的角色，如果只是系统配置和数据备份，建议单独放一张“系统维护用例图”，避免和业务用例混在一起。

5.4 需求优先级一刀切，缺少取舍逻辑

现象：所有功能需求标注“高”优先级，或干脆不标；报告里没有一处讨论“如果时间不够先砍什么”。

原因：没有从业务价值和成本两个维度去看需求。

解决：在需求追溯表之外增加一列“优先级（高/中/低）”，并在报告正文里用一段话说明判定依据。一个比较容易上手的维度是检查每条需求对核心业务目标的影响：没有它业务无法闭环，就是高；没有它业务能用但效率受损，就是中；没有它不影响主线，就是低。优先级低的条目在验收标准里可以放宽，甚至标注“超出本期范围，见展望”。

5.5 需求追溯表缺失，报告前后脱节

现象：用例图、类图、需求条目各做各的，评审提出“类图里的订单实体在用例里没有对应的‘提交订单’用例”，作者无法回答。

原因：写报告时按章节顺序写完就交，没有做一致性检查。需求追溯表就是把图纸和文字串起来的关键工具。

解决：在报告附录里放一张需求追溯表，格式如下。

这张表不用写得很长，能把测试用例或验收条目接住即可。它的作用不是给导师看，是给你自己“抄写”用的：写完后逐行过一遍，任何一格填不出来的，都说明前面有遗漏。

6. 收官技巧：用需求追溯表和验收矩阵证明分析有效

实验报告写到最后一章，很多人草草收尾：“本文对某系统进行了需求分析，完成了用例图和类图的绘制。”这句话没有任何信息量。真正能让报告加分的收官，是两条验证闭环：一是需求追溯表，把每条功能需求映射到用例、类图、非功能指标和验收标准；二是验收矩阵，把验收标准组织成“条件 + 预期结果”的结构化列表。两者合在一起，才能回答“你怎么证明需求分析做对了”。

需求追溯表我习惯放在附录，在正文里留一段“追溯表的使用方法”说明。比如 FR-AUTH-001 对应 UC-001 登录用例，类图里需要对应用户实体，验收标准 AC-AUTH-001 写“输入错误密码三次后，系统锁定账号 15 分钟并显示剩余锁定时长”。每次写完一条需求，就问自己：能不能找到画出这条需求的用例？能不能在类图里找到数据载体？能不能写出一个测试步骤证明它做完了？三个问题有一个答不上来，这条需求要么删掉，要么拆细。验收矩阵则建议单独一张表，列出测试步骤、输入数据、预期结果、需求编号。比如“输入已注册账号和正确密码，点击登录，预期跳转至首页并显示用户昵称”。我见过一份报告用这个方法把 30 多条需求全部接了一遍，导师当场就说“这报告可以当模板”。

我自己的教训是：第一次写需求分析报告时时间分配严重失衡，画图用了三天，写追溯表只用了一个小时，结果图里画了一个“导出课程表”的用例，追溯表里却找不到对应的数据字段，翻回去改又花了半天。从那以后我改成“每写完一个用例，立刻填对应的追溯表行”，不攒到最后。这个习惯也带到了真实项目里，每次评审前只需要检查表格有没有空项，就能快速判断文档是否完整。

需求分析的本质不是画图，是让模糊的描述变成机器可验证行为的边界。把这份报告当作第一次“从对话到代码之间搭桥”的练习，多花时间在追溯和验证上，少纠结措辞。希望帮到你。

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