需求文档中是怎样设计性能指标（如何编制合格的用户需求说明）

来源：CIO合规保证组织

作者：CIO专家-柳叶

如何做成合格的URS，或者说如何做成一个好的URS？这是一个长久以来一直被讨论的话题，在此文章开展探讨之前，我们不妨先说说，不合格的URS经常引发的几种场景：

场景一，供应商拿到我们的URS，问道：看完你们给我们的URS，我怎么还是不知道你们要的是什么要求的设备；

场景二，供应商看完URS，回复到：你们URS中的要求，我们看完了，可是我们技术有限，做不出来你想要的东西啊；

场景三，工程师看完URS，问URS的作者：URS我是看懂了，可是，我想问问您这几条URS怎么验证；

场景四，验证实施者验证活动完成后，发现他做的测试，不是为了满足有一条URS，而只是为了测试而测试。

这些场景其实在日常的验证工作中经常出现，作者在多年的验证工作中也经常解决这些问题。那怎样才能避免上述问题呢？主要要做到以下几大方面：

第一方面，URS源于需求。

我们说，URS中的每条、每款都不能由我们的工程师凭空想象的，都是必须有出处的。这样做是为了是让每条URS能落地实现，避免URS中的需求被无限扩展而造成的过度浪费。这些出处主要包括三方面：产品标准、法规要求、业务需求。

“产品标准”是URS的根本，因为我们写URS的最终目的，毕竟是让系统被开发制造出来后，能产出满足产品标准的合格产品，所以说URS的条款均是围绕产品标准而制定的。

“法规要求”是URS的指导，这里指的法规不知我们所熟知的GMP，还要考虑其他法规，比如健康安全、个人数据安全等，一句话来说，我们做URS的时候，法规是个圈，我们不能出圈设计我们的URS。

“业务需求”，通常是企业对所引入系统的业务，比如，系统的工作能力，产出能力、生产容量需求等，简单说，这是企业管理层对系统的要求。

第二方面，专业的人做专业的事。

URS是一个高技术类文件，而不应是管理型文件，也不是计划型文件，它里面的条款均是专业技术性很强内容，撰写URS不是一个人能完成的，良好的URS撰写流程应征询不同领域的专家，比如系统产出能力的需求要征询生产人员、设备水电汽的需求要征询支持部门、产品质量方面的需求要征询质量部门、健康安全方面的需求要征询EHS部门等等。这就要求在撰写URS征询意见的时候，不多不少地涵盖不同部门的专业人士，才能做到多不了、少不了、错不了的URS条款。

第三方面，SMART原则。

这个原则是不少企业撰写URS的经典手段，本身SMART原则来源于目标管理，现在被借用到了URS的撰写上。这里的SMART原则是：明确的（Specific），可测试的（Measurable），可实现的（Achievable），切合实际的（Realistic），可追溯的（Traceability）。按照这个原则把URS逐条进行评估，满足这个原则的话，URS会撰写得清楚，为日后与供应商的谈判，与工程师探讨后续项目的测试都很容易进行，标准明确。

在这里举个例子，如果一个企业要上SAP放行系统，该用户以前曾经使用过SAP系统，现在企业立项准备上个全新的替代SAP的系统，这是企业多方面各部门的用户聚集在一起，会把各自曾经适用SAP系统的各种酸甜苦辣都总结出来，形成新系统的URS，这时候的如果一味地把自己的需求无边无际地提出，那么URS就会不那么切合实际，如果把URS写成这个样子，基本上这个项目离失败就不远了。此时的项目经理应把控URS撰写的方向，应用SMART的原则撰写URS。还有一种情形，企业以前没有用过某个系统，只是有一堆需求，这时听了几家供应商的介绍，综合了一下，写出URS，这样的URS更像是系统的功能列表，举例SMART的URS还比较远。系统投入使用后，各种问题就爆发出来，大量的功能根本就不是自己想要的，这也是予以重视，必须避免的。

● 智能生产、智能制造质量代表

● 高级QA工程师、IT QA高级工程师

● 公司级验证专家及IT质量SME（Subject Matter Expert）

● 总部核心验证组及总部IT QA核心组的成员

如果您想和CIO专家-柳叶或专家库约100名专家中的任何一位交谈，请与我们联系。