3. eCOA平台需求分析
eCOA平台的需求分析不是把“电子化纸质问卷”当作唯一目标，而是要把临床试验中四类核心角色的工作方式、数据责任和合规约束翻译成可验证的系统需求。受试者关心“我什么时候填、怎么填、填错了怎么办”；研究者关心“我能否及时看到异常、是否需要干预”；监查员关心“数据是否完整、可溯源、可核查”；数据管理员关心“数据能否按标准导出、编码、锁定”。这四类角色的需求彼此耦合，任何一类被忽略，都会在后期以数据缺失、质疑积压或稽查发现的形式暴露出来。
一、四类角色的需求分解
受试者侧的核心需求是低负担与高依从。具体包括：按访视窗口自动推送量表、支持离线填写与断点续填、对必填项和逻辑校验给出即时提示、允许在提交前修改、提交后生成可读回执。例如某糖尿病试验中，受试者需在每日睡前完成“夜间低血糖事件”日志，系统应在设定时间窗（如20:00–23:59）内推送提醒，超窗后标记为“延迟提交”而非直接拒绝，以保留真实世界数据。
研究者侧的需求集中在临床判断与安全响应。系统应提供受试者列表、待审核量表、异常评分预警（如PHQ-9总分≥15触发红色标记）、以及电子签名确认。研究者不需要逐条修改受试者数据，但必须能查看原始记录、添加临床评语并决定是否发起质疑。
监查员侧的需求是核查效率与溯源能力。关键功能包括：按中心/受试者/访视筛选数据、查看字段级修改痕迹（谁、何时、旧值、新值、原因）、导出核查清单、标记待跟进项。监查员不应直接修改数据，但可发起质疑并跟踪关闭状态。
数据管理员侧的需求是标准与可控。包括：CDISC ODM/SDTM导出、医学编码（MedDRA/WHO Drug）、数据锁定与解锁、审计追踪导出、以及与其他系统（EDC、IWRS）的接口对账。数据管理员最关注的是“数据是否可重复导出且版本一致”。
二、功能性需求与非功能性需求的边界
功能性需求描述“系统必须做什么”，可直接映射为测试用例。例如：“当受试者在访视窗口外提交量表时，系统应保存数据并标记‘超窗’，同时通知研究者。”非功能性需求描述“系统必须在什么条件下做到”，往往决定平台能否通过稽查。典型非功能性需求包括：
- 合规性：符合21 CFR Part 11电子记录/签名要求，审计追踪不可关闭、不可编辑。
- 性能：量表页面在4G网络下首屏加载≤2秒，提交响应≤1.5秒。
- 可用性：计划内停机每月≤30分钟，年度可用性≥99.5%。
- 安全与隐私：传输TLS 1.2+，静态数据AES-256加密，角色权限最小化。
- 可扩展性：支持至少50个中心、5000名受试者并发填写。
实践中常见错误是把非功能性需求写成“系统应稳定可靠”。这类描述无法验证。应改为可度量指标，例如“在500并发用户下，95%的提交请求响应时间≤2秒”。
三、用户故事编写：从角色到可验收条件
用户故事的标准格式是：“作为<角色>，我希望<功能>，以便<价值>。”但仅写一句话不够，必须附验收条件。以下给出四个角色的示例：
| 角色 | 用户故事 | 验收条件（示例） |
|---|---|---|
| 受试者 | 作为受试者，我希望在手机离线时也能填写量表，以便在地铁等无网络环境完成日志。 | 离线提交后本地加密存储；恢复网络后自动同步；同步失败时保留本地副本并提示重试。 |
| 研究者 | 作为研究者，我希望对异常评分进行电子签名确认，以便完成临床审核闭环。 | 签名需二次身份验证；签名后记录时间戳、用户ID、签名含义；签名后数据不可直接修改。 |
| 监查员 | 作为监查员，我希望导出某中心某访视的字段修改痕迹，以便现场核查时逐条比对。 | 导出文件含受试者编号、字段名、旧值、新值、修改人、修改时间、修改原因；格式为CSV且带校验和。 |
| 数据管理员 | 作为数据管理员，我希望按SDTM IG 3.3导出AE和QS域，以便直接进入统计编程流程。 | 导出文件通过Pinnacle 21社区版校验，无Reject级别错误；变量标签与受控术语符合CDISC要求。 |
四、需求优先级与冲突处理
四类角色的需求并非同等紧急。通常采用MoSCoW法：Must have包括数据采集、审计追踪、权限控制、导出；Should have包括离线填写、异常预警、质疑管理；Could have包括多语言界面、可穿戴设备对接；Won't have（本期）包括AI自动评分。当受试者要求“提交后允许无限次修改”与数据管理员要求“锁定后不可更改”冲突时，应通过状态机解决：提交后进入“可修改”状态，研究者审核后进入“已审核”，数据管理员锁定后进入“已锁定”，各状态下的修改权限在需求中明确列出。
需求分析的最后一步是建立可追溯矩阵：每条用户故事对应到功能需求编号、非功能需求编号和测试用例编号。这样当稽查员问“你如何证明系统符合Part 11”时，可以沿着矩阵从法规条款追溯到具体测试证据，而不是临时翻找文档。