验证从业者谈URS编写常见问题与避坑经验

前几天培训，给用户说了，URS绝对不是形式。URS写不好，后面都是扯淡。

今天一大早，被员工反问。

我正在吃两个URS不是自己写的苦。

一般我都会说URS分为两种，采购的和验证的。

采购的URS的猫腻就不多说了。

验证的URS还是要遵循SMART的原则的。

我有一个项目，需要每一步测试都要有对应的URS。客户在审核测试用例的时候就问我，为什么一步会对应这么多URS？我说因为你们的URS没有遵循SMART原则，好几个URS说的都是一件事，甚至都是一个功能。

例如：

系统应该能够集成域控。这是一条URS。

系统能够识别域控账户。这又是一条URS。

还有就是URS写的太笼统。有个项目，系统控制N个设备。URS统一有个设备安全的章节的URS，这个URS没有对应具体的设备，而是所有设备都要满足设备安全的要求。这个就造成了有些设备不具备这些功能的，在DQ还需要额外说明。

另外一个项目，我是半路接手的。之前的验证服务商就是把网络设备的说明书全部转到了URS上，IT基础设施的URS写了三百多条。很多功能在这个项目上根本不用。结果也写上。虽然中途改了一些，但是我根本不确定用户用哪些功能。而写URS的用户也不是之前参与IT验收的人。最终在执行OQ的时候，发现很多功能，系统没有。或者有些功能系统有了，但是我们要做相关的测试需要准备很多。例如分布式存储，目前根本没有应用搭建在分布式存储上。那么相关的权限测试就需要我们先在windows层面去搭建一个共享存储，然后才可以测试。

之前做SAP的验证的时候，我经常说URS要SMART，要不然风险评估和确认活动会很难追溯。不过我们写DQ还有RTM会很难看，业主验收的时候也没法确定是否所有的URS都被满足了。

然而这两个项目就是因为我前期的疏忽。想着这两个小项目就算URS有问题又能怎么样。结果现在搞得我们这么被动。

最终，还有一些对验证不是很大的URS的建议，也和大家分享一下。

问题1：把法规条文抄一遍

这种URS最常见，也最没用。比如：

"系统应符合21 CFR Part 11的要求。"

"系统应确保数据完整性。"

"系统应具备审计追踪功能。"

写这种URS的人可能觉得"反正我写了合规要求，出了事赖不到我"。但问题是，这种URS对验证团队没有任何指导意义——"符合21 CFR Part 11"具体是什么意思？审计追踪要记录什么？数据完整性怎么保障？全都没说。

问题2：功能需求和合规需求分开写

有些团队会写两份文档，一份是"功能需求"，一份是"合规需求"。看起来很专业，实际上是给自己挖坑。

因为在实际开发中，功能和合规是分不开的。修改一条检验记录，既是功能（修改数据），也是合规（需要记录修改原因、审计追踪、电子签名审批）。然后做的时候，其实执行空间就很大，哪些执行审计追踪，哪些不做，不做依然能够响应URS。这样很容易造成验证的疏忽。

问题3：需求写得太大太空

比如：

"系统应具备良好的用户体验。"

"系统应保证数据安全。"

"系统应高效稳定。"

“系统应该确保扫描速度在100ms”

什么叫"良好"？什么叫"安全"？什么叫"高效"？这种需求没法测试，没法验收，写了等于没写。

100ms的测试也是我们没法执行的。

最终，劝一下大家，和自己，在写URS的时候付出12分的努力，会节约我们后期大量的工作。

最最后，劝一下大家，和自己，接手做了一半的项目的时候一定要慎重。我在20年的时候结过一个，疲惫不堪。当时和同事还有同行以及自己说了好多次。没想到6年后忘记了。又踩坑了。