验证文件应该包括生命周期的各个阶段，验证文件的复杂程度应该基于对风险的评估。风险评估应该是一个完整的闭环，对识别出来的风险采取的控制手段应该体现在整个质量体系中。

项目过程中应该进行变更和偏差的管理，当然这是项目阶段的变更，按照OECD的说法，项目变更记录的复杂程度与正式程度可以与运维阶段相比有所区别，但相应的项目过程中发生的变更和偏差，也应该在最终的报告中去总结，对照GAMP 5中的表述，配置管理以及项目变更控制对应的就是欧盟GMP附录11的这两段内容，在最终的验证报告中，应该明确体现出系统是否要以符合预期用途。

欧盟的GMP要求企业提供一个动态更新的系统清单，系统清单中应该体现出系统的GMP相关的功能，所谓的GMP相关的功能，从GAMP 5的描述来看，是和预期用途相对应的，系统的预期用途的描述可以体现在若干的验证文件中，比如用户需求标准，功能标准，当然对于复杂的系统也可以独立成文，至于什么是所谓的Up to Date，无论是GAMP 5还是欧盟的GMP附录11，都没有明确更新的频率是多少，这就需要企业自行定义，是在立项的时候就将系统体现在系统清单中，还是等到系统验证报告批准后，再将系统的信息添加到系统清单中，取决于公司内部的规定。

对于关键的系统，欧盟的GMP建议，需要在验证文件中写清楚系统的架构安排，数据流，与其他系统的接口，甚至还需要包括流程及软件的前提条件以及必要的安全控制措施。

用户需求应该记录下对系统的功能的需求，用户需求应该基于风险评估以及某项功能的GMP影响，用户需求应该在整个项目的生命周期内被追溯。

对此ISPE的解读是欧盟特别强调书面的风险评估以及GMP影响的评估，所谓的书面的风险评估并不是说一定要有一个打分的机制，分出高、中、低三个级别的风险才算。

建立用户需求的时候，考虑到对产品和工艺的理解，比如生产自动化设备的需求是否和工艺的流程或者业务流程进行了有机的结合，尤其是对法规有明确要求的活动，比如审批文件过程中需要电子签名标识签字人的身份，那么在系统设计的时候就需要考虑到在用户需求中体现。

在起草用户需求的下一级文件功能标准的时候，功能标准也应该侧重在于对影响产品关键质量属性的功能进行详细的说明和复核。