3. 数字化记录的需求分析与场景建模

数字化记录不是把纸质表格简单搬进手机，而是先弄清楚“谁在什么场景下、为了什么目的、记录哪些数据、数据流向哪里”。本节以池塘、网箱、工厂化三类典型养殖场为对象，完成一次可落地的需求调研与场景建模，产出数据流图与用户角色用例图，为后续系统设计提供依据。

一、先分清三类养殖场的记录差异

需求调研的第一步是识别场景差异。池塘养殖以水质调控和投喂为核心，记录频次受天气影响大，巡塘往往靠人工目测；网箱养殖受水流、溶氧和鱼群逃逸风险影响，记录点分散在浮排与岸上；工厂化循环水养殖则高度依赖设备运行参数，溶氧、温度、pH、氨氮、流量、能耗等指标由传感器连续采集，人工记录更多用于核对与异常处置。三类场景的数据源、记录频次和责任人都不同，若用同一套表单覆盖，必然出现字段冗余或关键信息缺失。

调研时应围绕“记录什么、谁来记、多久记一次、记完给谁看、异常怎么报”五个问题展开。以池塘为例，养殖员每日清晨巡塘需记录天气、水温、溶氧、鱼群活动、死鱼数量；投喂后记录饲料品种与投喂量；用药后记录药品名称、剂量、休药期。这些字段中，水温与溶氧是判断是否开增氧机的依据，死鱼数量是疫病预警信号，休药期则直接关系上市合规。调研表应把这些“字段—用途—责任人”对应关系写清楚，而不是只罗列字段名。

二、用数据流图刻画数据从产生到使用

数据流图（DFD）适合表达“数据在哪里产生、经过什么处理、存到哪里、被谁使用”。绘制时先画顶层图，把整个养殖场视为一个处理过程，外部实体包括养殖员、技术员、场长、监管平台和投入品供应商；输入数据流为巡塘记录、投喂记录、用药记录、设备参数；输出数据流为生产日报、预警信息、追溯档案。顶层图只保留一个处理框，避免过早陷入细节。

第二层展开时，按业务划分为“日常巡塘记录”“投入品管理”“水质与设备监控”“生产统计与上报”四个处理过程。以用药记录为例：养殖员提交用药申请，技术员审核药品名称与剂量，审核通过后形成用药记录存入生产档案，同时触发休药期倒计时；倒计时结束前，销售环节读取该记录并拦截出塘。这条数据流清楚说明了“一条记录如何影响后续业务”，比单纯列字段更有价值。绘制时注意数据存储用双横线表示，外部实体用矩形，处理过程用圆角矩形，数据流箭头标注数据名称而非动作名称。

三、用户角色用例图要落到操作权限

用例图的价值在于明确“谁能做什么”。调研中常见的误区是把所有功能都挂给“管理员”，导致实际使用时权限混乱。合理的角色划分应贴合岗位：养殖员负责巡塘、投喂、死鱼上报等现场记录，只能新增和查看本人记录；技术员负责水质异常研判、用药审核、设备参数核对，可修改审核意见但不能删除原始记录；场长负责日报查看、批次统计和监管上报；监管平台作为外部参与者，只读取上报数据，不直接写入生产库。

绘制用例图时，参与者用小人表示，用例用椭圆，连线表示参与关系。以“用药记录”为例，养殖员关联“提交用药申请”，技术员关联“审核用药申请”和“设置休药期”，场长关联“查看休药期状态”，监管平台关联“接收追溯数据”。这样一张图就能说明：一条用药记录从提交到上市拦截，涉及四个参与者、五个用例，权限边界清晰。

四、从调研到建模的落地做法

实际开展时，建议先用半天时间跟班观察，记录养殖员一天中真实发生的记录动作和时间点，再对照现有纸质表单核对字段。随后用一至两天完成数据流图草稿，重点检查每条数据流是否有明确的来源和去向，是否存在“只存不用”的字段。最后与场长、技术员共同评审用例图，确认每个用例都有对应角色，且没有角色承担相互冲突的职责。评审通过后，数据流图中的数据存储可直接转化为数据库表设计的输入，用例图则转化为权限矩阵，两者共同构成后续开发的需求基线。