3. 食品行业合规与标准约束
在食品工厂数字化项目中，需求分析最容易犯的错误，是把合规要求当成“上线后再补”的附加项。事实上，食品安全法规、追溯要求和数据完整性这三类约束，往往直接决定系统能不能上线、哪些数据必须采集、哪些环节不能省、哪些记录不能改。它们不是需求清单里的普通条目，而是需求边界的“硬边框”——边框之外的功能再漂亮，也可能因为不满足合规而被否决。
一、法规约束如何转化为系统需求
食品安全法规对数字化的影响，核心不在于“有没有系统”，而在于“关键控制点是否被系统化地记录、监控和可证明”。以危害分析与关键控制点（HACCP）体系为例，法规要求企业识别生物、化学、物理危害，设定关键控制点（CCP）及关键限值，并持续监控、纠偏、验证。落到需求上，这意味着系统必须能对每个CCP设定限值、按频率采集监控值、在超限时触发报警并生成纠偏记录，且这些记录要能关联到具体批次、班次、设备和操作人。
举个教学示例（以下参数为合理假设，非实测数据）：某乳品工厂将巴氏杀菌温度设为CCP，关键限值为“≥72℃且保持15秒”。需求分析时就应明确：系统需以不低于每5分钟一次的频率自动采集杀菌出口温度；温度低于72℃时，系统在10秒内产生报警并锁定该时段产品批次；操作工填写纠偏措施后，系统生成带时间戳的纠偏单。如果需求文档只写“系统支持温度监控”，而没有限值、频率、报警时限、批次锁定和纠偏闭环，这个需求就是不完整的，验收时也无法证明合规。
因此，法规约束转化为需求的正确做法是：先找到法规和标准中的“必须记录什么、必须多久记录一次、超限后必须做什么、记录必须保存多久”，再把这些“必须”翻译成数据字段、采集频率、报警规则、审批流和留存策略。凡是法规用“应当”“必须”表述的，在需求优先级上都应列为强制项，而不是可选项。
二、追溯要求决定数据模型的粒度
追溯要求对需求边界的影响，体现在“追到什么粒度”和“多久能追出来”两个维度。食品追溯通常要求实现从原料到成品、从成品到原料的双向追溯，部分品类还要求追溯到具体班次、生产线甚至农户或养殖场。需求分析阶段必须明确追溯单元：是按批次、按托盘、按箱，还是按单品？追溯粒度越细，数据模型越复杂，采集点越多，成本也越高。
一个实用的判断方法是做“追溯链路推演”。以某调味品工厂为例，假设其追溯要求为“4小时内完成成品批次到原料批次的追溯”。推演时会发现：成品批次号在灌装环节生成，需与当班使用的原料批次、香辛料批次、包装材料批次建立关联；原料入库时需记录供应商、到货批次、检验报告编号；生产投料时需扫描原料批次并与成品批次绑定。这条链路上任何一个环节缺数据，追溯就会断链。需求文档据此应明确：哪些工位必须配置扫码设备、哪些单据必须电子化、批次关联关系在哪一步建立、追溯查询的响应时间指标是多少。
值得注意的是，追溯要求还会反向约束“数据不能事后补录”。如果允许操作工在生产结束后统一补填投料记录，追溯的真实性就无法保证。因此需求中应规定关键追溯数据的采集时点和采集方式，例如投料时实时扫码、称量数据自动上传，而不是依赖手工台账。
三、数据完整性：最容易被低估的硬约束
数据完整性要求（常概括为可归属性、清晰性、同步性、原始性、准确性，即ALCOA原则）对需求边界的影响最为隐蔽，却最为致命。它要求记录能追溯到“谁、在什么时候、做了什么、原始数据是什么”，并且修改必须留痕、不能覆盖原始值。落到系统需求上，至少包括：用户唯一身份与权限分离、操作时间戳由系统生成而非人工填写、关键数据修改需理由并保留审计追踪、电子签名与纸质签名等效、数据备份与恢复可验证。
很多项目在需求阶段忽略审计追踪，上线后才发现：操作工可以随意修改已提交的检验结果，系统只保留最新值，监管检查时无法说明数据是否被篡改。这类问题不是“功能缺陷”，而是合规硬伤。因此需求分析时应把审计追踪、电子签名、权限矩阵作为强制需求单独列出，并明确哪些字段属于“关键数据”、修改时必须填写变更理由。
四、把三类约束落到需求边界上
将法规、追溯、数据完整性合并考虑，可以得到一张“约束—需求—验收”的映射关系。下图展示了三类合规约束如何收敛为具体的系统需求边界，以及每条边界对应的验收判断依据。
这张图的价值在于提醒需求分析人员：合规约束不是散落在各业务模块里的零散要求，而是一组必须整体成立的边界条件。CCP监控缺了报警时限，追溯缺了关联时点，数据缺了审计追踪，任何一处缺口都会让整个系统的合规性打折扣。
五、需求分析中的实操建议
在实际项目中，可以按以下方式把合规约束前置到需求分析：第一，建立“适用法规与标准清单”，明确本项目涉及哪些法规、哪些条款、哪些是强制项，避免凭经验拍脑袋。第二，对每条强制条款做“需求翻译”，写成可验证的需求描述，例如“系统应在温度低于72℃时10秒内报警并锁定对应批次”，而不是“系统应支持温度报警”。第三，设置合规否决评审，由质量或法规人员参与需求评审，对CCP、追溯、放行、数据修改相关需求逐条确认。第四，把验收判断依据写进需求文档，让开发和测试都知道“做到什么程度算合规”。
需要强调的是，合规约束会带来成本，但需求分析阶段识别它的成本，远低于上线后返工的成本。一个追溯关联字段的缺失，可能导致整条产线重新配置扫码工位；一个审计追踪功能的遗漏，可能导致系统无法通过监管检查而被迫替换。把合规当作需求边界的第一道筛子，是食品工厂数字化项目少走弯路的关键。