注：本指南及其附录的强制要求明确使用“shall”或“must”。使用“should”表示建议。对此，其他适当的合理方法也是可以接受的。使用“can”表示可能或不具约束力的举例。

1.介绍

此为核心文件《计算机化系统验证》的第二个附录，当计划、执行和记录复杂计算机化系统验证时，应与其一起使用。EXCEL电子表格的验证见附录一，本文不适用。

2. 用户需求规范(URS)

新软件和相关计算机和实验室设备的选择和购买应遵循基于计算机化系统的既定使用需求的决策程序。用户需求规范(URS)应描述计算机化系统软件和硬件的功能和技术要求。同时，应包括信息安全和数据可靠性方面的要求。

包括：

a) 软件的描述(如EXCEL、Access、Oracle)，包括版本

b)硬件配件和操作系统的要求

c) 功能的描述

d)数据属性的描述

e)专业术语

f) 数据库设计，包括mask和field以及数据关系图

g)宏指令、公式和控制命令的规范

h) 数据输入的规范(如格式、小数位数、单位)

i) 数据必填项目的规范

j)Mask、工作表或整个应用的保护

k)数据迁移的计划，如适用

l) 数据输入、修改(审计追踪)

URS应由具备相应责任的人发行。用户需求可以修改但应可追溯，用户需求文件应进行版本控制或使用具备同等效力的系统以确保可追溯性。新增或修改用户需求应向所有相关人员沟通。

3.安装确认(IQ)

系统硬件和操作软件在IT环境的正确安装应被记录并测试。应有详细的安装规程并只能由受良好培训的人员实施。

检查表，包含既定安装步骤和接受标准可以保证系统的正确安装和安装确认的可追溯性。

大多数情况下，计算机化系统通过界面与计算机网络连接到其他软件(其他应用)和硬件(计算机设备或实验室设备)。应确保系统正确完整，所有部件可用。

IQ通常包括：

a)检查系统资源，包括服务器和客户端，如适用。(如支持的操作系统、数据库引擎、处理器性能、硬盘可用空间、内存、访问权限)

b)系统部件的文件记录(至少描述部件和版本)

c)可用访问应用的用户或用户组清单，包括访问类型。

d)与其他系统/设备的接口的连接测试和/或通讯测试

通常，安装由供应商和内部IT部门支持。

4. 运行确认(OQ)

软件的正常运行应通过测试关键功能来检查，如校准和定量(内部标准品，外部标准品)、峰鉴定和系统适应性参数的计算。

理论上，可以用一组已知结果的原始数据序列进行测试。这些原始数据序列通常由软件供应商提供，通过软件处理，结果与预期数值对比。

如果没有这样的数据序列，可以通过运行典型的样品来获取原始数据序列。这些原始数据序列的结果应使用标准软件(如电子表格)验算关键参数(如标准品的峰面积校正曲线)。

功能测试的原始数据影响测试结构，其相关测量不确定度(输入、输出数据，截屏)应被记录于确认报告中。

在安装新的软件模块、新的软件版本、新的服务程序包、补丁更新后，或在计算机的软件结构发生重大变更后应基于风险进行运行再确认。对于每次硬件平台的变更或系统升级，也应采取类似的方法。

5. 性能确认(PQ)

性能确认的目的是证实计算机化系统在用户自身环境下符合其URS中定义的用途。应在PQ阶段测试用户需求，覆盖系统日常事务中的总体业务应用。

PQ通常包括：

a) 功能测试(如使用数据序列确认应用软件的每一个特性)

b) 负面或边界测试(如输入超出规定范围的数值)

c) 报警显示测试，如适用(如OOS结果展示)

d) 数据非授权输入和应用软件非授权访问

e) 异常数据测试(如输入错误格式数据)

f) 备份系统和恢复测试

g) 数据迁移确认，如适用

h)数据保护是否符合要求，如适用

i) 黑盒测试作为整个系统的可接受性测试

每一个测试均应可以追溯至URS并应描述预期结果、接受标准和测试结果。所有不符合预期结果和接受标准的偏差均应在测试报告中论述。偏差可能引起系统变更并重新测试，也可能判定可接受并记录，更新相应的URS。应在确认报告中记录测试的原始数据(输入、输出数据，截屏)。

6. 放行使用

验证报告应总结所有测试的结果，包括所有偏差和采取的纠正措施。当所有偏差均得到解决或接受后，系统才可以正式放行。