3. 数据平台需求工程

计算生物学数据平台的需求工程，难点不在于“把需求写下来”，而在于把三类来源完全不同的诉求翻译成同一套可设计、可验证的工程语言。科研问题关心的是假设能否被数据检验，临床场景关心的是结论能否在合规与时限内被信任，工业应用关心的是流程能否稳定、可重复、可规模化地交付。三者对同一个平台提出的要求经常互相冲突：科研要灵活探索，临床要严格审计，工业要高吞吐低成本。需求工程的任务，就是把这些冲突显性化，并转化为功能需求、非功能需求与约束条件三条并行的需求线。

三类来源，三种“提问方式”

从科研问题出发，典型提问是：“我要比较两组样本在某个通路上的差异，需要哪些数据、哪些元数据、哪些统计能力？”这类需求往往以分析目标为起点，倒推数据范围、参考基因组版本、注释版本、批次信息与可复现的随机种子。从临床场景出发，提问变成：“这份报告依据的是哪一版流程、哪一批样本、谁在什么时间审核？”它天然要求样本溯源、版本冻结、权限分级与审计留痕。从工业应用出发，提问则是：“每天新增 200 个样本时，平台能否在 24 小时内完成从原始数据到质控报告的交付，且单样本成本可控？”它把需求推向吞吐、并发、失败重试与资源计量。

因此，需求提炼的第一步不是写功能列表，而是建立“来源—诉求—可验证指标”的映射。例如科研来源的“可复现”落到工程上，是流程版本号、容器镜像摘要与参数快照必须随结果一起持久化；临床来源的“可追溯”落到工程上，是样本、文库、测序批次、分析任务、报告五级对象之间必须存在不可断链的关联；工业来源的“可规模化”落到工程上，是任务队列深度、单任务资源配额与失败自动重试策略必须可配置、可观测。

功能需求：从“能做什么”到“输入输出可检查”

功能需求最容易写成愿望清单，例如“支持多种组学数据分析”。可执行的做法是把它拆成“对象—操作—输入—输出—验收条件”。以“支持 RNA-seq 差异表达分析”为例，输入应明确为：原始 FASTQ 或已比对 BAM、样本分组表（含批次列）、参考基因组版本与注释 GTF 版本；操作应明确为：质控、比对或定量、标准化、差异检验、多重检验校正；输出应明确为：表达矩阵、差异结果表（含 log2FC、p 值、FDR）、质控报告与运行元数据。验收条件可以写成：给定一组已知的阳性对照基因，流程应能将其检出且 FDR 控制在设定阈值内；同一输入重复运行两次，结果表应逐行一致。

临床场景的功能需求还要增加“报告生成”与“审核流转”。例如报告对象必须包含：样本编号、检测项目、参考区间、结论、审核人、审核时间、所用流程版本。工业场景则要增加“批量提交”与“失败重跑”：提交接口应接受样本清单文件，返回任务批次号；失败任务应能按原参数重跑，且不重复消耗已完成样本的计算资源。

非功能需求：用数字替代形容词

非功能需求如果只写“高性能、高可用、安全”，就无法设计也无法验收。应尽量量化。以下是一组示例性指标，用于说明写法，并非实测结果：

这些指标之间会互相拉扯。提高吞吐可能要求放宽单任务资源上限，但会挤压单样本时限；加强审计会引入额外写日志开销，可能影响接口延迟。需求工程要做的不是消灭冲突，而是把冲突放到桌面上，由利益相关方在约束边界内做优先级排序。

约束条件：不可协商的边界

约束条件通常来自法规、预算、既有系统与数据主权。例如：人类遗传资源数据不得未经审批出境；临床检测流程必须使用经批准的试剂与版本；平台必须部署在已有院内机房，不能新增公有云支出；必须与现有 LIMS 通过固定接口对接。约束条件不参与“优先级排序”，它们是设计空间的外墙。功能需求和非功能需求都必须在这堵墙内求解。

一个可填写的需求条目模板

下面给出一个可直接使用的需求条目示例，字段刻意保持精简，只保留计算生物学数据平台真正需要的要素：

需求编号：REQ-003
来源：临床场景
类型：功能需求
描述：系统应支持对已完成的变异检测结果生成结构化报告，
      报告须包含样本编号、检测项目、流程版本、审核人与审核时间。
输入：变异检测结果文件（VCF）、样本元数据、流程版本号
输出：PDF 报告 + 结构化 JSON 记录
验收条件：随机抽取 10 份报告，五级对象关联完整率 100%；
          报告中的流程版本号与运行记录一致。
约束关联：须符合院内数据不出院规定；须与现有 LIMS 对接。
优先级：高

把三类来源的诉求分别落到功能、非功能与约束三条线上，再用可验证指标收口，需求文档才真正具备驱动架构设计的能力。后续的存储选型、计算调度、权限模型与审计设计，都应能追溯到这里的某一条需求或约束，而不是凭经验拍板。