2. 企业健康管理业务需求分析

企业健康管理平台的需求分析，不能从“我要一个健康档案模块”这样的功能清单出发，而应从企业真实运行的健康业务场景出发。企业健康管理的核心业务场景通常围绕五条主线展开：员工健康档案、体检管理、健康风险评估、干预服务、福利运营。这五条主线并非彼此独立，而是共享同一份员工健康数据，并在不同阶段产生新的数据与状态。需求分析的任务，就是把这五条主线上的对象、角色、数据、规则和状态变化梳理清楚，再转化为可建模的需求。

一、五条核心业务主线的对象与数据

员工健康档案是基础数据层，记录员工的身份标识、部门、岗位、既往病史、过敏史、家族史、生活方式（吸烟、饮酒、运动、睡眠）等相对稳定的信息。体检管理产生周期性数据，包括体检批次、体检项目、各项指标值、异常标记和体检报告。健康风险评估基于档案与体检数据，输出风险等级、风险因子和风险趋势。干预服务针对风险结果，产生干预计划、随访记录、完成状态。福利运营则记录福利项目、额度、使用记录和兑换状态。

这五条主线共享一个关键主键：员工唯一标识。所有业务数据都必须能回溯到具体员工，否则档案无法关联体检，体检无法驱动评估，评估无法触发干预。需求建模时，第一件事就是确认这个主键在各部门、各系统之间是否一致。

二、需求建模方法：从场景到用例再到数据模型

需求建模建议采用“场景—用例—数据模型”三层推进。第一层是场景描述，用业务语言写清楚谁在什么条件下做什么事、产生什么结果。例如：“体检机构在体检完成后三个工作日内上传体检报告，系统自动解析异常指标并标记，若员工存在三项及以上异常，则触发健康风险评估任务。”这句话里已经包含了角色（体检机构）、触发条件（体检完成）、时间约束（三个工作日）、数据动作（上传、解析、标记）、业务规则（三项及以上异常）和后续动作（触发评估）。

第二层是用例建模，把场景转化为系统用例。每个用例应明确参与者、前置条件、主流程、异常流程和后置条件。以“体检报告上传”为例，参与者是体检机构接口或HR管理员；前置条件是员工档案已存在且体检批次已创建；主流程是上传文件、解析字段、匹配员工、写入体检记录、计算异常标记；异常流程包括员工匹配失败、指标缺失、重复上传；后置条件是体检记录状态变为“已归档”，并可能触发评估任务。

第三层是数据模型，把用例中涉及的对象抽象为实体和关系。核心实体包括员工、体检批次、体检项目、体检指标、风险评估、干预计划、随访记录、福利项目、福利使用记录。实体之间的关系需要明确基数和可选性：一个员工可以有多条体检记录，一条体检记录包含多个体检指标，一次评估对应一个员工和一个评估时点，一个干预计划可以包含多次随访。

三、关键业务规则与状态流转

需求分析中最容易被忽略的是业务规则和状态流转。体检记录通常有“待上传、已上传、解析中、解析成功、解析失败、已归档”等状态；干预计划有“待开始、进行中、已完成、已终止”等状态；福利使用记录有“已领取、已核销、已过期”等状态。这些状态不是装饰，而是驱动后续动作的条件。例如，只有“解析成功”的体检记录才能参与风险评估；只有“进行中”的干预计划才允许新增随访记录。

另一个关键规则是权限与隐私。健康数据属于敏感个人信息，需求中必须明确：员工本人可查看自己的档案和体检报告；直属主管只能看到团队聚合数据，不能看到个人明细；HR健康管理员可查看全量数据但操作需留痕；体检机构只能写入本批次数据，不能读取历史档案。这些权限规则应在用例和接口层面同时约束，而不是只写在文档里。

四、需求优先级与迭代切分

五条主线不可能一次性全部上线。合理的切分方式是：第一迭代先做员工健康档案和体检管理，因为它们是数据基础；第二迭代加入健康风险评估，依赖前一步的体检数据；第三迭代做干预服务，依赖评估结果；福利运营可以并行或稍后接入，因为它对档案和评估的依赖相对较弱。每个迭代都应交付可验证的业务闭环，而不是只交付页面。

需求分析的最后一步是确认验收标准。例如，体检报告上传用例的验收标准可以写成：给定一份包含20项指标的体检报告，系统应在30秒内完成解析，正确匹配员工，标记出所有超出参考范围的指标，并在解析失败时给出可定位到具体字段的错误提示。这样的标准才能让开发和测试对需求有一致理解。