人力资源管理系统用例分析：登录、考勤到招聘的设计要点

简介：这是一份人力资源管理系统用例分析文档，主要面向软件工程课程设计、毕业设计或企业HR系统前期的需求分析工作。文档以用例图为抓手，系统梳理了登录、员工管理、考勤管理等模块的参与角色与功能流程，并延伸至招聘管理模块。其中员工管理细化为添加、删除、修改、查看信息等用例，考勤管理则包括考勤登记、查看与删除考勤记录、考勤项目设置等，能够帮助读者快速建立HR系统的功能全景与角色权限边界。资源以doc格式提供，共1个文件，包体约960KB，内容可直接查看，也便于在Word中继续编辑和复用。目前已有122人学习，无论是用于撰写需求规格说明书、绘制用例图，还是作为系统功能测试的参考，都能提供较完整的用例颗粒度支撑。

1. 一份能直接照着画用例图的人力资源管理系统分析文档

做人力资源管理系统最头疼的往往不是写代码，而是开工前画用例图。需求方说“加个员工管理”，到底要画几个用例？考勤和薪酬谁先谁后？我第一次接这种项目时，光用例图就返工了三次。这份《人力资源管理系统用例分析文档.doc》正是解决这个问题的：它把登录、员工管理、考勤、招聘、奖惩、薪酬、商品、订单、公告、员工自助、系统管理十一个模块的用例全部梳理好了，每个用例都带编号和详细说明。适合正在做课程设计、毕业设计，或者要给中小企业搭 HRMS 的开发者直接拿去复用，省掉从零拆需求的时间，用例设计这一步基本能照着走完。

2. 登录与员工管理：先把参与者和用例粒度定准

拿到这份文档，我建议先别急着翻后面的招聘和薪酬，而是花半小时把登录模块和员工管理模块吃透。这两个模块决定了整个系统的参与者划分和用例粒度，后面所有模块的写法都是顺着这套逻辑走的。

2.1 登录模块：分清“用户登录”和“系统管理员登录”的真实含义

文档里登录模块写了两个用例：用户登录、系统管理员登录。很多人第一次看会觉得这俩重复了——都是输入用户名密码进系统，为什么要拆成两个？这里其实是把参与者的差异显式化了。普通用户登录后只能进员工自助看自己的信息，系统管理员登录后能看到系统维护和权限管理入口。同一个登录动作，因为角色不同，系统授予的访问权限完全不同。

从用例分析的角度，我一般会建议把登录拆成三层来理解：

• 身份验证：核对用户名和密码，这是公共逻辑，两个用例都包含它。
• 会话建立：登录成功后创建会话，记录当前用户角色。
• 权限路由：根据角色跳转到不同首页，加载不同菜单。

这三个层次对应到技术上，就是登录接口、Token 生成、动态路由三件事。文档里虽然没有写实现代码，但用例拆分到这个程度，后端接口怎么设计已经很清楚了。常见做法是搞一个login(username, password)接口，返回用户角色，前端拿角色去拉菜单树。

2.2 员工管理四件套：增删改查的用例边界怎么划

员工管理模块是这份文档里最标准的部分：添加员工信息、删除员工信息、修改员工信息、查看员工信息、查看详细信息，一共五个用例。这里的核心问题是：为什么“查看详细信息”单独拆成一个用例，而不是合并到“查看员工信息”里？

文档的处理方式是：查看员工信息只展示列表页的基础字段——工号、姓名、部门、岗位、在职状态；查看详细信息则要进入二级页面，展示教育背景、工作经历、技能证书、合同信息。这个拆分是合理的，因为两个用例的权限往往不一样。很多公司普通员工可以看同事的基础信息，但详细信息只对 HR 或部门主管开放。

在实现层面，这两个用例通常对应两个接口：

