计算机化系统验证(七)-系统规格.pdfVIP

1.前言

系统规格包括了功能规格和设计规格，是供应商提供的相关文档中的

重要文件。此处的提供我表明4类软件系统和5类软件系统。当然这里的

规格文件也并非软件开发过程文档中的功能概述、设计概述、详细设计等

中的任何一个文档。规格，是供应商提供的关于软件系统的标准，是最小

单元的描述，但又不是最详细的描述。在此我还是站在验证的角度来具体

说明。

其实这块的东西对于非计算机相关专业或者没有学习过相关知识的人

来说几乎是很难看明白了……

2.功能规格FS

功能规格包括有硬件功能规格HDS和软件功能规格SDS。其功能规格

的文档的编写，各个供应商都有不同的逻辑/模板。其实这里的功能规格描

述主要是对URS中的各个需求描述的实例化。比如：用户需求中要实现某

个条码标签，其需求也给出了条码标签的模板，那在功能规格中就必须给

出这个条码标签的生成业务逻辑、标签中每个字段的长度、字段的类型（数

字、日期、字符、布尔值等）、字段的校验规则等。其目的是在后续功能

风险评估中有对应的风险分析以及后续的测试用例的编写过程中对其进行

详细的测试。又比如，URS中有库存管理的相关需求，则在功能规格中应

当完成对库存管理功能的说明。如库存管理业务逻辑、相关的判定规则、

使用条件、操作权限、数据增量说明、查询组合条件等等。对于4类软件

甚至可以明确给出相关的系统界面等。

对于中大型计算机软件系统，其功能规格可以由多个文档组成。详细

程度应能正确实例化URS中的需求项即可。必要时应增加相应的业务逻辑

图以及截图说明。关键的还是对每个需求描述中的相应的功能进行标准实

例化，说白了就是应当说明这个功能能做什么、怎么做的、怎么控制的等。

还有一点就是要能看明白……

3.设计规格DS

设计规格同样的包括了硬件设计规格HDS和软件设计规格SDS。其文

档的主要内容是用来完成系统的架构设计、编码语言的选择、编码逻辑的

设计、数据库相关的设计、数据库字段的实现等。

这块对于制药企业的用户来说，想看明白就更难了。后续的设计确认

DQ更是无法完成。所以国外的有些专家已经将设计确认DQ更改为了设计

审核DR。尽管一词之差，但做法就完全不同了。确认是获得证据以证实其

设计的满足性、合理性。而审核只是进行审查与核对，是对DS是否满足了

功能规格中的相关功能描述进行核对。

对于4类软件来说，其设计审核可以不提供，当且仅当有个性化需求

开发的时候才进行设计审核DR，同时其设计审核报告的起草与批准由制药

企业完成。对于后续的源代码审核SCR应当由非编码人员进行，如果源代

码处于供应商专利或保密策略中，也可以不进行相关的源代码审核。但供

应商应当出具相应的文件进行说明。对于5类软件来说，其DR、SCR都应

当由供应商提供，同时制药企业应当进行相应的审核并出具审核报告。

4.需求跟踪矩阵RTM

此处的需求跟踪矩阵为第一版。主要用来描述用户需求说明书URS、

功能规格FS、设计规格DS之间的对应关系。

制药企业应当建立其需求跟踪矩阵编写规程。RTM其实是对供应商提

供的FS和DS的一个审核过程。应当对URS中提及的每一条需求进行逐一

罗列其对应的FS和DS。可能会出现一对多、多对一、多对多的关系。无

论哪一种情况都应当罗列清楚以便于进行需求的跟踪。

需求跟踪矩阵是必查文档！

5.文件职责清单

制药企业应当建立文件职责清单列表，以说明计算机化系统建设过程中

的相关文件的起草、审核、批准过程。

图1文件列表清单

对于4类软件来说，源代码审核和审计审核报告可以不提供，但对于5

类软件来说，应进行提供或执行。

6.总结

其实这块真没啥好说的，因为各个供应商都有一套自己的相应的质量管

理体系，怎么做都有明确的目标，至于提供的文档对或不对，是无法用一

两句话来说明的，只是我们要清楚计算机化系统关注的是什么（真实性、

安全性、可追溯性），提供的是否都包含了这些基本的要求即可。