前文参考EU GMP Annex 11升版 2022.11概念性文件 ：
- 速读（一）:前言，第1,2条【升版目的、备份还原等数据有效性（
升版目的、备份还原等数据有效性）】； - 速读（二）：第3,4,5条【人为干预数据，Pharm4.0， CSV的原则和本质（人为干预数据，Pharm4.0， CSV的原则和本质）】；
- 速读（三）：第6,7,8条【云服务，CSV供应商评估与管理（云服务，CSV供应商评估与管理）】
9.[修订原章节4验证 4.1]对于计算机化系统应用的验证（或对于IT基础设施的确认）将被重新定义。（验证）URS应该包括验证中的工作和系统应满足的特定的功能；
大侠解读：一个计算机化系统的URS用户需求文件到底需要包括些什么内容？这点我们可以借鉴GAMP5 对于计算机化系统全生命周期的所有重要活动，如下图，作为GxP用户和软件厂商达成的项目共识，甚至作为商务合同的主文件，CSV URS应该主要包含以下几类内容：
1.项目实施方法论及交付物（左边部分验证V模型和顶部QRM风险管理工具）
2.CSV合规重点功能（中间部分诸如备份还原、审计追踪、用户管理等重点功能）
3.IT系统管理与运维（右边部分诸如系统上线后如何管理好验证环境与生产环境 – 具体可参考文章《GxP MES项目实战经验系列1 - 多个环境的设置（GxP MES项目实战经验系列1 - 多个环境的设置）》）
GxP MES项目实战经验系列1 - 多个环境的设置）》）4.供应商评估与管理（底部如何评估IT厂商产品是否适合GxP合规 – 具体可参考文章《CSV供应商管理合规探讨（集团化管理或外包IT服务）（CSV供应商管理合规探讨（集团化管理或外包IT服务））》）
CSV供应商管理合规探讨（集团化管理或外包IT服务））》）
10[修订原章节4验证 4.1]基于风险管理（上文的ICH Q9），系统的确认和验证应注重挑战（测试验证）系统涉及质量决策、产品质量、数据可靠性以及有特殊设计或者客制化的功能模块。
大侠解读：这一条再次重申了计算机化系统验证CSV，不是搞IT软件功能测试（Software Testing），而是验证和确认使用计算机化系统的自动化功能/信息化流程替代人工操作或纸质记录的合理性！
同时因为CSV不是IT software testing，不应该也不可能把所有软件的所有功能都测试一次当CSV验证通过（或正向、反向及挑战性的多方面测试），那么CSV测试重点就应该是基于QRM 质量风险的重点（数据是否用于质量放行）；其他的部分【特别是IT技术方面】可以适当的引用行业内成熟产品或者标准，而不做重复性IT性能测试（比如市场上通用的数据库软件，备份还原做一次就能证明可用性；做三次，结果不会有变化，也没有任何本质上的改变）。
当然，如果软件本身或其中某些功能是客户定制化的（Coding in Customer Case），属于特殊情况，不能用CSV 3Q所使用的黑盒测试法【预期输入在特定业务场景中是否能得到预期输出作为可接受标准】，需要进行要求更高的白盒测试，这里就不展开讨论了。
11.[修订原章节4验证 4.4] 原先法规“用户需求应在系统全生命周期内可追溯”的描述不够清晰；用户需求URS（或者其他类似目的的文件）作为一份描述所有GxP所需重要自动化功能，也是GxP用户所依赖的项目文件，应该成为所有系统确认和验证的基础，无论这个文件是否是由GxP用户或者系统厂商起草；URS应该在整个系统生命周期保证持续更新，并且与功能说明文件（FS、CS、DS等）和测试文件（IQ、OQ、PQ等）保持一致。
大侠解读：这一条简单来看，主要是对RTM（Requirement Traceability Matrix）需求追溯矩阵的要求-需求追踪矩阵RTM将会被建立以确保用户需求URS的可追溯性:覆盖到从用户需求到技术设计文档【FS、CS、DS及DQ】最终在IQ、OQ、PQ的测试用例得以响应和验收的“计算机化系统全生命周期管理”-SLC。
但更深层次看，这是从合规层面规定了CSV URS和项目变更Change的关联关系：比如学过PMP项目管理的小伙伴应该知道，项目实施过程中，项目目标或者范围的变更是如何“牵一发而动全身”的影响整个项目推进 – 而GxP IT System项目，URS就担当了“项目目标或者范围”；因此CSV验证阶段的项目变更虽然一般不判断为GMP体系变更(笔者个人项目经验而言) ，但是一旦在项目进行过程中，发现有新的业务或者功能需求需要变更URS时，所涉及的验证文件修订和补充验证测试工作都是需要纳入考虑和评估变更时机的（一般以OQ结束，PQ开始作为一个分界线）
12.[修订原章节4验证 4.5] 需要注意的是，目前软件开发行业使用敏捷方法作为开发是非常普遍的；但是在GxP合规领域接受（基于敏捷方法开发）的软件和相应文件时，需要考虑其中的风险。
大侠解读：这一条Annex 11 的修订意见看得到EMA的内心矛盾：大概是所有立法机构遇到行业科技发展比立法进程更快时都会遇到的问题
传统瀑布式开发的基本流程是 需求 → 设计 → 开发 → 测试 ， 是一个更倾向于严格控制的管理模式 。 要求有明确的需求，大家按照需求一步步做好规划，每一阶段工作的完成是下一阶段工作开始的前提，每一阶段都要进行严格的评审，保证各阶段的工作做得足够好时才允许进入下一阶段。瀑布式开发虽然有诸如耗时长，文件多等缺点，但对于GMP验证的V模型来说，这些都天然满足验证V模型需求的。
相反而言，敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把 用户（客户 ）最关注的软件原型做出来，交付或上线，在实际场景中去 快速 修改弥补需求中的不足，再次发布版本。通过一些敏捷实践方式，细化对象，提供更小的迭代。如此循环，直到用户（客户）满意。敏捷开发模式虽然在软件开发上灵活和快速响应的优势，但是对于CSV验证的V模型而言，反而违背了环环相扣的验证步骤逻辑，没有验证文档，而有变更开发这一要求的。
未完待续
