温馨提示本文约7000字，建议15~20分钟进行阅读
这是昨晚在质量管理交流群里分享内容，介绍了以下几方面的内容：
1）用户需求文件的重要性，是不是法规要求的必需的文件？
2）用户需求文件撰写过程中应该遵循的SMART原则是什么？
3）如何利用供应商的技术标准文件，偷懒的写一份用户需求？
4）用户需求文件如何与后续的测试文件相结合？
详细内容如下：
一、用户需求文件的重要性，是不是法规要求的必需的文件？
用户需求标准理论上是验证的第一份文件，但是实际上很多的公司其实对用户需求标准文件不是非常的重视，对于很多商用现成软件，很多人会觉得用户需求标准文件可有可无，这其实是一个很大的误区。
我们先来看看计算机化系统附录的第八条：企业应当指定专人对通用的商业化计算机软件进行审核，确认其满足用户需求。
确认其满足用户需求意味着你需要有一份书面的用户需求用于这个确认的活动。
我们一直在说，按照系统的预期用途进行验证，系统的预期用途很多的时候是记录在用户需求标准文件中的，很多公司花很大价钱买了供应商的3Q报告，以为这样就可以满足法规监管要求，但事实上并不是如此，用户需求标准实际上才是验证的基础。这其实很像打枪射击，用户需求标准当中定义了你对系统的需求，也就是你验证或者说确认的目标，有了目标，后续的工作才不至于脱靶，否则真的只能是打到哪里算哪里了。
谈到用户需求，我们先来看看用户需求的来源是哪里？对于工艺相关的自动化设备，你需要将产品生产过程当中的关键工艺通过自动化设备去实现，那么用户需求肯定首先来源于你对工艺的理解，来源于你对关键工艺参数，关键质量属性以及对影响关键质量属性的工艺控制手段的理解。一个最简单的固体颗粒制剂，经过称量后的物料，在流化床造粒机机中进行造粒操作，造粒后的产品或者说半成品的关键质量属性通常包括以下几个方面。半成品粒径大小，粒径分布，颗粒的致密度，可压性，流动性，水份含量是制粒成功的关键。我们以最简单的水份为例，那么回到设备上来说，哪些因素可能与水份含量相关？比如进风温度，干燥时间，那么对于影响这些关键质量属性的参数，设备就应该有相应的控制的能力，而这种控制的能力应该体现在需求中。不同产品的工艺不同，对设备的要求肯定不同，比如干燥时间的控制应该在XXX分钟~XXX分钟内可调节；干燥是否需要根据不同的阶段，自动控制不同的温度；进风温度应该在XXX~XXX的范围内可调节等，与工艺结合，才能写出一个好的UR，UR是基于对流程以及对产品知识的理解而写出的。
对于实验室分析设备，我们以高效液相色谱为例，对于色谱仪的需求往往取决于你的分析方法，方法需要采用怎样的检测器？对流速的要求是多少？是单元泵就够了，是需要多元泵包括需要是否需要进行梯度洗脱？所有的这些方法中的因素决定了你选择怎么样的设备。供应商可以提供你3Q服务，但是需求必须来自于用户自己，没有人可以代替你做决定，到底需要怎么样的设备。很多企业购买了供应商的确认服务，就以为万事大吉了，拿着供应商的文件应付药监部门的检查，N年以前可能这样的做法还可以忽悠过去，但是这两年监管的水平也在不断提升，靠供应商的文件应付检查，没有一个持续保持确认状态的认识，没有一个按照预期用途进行确认的意识，是做不好验证工作的，只能停留在机械的照搬条款的阶段。所谓的按照预期的用途去做确认和验证，设备或系统的预期用途最好的记录的地方就是在用户需求文档中。前面说的用户需求是计算机化系统验证第8条的要求，同时花了一定的时间说明用户需求应该来源于工艺，来源于方法，来源于对产品的认知，不知大家对这一段有没有疑问？我会打开禁言2分钟，大家现在可以发言了...
二、用户需求文件撰写过程中应该遵循的SMART原则是什么？
我继续来分享一下写用户需求的几个原则，概括起来叫SMART：
S代表Specific，具体的：要求是用户需求的表述应该是明确的和详细的，建议采取的句式是某某某系统应该怎么怎么样。比如我们以熟悉的微信朋友圈功能为例，明确和详细的表述。比如，朋友圈功能应支持用户发布图片，短视频，第三方平台链接或文字。
朋友圈功能应支持用户发布图片，短视频，第三方平台链接或文字。这个描述在我看来就是一个比较明确和详细的需求。
相比较而言，朋友圈功能应该支持分享生活的片段以及用户的感悟就不是一个很准确的需求，用户的感悟以什么样的形式呈现出来是必须放在用户需求里的，感悟和片段毕竟是个很空的东西，程序员并没有办法实现你的这种假大空的需求，需求必须可以落在实处。
大家在起草用户需求文件的时候可以刻意的去回避一些不是很准确的描述，比如足够，比如需要符合法规要求，需要符合国标要求等，具体什么叫足够，法规和国标要求究竟是什么，系统需要达到一个什么样的标准，都应该量化下来。
N年前工作的时候，我最反感看到的一条需求就是，计算机系统应该符合21CFR Part11的要求，不知道现在还有没有企业继续这样写UR。
同时Specific还有一个要求是要避免前后文之间的冲突，这就是所谓的准确，对于一些专有的名词，应该在前后文中保持一致。我最近在做一个项目，里面涉及到一个专有名词volumn pool，用户手册上的专业的翻译是重删池，可是也有人将其翻译成容量池，介质池等。
如果说同一份文件，你对同一个专有名词的翻译五花八门，那么会给你后续的验证带来很大的麻烦，这里建议大家可以考虑在文件的开头，设置一个专有名词的对照表，所有的专有名词统一起来，避免产生歧义。
M代表Measurable，可测试的，可以被验证的。前面之所以要求用户需求要明确和详细，实际上也是为了这个原则。关于需求的可测试性我也给大家举一个例子，一台带有自动时间控制的固体制剂混匀机，现在的自控技术可以达到百分之一秒级别的时间控制，那么你的需求应该怎么写？写成某某某设备时间控制的精度应该达到±0.01秒合不合适？
大家可以发表一下自己的看法，合适还是不合适？这个需求在我看来也不是一个好的需求，如果你为了证明你的设备能达到±0.01秒的精度，那么你测试是不是还要用一个更高级别精度的秒变去计时？你人的反应速度有那么快么，能够掐准秒表，证明你的设备符合这个需求么？我看不可能，既然不可能，为什么要把它体现在需求里？那么对于时间控制精度的要求应该是多少呢？这个问题我没法给你一个准确的答案，这个也不该我给你答案，而应该回到工艺要求中去，通常情况下可能±不超过5秒在我看来大多数情况是可以被接受的。写需求的时候必须要有前瞻性，要考虑到能否测试，提了一堆不能测试的需求，不如没有需求。
A代表Achievable，可达到：不要提一些不切实际的需求。我们排除掉一些定制化的系统，你可以提要求供应商帮你实现外，大多数的商用现成的软件其实系统的能力就在那里了，比如一个文档管理系统，支持的文件类型是Office系列的文件合适，比如WORD，EXCEL或者PPT，如果你还要求可以支持PDF格式的文件，装一个插件就可以解决，但是如果你非要这个软件支持CAD格式的图纸文件，那么这可能就是一个不太合理的系统需求。可能需要重新的开发，可能不是一个简单的插件就能解决的，在这种情况下，从风险的角度来说，我倒觉得应该去平衡一下哪些是真实的需求，哪些是锦上添花的需求。任何开发都是有成本的，额外的开发可能会带来额外的风险，这个是你在做项目的过程当中需要权衡的，做用户有的时候不能太任性，做项目管理有的时候需要在用户要求和供应商实施之间做一个很好的平衡。
SMART原则中的R代表Reliably，表示可信服的，可靠的，当然需求可靠往往也需要一个可靠的供应商，遇到一些猪队友有的时候会很郁闷。用户需求写好了，一定要及时和供应商沟通，不要想当然觉得系统肯定能够实现。笔者亲身经历过一个某品牌原子吸收的例子，由于供应商不够专业，我们对系统有电子签名的要求，供应商信誓旦旦会有这个功能，结果设备确认的时候发现如果要有电子签名的功能还要购买额外的模块，产生额外的费用，遇到这种情况，就相当被动了。这一条原则和第二条原则Measurable有些类似，需要是需要被测试的，测试是需要提供数据支持的，数据分析的方法应该在后期制订测试方案的时候制订，但是数据的接收标准往往有的时候会体现在用户需求中，这就要求在写用户需求的时候应该有明确的依据。用户需求中的标准的依据应该是科学合理的，这样才是一个比较靠谱的需求，千万不能拍脑袋定，否则遇到有经验的审计官，问你这个标准的出处，立即就抓瞎了。在供应商标准和国标的基础上，考虑实际的需求去制订标准。供应商的标准有的时候是对新系统的技术指标，系统在运行一段时间后，由于设备的性能漂移，往往会达不到出厂的技术标准，如果你直接把供应商的技术指标抄过来做为你自己的用户需求，通过一开始的验证没问题，但有可能后期会达不到。无论是供应商标准还是国标，对于你来说实际上都只能是参考，有些照搬没问题，有些标准抄的时候要谨慎，这其实也是特别考验验证人员功力的时候。
最后一个起草UR的原则是T，Traceability，可追溯，需求，尤其是关键的GxP相关的需求，应该经过必要的测试，这更多的是后面测试的内容，从UR的角度上来说，给大家一个建议，就是在起草需求的时候按照不同的模块去起草，这样不容易遗漏，测试的时候也会比较容易追溯。每一条用户需求都应该有唯一的编号，这个编号可以用于后续的设计确认与追溯。需求，设计确认和测试，共同构成一个Matrix。
三、如何利用供应商的技术标准文件，偷懒的写一份用户需求
前面说了用户需求标准起草的时候的五大原则，我们下面用一个实验室用的高压灭菌锅的实例来说明一下怎么样起草用户需求标准，在这个过程中如何去利用供应商的技术标准，将技术标准Translate成一个合格的用户需求。
这张图是一个品牌的实验室用高压灭菌器的技术参数，我们着重说里面的几条内容：
比如第一条：Inetegratedor seperated steam generator就可以根据实际的实验室情况，写成下面这样的需求。A. 灭菌器应配置独立的蒸汽发生装置或者B.灭菌器应支持连接工业蒸汽系统，至于到底是写成A还是B，完全取决于用户的硬件情况，这种需求供应商是猜不出来的，他只能提供你设备的设计标准的几种可能性，实际选哪种必须经过沟通，必须经过用户的批准，采购合同是一种规定设备配置的形式，但是通常采购合同不做为法规直接要求的验证和确认文件（当然不能排除合同中的设备采购组件清单可以用于支持IQ过程中的部件检查），所以，你需要有一份书面的需求和设计文件。这里的需求并不需要太过于细致，在这条需求里，你不用去纠结蒸汽发生装置的能力，不用去关注如何将工业蒸汽系统连接到你的设备上去，这一切是供应商需要考虑的问题，同时通过其他的诸如灭菌器体积的需求，供应商能够计算出来。很多情况下我们写UR唯恐不够细致，恨不得将控制面板的型号都规定下来，而笔者认为，写UR的时候应该有所为有所不为，把握一个恰当的详细程度。
从我个人而言，我是比较反感在用户需求当中规定PLC的品牌，但我实际也看过不少用户需求，要求供应商采用西门子的PLC，恨不得连型号都规定好，需求只提要求，至于设备最终是采用哪个品牌的PLC，完全是后续设计阶段的事情。
再比如，例子中的第5行Number of sterialization programs, up to 100，从设备的设计来讲，设备有这个能力储存100组灭菌参数，但是从用户需求的角度来说，你日常使用的灭菌参数可能最多10组，那么你完全可以将标准进行如下的转换：灭菌器应该至少支持设定和保存10组灭菌参数。为什么不写成100组？前面说过，UR是确认测试的基础，如果你要求100组，会给你后面的确认工作带来额外的工作。从这个角度上来说，写一份好的需求文件，实际上也是基于风险验证和确认的体现。我们写的需求是需要和测试相链接的，10组能够满足常规的需求，那么需要放10组又有何妨？
建议在签合同之前，就将UR批准后交给供应商进行设备的采购。当然，这个阶段的UR可能是一个比较粗糙的UR。如果你在采购前就可以拿到类似上面的技术参数表，那么对你起草UR应该是很有帮助的。
四、用户需求文件如何与后续的测试文件相结合
对于实验室设备，在前期的采购过程中，往往用户会和设备供应商进行沟通，沟通自己的测试要求，方法要求，供应商会根据客户的需求进行相应设备型号的推荐。在供应商推荐了相关型号的设备之后，很多企业往往就觉得万事大吉了。其实在这个时间点，你完全有理由向供应商要一份设备的技术标准，然后再次仔细的确认一下技术标准是否满足你的需求，也就是将这份设计标准转换成书面的用户需求。需要指出的是，这个从技术标准到用户需求的顺序严格意义上是错的，我也说了这是个偷懒的方式。采购之前，有的公司有可能会要求已经有批准的用户需求，这个用户需求从我的角度看可以写得简单些，不一定是正式确认文件中的用户需求，更多可以侧重于商务方面的需求，是合同的一个组成部分。而签了合同之后，你可以要求供应商给你提供详细的技术标准，然后企业可以利用下单到到货这个时间段，去起草相关的文件，比如确认计划，用户需求，确认方案等，而不用等设备到货再匆忙准备这些确认文件，这样可以提高效率。当然，你也可以将这个过程再提前些，下订单，签合同前就要求供应商提供技术文件，起草需求，但实际操作中这样的前瞻性的公司感觉并不多。试着将每一条设计标准转化成需求，写需求的时候建议大家用不超过30个字的陈述性质的短句来表述，采用最直接的主谓宾句式结构。这个转化的过程实际上是对自己的分析方法需求的再次确认。你越早期采用供应商的技术标准去建立UR，就越容易发现设计选型过程中可能忽略的问题，这实际上是很重要的对设计确认的过程，很多标准的分析设备，UR和DV是可以合并成一份文件的。
我们来看看几条需求，大家可以评论一下好还是不好：
设备应该能够产生足够量的纯化水，以供日常实验使用。这条大家觉得如何？足够其实并不是一个很明确的标准，比如可以修改成设备产生纯化水的能力应该至少达到100L/小时
再比如，设备产生的纯化水应该符合法规要求和药典要求。这条需求其实就不如明确的把法规要求中关键的参数罗列出来，比如25度时的电导小于XXμS/cm，微生物的限度不超过XXcfu/ml.
今天的分享实际上差不多到这里可以结束了，最后总结一下今天的要点：
1）用户需求文件是确认或者验证的起始点；
2）用户需求应该基于系统的预期用途以及实际的流程|业务需求；
3）用户需求起草的过程中应该遵循SMART的原则；
4）用户需求标准不要拍脑袋确定，可以从供应商的技术文件处得到支持；可以采用偷懒的方法，将学着将技术标准转化成需求的语言表述出来
5）用户需求的详细程度应该把握好，建议用不超过50个字的主谓宾结构来描述，不要将多个需求混在一条中，以便于后期的追溯。
问题1：对于用户需求，是否需要把所有的要求都写进
答复：对于用户需求，不需要把所有的需求都写进去，尤其是对于COTS的软件和系统，只需要写GxP相关的功能和你需要用的用途就可以了，任何测试都不可能无穷尽，任何需求也不可能包括所有的软件能达到的功能。
问题2：URS里面的需求，是否一定要遵守了？如果后期发现过度要求了
答复：后期发现URS中的要求过度了，要看你这个后期是什么阶段，如果是在项目阶段测试阶段发现，那么你可以修订你的需求，如果是在后期由于系统性能的漂移导致需求无法满足，其实是很容易被Challenge系统没有保持在一个验证状态的，这也是我们希望通过周期性的回顾，包括日常的预防维护能够及时发现，并及时解决的。
问题3：对于比较明确需要购买的系统，需要建立详细的需求吗？
答复：个人认为需要，但详细的程度可以基于你对流程的理解定，比如你对于高压灭菌器，你的需求不能只写一个型号，你需要写你的灭菌的工艺对设备的要求是什么
问题4：对于成熟工艺比较好理解，如果对于工艺本身就没什么可借鉴的，如何写
答复：对于新的工艺或新的设备的用户需求，我们需要充分的去理解我们的工艺，调研潜在供应商，来深刻的理解我们的关键需求并最终转化为书面的、可实现的、可被测试的且具体明确的需求说明，这个不仅体现了技术人员的能力，同时也是对验证人员能力的一种考量/挑战。我们GMP附录《确认与验证》中，就要求企业相关人员要进行知识管理，提升对工艺的理解。
联系客服
