简介：这份《基于UML的需求规格说明书(网上招聘系统)》面向软件工程专业学生、需求分析初学者及需要撰写规格文档的开发人员，以网上招聘系统为案例，完整演示如何用统一建模语言描述系统需求。文档从导言、系统定义、应用环境到功能规格逐层展开，涵盖目的与范围界定、术语与引用标准、项目背景与整体结构、网络与软硬件运行环境，并重点定义应聘者、雇主、管理员等角色及其用例，配合用例图、类图、序列图、状态图直观呈现系统的静态结构与动态行为。资源包为单一PDF文件，约746KB，结构清晰、目录完整，便于按章节检索学习。已有306人学习下载。读者可借此掌握需求规格说明书的规范写法、UML图表的实际应用以及从角色建模到功能拆解的分析思路，适合作为课程设计、毕业设计或需求分析练习的参考范本。
1. 网上招聘系统的需求规格说明书：为什么 UML 画完还是被开发怼
很多同学做课程设计或接私活时，都经历过这个场景：熬夜画完一堆 UML 图，用例图、类图、时序图整整齐齐贴进 Word，导出成《基于UML的需求规格说明书(网上招聘系统).pdf》，交上去或发给开发，结果对方一句「这跟代码对不上」就把你噎住了。问题不在 UML 本身，而在于大多数人把 UML 当成了画图作业，而不是需求建模工具。这份文档真正要解决的是：把「企业发职位、求职者投简历、HR 筛人」这套业务，翻译成开发能直接照着建表、写接口的契约。它适合正在做招聘类系统课设的学生、需要给外包写需求的产品新人，以及想用 UML 把需求讲清楚的独立开发者。下面我按自己踩过的路子，把这份说明书从建模到落地拆一遍。
2. 先想清楚网上招聘系统要建哪些模型：用例、类、时序三件套怎么分工
UML 图有十几种，但一份能落地的招聘系统需求规格说明书，核心就三张图撑场面：用例图定边界，类图定数据结构，时序图定交互流程。剩下的活动图、状态图是补充，别一上来就全画，画多了自己都圆不回来。
2.1 用例图先圈定角色和系统边界
招聘系统的角色其实比想象中多。最粗的划分是求职者、企业HR、系统管理员三类，但真实业务里「企业」本身还要拆：发布职位的是HR，审核企业资质的是平台运营。我一般会先列一张角色-职责对照表，再动手画用例，否则用例图会画成一锅粥。
| 角色 | 核心用例 | 边界说明 |
|---|---|---|
| 求职者 | 注册登录、搜索职位、投递简历、查看投递状态 | 只能操作自己的简历 |
| 企业HR | 发布职位、筛选简历、发起面试邀约 | 只能看本企业职位收到的简历 |
| 平台运营 | 审核企业资质、下架违规职位 | 不碰具体简历内容 |
| 系统管理员 | 用户管理、权限配置、日志查看 | 后台运维，不参与业务 |
画用例图时有个血泪经验：别把「登录」当成一个独立用例铺开画。登录是所有角色的公共前置，画进去会让图膨胀一倍。常见做法是把它抽成一个 include 的公共用例，或者干脆在文档里用一段文字说明，图上不体现。
用例之间的关系也要标清楚。求职者「投递简历」和「上传附件简历」之间是 include 关系——投递必然包含上传；而「投递简历」和「收藏职位」之间是 extend 关系——收藏是可选的扩展行为。这两个箭头方向搞反，是 uml用例图 里最高频的翻车点。
2.2 类图决定数据库表结构，别画成孤岛
类图是这份说明书里最值钱的部分，因为它直接对应数据库建表。很多人类图画得漂亮，但类与类之间没有关联线，开发看了根本不知道外键怎么建。
网上招聘系统的核心类我一般这么抽：
// 核心实体类骨架，字段对应数据库列 public class JobSeeker { // 求职者 private Long id; private String name; private String phone; private List<Resume> resumes; // 一对多：一个求职者多份简历 } public class Resume { // 简历 private Long id; private Long seekerId; // 外键指向求职者 private String education; private List<WorkExperience> experiences; } public class Job { // 职位 private Long id; private Long companyId; // 外键指向企业 private String title; private Integer status; // 0下架 1在招 2已招满 } public class Application { // 投递记录（关联类） private Long id; private Long resumeId; private Long jobId; private Date applyTime; private Integer status; // 投递状态机 }这段代码的关键不是语法，而是关联关系的表达。JobSeeker和Resume是一对多，Resume和Job通过Application这个关联类形成多对多。类图上对应的就是：求职者端 1 对 0..* 简历，简历端和职位端通过投递记录类连接，两端都是 1 对 0..*。
参数说明上，Application.status这个字段最容易出事。它是个状态机：已投递→已查看→邀面试→已录用/已拒绝。类图里如果只写个 int，开发根本不知道有哪些取值。我一般会在类图旁边附一张状态取值表，或者直接画个状态图补充。
2.3 时序图把「投递简历」这条主链路讲透
时序图不用多，挑最核心的一条业务链路画就行。招聘系统里最值得画的是「求职者投递简历」：求职者→前端→投递服务→简历服务→职位服务→数据库。
画的时候注意三个细节。第一，生命线上的激活条要标清楚，投递服务调用简历服务时，简历服务的激活条是嵌套在投递服务里的，表示同步调用。第二，返回消息用虚线箭头，别和调用消息混用实线。第三，异常分支要画出来，比如「职位已下架」时投递服务直接返回失败，不往下走。这条异常分支不画，开发联调时就会来问你「投了个已下架的职位怎么办」。
时序图里消息的命名也有讲究。别写「处理投递」这种模糊词，要写成checkJobStatus(jobId)、saveApplication(application)这种带参数的方法名，开发可以直接照着定义接口。
3. 把 UML 模型翻译成需求规格说明书的正式章节
图画完了只是草稿，真正交付的是一份结构化的需求规格说明书。这份文档的骨架决定了开发能不能按图索骥。
3.1 文档章节的标准骨架
一份能用的招聘系统需求规格说明书，我一般按这个顺序组织：
- 引言：目的、范围、术语定义（比如「简历」「职位」「投递」的准确定义）
- 总体描述：系统角色、运行环境、约束假设
- 功能需求：按用例逐个展开，每个用例写清前置条件、主流程、异常流程、后置条件
- 数据需求：类图 + 数据字典，每个字段的类型、长度、约束
- 接口需求：时序图对应的接口清单，含入参出参
- 非功能需求：性能、安全、可用性指标
这里有个坑：功能需求别只贴用例图。用例图只说明「谁做了什么」，但「怎么做」要靠用例规约表。比如「投递简历」这个用例，规约表里要写：前置条件是求职者已登录且简历完整度≥80%，主流程是选择职位→确认简历→提交，异常流程包括职位已下架、重复投递、简历不完整三种。
3.2 数据字典和类图怎么对齐
类图里的每个类，在数据字典里都要有对应条目。我习惯用一张表把类属性、数据库字段、约束条件三者对齐：
| 类.属性 | 数据库字段 | 类型 | 约束 |
|---|---|---|---|
| Job.title | job_title | varchar(100) | 非空 |
| Job.status | job_status | tinyint | 默认1，取值0/1/2 |
| Application.applyTime | apply_time | datetime | 默认当前时间 |
| Resume.seekerId | seeker_id | bigint | 外键，非空 |
这张表的价值在于：开发建表时不用再猜字段类型，测试写用例时也能直接照着约束造边界数据。我见过太多说明书类图和数据字典对不上，类图里status是字符串，数据字典里写成 int，最后开发按哪个来都要吵架。
3.3 用活动图补充复杂业务流程
时序图讲的是「谁和谁交互」，活动图讲的是「业务怎么流转」。招聘系统里最值得画活动图的是「简历筛选」：HR 打开职位→查看投递列表→逐份查看→标记通过/淘汰→通过的发面试邀约。
活动图里要标清楚决策节点的条件。比如「简历是否完整」这个判断，不完整就走「退回补充」分支，完整才进入「进入筛选」分支。泳道也要分好，求职者泳道、HR泳道、系统泳道各管各的动作，别混在一起。
4. 需求规格说明书的避坑与排查：那些让开发翻白眼的写法
这一章是我这些年被怼出来的经验，每条都是真实翻车现场。
4.1 用例粒度太粗，一个用例包打天下
现象：用例图里只有一个「管理职位」用例，开发问「发布、修改、下架、刷新是不是都算」，你答不上来。
原因：把 CRUD 操作揉成一个用例，边界模糊。
解决：按业务价值拆分。发布职位、修改职位、下架职位是三个独立用例，各自有独立的前置条件和异常流程。CRUD 是代码层面的，用例是业务层面的，别混。
4.2 类图关联关系缺失，外键全靠猜
现象：类图里Resume和JobSeeker之间没有连线，开发建表时不知道该不该加seeker_id。
原因：画类图时只关注属性，忽略了类与类之间的静态关系。
解决：每个类画完后，强制问一句「这个类和哪些类有关系，是一对一、一对多还是多对多」。关联线要标多重性（1、0..、1..），聚合和组合用空心/实心菱形区分。
4.3 时序图只画正常流程，异常分支全丢
现象：开发联调时发现「投递已下架职位」没处理，回头问你，你说「忘了画」。
原因：画时序图时只想着 happy path，没考虑边界情况。
解决：每条主流程至少配 2 个异常分支。投递场景的异常至少包括：职位已下架、重复投递、简历不完整、企业已注销。异常分支在时序图里用 alt 组合片段框起来，别偷懒。
4.4 需求描述用「等等」「若干」这类模糊词
现象：文档里写「职位列表支持按关键词、地点等筛选」，开发问「等」还包括什么，你说「你看着办」。
原因：写文档时图省事，用模糊词兜底。
解决：筛选条件必须穷举。关键词、地点、薪资范围、经验要求、学历要求、公司规模，一个都不能用「等」代替。每个筛选条件的匹配方式是精确还是模糊，也要写清楚。
4.5 非功能需求完全缺失
现象：系统上线后 HR 抱怨「投递列表加载要 10 秒」，你回头翻文档，发现压根没写性能指标。
原因：只关注功能，忽略了性能、安全、并发这些非功能需求。
解决：至少写三条硬指标。比如「职位搜索响应时间≤2秒」「简历投递接口支持 500 QPS」「用户密码加密存储，不可逆」。这些指标不写，测试没有验收标准，上线就是开盲盒。
5. 从说明书到可运行原型：用类图直接生成建表 SQL 的技巧
需求规格说明书的终点不是 PDF，而是能跑起来的代码。我一般会在文档定稿后，直接从类图推导建表 SQL，这样能反向验证类图有没有漏洞。
-- 由类图直接推导的建表语句，字段与类属性一一对应 CREATE TABLE job_seeker ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, phone VARCHAR(20) UNIQUE NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE resume ( id BIGINT PRIMARY KEY AUTO_INCREMENT, seeker_id BIGINT NOT NULL, education VARCHAR(20), content TEXT, FOREIGN KEY (seeker_id) REFERENCES job_seeker(id) ); CREATE TABLE job ( id BIGINT PRIMARY KEY AUTO_INCREMENT, company_id BIGINT NOT NULL, title VARCHAR(100) NOT NULL, status TINYINT DEFAULT 1 COMMENT '0下架 1在招 2招满' ); CREATE TABLE application ( id BIGINT PRIMARY KEY AUTO_INCREMENT, resume_id BIGINT NOT NULL, job_id BIGINT NOT NULL, apply_time DATETIME DEFAULT CURRENT_TIMESTAMP, status TINYINT DEFAULT 0 COMMENT '0已投递 1已查看 2邀面试 3录用 4拒绝', UNIQUE KEY uk_resume_job (resume_id, job_id) -- 防重复投递 );这段 SQL 有两个地方是直接从需求推导出来的。第一，application表上的uk_resume_job唯一索引，对应需求里「同一简历不能重复投递同一职位」这条业务规则。第二，job.status和application.status的注释，对应类图旁边的状态取值表。如果类图里没写状态取值，这里就写不出注释，开发就得来问你。
参数上重点看status字段。用 tinyint 而不是 varchar，是因为状态值是有限枚举，tinyint 省空间且查询快。但代价是可读性差，所以注释必须写全，否则运维查数据时一脸懵。
验证类图有没有漏洞，有个简单办法：拿建表 SQL 反向问业务。比如resume表没有job_id字段，说明简历和职位是多对多关系，必须通过application关联。如果业务说「一份简历只能投一个职位」，那类图就画错了，得改成一对多。这种反向验证比盯着类图看有效得多。
最后说个我自己的习惯：说明书定稿前，我会把类图、时序图、数据字典三份东西摊在一起，逐字段对一遍。类图里的每个属性，数据字典里必须有；时序图里的每个方法调用，接口清单里必须有；用例规约里的每个异常流程，时序图里必须有对应分支。这三者对不齐，文档就是废纸。希望帮到你。
本文还有配套的精品资源，点击获取