# 员工列表接口：返回基础字段，支持分页和关键字搜索 def get_employee_list(keyword: str = "", page: int = 1, size: int = 20): query = Employee.query if keyword: query = query.filter( or_(Employee.name.like(f"%{keyword}%"), Employee.employee_no.like(f"%{keyword}%")) ) total = query.count() items = query.offset((page - 1) * size).limit(size).all() return { "total": total, "items": [emp.to_basic_dict() for emp in items] } # 员工详情接口：返回全量字段，需要单独做权限校验 def get_employee_detail(employee_id: int, current_user: User): if not current_user.has_permission("employee:detail"): raise PermissionDenied("无权限查看员工详细信息") emp = Employee.query.get_or_404(employee_id) return emp.to_full_dict()

逻辑上，两个接口对应两个用例，权限注解挂在方法上是常见做法。参数方面，列表接口的关键参数是keyword、page、size，控制搜索和分页；详情接口的参数只有一个employee_id，但权限校验是重头。

这里有一个很容易翻车的点：删除员工信息这个用例，很多初学者直接写成物理删除。但实际业务里，员工离职后他的考勤记录、薪酬记录、奖惩记录都还要保留，物理删除会导致这些关联数据全部悬空。正确的做法是逻辑删除——给员工表加一个is_active字段，删除时只改状态，查询时默认过滤掉非活跃员工。

文档里没有明确写逻辑删除还是物理删除，但这是用例分析阶段的遗漏点。你如果在做设计，这份文档的“查看员工信息”用例里最好补一条约束：“只展示在职状态为‘在职’的员工，离职员工默认不展示。”

2.3 员工自助和系统管理：要跟着用例图一起看的两个模块

文档里员工自助模块和系统管理模块容易被忽略，但这两个恰好能检验用例设计是否闭环。员工自助覆盖了查看个人基本信息、修改个人基本信息、辞职申请、修改登录密码、查看个人积分五个用例；系统管理覆盖了系统维护、权限管理、用户管理、角色管理。

注意看文档的编号写法：11.2.1 用户管理下面有 11.2.1.1 添加用户、11.2.1.2 修改用户、11.2.1.3 删除用户、11.2.1.4 查看用户，但 11.3.1 角色管理直接接在用户管理后面，编号上 11.3.1 应该是 11.2.2 的级别才合理。这种编号跳跃在原始文档里就有，是典型的文档编辑失误。使用的时候可以把角色管理的编号修正为 11.2.2.x，避免后面做需求追溯时对不上号。

员工自助和系统管理放在一起看，还能发现一个关键设计：修改个人信息和修改登录密码这两个用例，走的是员工自助通道，不走员工管理通道。这意味着员工管理模块的“修改员工信息”用例实际上应该限定为“修改他人信息”——HR 才有这个权限。用例图里如果不把这个区分画清楚，开发阶段很容易把修改接口写成一个，最后权限控制全乱掉。

我一般会做一张参与者与用例的映射表，理清这个关系：

这张表画出来，开发时每个接口的权限装饰器基本就有依据了。

3. 考勤管理与薪酬管理：把流程用例拆到“项目设置”级别

考勤管理是这份文档里写得比较厚的模块，从考勤登记、查看考勤记录、删除考勤记录，到考勤项目设置、考勤统计表，一共覆盖了五个用例层级。薪酬管理相对薄，只有四个增删改查用例。这两个模块放在一起看，正好能看出用例分析的两种不同深度。

3.1 考勤项目设置：最容易在需求评审时被追问的用例

文档里 3.4 考勤项目设置下面又拆出添加考勤项目、修改考勤项目、删除考勤项目三个子用例。很多做系统的人会疑惑：考勤项目不就是上班、下班吗？为什么要单独做一个管理功能？

实际业务里，考勤项目远不止早晚打卡。常见的考勤项目有：上班打卡、下班打卡、外勤打卡、加班开始、加班结束、补卡申请。每个项目的计薪规则不同——加班按 1.5 倍工资计算，节假日按 3 倍。如果把这些项目写死在代码里，后面公司调规则就要改代码、重新上线，非常被动。

用例层面拆出“考勤项目设置”，本质上是把考勤规则从代码逻辑里抽出来，变成可配置数据。对应到数据库设计，至少要有一张表：

