企业官网建设流程全解析

简介：压缩包内是一份完整的《集团人力资源管理系统》用户需求说明书，主要面向需求分析、设计、开发与测试人员，用于帮助团队明确系统功能边界、业务流程与数据规范。包内共1个doc文档（人力资源用户需求文档.doc），大小5.72MB，便于按需查阅。目前已有96人学习。文档涵盖项目背景、文档目的、模块命名规则、模块汇总与模块设计等章节，系统性地通过用例描述时间、地点、起因、经过与结果，区分用户角色、系统角色等参与对象，并配合流程图、时序图、协作图说明交互流程；同时对字段含义、要求、约束、格式及异常处理机制进行了详细整理。此外，说明书涉及KPI、BSC、MBO、360度考核、532绩效考核模型等常见术语解释，可帮助团队统一认知，直接支撑产品规格说明书编写以及后续开发测试、验收评估工作的开展，助力项目按计划推进。

1. 人力资源用户需求文档：别让它变成业务方的“许愿池”

我见过的“人力资源用户需求文档”里，最常见的一种是十几页里一半是系统截图，另一半是“希望系统能自动统计考勤”这类愿望。真正能落到开发验收的条件，只剩两三条。人力资源用户需求文档，说白了就是需求工作流里的 URD，解决“HR 业务到底要什么、不上线会出什么事”这两个问题。它不回答按钮怎么摆、表怎么建，而是一份业务方和研发之间提前谈好的契约。载体是 .doc 还是线上文档，不重要；重要的是结构能不能支撑后续的研发。适合看这篇的人：刚接手 EHR/HRMS 模块的产品和研发，做薪酬、考勤、招聘外包的个人开发者，以及被安排去“整理需求”的运维同学。

2. 术语表、角色权限和边界：先把需求文档的三层骨架搭出来

2.1 从术语表开始：HR 行话不定，评审会当场翻车

HR 是我见过黑话密度最高的业务领域。考勤周期、薪资项、加班结算、HC、编制、结转，任何一个词不写定义，评审会现场就会出现三种理解。拿“结转”来说，有人认为是年假顺延到第二年，有人认为是未休年假折成工资，还有人认为两种都算。研发按其中一种做了，上线后另一个部门说完全不对，这种返工成本很肉痛。

术语表不用很长，把文档里每一个业务词给一句“定义 + 数据来源 + 口径示例”就够了。最容易漏的是“薪资项不能随意删除，历史薪资要保留”这类话。它表面在解释术语，实际在定数据保留策略。这里有个黑匣子要特别注意：HR 现有的 Excel 表头就是术语的第一来源，不要把这个黑匣子里的字段名随便换个名字继续用，等研发对着旧表做数据迁移时会全部对不上。

具体做法分三步：

1. 找 HR 现有的考勤制度、薪酬制度全文，把名词对应的 Excel 表头抄下来。
2. 约 30 分钟访谈：问考勤专员“月底对账你怎么做”，问招聘专员“HC 什么时候进入编制报表”。
3. 把访谈得到的答案写进术语表的“口径”列，而不是只写字典式定义。

术语表示例：

术语表完成的标志是：发回给业务方，对方看到某一条说“这不是我们说的意思”。没有歧义的术语表反而值得怀疑，说明很多口径被默认了。

2.2 角色与数据权限：权限不只写到菜单，要写到数据行

HR 系统的权限是敏感地带。需求文档里如果只写“考勤专员可查看薪酬报表”，上线第二天就会出问题：薪酬专员能看到全公司所有部门工资，考勤专员也能顺手看到别人的薪资明细。HR 业务方的角色其实不复杂，按典型的小型 EHR 系统划分：

• 员工：只能看自己的个人档案、余额、申请记录；
• 直属主管：看本部门下属的审批与出勤；
• HRBP：看所辖组织范围，通常跨部门；
• 考勤专员：看全局并做数据修正；
• 薪资专员：只处理薪资项的“计算”和“核对”，工资明细默认只开放给本人。

需求文档里权限描述不能只写“有/无查看”，要写“数据范围”。“考勤专员可查看全局考勤记录并执行补卡、修正；部门主管只能查看本部门数据，不可修正”。这个句式看似只是多了半句话，但落库实现时对应的是行级数据权限，而不是一个菜单开关。

角色权限矩阵表：

