计算机化系统验证（七）-系统规格

恨我不成钢

1.  前言

【如果您对我整理的本系列计算机化系统验证文章有兴趣，可在论坛中查找“老生长谈”类相关帖子，或者可以关注个人微信公众号“CSV_Refer_2017”查看历史文章。如果您有任何意见或建议可以回帖留言，我定第一时间回复您！谢谢！】

       系统规格包括了功能规格和设计规格，是供应商提供的相关文档中的重要文件。此处的提供我表明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类软件来说，应进行提供或执行。

wwhcom

学些了谢谢无私的分享

北重楼

追溯矩阵是不错的方法。

韩天相

谢谢楼主，以后经常关注楼主的帖子，受益匪浅

piaopiaohu003

学习一下，谢谢楼主的分享

simonpeng1101

很有用，谢谢分享！

小金库

这么好的资料，值得拥有