CREATE TABLE attendance_item ( id INT PRIMARY KEY AUTO_INCREMENT, item_code VARCHAR(50) NOT NULL UNIQUE COMMENT '项目编码，如 CHECK_IN / CHECK_OUT / OVERTIME_START', item_name VARCHAR(100) NOT NULL COMMENT '项目名称，如上班打卡 / 加班开始', calc_ratio DECIMAL(3, 2) DEFAULT 1.00 COMMENT '计薪系数，普通上班 1.00，加班 1.50', is_active TINYINT DEFAULT 1 COMMENT '是否启用', sort_order INT DEFAULT 0 COMMENT '排序权重' );

这里的关键参数是calc_ratio——计薪系数。考勤登记的数据最终要流向薪酬计算，如果考勤项目和薪酬规则没有通过这个系数关联起来，后面薪酬模块就只能手动改数字，失去了自动化的意义。

有一个值得注意的点：文档里 3.3 是删除考勤记录，3.4 是考勤项目设置，3.5 是考勤统计表。按业务流程看，删除考勤记录是数据层操作，考勤项目设置是配置层操作，考勤统计表是报表层操作。这三层用例画在同一张用例图里不是问题，但开发时要明确它们的分层——配置驱动数据生成，数据驱动报表输出。

3.2 考勤统计表：报表类用例的三个必备参数

文档里的 3.5 考勤统计表只列了名字，没有展开参数。这是文档的先天不足，但也是你发挥的空间。我在实际项目里做考勤统计表，通常会配置这组筛选参数：

统计结果一般按员工维度汇总，输出字段建议包含：工号、姓名、部门、应出勤天数、实际出勤天数、迟到次数、早退次数、加班时长。这样一张表可以直接对接薪酬模块的“应发工资”计算。

这里补充一个我踩过的坑：考勤统计的截止时间。如果统计周期是 2025 年 3 月，很多人的第一反应是查create_time在 3 月 1 日到 3 月 31 日之间的记录。但考勤记录经常有补录——4 月 2 号补 3 月 28 号的卡。正确做法是查考勤日期字段落在 3 月的记录，而不是创建时间。

3.3 薪酬管理：文档最薄，但恰恰是最该补用例的地方

薪酬管理模块在文档里只有四个用例：修改薪酬信息、添加薪酬信息、删除薪酬信息、查看薪酬信息。这个深度对课程设计来说勉强够用，但放到真实业务里有一个明显缺口：没有薪酬计算用例。

薪酬信息的“添加”如果全靠手工录入，那系统就退化成 Excel 了。正常做法是薪酬模块从考勤统计表和员工薪资标准表取数，自动生成当月薪酬记录，HR 只需要在异常情况下手动调整。用例图上应该补一条“生成月度薪酬”的用例，由系统定时触发，也可以由 HR 手动触发。

补用例时的表达可以参考这种风格：

用例名称：生成月度薪酬 参与者：系统（定时触发）、HR（手动触发） 前置条件：考勤统计表已生成指定月份数据 主流程： 1. 系统读取指定月份的考勤统计结果 2. 系统读取员工薪资标准表中的基本工资和岗位工资 3. 系统按计薪项目和计薪系数计算加班费、扣款项 4. 系统生成薪酬草稿，状态为“待确认” 5. HR 确认后，薪酬状态变为“已发放”

这份文档没写这块内容，是因为它本身定位是“用例分析”，不是“详细设计”。但你在做系统时，不把这个补上，薪酬模块就是空中楼阁。

4. 招聘管理：十一页文档里藏着的完整业务闭环

招聘管理是这份文档当之无愧的重点，从 4.1 招聘计划管理到 4.4 招聘筛选管理，覆盖了计划、审批、储备、筛选、录用五条业务线。这一章能写这么细，说明原作者对招聘业务的理解是到位的，你要做的就是把这五条线串成一条完整的流程。

4.1 五条业务线的边界和连接点

先把文档里给到的招聘管理用例分布理一遍：

