一、URS介绍

ISPE调试与确认第二版2019年发布的指南中，把User Requirements Specification（URS)放在一个重要的位置。在该指南中认为URS汇集了来自多学科资源的系统需求，以支持系统设计、C&Q、操作和维护。在C&Q 流程中，它是一个基本文档，用于识别系统的产品和流程要求。这些与产品质量相关的用户需求是基于产品知识(CQAs)、流程知识(CPP),监管要求和组织/现场的质量要求。URS 中产品和流程要求是 C&Q 流程的输入；它们提供了基于科学的知识，形成了将QRM 应用于C&Q 的基础。

现基本上的做法都是为直接影响熊起草URS，在ISPE C&Q中建议为每个可能影响产品质量的系统或者直接影响系统开发URS。但是URS的表现形式可以是多样的，并非所有的均需要形成正式的URS（如后文模板），URS的表现形式可以是采购申请、功能规范、变更请求或数据表。对于标准的或现成或简单的设备，系统的URS内容可能仅是一个采购订单，或者供应商的产品介绍单。

无论URS的表现形式是什么，系统的验证都是根据需求进行验证的。

URS应用可验证的术语说明需求，不需描述如何满足及无法核实的参数。应描述项目的背景和系统的预期用途、描述需求类别和需求来源，还需包含数据完整性要求、数据存储和显示要求、报警要求、自动化要求。

需求的类别可以有：质量、商业、HSE、过程要求、自动化和记录、设计和建造、操作与维护、其它，如果类别不适用可输入"不适用“。这里之所以分类是为了让需求更清楚，哪些是质量关键必需满足的，哪些不是。这里可以简单的分类，法规和影响质量需求的内容就可以是划为质量类、商业类的为可能涉及到费用或者期望达到的。

需求的来源一般有：产品和工艺知识、GMP法规要求、质量控制要求、风险评估、受控的参数范围和精度、区域和场地要求、HSE及系统所有者的需求、工程和行业规范需求。

以下URS模板是将URS与合同中的商业要求完全分开，对于C&Q中，他给出的模板是一个纯粹站在用户的角度提出的一个URS，但是在实际的执行过程中，往往URS中没有提出的需求，在合同中容易遗漏，因为这是两个部门执行的事情，需求部门是一个团队，采购合同部门又是一个团队，所以我个人建议还是将一部分需求纳入到URS中，比如文件的需求，可以划为其它类型中。

URS名称、编号、版本号

URS审批页

正文

1目的和范围：确定URS将涵盖的系统

2术语和缩写

2.1术语

2.2缩写

3.参考

4．系统概述

提供一个简单的系统描述并展示它如何与其他系统接口。如适用，列出输入和输出。

可参考适当的工艺流程图、数据流程图、网络图等。

如有必要，列出管道和仪表图，以明确定义用户要求的范围。

5.     用户需求

下表定义了XXX系统的用户需求。每一个表格都包含用户对某一功能领域或专业的需求，如工艺、设计和施工、操作和维护等。

自动生成的唯一需求号、

要求 、

类型（下拉菜单，允许选择质量、EHS或业务或其他作为属性类型，确定哪些是质量关键必需的，哪些不是）、

来源（项目要求文件、产品和工艺知识/GMP法规要求/质量控制要求、风险评估、受控的参数范围和精度、区域和场地要求、HSE及系统所有者的需求、工程和行业规范需求）。

5.1.     工艺与技术参数

5.2.     材质与加工制造要求

5.3.     自动化和记录

5.4.     EHS要求

5.5.     公用工程

5.6.     操作维护

6.     变更

注：QRM:质量风险管理