如何写好GxP行业/范畴计算机化系统的URS？

应用场景：医药企业的研发实验室、质量控制实验室等，用于药品的成分分析、质量检测等环节。

MES（制造执行系统）

主要功能：对药品生产过程进行实时监控和管理，包括生产计划排程、生产过程控制、设备管理、质量追溯等。确保生产过程符合 GMP 规范，提高生产效率和产品质量。

应用场景：药品生产车间，监控药品的生产过程，保证每一个环节都符合质量要。

SAP（企业资源计划系统）

主要功能：整合企业的财务、采购、销售、库存、生产等各个环节的管理，实现企业资源的优化配置。在医药行业，可以帮助企业实现对供应链的有效管理，确保药品的原材料采购、生产、销售等环节的顺畅进行。

应用场景：医药企业的整体管理，涵盖企业的各个业务部门。

CDS（色谱数据系统）

主要功能：专门用于色谱分析数据的采集、处理和管理。可以确保色谱分析数据的准确性和可靠性，满足医药行业对药品质量分析的严格要求。

应用场景：医药企业的质量控制部门，用于药品的成分分析和质量检测。

URS（用户需求说明）：User Requirements Specification的首字母缩写。即用户对自己期望的产品、功能需求的说明文件。

用户在选择设备、厂房、硬件设施、计算机化系统、服务等方面的供应商时，会精心编制多个具体的URS，供应商应据此提出响应，提出具体的方案进行设计和实施。 

本文所提及的URS特指计算机化系统的URS，下不赘述。

法规

• NMPA GMP 附录十：计算机化系统——第四章验证 第八条

• l EU GMP 附录十一：计算机化系统

• GAMP5 2nd

• URS是一个系统实现的前提，没有一份被批准的URS文档，后续工作都将无法开展。
• URS一旦出现逻辑混乱、表述模糊错误、不完整，会直接影响到供应商对用户需求的认知和系统的实现过程，最终间接的影响系统的交付质量。
• 尤其是到了项目后期，URS文档中的需求如果有增减、修改，都有极大可能将导致已输出验证文档升级调整，重新签批，进而导致项目进度受到影响。URS是一个动态的文件，这里并不是禁止在项目后期升级调整URS，只是通过以上努力，尽量减少此类变更的发生。URS与计算机化系统验证（CSV）相关交付文档之间的关联关系主要有以下几个方面：

• 使用递归层次结构编写URS。

△图1 典型的递归层次结构

• 对用户需求进行分级。

考虑以其他方式（例如按质量、安全或业务）对需求进行分类可能会很有用。对于商用和低风险系统，可能不需要优先级。

在适当的情况下，向供应商提供强制性和其他期望需求（强制、期望）的明确说明。

• 在整个生命周期内实现关键需求的清晰沟通和管理。

建立需求沟通机制，在各个相关方之间清晰的传达关键需求的沟通信息。

在整个URS的生命周期内，建立URS的编写、审核、批准、更新、维护、归档的管理措施，并在项目阶段对其进行追溯管理。

针对每条具体的需求而言，良好的URS可采用的原则主要有以下两个方面：

• SMART原则

该原则适用于典型URS的起草、审核阶段。

S代表Specific，具体的：用户需求的表述应该是明确的和详细的。

• 准确清晰。

• 切勿含糊不清。

• 完整的。

• 避免前后矛盾。

M代表Measurable，可测试的、可衡量的。用户需求应能够被测试或衡量的。

• 应确保测试的方法是可获得的与可实现的。

这条虽然很容易理解，但在实际操作中很容易出现偏差。

• 在适当的情况下链接到相关的业务流程步骤，并能为正式测试提供依据（截图、拍照等）

A代表Achievable，可实现的：用户需求应能够实现的。

• 制定用户需求前，应对需求与供方的反馈做出评估和权衡，确保所有的需求是必要的且可实现的，避免提出不是出于需求本身的、不切实际的需求。

• 需求在制定时，应考虑设计约束（即系统必须满足的外部定义的限制，例如硬件和/或软件平台、速度、功率、测试、环境和操作条件）。

R代表Reliable，可靠的，令人信服的：用户需求应是可靠的，所依据的指标应科学合理、可靠并令人信服的。

T代表Traceable，可追溯的：用户需求应是可追溯的。

• 需求尤其是关键的需求（如：GxP、EHS、业务等方面的关键性），应该经过必要的核实（Verify），并在核实（Verify）过程中对其进行追溯。

• 制定用户需求前，应根据用户需求的特点划分成不同的模块，便于说明、核实（Verify）以及追溯。

• 每一条用户需求都应该有唯一的编号，便于追溯。

• 所有的需求应具有逻辑性，建议分条描述，或者采用“主题词+序号”的方式描述，便于追溯。

• 能够通过配置/设计和测试支持完全可追溯性。

• 使用一致的命名约定、唯一标识和版本控制，并维护变更历史.

以上这些原则并不是孤立的，而是互相渗透、互相嵌入的，他们共同支撑起良好需求的各个层次和方面。如：”XX房间的温度应控制在20.00°C”。这条需求不但是“不具体的（S）”，同时，也是无法成功测试的（M）和无法实现的（A）。良好的做法是根据实际的业务需求、结合法规要求和测量工具的精度，提出更合理的（更具体、可测试的、可实现的）需求，比如改为”房间应控制在20.0℃±2.0℃。允许温度不超过7°C的偏差小于10分钟”。

注1：上述SMART原则在个项的解释上可能有多种版本，以上版本仅供参考。

• INVEST原则

