4. eSource系统需求工程

eSource系统的需求工程不是“把用户想要的功能列出来”，而是把临床方案中的终点、访视、评估和合规约束，逐层翻译成可设计、可验证、可追溯的系统需求。需求一旦写错或漏写，后续的数据库设计、接口开发、验证测试都会偏离临床真实需要。本节围绕四条主线展开：URS编写、功能与非功能需求划分、临床终点到数据点的映射、以及需求追溯矩阵（RTM）的构建。

一、URS：用临床语言定义“系统必须做到什么”

用户需求规格（User Requirement Specification, URS）描述的是使用者的业务需要，而不是软件实现方式。它回答“谁在什么场景下需要系统完成什么，以满足哪条法规或方案要求”。URS的每一条应具备唯一编号、需求陈述、来源依据、优先级和验收标准。来源依据通常指向ICH E6(R3)、21 CFR Part 11、方案章节号或SOP编号；验收标准则说明如何证明该需求被满足。

例如，一条URS可以写成：“URS-007：研究者应能在受试者访视现场离线录入生命体征，并在网络恢复后自动同步，且同步过程不得产生重复记录。来源：方案3.2节、21 CFR Part 11 §11.10。优先级：高。验收标准：断网录入5条记录，恢复网络后系统自动上传且记录总数仍为5条。”这样的写法把业务场景、合规依据和可验证结果绑定在一起，避免“系统应支持离线录入”这类无法验收的模糊表述。

二、功能需求与非功能需求的边界

功能需求描述系统“做什么”，例如：创建受试者、录入访视数据、触发质疑、生成稽查轨迹、导出SDTM数据集。非功能需求描述系统“做得怎么样”，包括性能、安全、可用性、可维护性和合规属性。二者常被混写，导致测试时无法判断通过标准。

在eSource中，典型的非功能需求包括：页面响应时间在200名并发用户下不超过2秒；稽查轨迹不可修改且保留至少25年；电子签名符合21 CFR Part 11；系统可用性不低于99.5%；数据加密传输采用TLS 1.2以上。功能需求可以对应到具体界面和操作，非功能需求则往往对应架构决策、部署方案和验证脚本。编写时应把非功能需求量化，例如“系统应快速保存”应改为“单条访视表单保存操作在正常网络条件下P95响应时间≤1.5秒”。

三、临床终点到数据点的映射

这是eSource需求工程中最能体现临床与工程结合的一步。临床终点是方案中定义的疗效或安全性判断指标，数据点是CRF或eSource中实际采集的字段。映射过程通常为：主要/次要终点 → 评估指标 → 访视时间点 → 表单/字段 → 数据点类型与单位 → 派生规则。

以某II期肿瘤试验为例，主要终点为“客观缓解率（ORR）”，依据RECIST 1.1评估。映射链为：ORR → 靶病灶最长径之和（SLD）变化与总体缓解评价 → 基线、第6周、第12周影像评估访视 → 影像评估表单中的“评估日期”“靶病灶编号”“最长径(mm)”“非靶病灶评价”“新病灶”字段 → 数值型/日期型/单选型数据点 → 由SLD变化和总体评价派生CR/PR/SD/PD。若漏掉“新病灶”字段，PD判定就会缺失，ORR无法计算。因此映射表必须逐条核对，确保每个终点都有完整的数据点支撑。

四、需求追溯矩阵（RTM）的构建

RTM是一张把需求从来源到验证串联起来的表。它的核心作用是：证明每条临床终点都有需求覆盖，每条需求都有数据点支撑，每条数据点都有测试用例验证。构建RTM时，通常以URS编号为主键，向右关联功能需求、非功能需求、数据点、测试用例和验证状态。

一个可用的RTM至少包含以下列：URS编号、需求描述、需求类型（FR/NFR）、来源依据、对应数据点、测试用例编号、验证状态、备注。填写时要注意双向追溯：从终点向下能找到数据点和测试，从测试向上能找到它验证的是哪条需求。若某条URS没有对应测试用例，说明验证覆盖不足；若某个数据点没有对应URS，说明可能存在范围蔓延。

五、需求评审与常见缺陷

需求评审应邀请临床、数据管理、统计、IT和QA共同参与。常见缺陷包括：需求不可验证（如“系统应友好易用”）、需求与方案脱节（如漏掉某次访视的实验室检查）、功能与非功能混淆（如把“稽查轨迹不可修改”写成功能需求）、以及缺少优先级导致开发排期困难。评审时可以用“这条需求如何测试”作为检验标准，凡是无法写出测试用例的需求，都应退回重写。

需求工程的质量直接决定eSource系统能否通过验证并支撑临床决策。URS提供业务意图，功能与非功能需求提供设计边界，终点到数据点的映射保证临床完整性，RTM则把这一切锁在可追溯的链条上。四者缺一不可，且必须在同一版本控制下协同维护。