老生长谈-计算机系统验证
老生长谈-计算机化系统验证（二）-风险评估
1. 前言
在写这篇文章的时候一直在纠结，到底要不要去把这个拿出来整理下，后来想了想觉得还是有必要的。之前做过的计算机软件系统项目，发现客户提供的用户需求实在是没法进行后续的
RTM
（需求跟踪矩阵），因为缺了很多东西。
通过此文章我主要是想整理下一份完整的用户需求规范文档到底如何来写，才能满足基本的验证要求，从而保证后续
RTM
的完整，进而让供应商可完成无论是
4
类软件还是
5
类软件的相关配置或开发。
2. 用户需求规范概述
关键字：用户需求规范概述
用户需求规范作为计算机化系统验证的第二阶段基础（第一阶段是系统评估），其完整性、规范性决定了该计算机化系统的规范、完整，同时也决定了应用该系统以后的相关数据可靠性的基本要求。
从软件系统配置或开发的角度来说，用户需求规范决定了供应商提供的系统是否满足各项需求的同时仍满足其基本的法规要求。之前遇到的是制药企业提供的用户需求规范文档中本身就存在很大的漏洞，而作为软件或系统供应商，本应该是软件或系统的基本功能的反而变成了卖点。就如现在国外的汽车一样，
ESP
是法规强制要求必须配置的，而到了国内却成了
“亮点”、“卖点”。
3. 用户需求规范框架
关键字：框架
作为一份完整的用户需求规范文档（以下简写为
URS
），基本应包含（不限于）的是系统整体描述、系统的功能需求、系统运行的环境需求、系统运行的安全需求、系统数据的安
全需求、系统的性能需求、系统的界面需求、系统的接口需求等。对于其他类型的系统可能还会有材质需求、工艺需求等等。见如下图：
图
1
用户需求规范框图
系统整体描述：用于对系统的高层次的需求的描述，主要包括背景、目的、范围、面向的用户以及该系统带来的益处；系统的主要功能概述；相关的
GxP
要求及其他相关的法规。
系统功能需求：可按模块、业务类型进行分类描述。其描述应当是对功能的最小单元需求，切不可出现如
“系统应实现物料管理功能”的模糊描述。会造成供应商在响应其需求时更加的模糊，甚至模糊处理。其次，描述具体功能时尽量避免用“等”字眼，同样的会造成
RTM
时不可追溯。对于关键数据定义应明确，包括其测量范围、参数控制、逻辑控制等。
系统运行环境需求：物理条件中的温湿度、灰尘、噪音、震动；电源及设施需求；软件环境下（如适用）的数据库需求、服务器品牌需求（有些企业为了供应商的集中服务而统一采购同一品牌的服务器）等。
系统运行的安全需求：软件系统访问时的传输协议需求（如
http/https
）、网络环境需求（内网环境或
VPN
访问）、防病毒需求、故障恢复需求等。
系统的数据安全需求：备份需求（热备
/
冷备
/
频率）、各类默认端口屏蔽需求、
SQL
注入
/
盲注（
web
系统基本需求，如适用）等。
系统性能需求：软件系统的并发访问压力需求、响应速度需求、数据量增长需求（涉及到系统数据库规划）等。
系统界面需求：语言需求、界面样式需求、布局需求等。
系统接口需求：主要用于方便系统的扩展需求，目前常用的接口技术有
Web Services
、
JSON
，由于其技术成熟，风险相对较小。（此处涉及系统集成，不同的系统集成一般不建议使用数据库层面的集成，其风险等级较高，一旦发生偏差则很难发现根本原因。但可采用数据库中间表的方式进行，此表至少应与任何一个系统的所属表隔离）。
通过上述的各类需求（不限于）的描述，基本可满足相关规范要求的同时保证供应商可对
URS
进行明确的响应。
4.
功能需求
-
审计跟踪
关键字：功能需求、审计跟踪
审计跟踪功能本身并不神秘，无非就是对系统产生的数据做到跟踪处理，如发现修改时同时记录历史数据、修改时间、修改人、修改原因等，但不可与
workflow event log
混谈，
WEL
仅仅是对工作流中的操作人、日期进行了记录，并未对其操作的数据进行跟踪记录，是一个软件系统的基本功能。审计跟踪功能包含有全数据跟踪和部分数据跟踪。之前遇到过的需求中有要求全跟踪，综合分析下来发现其实是企业对风险评估不到位。全数据跟踪固然很完整，但对系统的压力、数据的存储等都提出了很高的要求，系统长时间运行后其性能严重降低。所以大家在选择审计跟踪功能时，切不可一股脑的去选择全跟踪，应根据其功能风险评估去做好相应的选择。
上面提到了，审计跟踪功能本身不神秘，但特别繁琐，不亚于其系统本身功能的开发成本，甚至还要比功能开发成本更高。对于软件系统供应商来说最好的做法就是通过各种配置去实现其审计跟踪功能，诚然成本也更高了。这一点国外的一些软件做的还是相当不错的，比如国外系统供应商
Thermo Fisher
的一些软件在这方面就做的很好。
5.
功能需求
-电子签名
关于电子签名需求这块，企业参考的无非就是
FDA_21_CFR_Part_11
，但在实施项目过程中发现企业对电子签名这块的理解的理解有个很大误区：把手工签名后上传到系统中而后在各种报告中展现出来认为是电子签名。。这个我在跟一位
FDA
的专家沟通的时候，他跟我解释的是这只能算是电子签名的一种美化（前提是电子签名功能必须完整）。
完整的电子签名要求包括有（参考中华人民共和国电子签名法【
2015
】
http://www.miit.gov.cn/n1146285/n1146352/n3054355/n3057254/n3057259/c3868973/content.html
）：
1
）
电子签名属于签名人专有，也就是说电子签名所属人必须妥善保管，并且当认为电子签名数据失效后应及时告知有关放，并且终止使用该电子签名。。
2
）
签名时，其操作仅可由所属人控制，也就是说不能带签。
3
）
签名完成后，对电子签名的任何改动都能够被发现，也就是说系统必须有自动校验功能。
4
）
对于签名后的数据或文件的改动，都能够被系统侦测到并明显提醒。
对于签名的形式，可以是任意的。哪怕是系统宋体的签名也是可以认可的。但对系统的电子签名功能有了很高的要求。微软的电子签名认证做的就很完善。
6.
总结
URS
在编写过程中，本身即必须符合相关法规要求，同时应根据企业自身的条件而进行优化，生搬硬抄的
URS
只会将企业限于更深的泥潭。主要表现在计算机化系统上线运行后带来的管理成本的提高，甚至无法做到其符合规范的管理。
对于明显存在高风险的需求，应当严格控制，尽管对软件系统供应商来说实现起来可能很简单。比如原始数据的复制功能，其需求已经偏离了原始二字。
本来还想把数据可靠性的相关需求也加入到这篇文章中来，后来想想还是后续单独列出来整理吧。
ouryao-com
·
因为有你