矩阵生成方式很简单：列出系统内所有业务对象，逐行写“角色 + 能做什么 + 数据范围”。这页矩阵是评审会必过的一页，别为了省地方只写“按组织架构控制权限”，那是把定义工作丢给开发。

2.3 明确边界与“不做”的需求：没有边界条款，文档就是需求无底洞

“不做什么”这一段往往是整份文档里最空的一节。常见写得好一点的只有一句“本期不实现与一卡通厂商对接，接口留待二期”，大部分文档连这句都没有，于是所有被当场口头答应的事都成了二期承诺，而且没有写在纸上。

边界清单至少要覆盖三类东西：

1. 明确不接的硬件或平台：打印控件、考勤机、企业微信的某些组件；
2. 不做的特殊规则：如“停薪留职期间假期暂停累计”“跨子公司的假期额度合并”这类少数派规则；
3. 历史数据不保证完整迁移：迁移策略单独成节，见第 5 章避坑条目。

有了边界以后，业务方再提“能不能顺带把考勤机也接了”，标准回复是“请查文档第 2.3 节，不在本次范围，加变更流程走需求单”，而不是当场口头承诺。边界不是把需求做小的借口，是防止需求无底洞的最后一道闸。这道闸不立起来，前面所有流程拆分都白做。

3. 把“请假审批”拆成五条需求记录：一套可直接套用的模板

3.1 用业务事件驱动需求拆解：角色、触发、规则与结果

很多需求文档按菜单页写功能，比如“请假管理页：需要能提交、能查询、能修改、能删除”，这是把需求拆成了按钮。按钮拆法到了开发阶段会发现，真正复杂的是状态流转。建议改成按“业务事件”拆：谁、在什么条件下、执行什么动作、产生什么结果。一个“员工提交年假申请”的事件，就包含角色、触发条件、异常路径和后置结果。事件写法会逼出边界——比如“主管驳回后是否允许员工再次提交”这种异常路径不写清楚，测试用例根本没法设计。

这里有个新手特别容易忽略的点：HR 系统的“用户”往往不是一个人。“请假审批”这个功能背后至少站着员工、主管、HRBP、薪资专员四个角色，而一个功能至少对应五个事件。从菜单拆，只能写出“审批”两个字；从事件拆，“审批”才会变成“主管查看待办→通过→通知薪资计算”。事件拆法天然要求把角色和数据范围放到一起考虑，这比任何模板字段都重要。

3.2 五条需求记录示例：字段、优先级与验收标准

给一个最小可用的需求记录模板，关键字段有四个：

• 需求编号：模块缩写-功能类型-序号，如 HR-FN-01，后面表格引用时不会再说“这个需求”“那个模块”；
• 优先级：P0 是取消就停业务，P1 是短时间可手工替代，P2 是体验优化，P3 是暂不排期；
• 验收标准：写数字和规则，不写“流畅、便捷、友好”；
• 关联页面：只做提示作用，页面本身不是需求。

拿“请假审批”拆成五条需求记录，直接可抄：

这张表里最重要的不是“业务规则”列，而是“验收标准”列。像“剩余额度不足，系统提示并阻止提交”这种写法，测试拿到后可以直接转成用例，不用再回来问“提示什么文案、阻止到什么程度”。

提示：不要迷信模板字段齐全，真正决定需求文档质量的是验收标准能否写进测试用例。

3.3 用一条 SQL 核对额度计算：需求规则和数据实现之间加一层验证

需求文档写完后，我习惯把“额度计算”这种高风险规则做成一条可执行的校验 SQL，交给薪资专员或 DBA 在测试环境离线跑一遍。价值不是秀技术，而是在需求阶段就把“额度口径”查出来了：到底是按小时还是按天，结转算不算已用额度，历史已休假数据有没有超标。

-- 核对某考勤周期内已审批年假时长是否超过员工年度额度 SELECT e.employee_no AS 员工编号, e.employee_name AS 员工姓名, e.annual_leave_quota AS 年度额度小时, SUM(CASE WHEN a.leave_type = 'ANNUAL' AND a.approval_status = 'APPROVED' THEN a.period_hours ELSE 0 END) AS 已审批年假小时 FROM hr_employee e LEFT JOIN hr_leave_application a ON a.employee_id = e.id AND a.leave_date BETWEEN '2025-01-01' AND '2025-12-31' GROUP BY e.employee_no, e.employee_name, e.annual_leave_quota HAVING SUM(CASE WHEN a.leave_type = 'ANNUAL' AND a.approval_status = 'APPROVED' THEN a.period_hours ELSE 0 END) > e.annual_leave_quota;

