1. 追溯系统需求分析

追溯系统建设失败，十有八九不是败在编码或硬件，而是败在需求阶段。食品、药品、制造、物流四类场景对"追溯"的理解差异极大：食品企业关心的是"一批原料流向哪些成品"，制药企业关心的是"每一盒药经过哪些工序、由谁放行"，离散制造关心的是"这台设备的关键件来自哪个供应商批次"，物流企业关心的则是"这个包裹在哪个节点被扫描、由谁交接"。如果需求分析阶段不把这些差异拆开，后续的编码规则、标签选型、采集点布置都会失去依据。

需求分析的核心任务可以归纳为四件事：定粒度、定采集点、定合规、定目标。四者相互约束——粒度越细，采集点越多，合规要求越严，业务目标越难同时满足。因此需求规格说明书不是把四者简单罗列，而是要把它们之间的取舍关系写清楚。

一、追溯粒度：从批次到单品

追溯粒度决定了标识对象的层级。常见粒度有四档：

• 批次级：以生产批号或收货批号为最小追溯单元，同一批次内不区分个体。适用于食品原料、化工原料、大宗物料。
• 托盘/箱级：以物流包装单元为追溯对象，常见于快消品分销、仓储出入库。
• 单品级：每一件产品拥有唯一序列号，可精确到"这一盒药、这一台设备"。药品电子监管、高值医疗器械、汽车关键件多采用此级。
• 工序级：在单品级基础上，记录每道工序的设备、操作人、工艺参数，用于质量追溯与工艺分析。

粒度选择不是越细越好。以某乳制品企业为例，若将常温奶做到单品级追溯，需要为每条产线增加喷码、读码、剔除工位，单线改造成本约数十万元，而消费者投诉场景中真正需要定位到单盒的比例不足千分之一。因此该企业最终选择"原料批次级 + 成品箱级"的混合粒度：原料可追到供应商批次，成品可追到箱，箱内单品通过箱码关联。这一决策直接写入了需求规格说明书的"追溯粒度矩阵"。

二、数据采集点：把物理动作映射为数据事件

采集点是追溯数据的源头。需求分析阶段要回答：在哪些物理位置、由谁、用什么设备、采集什么数据、数据何时上传。采集点识别不充分，会导致追溯链断裂——例如原料入库采集了批次，但领料出库未采集，就无法建立"原料批次—成品批次"的关联。

识别采集点可用"物料状态变化法"：物料每发生一次状态变化（收货、检验、入库、领料、投料、加工、包装、入库、出库、运输、签收），就应评估是否需要采集。评估标准有三条：该状态是否影响追溯链完整性、是否影响合规举证、是否影响业务决策。三条中满足一条即应设采集点。

三、合规要求：把法规条款翻译成系统约束

合规要求是需求规格说明书中"不可协商"的部分。食品行业需满足《食品安全法》及GB 7718等对标签和追溯的要求；药品行业需满足GMP及药品追溯码相关规范，要求追溯数据保存不少于5年；出口欧盟的食品需满足EC 178/2002的"一步向前、一步向后"追溯要求；汽车零部件则常需满足IATF 16949对批次追溯的规定。

需求分析时，应把每条法规翻译成可验证的系统约束。例如"数据保存不少于5年"应转化为：追溯数据库保留策略、归档机制、查询接口的响应时间要求；"一步向前、一步向后"应转化为：系统必须支持按批次正向查询下游去向、反向查询上游来源，且查询结果可导出为规定格式。这些约束应逐条列入需求规格说明书的"合规需求"章节，并标注法规来源和验证方式。

四、业务目标与需求优先级

业务目标决定需求的优先级。常见目标包括：缩短质量事件响应时间、降低召回成本、满足客户审核、提升产线效率、支持防窜货。不同目标对系统的要求不同——以"缩短召回响应时间"为目标时，查询性能是核心指标；以"满足客户审核"为目标时，数据完整性和可导出性更关键。

建议用"目标—需求—验收指标"三层结构组织需求规格说明书。每个业务目标对应若干功能需求，每个功能需求对应可测量的验收指标。例如目标"将质量事件定位时间从4小时缩短到30分钟"，对应需求"支持按成品箱码反查原料批次及投料记录"，验收指标"在10万条追溯记录下，反查响应时间≤3秒"。

五、需求规格说明书的落地写法

需求规格说明书不是一次性文档，而是贯穿设计、开发、验收的基线。建议包含以下部分：场景与范围说明、追溯粒度矩阵、采集点清单、合规需求条款、功能需求列表（含优先级）、验收指标、假设与约束。其中"假设与约束"常被忽略，却极其重要——例如"假设车间网络覆盖率达到95%以上""约束：现有ERP不开放实时接口，追溯数据通过定时任务同步"，这些假设一旦不成立，方案需重新评估。

完成需求分析后，应组织质量、生产、仓储、IT四方评审，重点确认三件事：采集点是否覆盖了所有关键状态变化、合规条款是否逐条有对应系统约束、验收指标是否可测量。评审通过的需求规格说明书，才是后续编码规则设计、标签选型、采集设备布置的可靠输入。