3、需求分析：如何定义样本追踪的业务需求
各位做样本追踪的朋友，需求分析这步看起来简单，实则最容易被带偏。很多人一上来就聊技术栈、数据库、条码格式，结果做到一半才发现业务场景根本没摸透。我个人习惯是，不管项目多大，先坐下来把业务场景拆清楚，再谈系统怎么落地。
说白了，样本追踪不是IT项目，是业务流程优化项目。你想想看，一个样本从采集到销毁，中间经过谁的手、变更了什么属性、走什么流程——这些不搞清楚，系统再牛也是白搭。
3.1 理解样本追踪的业务场景
我们先看看典型的业务场景。每个场景对追踪的要求都不同，我列几个常见的：
| 场景类型 | 核心诉求 | 典型失败点（我踩过的坑） |
|---|---|---|
| 单中心单库 | 追溯样本位置、状态变更 | 忘记记录样本出入库的温度条件 |
| 多中心多库 | 跨库调拨、权限隔离 | 中心之间的样本编号规则冲突 |
| 物流托管 | 第三方物流交接、GPS位置 | 交接时只签收不核对样本数量 |
| 临床试验 | 盲态保持、有效期管控 | 盲态揭盲后样本状态没来得及锁定 |
我在一个多中心项目中遇到过，两个中心的样本编号用了不同的前缀规则，导致系统合并时大量冲突，最后回退用了三周。所以，场景梳理阶段，我建议拉上所有干系人（实验室、物流、质量、IT）一起过一遍业务步骤。
3.2 定义核心追踪元素
场景摸清后，我们得定义追踪什么。我通常把要素分为三类：样本本身、样本的状态、样本的流转记录。这三类对后续数据模型影响很大。
3.3 梳理业务需求清单
场景和要素都齐了，接下来我们出需求清单。我曾见过一个团队，一上来就画ER图，结果需求漏了一半。我的做法是，用一张表把每个场景下的需求打平：
| 需求类型 | 需求描述 | 关键问题（我们得问清楚） |
|---|---|---|
| 标识管理 | 为每个样本分配唯一编号 | 编号规则是否全局唯一？是否包含业务含义？ |
| 入库管理 | 记录样本入库时的位置、容器、温度 | 入库时是否需要扫码复核？温度阈值是多少？ |
| 状态变更 | 样本在任意环节的状态变化需记录 | 状态机有哪些？谁有变更权限？ |
| 检索回溯 | 支持按样本编号、时间、操作人等条件查询 | 查询范围是否跨中心？历史数据归到哪里？ |
| 异常处理 | 记录样本丢失、破损、超期等异常 | 异常是否需要人工审批？严重等级怎么定？ |
你可能会问，需求清单到底要多细？我有个判断标准：能把每个需求背后的“为什么”讲出来，就够了。如果只是写“支持样本入库”，那等于没写。入库为什么重要？因为入库是追踪链的起点，入库数据错了，后面全乱。
3.4 定义非功能性需求
业务需求之外，还得考虑非功能需求。这些容易被忽略，但恰恰是后期出问题的重灾区。
- 性能要求：高峰期每秒能处理多少条样本？我曾有个项目，入库峰值每秒要写500条记录，一开始没压测，上线直接崩。
- 数据完整性：流转记录是否实时写入？能否容忍丢失？临床试验场景一条都不能丢。
- 权限控制：操作人和查看人的权限分开。我见过一个系统，操作员能看到全库样本，结果数据泄露。
- 合规需求：是否需要符合FDA 21 CFR Part 11、GxP、HIPAA？别等审计时才发现。
- 接口对接：是否需要对接LIMS、ELN、ERP？接口字段、频率、重试策略都要提前定义。
3.5 输出需求文档与确认
最后一步是把所有需求文档化、签字确认。我个人习惯用Markdown写需求，然后转成HTML版和PDF版各一份。结构大概这样：
# 样本追踪系统业务需求文档 v1.0
## 1 业务场景说明
1.1 单中心样本管理
1.2 多中心跨库调拨
1.3 外送检测物流追踪
## 2 核心追踪要素定义
2.1 样本标识规则
2.2 样本状态机
2.3 流转记录字段
## 3 业务需求列表
3.1 标识管理（需求ID: REQ-001）
3.2 入库管理（需求ID: REQ-002）
3.3 状态变更（需求ID: REQ-003）
3.4 检索回溯（需求ID: REQ-004）
3.5 异常处理（需求ID: REQ-005）
## 4 非功能性需求
4.1 性能目标（TPS ≥ 300）
4.2 数据完整性（零丢失）
4.3 权限模型（RBAC）
4.4 合规标准（21 CFR Part 11）
## 5 附录：关键干系人签字确认表
确认环节也很关键。我曾经有个项目，需求文档写完了，但只给业务部门看了个标题，没逐条核对。结果上线后业务反馈多处不符合实际流程，返工了两个迭代。现在我的铁律是：每条需求都要有业务方签字，关键流程要拉上所有干系人过一遍。