参数说明：annual_leave_quota假设存的是小时，如果员工表里存的是“天”，需要把period_hours统一成同一单位后再比对。leave_date的过滤范围要和公司的年假年度口径一致，按入职周年计算的不能写死自然年。这条 SQL 在需求阶段用来清洗 HR 给的历史 Excel 数据，查出“已休假超过额度”的员工，再回头找业务方确认是口径错误还是历史数据问题。数据量不大，直接跑 MySQL 8 测试环境即可，不需要建索引优化。

4. 流程图、字段清单与 SRS 衔接：让文档能交给研发

4.1 不画图怎么表达流程：给一张流程节点表

需求评审会最爱出现的一幕：业务方在白板上画流程图，画了改改了画，最后手机一拍发群里。图没错，错在只画了主流程，驳回、撤回、超时这些异常路径要么没画，要么画完根本看不出走的是哪条分支。我习惯把流程写成流程节点表，一行一个节点，每个节点都写前置条件和分支去向，评审时逐行对，研发也不用把图再重新理解一遍。

以上一节的请假审批为例，流程可以写成：

这个表本身就是需求文档里“业务流程”章节的最小内容。它和画出来的泳道图等价，但逐行可审，业务方能逐行确认“分支为什么这样分”。流程图有用的前提是能和节点表对得上，对不上时一律以文字为准。

4.2 字段清单：把页面上每个输入框定义成数据项

HR 需求文档里最容易被忽略的是字段定义。比如“请假时长”不写单位，员工填 2，是 2 天还是 2 小时完全凭猜；“开始日期”到了跨天请假场景，要不要拆成“开始日期 + 结束日期 + 时长”又得在开发时吵一轮。与其让研发猜，不如在需求文档里固定一个业务对象清单。以“请假申请”为例：

字段清单需要和术语表成套出现。“考勤周期”的定义决定“请假时长”落在哪个周期，字段定义又反过来影响术语表。需求文档的完整度，就看这两张表能不能互为印证。如果 HR 已经有纸质表单和 Excel，再逐一核对一遍旧表单字段，能防止“新旧表字段类型不同步”这种看起来很低级、上线却要返工的问题。

4.3 从 URD 到 SRS：谁来把需求翻译成系统行为

看完一份“人力资源用户需求文档”，研发直接上手写代码还是有障碍，因为 URD 说的是“业务要什么”，SRS 说的是“系统做成什么”。很多中小团队把两者合并成一份文档，这没有错，但既然合并，至少要补上状态机描述、接口约定、缓存策略、数据归档这些系统行为。如果团队决定分开，URD 定稿后，产品负责人还需要再花一个迭代去补 SRS，研发才能进场。

给需求质量做快速抽检，我会用 Excel 公式扫一遍验收标准列，把主观词挑出来，要求需求负责人逐条改成数字：

=IF(SUMPRODUCT(--ISNUMBER(SEARCH({"友好","合理","流畅","尽量","及时"},C2)))>0,"需要改写","可进入评审")

参数说明：C2是验收标准所在单元格，需要按自己表格的实际列调整；关键词数组可以自定义，凡是出现“友好”“合理”“流畅”这类无法测试的词就返回“需要改写”。这个公式只是一个提示，不替文档做决定，但它每次都能扫出几条“加载流畅”之类的返工项，比人工逐字看要省时间。扫完这一轮，再往下走，才不会出现“需求文档已经签收、开发读不懂”的悬案。

5. 人力资源需求文档避坑：五条高频踩坑和一张走查清单

5.1 招聘需求只写“岗位描述”，漏了流程截点

现象：需求评审时业务方说“我们急需招人”，研发追问“入职以后要做什么”，发现新增员工账号开通、导师分配、合同签署都没有写进需求。

原因：招聘模块的需求在文档里只写了“发布职位、收简历”，把“招聘”当成了静态列表，漏掉了“新员工入职”这条链路上的所有截点。

解决：把“新员工入职”单独拆成需求条目：offer 确认 → 创建员工档案 → 开通系统账号 → 分配组织与职级 → 通知薪资专员。每个截点都要有责任人和时限。新人入职最怕“工号没生成，所有系统都登不上”，需求文档里没有这个流程，研发只能自己发挥，发挥出来的流程大概率不是 HR 要的。