• 4.1 招聘计划管理：查看、添加、修改、删除招聘计划，添加、删除、修改、查看招聘信息。计划管理管的是“要招什么人、招多少人、什么时候招完”。
• 4.2 审批计划管理：审批计划、修改审批计划、删除审批计划、查看审批计划。招聘计划创建后要走内部审批流程，审批通过才能对外发布。
• 4.3 人才储备管理：添加、修改、删除、查看人才信息。这个模块管理的是候选人才库——可能是以前投过简历但没录用的，也可能是内推但暂时没有合适岗位的。
• 4.4 招聘筛选管理：添加、修改、删除、查询筛选信息，正式录用，删除、修改、查询录用信息。筛选和录用是招聘流程的末端。

这五条线的关系是：招聘计划经过审批后生成招聘信息，招聘信息对外发布后收集候选人简历，候选人通过筛选后进入录用环节，没录用的优秀候选人转入人才储备库。这是一个完整的闭环——储备库里的人才在下次招聘时可以直接复用，不需要重新走一遍发布流程。

文档的写法是每个用例单独列操作，这适合做需求追溯，但开发时你需要把它们串成状态机。招聘计划至少要有一个状态字段：草稿、待审批、已批准、已驳回、进行中、已完成。后面的操作要跟着状态走——只有“已批准”的招聘计划才能发布招聘信息，只有“进行中”的招聘信息才能添加筛选记录。

4.2 审批计划管理：容易被做成走过场的模块

4.2 审批计划管理在课程设计里经常被随意处理——审批人永远通过，流程形同虚设。但放在真实业务里，审批逻辑是招聘质量的第一道关口。审批计划时要看什么？预算够不够、编制有没有空余、招聘周期是否合理。这些信息分别来自财务系统的预算数据、组织架构的编制数据、历史招聘周期的统计数据。

从实现角度，审批计划管理对应的是一张审批流表，核心数据结构一般是：

CREATE TABLE recruitment_approval ( id INT PRIMARY KEY AUTO_INCREMENT, plan_id INT NOT NULL COMMENT '关联的招聘计划ID', approver_id INT NOT NULL COMMENT '审批人ID', approval_status TINYINT DEFAULT 0 COMMENT '0待审批 1通过 2驳回', approval_comment VARCHAR(500) COMMENT '审批意见', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_plan_id (plan_id), KEY idx_approver (approver_id) );

这里的核心设计是plan_id和approver_id都建了索引——招聘计划详情页要查审批记录，审批人的待办列表也要查未审批的记录，这两个方向都是高频查询。审批通过后要回写招聘计划表的状态，常见做法是在审批接口的事务里做两步：更新审批记录状态、更新计划状态。

文档里 4.2.2 是修改审批计划，这里要注意：审批记录创建后，审批人不能随意修改自己已经提交的审批结论。合理的设计应该是“修改审批计划”只发生在审批前——审批人发现信息填错了可以撤回重填，一旦提交并流转到下一步，修改入口就关闭了。这个边界不定义清楚，后面就会出现审批人把已驳回的计划改成已通过的脏数据。

4.3 筛选与录用：文本操作背后的状态流转

4.4 招聘筛选管理是整个招聘模块用例最密集的部分：添加筛选信息、修改筛选信息、删除筛选信息、查询筛选信息、正式录用、删除录用信息、修改录用信息、查询录用信息，八个用例对应一个完整的筛选流程。

筛选信息的常见状态线是：简历初筛 → 笔试 → 一面 → 二面 → HR 面 → 待录用 → 已录用 → 已入职。每个状态节点的操作权限不同，比如一面面试官只能把状态改为“通过一面”或“淘汰”，不能直接操作最终录用。

“正式录用”这个用例要特别留意。录用不是发个口头通知就完事了，它通常触发一系列动作：生成录用通知书、创建员工档案草稿、通知用人部门、记录预计入职时间。如果系统设计只做了“录用”这一个动作，后面这些联动没人处理，HR 还得手动去员工管理模块再录一遍新员工信息。

