网硕互联帮助中心
2018 年那套 LIMS（实验室信息管理系统，Laboratory Information Management System）选型，我把 URS（用户需求说明，User Requirements Specification）发给三家供应商，回标价格差了将近三倍。采购拿着三份标书回头问我一句：三家报的不是一个东西吗？
我给价格最低那家打电话，问为什么这么低。他说：你们写「界面友好、操作简便」，我们就按标准功能估的。
那一问我才明白，问题不在供应商，在我那份 URS——写满了形容词，没有一条能判对错。
法规要的是「可追溯的需求」，不是一段描述
GMP（药品生产质量管理规范）附录《确认与验证》（2015 年发布，2015-12-01 施行）把设计确认的起点指向用户需求：设计要逐项对照需求做确认。
附录《计算机化系统》（2015 年发布，2015-12-01 施行）要求系统需求在生命周期内保持可追溯。
EU GMP Annex 11（欧盟 GMP 附录 11，2011-06-30 生效）第 4 章 Validation 里有一条专门讲用户需求说明，要求它描述系统必须具备的功能，并保持可追溯。
要存电子记录、要用电子签名，就得把 21 CFR Part 11（1997-08-20 生效）的要求拆成条目写进 URS，不能只写一句「符合 Part 11」。
GAMP 5 第二版（ISPE，2022 年发布）把需求规格放在「能追溯到设计、能对应到测试」的位置上。
四份文件说的是同一件事：需求不是写给供应商看的说明，是后面每份文件都要回头对的那条线。
三种写法，错在同一个地方
第一种，形容词堆砌。
「界面友好」「操作简便」「性能稳定」「符合法规要求」。这类话供应商照抄回你的标书，看着一字不差，其实什么都没承诺。
第二种，拿供应商的功能清单倒填。
先把三家演示看完，再把他们的功能列表改成「我方需求」。这样写出来的一定做得出来，问题是：你家流程里那些特殊的地方，一条都没进去。
第三种，只写功能，不写约束。
功能写了三十条，数据量、并发人数、接口协议、审计追踪留几年、报表格式，一句没有。供应商按功能估，这些全算「包含在内」，上线前逐项加钱。
三种错法一个根子：把 URS 当成「向供应商提要求」，没当成「自己验收时的判据」。
换个写法：每条需求都要能设计出一个测试
这套活儿叫计算机化系统验证（CSV，Computerized System Validation）。URS 是它的第一份输入文件，写歪一个字，后面 IQ（安装确认）、OQ（运行确认）、PQ（性能确认）全跟着歪。
第一步，先列流程，不列功能。
把「谁在什么岗位、拿什么数据、做完这一步交给谁」写成流程清单，一条流程一行，注明产出什么记录。
为什么：漏功能最常见的形态不是忘了写，是压根不知道有这个环节。
第二步，每条需求用同一个句式写。
「系统应能〈动作〉〈对象〉，〈判定条件〉」。判定条件必须是能查的：字段长度、时间范围、必填项、允许的角色、响应秒数。
为什么：判定条件就是验收时的判据。写不出判定条件，说明这条需求还没想清。
第三步，给每条需求编号和优先级。
编号取「URS-模块-序号」，优先级分三档：必须、应该、可以。
为什么：供应商按「必须」估，另两档留作谈价空间；没有优先级，砍需求时只能凭感觉砍。
第四步，把非功能约束单列一节。
数据量、并发用户数、接口清单（含协议与频率）、权限角色、审计追踪范围与保留期、备份与恢复、报表输出格式（含打印模板）。七类各写一段。
为什么：这七类是价格里最容易变成「另外计费」的部分，也是检查时最容易被追问的部分。
第五步，写完做一次可测性自检。
逐条问：这条需求，我能设计出一个测试用例吗？能判通过或失败吗？答不出就退回重写。
为什么：URS 写不清，测试用例一定写得糊；用例糊，OQ 就变成走过场。
交付件：URS 骨架 + 可测性自检 10 问
表一是骨架，一节一页，填完就是一份能发标的 URS。第三列是被供应商顶回来过的写法。
| 1 目的与范围 | 本文件适用于 XX 系统，覆盖 A/B/C 三个流程，不含 D | 只写系统名 |
| 2 流程与角色 | 共 N 条流程，每条注明发起岗位、审批岗位、产出记录 | 写成部门列表 |
| 3 功能需求 | 按 URS-模块-序号编号，句式统一，每条带判定条件 | 只写功能名 |
| 4 非功能约束 | 数据量、并发、接口、权限、审计追踪、备份、报表七类各一段 | 整节缺失 |
| 5 数据与记录 | 产生哪些记录、保存几年、以什么形式保存、谁可修改 | 只写「符合法规」 |
| 6 接口清单 | 每个接口写方向、协议、频率、失败处理 | 只写「可与 XX 对接」 |
| 7 假设与边界 | 本期不做的事、依赖甲方先提供的东西 | 不写，后期扯皮 |
表二这 10 问，任一条答不上，这条需求就还不能发出去。
检查官会怎么问
「这条需求怎么验收的？」
答：报需求编号，翻需求追溯矩阵（RTM，Requirements Traceability Matrix）指到对应用例，说出判定条件。答「按供应商的验收方案做的」，等于承认 URS 没起作用。
「URS 是你们写的，还是供应商写的？」
答：翻版本记录，起草人是甲方业务与 IT，批准人是 QA，供应商只提意见。供应商代写、甲方只签字的 URS，检查时基本站不住。
「上线后加的这个功能，在 URS 里吗？」
答：走变更控制评估后升版 URS，同步升 RTM 与测试用例，版本号写进变更单。答「口头提的，供应商直接做了」，这一条就落成缺陷。
一句总结
URS 的第一读者不是供应商，是验收那天拿着用例回头对的人。
下一篇：第 12 篇《需求追溯矩阵 RTM：为什么检查官必看这张表》——一张表证明每条需求都被测过，缺行就是缺证。
法规依据
关于我
在实验室一线待了 13 年（9 年制药 + 4 年第三方检测），做的一直是实验室信息化。做过某商业 LIMS 产品的甲方 PM——一期、二期两轮上线都由我主导（招标到 3Q 验证到验收全流程）；也在那套系统上自己做过二次开发——把纸质的账号申请流程搬到线上跑；在那之前还有 6 年多 CS 架构 LIMS 的使用与运维经验（其中一段经远程桌面接入）。现在专做实验室里那些重复劳动：报表自动生成、仪器数据对接、合规文档批量处理。
本科物理化学、硕士计算机化学，既听得懂 QA 说的变更控制，也看得懂仪器导出的原始数据长什么样。SOP、偏差、OOS、样本流转这些词，不用你解释。
现在主要做这几类：
– 检验报告与台账批量生成：模板不动，数据自动填，格式一步不错
– 仪器数据对接：色谱、光谱、酶标仪导出的原始文件，解析、清洗、入库、转成报表
– 合规文档自动化：SOP、验证方案、批记录这类重复文档的批量生成与核对
– 数据完整性核查：按 ALCOA+ 逐条核对原始数据与记录是否对得上
手里有这类活儿卡着，或者只是想问问能不能自动化，都欢迎评论区聊，先把问题说清楚再谈怎么做。
评论前必须登录！
注册