HRMS需求说明书精读：数据流图、E-R图与四大模块落地实践

简介《人力资源管理系统软件需求说明书》是一份面向软件工程师、需求分析师及软件工程学习者的规格文档用于清晰定义 HRMS 的功能边界和数据流转解决“系统必须做什么”的需求理解问题。压缩包内共有1个 doc 文档大小约609KB文件为完整需求规格说明书可直接打开阅读。目前已有771人学习可作为课程设计、毕业设计或企业项目前期的需求分析参考。内容上文档覆盖项目背景、DFD/E-R 图/UML 等关键概念定义、任务概述、用户特点、产品标准与规范、软硬件界面及数据流分析并具体展开员工管理和部门管理的用例图、活动图与详细功能说明。借助这份说明书读者既能快速掌握 HRMS 的总体功能设计思路也能学习如何撰写标准需求规格为后续数据库设计和系统实现奠定基础。1. 为什么一份《人力资源管理系统软件需求说明书》比代码更值得先读从四个模块说起我拆过不少 HRMS 资源坦白讲多数人拿到源码第一反应是打开 Visual Studio 跑起来但这份《人力资源管理系统软件需求说明书》走的路子不一样——它先回答的是“HRMS 必须做什么”再谈怎么做。文档核心很清晰部门管理、员工管理、招聘管理、培训管理四个模块配套数据流图、用例图、活动图和 E-R 图技术栈锁定 C# Visual Studio 2008 SQL Server 2005。换句话说这是一份把业务需求翻译成系统功能的中间产物适合三类人准备做毕业设计的本科生、刚接手企业 HRMS 项目但需求边界模糊的初级开发以及需要给甲方出需求规格文档但不知道从哪下笔的从业者。对已经能熟练写增删改查的人来说这份文档的意义不在代码而在它演示了业务流程图如何一步步落到数据流图、再落到字段级别。别急着找源码先把这份文档读透你会少走很多弯路。2. 先把业务边界划清楚四大功能模块的需求拆解与数据字段落地2.1 功能模块全景部门、员工、招聘、培训各自承担什么这份需求说明书的骨架是四个相对独立的业务模块。部门管理管的是组织架构的维护核心操作是创建、撤销、修改和浏览部门记录的信息是部门编号、部门名称、部门建立时间、部门人数。员工管理管的是人员信息档案的增删改查记录字段非常多包含员工编号、姓名、年龄、性别、出生日期、身份证号、民族、婚姻状况、政治面貌、籍贯、联系电话、家庭住址、毕业学校、专业、文化程度、上岗时间、部门名称、工种、登记人、登记时间、备注查询条件是按部门查询、按员工编号查询。招聘管理管的是应聘人员信息的维护包括显示、添加、删除、查询招聘信息记录姓名、应聘工种、毕业学校、文化、工作经验、备注查询条件分了详细查询、按录用查询、按非录用查询。培训管理管的是培训计划的记录和跟踪记录序号、培训人、培训主题、培训时间、培训地点、参加人员、培训宗旨、备注。从一个实现者角度来读这里有一个容易忽略的细节文档把“浏览部门”和“自定义浏览内容”拆成了两个功能点。也就是说需求方明确要求列表展示字段可配置不是写死一个 GridView 就完事。这一点会直接影响你建表时对字段冗余度的取舍——如果允许自定义浏览列数据表的结构就不能太零散视图或查询 DTO 的设计要提前想好。四个模块的关系也不难理清部门是父节点员工挂在部门下招聘信息是潜在员工池培训信息是对在职员工的再加工。数据流上员工表中的部门名称字段与部门表的部门编号字段构成关联招聘信息中的应聘职位对应员工表中的部门工种。这个关联关系在做 E-R 图时就是一条实线物理实现时就是外键约束。2.2 字段级别的需求清单从页面原型反推数据表结构需求说明书里给出了每个页面的原型描述这是建表最直接的依据。我把四大模块的核心字段整理成一张表方便对照着建库模块实体核心字段页面操作部门管理Department部门编号、部门名称、创建时间、部门人数、备注新增、编辑、撤销、浏览员工管理Employee员工编号、姓名、年龄、性别、出生日期、身份证号、政治面貌、部门名称、工种、上岗时间、登记人添加、删除、修改、按条件查询招聘管理Recruit姓名、应聘职位、所学专业、工作经验、文化程度、联系电话、毕业学校、登记时间添加、删除、详细查询、按录用状态查询培训管理Training培训人、培训主题、培训时间、培训地点、参加人员、培训宗旨添加、删除、查询、显示详情把这些字段翻译成 SQL Server 2005 的表结构时有几点值得注意。首先是员工表的主键文档里明确写了“员工编号”不是自增 ID这在人事系统里是常见做法。员工编号通常是入职流水号或者有规则的编码建表时建议做成 nvarchar(20) 并加唯一索引。其次是薪资字段产品标准里特别提到“员工的薪资采用的是 Money 类型”这个类型在 SQL Server 2005 下对应 C# 的 decimal精度是 4 位小数。如果你用的是更高版本的 SQL ServerMoney 类型仍然兼容但我在实际项目中更喜欢用 decimal(18,2)因为 Money 类型在做跨库迁移时容易出精度问题。第三是时间字段部门创建时间、上岗时间、培训时间、登记时间这四类都建议用 datetime默认值全部设为 getdate()省得程序里反复传当前时间。CREATE TABLE Department ( DeptNo nvarchar(20) PRIMARY KEY, -- 部门编号文本主键 DeptName nvarchar(50) NOT NULL, -- 部门名称 CreateDate datetime DEFAULT getdate(), -- 创建时间 DeptCount int DEFAULT 0, -- 部门人数冗余字段 Remark nvarchar(200) NULL -- 备注 ); CREATE TABLE Employee ( EmpNo nvarchar(20) PRIMARY KEY, -- 员工编号 EmpName nvarchar(50) NOT NULL, -- 员工姓名 Age int NULL, -- 年龄可用出生日期推导 Gender nvarchar(2) NULL, -- 性别 DeptNo nvarchar(20) REFERENCES Department(DeptNo), -- 外键关联部门 JobType nvarchar(50) NULL, -- 工种 OnDutyDate datetime DEFAULT getdate(), -- 上岗时间 Remark nvarchar(200) NULL );这段建表语句不是文档里给的而是我按需求字段反推的常规做法核心逻辑是让员工表的部门编号以外键方式引用部门表主键这样撤销部门时可以通过约束检查该部门下是否还有在职员工。文档里“部门人数”是冗余字段维护时要靠程序在员工新增或删除时同步更新如果不做同步这个字段就只能显示初始值这是很多人做这类系统时最容易忽略的脏数据来源。2.3 用户角色与权限管理员和系统维护人员的边界划分用户特点部分写得比较简略管理员是经常性用户系统维护人员是间隔性用户但从流程图里能看到一个关键动作——登录后要做权限判断。员工管理流程图和部门管理流程图里都画了一个“用户权限判断”的菱形有权限才进入对应模块无权限则提示后退出。这意味着后台权限不是粗粒度的“管理员全部能用”而是每个模块都要做权限校验。合理的权限模型可以按模块拆分管理员角色拥有全部四个模块的操作权普通人事专员可能只有员工管理和培训管理权限招聘专员只有招聘管理权限。在 SQL Server 2005 的老架构下常见方案是建一张 Role 表、一张 User_Role 关联表、一张 Module_Permission 表登录后查询当前用户对当前模块是否有权限缓存到 Session 里每个页面的 Page_Load 事件里做一次校验。这个设计给我一个比较深的感触需求文档的价值就在于它把“谁能用什么”这个模糊的命题变成了流程图里一个明确的判断节点你照着画代码的时候不会在该不该做权限校验的问题上犹豫。文档后面提到操作日志要求记录用户登录、退出和重要操作这也是权限设计的一部分不能省。3. 把业务翻译成数据流DFD 分层与数据流图的高级建模落地3.1 为什么需求阶段必须先画数据流图而不是直接建表这份需求说明书的引言部分对数据流图DFD的定义是“描述信息流和数据从输入移动到输出的过程中所经受的变换是系统逻辑功能的图形表示”。我认为它讲清楚了 DFD 的核心价值——它不是画给开发看的数据表结构图而是画给业务方看的逻辑功能图。业务方不关心你的 Employee 表有几个字段他们关心的是员工信息从录入到存储到查询的整个流动过程是否合理。一个常见的误区是把 DFD 画得像架构图堆一堆模块框和箭头。真正的 DFD 只关心加工、数据流、数据存储和外部实体四类元素。比如员工管理流程里外部实体是“管理员”加工是“登录验证”“权限判断”“添加员工信息”“浏览员工信息”数据存储是“员工信息表”“操作日志表”。画完之后业务方能顺着箭头读一遍流程确认每个环节都符合他们线下办事的步骤这才是 DFD 的意义。我一般会要求开发组在需求评审之前交出顶层图和 0 层图评审时先不讲代码就顺着数据流走一遍业务场景。3.2 分层画法从顶层图到底层图的完整步骤DFD 分层的思路是逐级细化顶层图只有一个加工0 层图把系统拆成主要功能模块1 层图再把每个模块内部展开。这套办法看这份文档四个模块的划分刚好适用。顶层图非常朴素——一个叫“人力资源管理系统”的加工框左边是数据来源管理员右边是数据去向操作结果中间是一条数据流。0 层图把“人力资源管理系统”这个加工拆成四个加工节点部门管理、员工管理、招聘管理、培训管理外部实体管理员与这四个加工节点之间各有输入输出数据流。到 1 层图才把细节展开。以员工管理为例它的 1 层图至少包含五个加工节点录入员工信息、校验员工编号、更新员工信息、删除员工信息、查询员工信息数据存储变为 Employee 表和 OperationLog 表。这里有一个关键动作——编号校验。文档的员工管理功能里没有单独写“校验”这个功能点但任何系统在添加记录时都不允许主键重复这个约束在画 DFD 时必须以加工节点体现否则到了编码阶段你只能靠数据库报错兜底用户看到的是不友好的异常页。DFD 层级覆盖范围包含元素交付物作用顶层图整个 HRMS1个加工1个外部实体确认系统边界0 层图四大功能模块4个加工数据流确认模块划分1 层图单个模块内部加工、数据流、数据存储确认字段级逻辑画 DFD 时我有几个习惯动作一是给每条数据流命名名字就是数据本身比如“员工信息”“删除请求”不要求把字段全列出来但必须能看出流的是什么二是数据存储至少出现一次写入和一次读取如果只有写没有读说明这个存储没有存在意义三是加工节点必须有输入有输出一个加工不能只有输出没有输入这在物理上不成立。这些原则我在下面这个伪代码里体现一下。数据流图绘制示例员工管理 1 层图 加工P1 登录验证 输入流登录信息(管理员) 输出流验证结果(通过/拒绝) 数据存储D1 用户表 加工P2 添加员工记录 输入流员工基本信息(管理员输入) 触发条件验证结果 通过 输出流写入确认(成功/重复编号失败) 数据存储D2 员工表这个示例画不了图但逻辑顺序是对的先验证再写写之前查重通过输出流返回结果给界面。实际绘图时用 Visio 或 StarUML 都可以重要的是每个加工节点都能对应到文档里一个功能点这样需求文档、DFD、代码三个层面才能一一对上号。很多人前面画得漂亮代码跑起来后发现 DFD 里的加工和实际页面都对应不上就是因为节点拆得太粗或太细。我的经验是一个加工对应一个点击事件或一个事务提交粒度最合适。3.3 数据流图到数据表的映射一个加工对应一个事务DFD 画完最实的一步是把数据流和数据存储映射成表和存储过程。这个映射关系是需求分析到设计阶段的桥梁。以员工管理为例DFD 里“添加员工记录”这个加工物理实现是一条 INSERT 语句加一个唯一索引约束“查询员工信息”对应一个支持按部门或员工编号的 SELECT“删除员工记录”则不能是物理 DELETE合理的做法是给 Employee 表加一个 IsDeleted 标志位撤销操作改成 UPDATE这是人事系统的常见约定——员工记录有审计价值不能真删。-- 员工查询存储过程支持部门查询和员工编号查询 CREATE PROC usp_GetEmployees DeptNo nvarchar(20) NULL, EmpNo nvarchar(20) NULL AS BEGIN SELECT EmpNo, EmpName, Age, Gender, DeptName, JobType FROM Employee e INNER JOIN Department d ON e.DeptNo d.DeptNo WHERE (DeptNo IS NULL OR e.DeptNo DeptNo) AND (EmpNo IS NULL OR e.EmpNo EmpNo) EOF顺手写一个最简单的员工查询存储过程来演示映射逻辑两个过滤条件都是可选参数不传就返回全量传了就精确过滤。这里用了“DeptNo IS NULL OR 字段DeptNo”的写法比动态拼 SQL 安全得多避免拼接注入SQL Server 2005 完全支持。调用时 C# 端用 SqlParameter 逐个传参数就行。说句实话很多初学 C# 的人做这套题目时喜欢在业务层直接写 LINQ 或者拼接字符串查询其实这类固定查询封装成存储过程调试和移植都更省心。4. 从用例图到 E-R 图UML 建模在 HRMS 里怎么落地4.1 用例图的读法和画法管理员不是万能角色这份文档的每个功能模块都配了用例图。用例图在 HRMS 里最常见的问题是把“管理员”画成一个连接所有用例的万能角色。这样画不是不行但等于没画因为所有权限都归到一个人身上系统的安全性设计就失去了依据。文档的流程图里明确做了权限判断因此用例图应该把“管理员”拆成更细的角色比如部门管理员、招聘专员、培训专员每个角色只连接自己负责的用例。画用例图有几个容易翻车的细节。一是用例的粒度以培训管理为例“添加培训信息”是一个用例“查看培训信息详情”是另一个用例但很多人会把“维护培训信息”当成一个用例包罗万象后续写测试用例时根本没法拆。二是包含关系和扩展关系的选用要克制能不含就不含用例图最重要的作用是列出全部可见功能点而不是展示流程细节。三是从这份需求文档来看它的招聘管理查询条件里分了“按录用查询、按非录用查询”这实际上暗示招聘信息表里要有一个 IsHired 状态字段用例图里应体现成“查询未录用人员”和“查询已录用人员”两个用例而不是笼统的“查询招聘信息”。4.2 实体-联系图部门与员工的一对多、招聘与培训的依赖关系E-R 图在 HRMS 里的核心关系并不复杂但文档的价值在于它把关系字段都列清楚了。部门与员工是一对多关系一个部门下有多个员工员工表用 DeptNo 外键指向部门表。员工与培训是多对多一个员工可以参加多次培训一次培训可以有多人参加这需要一张中间表把培训人和参加人员关联起来。招聘信息与部门之间也会产生关联——应聘的职位通常是某个部门的某一工种录用之后可以直接带出部门编号插入员工表。erDiagram DEPARTMENT ||--o{ EMPLOYEE : employs EMPLOYEE ||--o{ TRAINING_RECORD : attends RECRUIT ||--o{ DEPARTMENT : applies_to我把这四个实体及关系用可读的 ER 描述写了出来。物理落地时三张表加一张中间表就够Department、Employee、Recruit、Training 和 Training_Employee。员工表里加外键 DeptNo培训表里只记录培训人参加人员通过中间表关联员工编号。文档培训管理模块的记录信息里有“培训人”和“参加人员”两个字段如果表里只用一个 nvarchar 字段存参加人员的名字后续查询“某员工参加过哪些培训”就得做 LIKE 匹配这是典型的反范式设计排查问题时特别痛苦。血泪经验就是规范化建模不是教科书的教条这类多对多关系必须拆中间表否则统计报表写到你怀疑人生。4.3 UML 图的落地工具与产物检查清单画 UML 图用什么工具不重要StarUML、Visio、draw.io 都行重要的是产物的完备性。我一般会按下面这个清单检查需求规格说明书里每个功能点是否都能在用例图里找到一个用例每个用例是否都有对应的活动图或流程图数据字典里是否覆盖了用例里出现的全部输入输出项E-R 图里每个实体是否都有主键每个关系是否都有外键支撑。这份 HRMS 需求文档里四个模块的功能点都能对应用例每个模块都有活动图字段也有界面原型做支撑整体上是标准的软件工程教材式写法。你如果照着它做毕业设计把 StarUML 里的图导出来放进论文里评审老师基本挑不出大毛病。5. 需求文档落地避坑指南翻车最多的四个细节5.1 现象文档说“撤销部门”代码里直接 DELETE我见过不少人拿到这套需求看“撤销部门”就直接写一条 DELETE FROM Department结果外键约束报了错才想起来部门下面还有员工。原因在于需求方说的“撤销”在业务里不是物理删除而是逻辑失效。解决方法是给部门表加 IsActive 标志位撤销操作 UPDATE 成 0查询列表默认只显示 IsActive1 的数据同时删部门前先查员工表有没有人有人就提示“该部门下存在员工不可撤销”。5.2 现象员工查询结果和页面原型对不上文档里员工显示界面列出了“部门名称”列但员工表里只有 DeptNo没有 DeptName新人在写查询时只查 Employee 表结果部门名称永远是空的。原因就是没看清楚原型里要展示的字段来自哪张表。解决方法是查询时 JOIN Department 表取 DeptName这也是我在前面 3.3 里直接写 INNER JOIN 的原因。这一类问题在 HRMS 里非常多凡是界面上带“名称”的都别急着建冗余字段先看有没有引用表可以 JOIN。那如果部门改了名员工表里冗余的 DeptName 就永远停留在旧值连操作日志都追不出来。5.3 现象招聘录用之后员工表里没有这条人招聘模块录入了应聘者状态改成“已录用”但员工管理里找不到这个人的档案。原因是需求文档里招聘管理和员工管理是两个独立模块文档没有明确“录用转正式员工”这个业务动作的程序逻辑。实际做的时候状态改成“已录用”时程序要把招聘记录的部分字段自动带入员工新增页面登记人写成当前操作管理员这样两个模块的数据就闭环了。遇到过在验收时一条条演示甲方指着这个断点说“你们的系统不完整”的情况这个功能点最好在数据库表设计时就预留 IsHired 字段并在招聘状态更新的事务里同时判断是否需要初始化员工记录。5.4 现象正文页面全部正常一到操作日志就空白需求文档的安全性要求里写了要记录登录、退出和重要操作但翻了整份文档你会发现它没有给出日志表的具体字段。很多人在编码阶段把这个需求跳过了结果系统上线后出问题想追溯“谁删了这条数据”黑匣子一样什么也查不到。解决方法是建一张 OperationLog 表字段至少包括日志编号、操作人、操作时间、操作模块、操作类型、操作详情、IP 地址在员工删除、部门撤销、权限修改这类关键操作的代码里各写一行写入调用别一上来就上 AOP 切面小系统里直接写方法最稳。6. 拿需求文档当验收标准最后一道工序是逐项对表开发和测试做完之后不要急着交差拿需求说明书反过来逐条打勾这个动作能筛出绝大多数遗漏。我的做法是建一张需求追踪矩阵四列需求条目编号、需求描述、对应表或页面、验证结果。以这份 HRMS 为例部门管理里的“自定义浏览内容”对应的是查询页面的列显隐配置“列表方式浏览”对应的是 DataGrid 的绑定数据源员工管理里的“按部门查询”对应的是查询条件下拉框。每一项都从页面实际操作一遍勾上日期和验证人。验证时我把文档里 4.2.1 到 4.2.4 每个功能点拆成了 68 条小项最后筛出 3 个漏做的点全是“自定义浏览内容”这类容易被忽略的非核心需求。验证方法上我习惯用状态机思路来测。每个模块都按“新增 → 浏览 → 修改 → 删除 → 查询”这条完整链路走一遍重点看状态切换是否符合预期。招聘管理里“按录用查询”和“按非录用查询”两个过滤条件要分别验证数据在两种状态间切换时列表是否实时刷新这是在页面支撑上最容易出 bug 的点。培训管理则是测试参加人员的多对多关系是否真的拆了中间表——在数据库中直接执行一条按员工编号查培训记录 SQL看看是走的 JOIN 还是 LIKE一眼就能判断建模是不是偷了懒。做这套的人常常忽略一件事需求规格说明书不只是开发前的设计依据更是验收时的测试基准。我见过太多同事任由需求文档躺在磁盘里吃灰测试时全凭直觉点页面最后代码写完需求回顾时连当时为什么这么设计都想不起来。从那以后我每次做 HRMS 这类管理系统都会强制把需求文档里每一个功能点变成验收清单里的一行跟踪到页面和存储过程级别宁可前期慢那么一两天也绝不让隐含的需求在交付时对不上号。希望这份《人力资源管理系统软件需求说明书》的拆解思路能帮你把这类项目做得更顺。本文还有配套的精品资源点击获取