第4章 用户需求规范（URS）编写：功能性、安全性、合规性需求
我第一次做GxP相关审计时，甲方扔给我一份URS，满打满算只有两页半。我当时就觉得不对劲。果然，上线不到三个月，系统就被FDA打回来两次。说白了，URS写不好，后面所有的审计都是空中楼阁。
这一章我们重点聊聊URS怎么写才经得起审计。我会从功能性、安全性、合规性三个维度展开。不讲空话，只讲我踩过的坑和现在让我重写的做法。
4.1 功能性需求：让系统干该干的事
功能性需求最容易被轻视。很多人觉得“能跑起来就行”。但GxP环境里，功能的边界、异常处理、日志记录都算需求。
我之前验收过一套流程，上游交付的fastq文件命名不规范，到下游直接中断了。你说这算不算bug？其实根子在URS里没写“文件名解析规则”这条需求。
4.1.1 输入/输出规范
你必须明确写明：
- 输入格式：FASTQ、BAM、VCF？具体到版本号。
- 输入限制：单样本最大文件大小？是否支持压缩输入？
- 输出产物：报告格式、中间文件的保留策略。
- 错误状态：输入不符合规范时，系统是报错退出，还是自动补全？
举个例子，我常用的写法是这样的：
URS-FUNC-001: 系统应接受gzip压缩的FASTQ文件作为输入
URS-FUNC-002: 输入文件名必须匹配正则 ^[A-Za-z0-9_-]+_R[12]\.fastq\.gz$
URS-FUNC-003: 单个文件超过4GB时，系统应分段处理并记录日志
URS-FUNC-004: 所有输出文件的时间戳统一使用ISO 8601格式4.1.2 流程编排与重入能力
生信工作流不是一次性跑完就完事的。重跑、断点续跑、局部修正，这些场景你必须提前想到。
- 重入性：中途失败后能不能从断点继续？
- 版本锁定：每个步骤的工具版本是否有锁？
- 依赖检查：下游步骤是否校验上游的输出完整性？
4.2 安全性需求：防泄露、防篡改、防误操作
安全性在生信领域经常被忽略。大家总觉得数据是科研数据，没那么敏感。但GxP审计里，患者隐私、研发机密、原始数据完整性都是重灾区。
我记得有一个项目，团队把原始测序数据放在共享盘上，权限是0777。审计当场开了严重不符合项。为什么会这样？因为URS里压根没提“访问控制”这回事。
4.2.1 数据访问控制
| 需求编号 | 需求描述 | 实现方式（示例） |
|---|---|---|
| URS-SEC-001 | 原始数据仅限数据管理员可写 | POSIX ACL + LDAP组策略 |
| URS-SEC-002 | 分析结果仅项目组成员可读 | 工作流输出目录限定组权限 |
| URS-SEC-003 | 所有删除操作需二次确认 | 回收站机制 + 日志记录 |
| URS-SEC-004 | 涉及PII的数据必须脱敏后处理 | 脱敏模块在流程入口前插入 |
4.2.2 数据完整性与防篡改
这个点很关键。生信工作流数据体量大，极容易被不小心覆盖或误删。一旦原始数据被改，整个分析链条都是废的。
- 校验和：每个文件入库前计算SHA256，存储校验和。
- 写入保护：原始数据目录设置写保护，只允许ETL流程写入。
- 审计日志：所有写操作记录时间、操作人、工具、参数。
4.3 合规性需求：对GxP条款的翻译
合规性需求不是凭空写的，是对GxP条款的具体落地。你不能只写“符合21 CFR Part 11”，你得写清楚怎么符合。
我在做生信审计时，最怕看到URS里大段复制法规条文。审计不是考试，验证人员看的是你能不能实现，不是你会不会背书。
4.3.1 电子记录与电子签名（21 CFR Part 11）
对于生信工作流，常见的合规点有：
- 用户身份认证：系统必须使用域账号或双因素认证登录。
- 操作时间戳：每个步骤的执行时间、完成时间自动记录，不可修改。
- 记录保护：分析日志、运行日志不可删除，只能归档。
- 电子签名：关键操作（如审批、发布）需配对username+password。
URS-COMP-001: 系统应使用组织级LDAP/AD进行用户身份验证
URS-COMP-002: 每次工作流运行自动生成JSON格式的执行日志，且不可逆写入日志存储区
URS-COMP-003: 日志存储区使用WORM（一次写多次读）存储策略
URS-COMP-004: 电子签名必须包含签名人、时间戳、签名含义三要素4.3.2 数据保留与归档
GxP要求原始数据和分析记录保留特定时长（通常是5年或以上）。你需要在URS里说明：
- 归档触发器（项目结束后？
- 归档格式（是否转成通用格式，避免工具依赖）
- 归档后验证（确认数据一致）
4.4 URS的结构示例
下面是我现在写URS的标准模板。你可以直接拿来改。
# URS-FUNC：功能性需求
URS-FUNC-001：输入支持FASTQ、BAM
URS-FUNC-002：工作流支持CWL描述
URS-FUNC-003：失败自动重试最多3次
# URS-SEC：安全性需求
URS-SEC-001：所有传输使用TLS 1.3
URS-SEC-002：数据盘使用dm-crypt加密
# URS-COMP：合规性需求
URS-COMP-001：执行日志符合21 CFR Part 11
URS-COMP-002：数据保留周期5年
URS-COMP-003：归档前执行完整性校验每个需求编号必须唯一，且与验证测试用例一一对应。审计问到你的时候，你直接能说出“URS-FUNC-002的验证测试在VTP-002中有三条用例”。
这张图表达的逻辑很简单：URS拆成三类需求，每一类对应具体的验证测试。测试通过了，审计才能证据链闭环。你想想看，如果没有这个分解，审计问你某条需求怎么验证的，你连从哪找答案都不知道。