2. 工作站需求分析与功能定义

实验室自动化工作站项目失败，很少是因为机械臂选得不好，而是因为一开始就没有把“用户到底要什么”翻译成“系统必须做到什么”。需求分析与功能定义，就是把实验室里模糊的、口语化的、甚至互相矛盾的期望，逐步收敛为可设计、可采购、可验证的工程输入。它包含四件事：用户需求采集、流程映射、功能规格书编写、验收标准制定。四者不是并列的文档工作，而是一条从“用户语言”到“工程语言”再到“验收语言”的传递链，任何一环失真，都会在调试阶段以返工的形式暴露出来。

一、用户需求采集：从“我想要”到“我需要”

用户最初提出的往往是解决方案而非需求，例如“我要一台能抓试管的机械臂”。采集的任务是追问其背后的真实目标：是通量不足、是人员暴露风险、还是夜间无人值守？常用手段包括现场跟班观察、结构化访谈和问卷。访谈应覆盖三类角色：操作员关心易用与容错，实验室负责人关心通量与合规，IT/设备部门关心接口与维护。

采集结果建议用“需求条目表”记录，每条包含编号、来源角色、原始表述、真实需求、优先级（必须/应当/可选）和约束条件。例如原始表述“每天手工移液太累”，真实需求可能是“将 96 孔板到 96 孔板的转移自动化，单板处理时间不超过 4 分钟，且避免交叉污染”。优先级用 MoSCoW 法区分，避免后期所有需求都变成“必须”。

二、流程映射：把实验动作拆成可自动化的步骤

流程映射是把用户现有操作画成带对象、位置、时间和判断的流程图。它不是简单罗列步骤，而要标注每一步的输入物、输出物、所在设备、耗时、人工介入点和异常分支。以“血清样本 ELISA 前处理”为例，可拆为：样本管扫码 → 开盖 → 吸取 50 µL 至 96 孔板 → 加入 100 µL 稀释液 → 混匀 → 封膜 → 孵育 30 min。映射时需明确每一步的容器位置（样本架第几列、板位编号）、体积精度要求和允许的等待时间。

流程映射的关键产出是“人工介入点清单”和“异常分支清单”。前者决定工作站需要多少自动化工位、是否需要机械臂与人工协作；后者决定系统需要哪些传感器和错误处理逻辑，例如“扫码失败时暂停并提示”“液面检测异常时跳过该孔并记录”。

三、功能规格书编写：把流程翻译成可设计的条目

功能规格书是需求与设计之间的合同。它不描述“怎么做”，而描述“必须做到什么”。每条功能应有唯一编号，并包含：功能描述、输入/输出、关键参数、接口、约束、假设和对应的需求编号。参数必须带单位和容差，例如“移液精度：50 µL 时 CV ≤ 3%”“定位重复性：±0.1 mm”。

规格书要区分“功能需求”与“非功能需求”。前者如“支持 96 孔板到 96 孔板转移”，后者如“单板处理时间 ≤ 4 min”“连续运行 8 h 无故障”“噪声 ≤ 65 dB”。非功能需求往往决定机械选型和成本，必须与用户确认优先级。规格书还应列出“假设与依赖”，例如“假设样本管已预扫码”“依赖实验室现有 230 V 电源”，这些是后期变更的高发区。

四、验收标准制定：让“做完了”有据可依

验收标准是规格书的镜像：每条功能需求都应有对应的测试方法和判据。判据要可测量、可重复、有明确阈值。例如针对“移液精度 CV ≤ 3%”，验收方法可写：取 50 µL 目标体积，在 96 孔板中重复 24 次，用称重法或荧光法测量，计算 CV，要求 ≤ 3% 且无单孔偏差超过 10%。针对“单板处理时间 ≤ 4 min”，测试方法为连续处理 10 块板，记录从第一孔吸头接触到最后一孔移液完成的时间，取平均值。

验收标准还应包含异常处理验证：人为制造扫码失败、吸头堵塞、液面不足等场景，检查系统是否按规格书要求暂停、报警或跳过，并记录日志。最后，验收标准要明确“通过/失败”的判定规则和样本量，避免用“基本满足”这类模糊表述。

实际项目中，建议用一张“需求-规格-验收追溯表”贯穿始终。表中每行是一条需求，列出其对应的规格编号、验收方法编号和当前状态。当用户提出变更时，先更新需求表，再检查规格和验收是否同步，而不是直接改代码或改机械结构。这样，工作站的功能定义才真正成为工程控制的抓手，而不是一份写完就归档的文档。