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