我见过一个比较顺的联动方案：录用时自动调用员工管理模块的“添加员工信息”接口，把候选人的基础字段带过去，生成一个“待完善”状态的员工档案。等员工正式入职后，HR 只需要补充岗位和薪酬字段，不用从头录入。

调用场景：招聘筛选管理 → 正式录用 → 创建员工档案 字段映射：候选人姓名 → 员工姓名，候选人手机号 → 员工手机号， 候选人应聘岗位 → 员工岗位，候选人期望薪资 → 员工薪资参考

这种联动逻辑在用例分析文档里一般不会写，但它恰恰是系统做得好不好用的分水岭。

5. 避坑与排查：这份文档我实际用下来遇到的五个问题

用例分析文档不是代码，使用时有很多细节不会直接告诉你。下面是我照着这份文档做系统时实际踩过的坑，按现象到原因到解决写出来，你碰到类似问题可以直接对号入座。

5.1 用例图里的“查看详细信息”和“查看员工信息”指向同一个页面

现象：画好的用例图里，“查看员工信息”和“查看详细信息”是两个用例，但开发时发现点列表里的员工姓名就直接进了详情页，两个用例对应的页面和接口是同一个。

原因：需求阶段没有限定“查看员工信息”的展示范围，开发默认列表点击就跳详情，相当于把两个用例合并了。但用例图里它们是分开的，需求评审时没人指出这个矛盾。

解决：在用例说明里补充明确约束。“查看员工信息”只展示列表表格，包含工号、姓名、部门、岗位、联系电话；“查看详细信息”展示完整档案，包含教育背景、工作经历、紧急联系人、合同信息。前端上，列表页点击行只展开一个只读抽屉，不去详情页。接口上，列表接口不返回教育背景等敏感字段，从数据层面兜底。

5.2 考勤项目设置里删除了一个项目，历史考勤记录全部显示异常

现象：把“加班结束”这个考勤项目从项目表里删掉后，历史考勤记录里所有加班结束时间都查不到了，报表统计加班时长时数据少了三分之一。

原因：考勤记录表里存的是item_id，项目删了之后关联不到名称，前端显示空值。这是典型的物理删除问题——配置项被删除，但数据项还引用着它。

解决：给考勤项目表加is_active字段，删除操作改为停用。查询时 JOIN 考勤项目表不限制is_active，保证历史记录永远能显示项目名称。新增的考勤登记只允许选择is_active = 1的项目。如果已经发生了物理删除，需要写一个数据修复脚本，从操作日志里恢复被删的项目记录。

5.3 审批计划管理里直接删除了审批记录，招聘计划状态卡死在“审批中”

现象：测试审批流程时，把一条“待审批”的审批记录直接删除了，结果对应的招聘计划状态一直停留在“审批中”，后面所有操作全部被状态机挡住。

原因：删除审批记录时没有同时更新招聘计划的状态。状态机设计里，“审批中”状态只能流转到“已通过”或“已驳回”，现在中间记录没了，状态没有出口。

解决：删除审批记录前校验招聘计划当前状态——只有“草稿”状态的计划允许删除审批记录；已经进入“审批中”的计划，只能通过“驳回”操作让状态回到“草稿”。代码里在删除接口加一个前置检查逻辑：

def delete_approval(approval_id: int): approval = RecruitmentApproval.query.get_or_404(approval_id) plan = RecruitmentPlan.query.get_or_404(approval.plan_id) if plan.status != "DRAFT": raise BusinessError("仅草稿状态的招聘计划允许删除审批记录") db.session.delete(approval) db.session.commit()

这个检查逻辑看着简单，但能堵住状态机最常见的漏洞。参数上注意，删除接口不能只传approval_id，必须查出关联的plan来校验状态。

5.4 用户管理和角色管理的编号层级错位，文档追溯对不上

现象：文档正文里 11.2.1 用户管理的下级是 11.2.1.1 到 11.2.1.4，但紧接着出现 11.3.1 角色管理，下级是 11.3.1.1 到 11.3.1.3。从层级关系看，角色管理应该是用户管理的同级，编号却差了一级。

