1. 课程导入与全景认知
医疗软件与普通商业软件最大的区别，不在于功能复杂度，而在于每一个需求都必须能被证明、被追溯、被审计。当监管机构问“你怎么证明这条安全需求真的被实现了”，如果团队只能回答“我们测试过了”，这通常不足以支撑一次注册审评或飞行检查。需求追溯与验证证据工程，正是把“我们做了”转化为“有据可查、可逐条对应、可复核”的工程能力。
一、它到底是一门什么工程
可以把这门课拆成三个关键词来理解：
- 需求追溯（Requirements Traceability）：在需求、设计、代码、测试、缺陷、风险之间建立双向可追踪的链接关系，确保“上游每一条需求都有下游承接，下游每一项活动都能回溯到上游依据”。
- 验证证据（Verification Evidence）：指能够证明需求已被正确实现的客观记录，包括测试用例与结果、评审记录、静态分析报告、覆盖率数据、仿真/台架记录、临床评价资料等。
- 证据工程（Evidence Engineering）：不是临时补材料，而是把证据的生成、采集、关联、版本化、可检索作为工程活动来设计，使证据在需要时能自动、完整、可复现地输出。
三者合起来，就是让“需求—实现—验证—证据”形成一条闭合、可审计的链路。它既是质量活动，也是合规活动，更是研发流程的基础设施。
二、法规背景：FDA、NMPA、MDR 的共同诉求
不同市场的法规表述不同，但对追溯与证据的要求高度一致。
| 监管体系 | 代表性要求 | 对追溯/证据的核心诉求 |
|---|---|---|
| FDA（美国） | 21 CFR 820.30 设计控制；软件指南（如 IEC 62304 认可） | 设计输入与输出对应、设计验证/确认记录、可追溯至需求 |
| NMPA（中国） | 医疗器械生产质量管理规范、软件注册审查指导原则 | 需求可追溯、验证证据完整、版本与变更受控 |
| MDR（欧盟） | MDR 2017/745 附录I 通用安全与性能要求、附录II/III 技术文档 | 风险管理与验证证据联动、全生命周期可追溯 |
可以看到，法规并不要求某一种特定工具，而是要求可证明的对应关系。审评员真正关心的是：这条风险控制措施对应哪条需求？这条需求由哪个测试用例验证？测试结果是否覆盖了边界与异常？变更后证据是否同步更新？
三、核心价值：不只是为了过审
如果只把追溯当成“审评前补文档”，投入产出会非常低。它的真实价值体现在四个方面：
- 降低漏测与漏实现风险：通过双向追溯矩阵，快速发现“有需求无测试”“有测试无需求”“有设计无需求”的缺口。
- 支撑变更影响分析：当某条需求变更时，可沿追溯链定位受影响的设计、代码、测试与风险项，避免“改一处、漏一片”。
- 提升审评与审核效率：证据按需求组织、可检索、可导出，减少现场翻找与反复解释。
- 沉淀组织资产：追溯关系与证据库可复用，新项目不必从零重建合规材料。
四、全景学习地图
本课程围绕“从需求到证据”的完整链路展开，可以用下面这张全景图来建立整体认知。它展示了法规输入、需求与风险、设计实现、验证活动、证据库以及追溯矩阵之间的数据流与依赖关系。
这张图说明了一个关键点：追溯矩阵不是孤立文档，而是连接法规、需求、设计、验证与证据的枢纽。证据库则是矩阵的“内容支撑”，没有证据，矩阵只是空壳。
五、最终交付物：学完这门课你会得到什么
本课程不追求概念堆砌，而是围绕可交付成果组织。完成学习后，你应当能够产出并维护以下核心交付物：
- 需求追溯矩阵（RTM）：至少覆盖需求 ID、需求描述、风险项、设计项、测试用例、测试结果、证据链接、状态。
- 验证证据包：按需求或模块组织的测试记录、覆盖率报告、评审纪要、静态分析结果，带版本与签署信息。
- 覆盖率与缺口报告：统计需求覆盖率、测试执行率、双向追溯完整率，并列出未覆盖项与处理计划。
- 变更影响分析清单：需求变更后，自动或半自动列出受影响的设计、代码、测试、风险与证据，明确需回归的范围。
六、怎么学：从认知到落地
建议按“先建框架、再填内容、后做自动化”的节奏推进。前期先理解法规诉求与追溯模型，中期在真实项目中建立需求—设计—测试的对应关系，后期引入工具链实现证据自动采集与矩阵自动生成。每学完一个模块，都应回到自己的项目问三个问题：这条需求有没有下游承接？它的证据在哪里？变更后我能不能快速定位影响范围？
当你能稳定回答这三个问题，需求追溯与验证证据工程就不再是审评前的负担，而是研发过程里真正可用的质量基础设施。