2. 电子知情同意系统的需求分析与角色建模

电子知情同意（eConsent）系统不是把纸质ICF扫描成PDF再放到平板里，而是一套需要同时满足法规、伦理、临床运营与受试者体验的多角色协同系统。需求分析的第一步，不是急着写功能清单，而是把“谁在什么场景下要完成什么、受什么约束、失败时怎么办”识别清楚。本节围绕申办方、研究者、受试者、伦理委员会、监查员五类核心利益相关方，说明如何从诉求推导用户故事、用例与需求规格说明书。

一、先识别利益相关方及其核心诉求

需求来源不同，优先级也不同。受试者关心“看得懂、签得快、能随时查”；研究者关心“不增加访视负担、签署记录可追溯”；申办方关心“多中心数据一致、稽查可举证、版本可控”；伦理委员会关心“知情过程是否充分、弱势群体是否被保护、变更是否重新知情”；监查员关心“源数据可核对、签署时间与访视时间是否匹配”。这些诉求之间存在张力：例如受试者希望流程短，伦理要求关键信息必须逐项确认。需求分析的价值，就是把这些张力显性化，并在需求规格中给出可验证的平衡方案。

二、从诉求到用户故事：以角色—目标—价值组织

用户故事适合表达“谁、要什么、为什么”。写法建议采用“作为<角色>，我希望<能力>，以便<价值>”，并补充验收条件。以下为示例（参数为教学假设，非实测）：

• 作为受试者，我希望在签署前能按章节阅读ICF并标记“已理解”，以便确认我真正理解关键风险。
• 作为研究者，我希望系统自动校验受试者是否已完成所有必读页，以便避免漏签导致方案偏离。
• 作为申办方，我希望每次ICF版本变更都生成新版本号并锁定旧版本，以便稽查时能还原当时签署内容。
• 作为伦理委员会，我希望能够查看某受试者的完整知情时间线，以便评估知情过程是否合规。
• 作为监查员，我希望比对eConsent签署时间与访视记录，以便发现时间逻辑异常。

用户故事不宜只停留在“能签署”。真正决定系统质量的是边界条件：受试者中途退出、网络中断、签名设备更换、代理人签署、版本更新后是否需要重新知情。这些应写成验收条件，例如“当ICF版本从V2.0升级到V3.0且涉及新增风险时，系统必须要求所有在组受试者重新知情，并保留V2.0签署记录不可篡改”。

三、用例图：把角色与系统边界画清楚

用例图用于表达“谁与系统交互、系统提供哪些用例”。建议把系统边界限定为eConsent平台本身，外部系统如EDC、CTMS、IAM作为参与者或外部接口。核心用例包括：阅读ICF、逐项确认、电子签名、获取副本、撤回同意、重新知情、版本管理、审计追踪、权限管理、异常处理。参与者与用例之间用关联线连接，包含关系（include）用于抽取“身份认证”“时间戳”等公共行为，扩展关系（extend）用于“代理人签署”“离线签署”等条件分支。

四、需求规格说明书：把故事写成可验证的条目

需求规格说明书（SRS）应把用户故事转化为可测试的需求条目，每条包含编号、名称、描述、优先级、验收标准、来源角色与法规依据。建议按功能域组织：身份与权限、知情过程、签名与存证、版本管理、副本与撤回、审计与报告、接口与集成、异常与恢复。以下为示例条目（教学假设）：

五、角色建模中的关键判断

角色建模不是画完图就结束，而要回答三个问题：第一，权限边界是否清晰——受试者只能看自己的记录，监查员只能看授权中心，伦理委员会可查看脱敏时间线；第二，责任边界是否明确——研究者负责知情过程，申办方负责系统与版本，伦理负责审批与监督；第三，异常路径是否覆盖——拒签、撤回、设备丢失、代理人变更、版本冲突。建议在SRS中为每个用例补充“前置条件、主流程、备选流程、后置条件”，并标注对应的法规条款（如ICH GCP E6(R2) 4.8、21 CFR Part 11、GDPR第7条等），使需求可追溯、可审计、可验证。

完成本节工作后，你应能输出一份包含五类角色、至少12条用户故事、一张用例图与一份可验证SRS条目的需求分析包。下一阶段将进入系统架构与数据模型设计，把上述需求映射为可实现的模块与数据结构。