3. 设计输入与需求工程

设计输入是医疗器械设计控制的起点，也是后续设计输出、设计验证、设计确认和变更控制的共同基准。它的本质不是“把需求写下来”，而是把来自用户、临床、法规、标准、企业内部质量体系以及风险管理的多源要求，转化为一组明确、无歧义、可测试、可追溯的工程陈述。设计输入一旦含糊，验证就只能靠解释，确认就只能靠印象，最终导致设计历史文档无法证明产品安全有效。

需求工程的核心工作可以概括为三条主线：来源识别与转化、可测试性构造、追溯与验收准则绑定。下面按实际工作顺序展开。

一、需求来源的识别与分层

设计输入不是凭空编写的。典型来源包括：用户需求（使用场景、操作习惯、期望结果）、临床需求（诊疗流程、患者群体、临床终点、并发症控制）、法规要求（注册审查指导原则、强制性标准、不良事件报告要求）、风险管理输出（危害、可预见误用、风险控制措施）、以及产品维护与兼容性要求。这些来源的表述方式差异很大：用户说“希望操作简单”，临床说“不能漏诊”，法规说“应符合YY/T 0316”，风险说“应防止误触发”。

需求工程的第一步是分层：把原始陈述分为用户需求层、临床需求层、法规/标准层和风险控制层，再统一转化为设计输入层。设计输入层必须使用工程语言，例如“设备在环境光100～100000 lx范围内，显示屏对比度不低于4.5:1”，而不是“屏幕要看得清”。

二、可测试性：把“形容词”变成“判据”

可测试性是设计输入质量的核心判据。一个需求如果无法设计出验证或确认方法，就不能作为设计输入。常用做法是采用参数化句式：主语 + 动作/状态 + 条件 + 量化指标 + 验收判据。例如：

• 模糊需求：“报警要及时。”
• 可测试需求：“当血氧饱和度低于90%并持续5 s时，设备应在10 s内发出中优先级视觉报警，报警灯亮度不低于100 cd/m²。”

可测试性还要求明确测试边界：正常条件、最坏条件、边界值和失效条件。例如温度范围应写成“10 ℃～40 ℃”，并注明在该范围内所有功能符合要求；若只在25 ℃验证，就不能声称覆盖了全范围。

三、可追溯性：需求不是孤岛

可追溯性要求每条设计输入都能向上追溯到来源，向下追溯到设计输出、验证方案和确认证据。实际做法是建立需求追溯矩阵，至少包含：需求编号、需求描述、来源、验收准则、对应设计输出、验证方法、验证结果、确认证据。追溯不是文档装饰，而是变更影响分析的基础：当临床需求变化时，能快速定位哪些设计输入、测试用例和风险控制需要同步更新。

四、验收准则的编写方法

验收准则是设计输入与验证活动之间的“合同”。它应包含：测试对象、测试条件、操作步骤、测量参数、合格阈值、样本量和判定规则。例如：

需求编号：DI-ALM-007
需求描述：当血氧饱和度低于90%并持续5 s时，设备应在10 s内发出中优先级视觉报警。
验收准则：
1. 测试条件：环境光500 lx，设备预热5 min，模拟器输出SpO₂=89%。
2. 操作：从SpO₂=95%阶跃降至89%，保持10 s。
3. 测量：报警触发时间、报警灯亮度、报警声压级。
4. 合格判据：触发时间≤10 s；亮度≥100 cd/m²；声压级55～75 dB(A)。
5. 样本量：3台样机，每台重复3次，全部合格。

验收准则必须与需求一一对应，不能出现“验证时再定”的空白。对于主观类需求，如“操作界面易于学习”，应转化为可观察的客观指标，例如“首次使用人员在5 min内完成开机自检并进入测量模式，成功率≥90%”。

五、需求转化中的常见陷阱

实际项目中最常见的失败模式包括：把法规原文直接抄成设计输入而不转化为产品特性；把风险控制措施写成“应进行风险分析”而不是具体设计约束；验收准则只写“符合要求”而没有阈值；追溯矩阵只连到文档编号而不连到具体条款。这些都会导致验证活动无法闭环。

六、需求追溯与验收准则关系图

下图展示从多源需求到设计输入、验收准则、验证证据和确认证据的追溯链路。图中左侧为需求来源，中间为设计输入与验收准则的绑定关系，右侧为验证/确认证据，箭头表示追溯方向。

在实际项目中，建议把上述追溯关系落到需求管理工具或受控表格中，并在设计输入评审时逐条检查“来源—输入—准则—证据”四要素是否完整。只有做到每条需求都有来源、有判据、有证据，设计输入才真正具备可验证性和可追溯性，后续的验证确认活动才有稳固的基准。