原因：文档编辑时复制粘贴章节，没有统一调整编号。这类原始文档里常有，属于格式问题，不影响内容本身。

解决：使用前手动修正编号，把角色管理统一改为 11.2.2 系列。同时建议在项目文档里建立一张编号对照表，标注“原始编号与修正编号的映射”，方便团队协作时大家看的都是同一套编号，避免在会议上对齐需求时出现“你说的是哪个用例”的尴尬。

5.5 商品管理和订单管理出现在 HRMS 文档里，职责边界要特别留意

现象：文档后半部分出现了商品管理（入库、查看商品、查看购物车、删除商品、修改商品信息）和订单管理（销售订单、进货订单）。第一次看到的人会问：这不是人力资源系统吗，怎么突然做起电商了？

原因：这类文档通常是“统一管理系统”的项目分析，商品和订单是附加模块，给的是企业内部商城或积分兑换用的场景。也可能原始项目就是一个综合管理系统，HRMS 只是其中一个子系统。文档标题叫人力资源管理系统，但分析范围超过了 HR。

解决：使用时先确认你的项目范围。如果只做 HRMS，商品和订单模块的用例可以直接忽略；如果做的是覆盖 HR + 内部商城的统一系统，那要把商品和订单的参与者单独定义——普通员工在商品模块是“购买者”，在 HR 模块是“被管理者”，两种身份的权限要分开。建议在用例图里把商品和订单模块放在独立的包（package）里，和 HR 模块平行，而不是混在同一个参与者下面。

6. 进阶用法：拿到文档后如何扩展成用例规格说明书

这份用例分析文档覆盖了用例图的内容，但用例分析不止画图。如果你要让这份文档真正指导开发，我建议把每个用例扩展成一张规格说明表，包含六列：用例编号、用例名称、参与者、前置条件、基本流程、异常流程。以 3.1 考勤登记为例：

每扩展一个用例就更新这张表，全部完成之后，数据库表结构、接口列表、前端页面清单都能从这张表里推导出来。这是用例分析真正落地到开发的关键一步，也是文档里没写但你需要补的功课。

如果你要做更进一步的设计，可以试着从文档里已有的用例反向推导数据库表。比如员工管理模块的“查看详细信息”里提到了工作经历、教育背景、技能，对应就需要员工主表加三个子表。考勤管理模块的“考勤项目设置”里计薪系数要能对应到薪酬管理模块的“添加薪酬信息”，两边的数字口径必须一致。这类跨模块的数据映射，用一张字段来源表管理起来：

• 薪酬表.员工ID ← 员工表.ID
• 薪酬表.基本工资 ← 员工表.基本工资
• 薪酬表.加班费 ← 考勤统计表.加班时长 × 考勤项目表.计薪系数
• 薪酬表.绩效奖金 ← 奖惩管理模块.奖励金额

这份字段来源表的价值在于：它把十一个模块之间的数据依赖关系画了出来，开发时谁先谁后一目了然。就算你拿到的文档没有这些内容，自己动手补一遍，需求分析的功底会扎实很多。

还有一个值得做的事：把文档里“录用信息”和“员工信息”做关联验证。招聘筛选管理的“正式录用”用例会生成录用信息，员工管理模块的“添加员工信息”会创建员工档案。但文档没有说明录用信息和员工档案是同一份数据还是两份独立数据。正确设计是：正式录用时同步生成一份“待入职”的员工档案，员工档案表加一个candidate_id字段指向录用信息。这样员工入职后，他的招聘经历和员工档案就能串起来，以后做离职分析和招聘质量分析时不需要跨系统拼数据。

我自己的习惯是拿到这类文档后先不急着写代码，而是花一个晚上把每个模块的用例逐条做状态标注：哪些用例是纯表单操作，哪些会跨模块联动，哪些会触发后续流程。这份标注表做完，整个系统的开发顺序和接口依赖基本就清晰了。从那以后我每次做需求分析都会强制走一遍这个流程——先画用例图，再补规格说明，最后做跨模块字段映射。这套流程看着笨，但后面写代码翻车的概率会小很多。希望帮到你。

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