5.2 权限描述只到菜单级，专员之间互相可见全公司工资

现象：上线后，某考勤专员打开薪酬报表看到全公司薪资，虽然他只想查本部门新员工的入职薪资。

原因：需求文档只写了“考勤专员可查看薪酬报表”，没限定数据范围。权限矩阵写起来像玄学，实际是数据范围没有落到行级。

解决：权限矩阵里加“数据范围”列，按第 2.2 节那张矩阵逐角色核。HR 数据按“本人、本部门、所辖组织、全局”四级收敛，报表默认只展示当前用户有权限的数据行。这是需求文档里最容易省的一页，也是最容易炸的一页，评审时别跳过。

5.3 把“现状截图”当流程，系统变成 Excel 复刻

现象：开发拿到需求文档照截图完成了页面，业务方试用后说“不对，我们实际是先打电话确认再提交的”，主流程立即返工。

原因：截图只表达界面形态，不表达业务动作。业务方写文档时习惯截图，真正的逻辑藏在口头约定里。

解决：在文档开头加一条约定：“截图仅用于展示信息，一切业务规则以文字需求为准。若图片与文字冲突，以文字为准。”这条约定能让截图回归辅助材料，而不是被当成需求本体。

5.4 历史数据迁移只字未提，上线那天余额从零开始

现象：EHR 系统切换当天，员工发现年假余额全部清零；老系统的考勤记录没有导入，薪资核算只能手工补两个月。

原因：需求范围没有包含“数据迁移”，或者只提了“把旧数据导过来”，但没有清洗规则和迁移验证标准。

解决：在边界章节单列“历史数据迁移”，写明迁移对象（员工档案、考勤记录、未休年假、历史薪资单）、清洗规则（重复员工、离职再入职）、验证方式（迁移后行政部选取样本核对）。这一节不写，上线就变成重建历史现场。

5.5 验收标准写“体验友好”，测试用例没法写

现象：测试拿到需求“审批体验要友好”，不知道友好是几秒，用例无法落地。

原因：验收标准用了形容词，没有绑定可测量指标。

解决：约定验收标准必须满足“可以直接写成测试用例”。把“加载流畅”改成“首页加载不超过 3 秒，提交后 1 秒内出现成功提示”；把“支持批量审批”改成“列表勾选 20 条申请单后可一键通过”。“友好”这类词可以出现在目标里，不能出现在验收标准里。

5.6 走查清单：把踩坑经验倒成问题

踩坑之后，我养成了一个习惯：评审前拿一张走查清单逐条过文档，直接把经验倒成问题。这张清单可以当评审会的第一页议程：

走查清单放到团队共享目录，版本号随需求文档一起走。它本身不是需求，是给需求做体检的工具。体检不过，不进评审。

6. 用一轮评审、两轮追问收口：怎么验证文档可以签收

6.1 书面评审清单

正式评审会后不要直接签收。我的做法是把评审变成“过清单”：术语表、权限矩阵、边界、异常流程、字段定义、验收标准六样逐项过，每一项必须有 HR 业务方和研发两方的点头记录。这份记录就是签收依据。人力资源需求文档最容易出的问题不是没写完，而是没人承认它写完了。

6.2 两轮追问能挖出非功能需求

签收前对业务方做两轮追问。第一轮问“明确不做什么”，把边界再念一遍。第二轮问“频率和量”：考勤专员每月核几次数据？高峰在什么时候？把“每月 800 人次、集中在最后两天”这类回答量化后写进非功能需求：审批列表支持 500 条分页，审批页面响应时间小于 3 秒。这类追问能挖出文档正文里漏掉的大量性能规则。

6.3 签收后隔天回访一次

最后再等一天，第二天拿同一份文档回去找 HRBP，用最朴素的一句话问：“这一版和你们的现实有没有对不上的地方。”这类回访做过不止一次，最常见的修订原因是“我们子公司间假期不共享，文档里写成了共享”。因为这一句话，避免了模块上线后的返工。把回访结果直接追加到文档修订记录，标注“回访日期 + 修改内容”。

我后来养成的习惯是：没有经过一轮正式评审和两轮追问的文档，从不当成可开工的依据；宁可晚两天签收，也不要上线前去补救“当初没说”。希望帮到你。

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