该原则适用于软件敏捷开发项目、或者URS的收集阶段，是用于检测用户故事（User Story，“在软件开发和产品管理中，一个用户故事是一个非正式的，自然语言描述的一个或多个软件系统功能。” - 维基百科）是否拆分得当的原则，它由下方6个英文单词的首字母组成。

△图2 INVEST 原则

图片来源：知乎@Richardxp

• 每个用户故事需要彼此独立，低耦合。

• 每个用户故事需要是完整的，对应的每个需求都是相对完整可验收的。这样做的目的有利于团队开发任务分配和保证用户使用场景的完整可用。
  

?Negotiable(可协商原则）：

• 非契约性

在进入开发前，这些故事卡片/需求项仅仅用来提醒团队及干系人进行讨论，而不是作为产品经理与开发人员的契约来使用。这个需求和用户故事不是固定的，是个动态的逐步深入明晰的过程，不是产品经理直接定义好的需求项。这样做的好处能够集各角色之长，使得用户场景考虑的更加全面，减少产品经理因思考不周而造成的决策失误，也能使研发团队更好的理解项目的背景，有助于产品的功能和体验的顺利达成。

• 远粗近细

和人类对于新事物的理解规律一致，用户故事符合远粗近细的原则，避免在一开始就引入太多的细节设计，使得相关人员误以为这个需求已经是非常明确的，不需要再展开讨论。

• 避免细节遗漏

故事卡片本身就是一个沟通的工具，希望借此工具我们能够及时、面对面的沟通，从而避免细节遗漏，尤其是关键细节。

• 迭代性

很多故事是随着对业务需求对场景的理解而不断深化的，所以在迭代开始前，我们后希望能够获取到更多的细节，将用户故事不断完善，最终开发的功能是客户真正想要的。

?Valuable（有价值原则）：

• 指用户故事（功能项）对于用户来说是重要的，有价值的。

这条原则在整个INVEST原则中是最重要的一条，故事必须有价值。这里需要遵循“二八原则”来实现。举个例子，我们常用的微信，大大小小上百个功能肯定是有的，而我们每天用的有几个？文字、语音、视频、朋友圈等等，远远达不到20%，所以很多功能对于我们来说其实是没有太大作用，甚至超过80%的功能你从来没用过。所以我们在收集用户需求时，要重点把握好20%的关键需求，不要把精力浪费在非关键需求上面。

Estimable（可估算原则）：

• 开发团队能够根据用户故事估算所需的工作量。这项类似于开发看到需求之后要对开发周期，工作量，难点有个清晰认识，方便后续开发的顺利推进。

Small&Similar Size（规模小且适中原则）：

• 用户故事必须足够小，尽可能在一个迭代内完成。

• 多个用户故事之间的开发工作量差异不宜过大。这样做的目的是能够保证开发能够合理的预估工作时长，降低不确定因素的影响。此处有一个比较形象的比喻：你对一个足球体积的估算偏差一定远远小于对于月球体积的估算偏差。

Testable（可验证原则）：

• 用户故事必须是可以被验证的。一个是功能开发阶段：开发设计完成之后有明确的验收标准，确定开发完成了该用户需求。另一个是产品发布之后，针对这个场景/用户故事能够收集到明确的市场反馈，是否满足用户需求，有没有达到用户预期等等，方便后续的迭代改进。

• 比如说在一个需求要求对系统性能进行优化，如何没有清晰的测试范围，这个故事是无法进行验收的，这时候我们就需要考虑定义需求的范围、细化验收标准，如页面加载提升到2s以内，这就是我们对性能优化的最终结果，是具有可测试性的。当然可测试是有多种手段的，并不是纯粹的手工测试、界面测试等。

针对上述的INVEST原则，不要误以为所有的事情都必须100%的满足INVEST才算是一个好的需求，实际上除了强调故事必须有价值以外，其他的几个原则都是可以权衡的，不能因为一个故事必须拆成独立的而花费了2天的时间去研究如何去拆，这实际上是得不偿失的，所以我们在需求落地过程中尽量把握一个度，需要适当的批判性思维（Critical Thinking）。

另外，所谓的原则，比如整体和具体的原则，以及SMART和INVEST两个原则，各个原则之间是相互暗含（Self-contained）,且有主次之分（如SMART中的S、T以及INVEST中的V的重要性要更突出些）。

至于SMART和INVEST两个原则，他们的区别主要在于适用的场景不同罢了。前者对于整理和审核URS（不局限于计算机化系统的URS，而且对于其他各种规范如：FS\DS\CS同样适用）更具指导意义，以便于后续的测试、验证和追溯；后者在URS的初始收集阶段或者需求迭代较快、开发进度要求较高的情况下使用起来更高效一些，并且更适用于计算机化系统的敏捷开发阶段。

综上所述，URS（或者敏捷开发中的“用户故事”）在计算机化系统的规范、开发、验证过程中尤为重要，值得在项目初始阶段，花大的功夫去收集和完善。

毕竟一个好的开始是成功的一半。

以上仅是本人对一些计算机化系统验证项目的一些粗浅的认知分享。如有不当之处，欢迎批评指正，下方留言讨论。

1. ISPE GAMP 5 A Risk-Based Approach to Compliant GxP Computerized Systems -Second Edition.

2. ISPE GAMP GPG: Enabling Innovation- Critical Thinking, Agile, IT Service Management.

3. 《用户故事与敏捷方法》 Mike Cohn（美国）著。

4. 《PMP项目管理方法论与敏捷实践》（第三版）王前、刘通、梁敏、王珊珊著。