2. 医疗软件需求工程基础

医疗软件的需求工程与普通商业软件最大的区别在于：需求不是从产品经理的头脑风暴或用户访谈中“长出来”的，而是从三条并行的源头汇聚而成——临床工作流、法规要求与标准规范。任何一条源头被遗漏，都可能在注册审评或临床使用中形成致命缺口。理解需求的来源、分类与质量准则，是后续追溯矩阵与验证证据链能够成立的前提。

一、需求的三个来源

临床来源是需求最原始、最具体的来源。它来自真实诊疗场景中的角色、任务与信息流。例如在“输液泵药物库管理”这一功能中，临床来源会给出：护士需要在交接班时核对当前输注药物与速率；医生调整医嘱后，泵端应在多长时间内同步；药物浓度上限超出时，谁有权覆盖。这些内容通常通过临床观察、任务分析、与临床工程师和护士长的访谈获得，输出物是用户需求（User Needs）与用例场景。

法规来源是强制性的、不可协商的。以中国《医疗器械软件注册审查指导原则》和 FDA 21 CFR Part 820 为例，法规会直接派生出一批软件需求：网络安全能力、软件生存周期过程、唯一器械标识（UDI）关联、上市后监督数据接口等。法规需求的特点是“必须存在”，即使临床用户从未提出，也必须写入需求规格。

标准来源提供的是可验证的技术约束。IEC 62304 规定软件安全分级与开发过程；IEC 62366-1 规定可用性工程过程；ISO 14971 规定风险管理；IEC 82304-1 针对独立健康软件。标准本身不直接给出“软件应做什么”，而是给出“必须考虑哪些方面、必须留下什么证据”。例如 IEC 62366-1 要求对使用错误相关的危险进行可用性测试，这会派生出“报警确认按钮的触控目标不小于 9 mm”这类可测量的需求。

三条来源并非孤立，而是通过风险管理活动交汇：临床场景识别出危害，法规要求建立风险控制，标准规定控制措施的验证方法。需求规格说明书（SRS）应当为每条需求标注来源，形成可审计的溯源链。

二、需求的四类划分

医疗软件需求通常划分为功能、性能、安全与可用性四类。这一划分不是学术分类，而是直接对应不同的验证方法：功能需求用功能测试验证，性能需求用负载与计时测试验证，安全需求用威胁建模与渗透测试验证，可用性需求用形成性/总结性可用性测试验证。

功能需求描述系统“做什么”，例如“系统应支持按患者ID查询最近30天内的输注记录”。性能需求描述“多快、多准、多稳”，例如“在500并发用户下，查询响应时间P95不超过2秒”。安全需求包含两层含义：一是患者安全（如剂量上限硬限位），二是信息安全（如传输加密、访问控制、审计日志）。可用性需求描述人机交互的可用性目标，例如“报警优先级在视觉与听觉上可区分，且误确认率低于1%”。

需要特别注意的是，安全需求与可用性需求经常相互拉扯。过于严格的确认流程会降低可用性，而过于简化的界面会引入使用错误。需求工程的任务不是消除这种张力，而是把它显式化，并在风险文件中记录权衡依据。

三、需求质量准则与常见缺陷

一条合格的需求应当满足以下准则：单一性（一条需求只表达一件事）、无歧义（不同人读出的含义一致）、可验证（存在客观的通过/失败判据）、可追溯（能向上追溯到来源，向下追溯到设计与测试）、完整（不遗漏必要的条件与异常路径）、一致（不与其它需求冲突）。

常见缺陷包括：使用“快速”“友好”“尽可能”等不可测量的形容词；把设计决策写成需求（如“使用MySQL数据库”）；把多个需求塞进一句话导致无法独立验证；遗漏异常与边界条件；需求之间相互矛盾却未被发现。这些缺陷在评审阶段若未被拦截，会在测试阶段以“无法判定是否通过”的形式暴露，代价极高。

四、需求来源、分类与验证方法的对应关系

下面的关系图展示了本节的核心结构：三条来源如何汇入需求规格，四类需求分别对应哪些验证手段，以及质量准则如何作为贯穿始终的约束。图中同时标出了常见的缺陷位置，便于在评审时快速定位。

把这张图当作评审时的检查地图：先确认每条需求能否指回三条来源之一，再确认它属于四类中的哪一类、对应哪种验证方法，最后用质量准则逐条过滤。来源、分类、准则三者同时成立，需求才具备进入追溯矩阵与验证计划的资格。