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

在医疗软件项目中，需求不是一句“系统要能管理患者”这样的愿望，而是一份可被验证、可被追溯、可被监管审查的工程约定。IEEE 610.12 将需求定义为“系统或组件为满足合同、标准、规范或其他正式文档所必须满足的条件或能力”。放到医疗语境中，这个定义要再加一层约束：需求不仅要让开发团队能实现，还要让临床使用者能确认、让质量与法规人员能举证。因此，医疗软件需求工程的核心任务，是把临床意图、法规义务和技术约束，转化为一组层次清晰、类型明确、可双向追溯的需求条目。

一、需求的层次：从业务目标到可测试条目

需求通常分为四个层次，层次之间是“为什么—做什么—怎么做—怎么验”的分解关系。以“住院患者静脉用药闭环管理”为例：

• 业务需求：降低用药差错率，满足三级医院评审对用药安全的要求。它回答“为什么做”，通常由医院管理层或临床科室提出。
• 用户需求：护士希望在床旁用扫码确认患者与药品，医生希望开嘱后能立即看到配伍禁忌提示。它回答“谁要做什么”。
• 系统需求：系统应在 2 秒内完成患者腕带条码与药品条码的匹配校验，并在不匹配时锁定给药操作。它回答“系统必须提供什么能力”。
• 软件需求：校验服务应调用患者主索引接口，比对字段包括住院号、姓名、药品编码；比对失败时返回错误码 MED_MISMATCH 并写入审计日志。它回答“软件具体怎么做、怎么验”。

层次划分的价值在于追溯：任何一条软件需求都应能向上追溯到用户需求与业务目标，向下追溯到设计、代码和测试用例。若一条需求无法向上追溯，它很可能是“镀金需求”；若无法向下验证，它只是口号。

二、需求的类型：功能、非功能、法规与安全

医疗软件的需求类型比通用软件更复杂，因为法规与安全往往不是附加项，而是决定系统能否上线的硬约束。

功能需求描述系统“做什么”。例如：医生提交医嘱后，系统应生成待执行任务并推送至护士站；护士执行给药后，系统应记录执行时间、执行人、药品批号。功能需求应尽量写成“触发条件—输入—处理—输出”的形式，避免“系统应友好”这类不可验证表述。

非功能需求描述系统“做得怎么样”。医疗场景中常见的非功能需求包括：可用性（门诊高峰期系统可用率不低于 99.9%）、性能（条码校验响应时间 P95 不超过 2 秒）、可维护性（接口变更后 4 小时内完成回归测试）、易用性（新护士完成一次床旁扫码给药的操作步骤不超过 5 步）。非功能需求必须带度量口径，否则无法验收。

法规需求来自外部强制约束。例如：电子病历系统需符合《电子病历应用管理规范》对操作留痕、时间戳、数据可追溯的要求；若涉及医疗器械软件，还需满足 NMPA 注册审查指导原则中对软件生存周期、风险管理、网络安全的要求。法规需求通常以“应满足……”“应保留……记录不少于……”的形式出现，并需要建立法规条款到需求条目的映射矩阵。

安全需求在医疗软件中至少包含两层含义：一是患者安全，即软件失效不得导致用药、剂量、手术部位等错误；二是信息安全，即患者隐私数据在传输、存储、访问各环节受到保护。典型安全需求如：系统应对药品剂量超出安全范围的情况进行强制拦截，拦截规则不可由普通用户关闭；患者身份信息在数据库中应加密存储，密钥与数据分离管理。

三、需求工程过程模型：从获取到变更

需求工程不是一次性写文档，而是一个持续循环的过程，通常包括需求获取、分析、规格说明、验证和变更管理五个活动。医疗软件尤其强调“临床参与”和“可追溯”，因此过程模型需要把临床用户、法规人员、质量人员和开发人员放在同一条信息链上。

需求获取阶段，常用方法包括临床访谈、现场观察、任务分析和现有系统日志分析。例如，要获取“急诊分诊”需求，仅靠访谈可能得到“要快”，而现场观察会发现护士在分诊时同时操作三个界面，真正的痛点是重复录入。分析阶段则要识别冲突、补齐边界条件，例如“药品库存不足时是否允许开嘱”这类业务规则必须在分析阶段明确。

规格说明阶段，推荐使用结构化需求条目模板，每条需求至少包含：唯一编号、需求描述、类型、优先级、来源、验收标准、追溯关系。验证阶段通过评审、原型走查和测试用例反查来确认需求是否完整、一致、可测试。变更管理阶段则要建立变更影响分析机制：一条需求变更会影响哪些设计模块、哪些测试用例、哪些法规映射，必须可查。

四、把需求写成可验收的条目：一个可参考的示例

下面给出一条医疗软件需求的完整写法示例，可直接作为团队需求条目的参考模板。示例中的参数为教学假设，不代表任何真实系统的实测值。

需求编号：REQ-MED-0042
需求名称：床旁给药条码不匹配拦截
类型：功能需求(F) + 安全需求(S)
优先级：高（Must）
来源：护理部访谈记录 2024-03-12；《电子病历应用管理规范》第X条
描述：当护士在床旁扫描患者腕带条码与药品条码后，
      系统应在 2 秒内完成比对；若住院号或药品编码不一致，
      系统应锁定给药确认按钮，显示“患者与药品不匹配”，
      并记录操作人、时间、两个条码值到审计日志。
验收标准：
  1) 正常匹配时，给药确认按钮在 2 秒内可点击；
  2) 不匹配时，按钮保持禁用，错误提示可见；
  3) 审计日志中可查询到本次操作记录，字段完整；
  4) 断网重连后，未同步的拦截记录不丢失。
追溯：上游 USR-012（护士床旁扫码）；下游 TC-MED-0042-01~04

这条需求同时覆盖了功能与安全两类，带有明确的触发条件、时间约束、异常路径和可验证的验收标准。评审时，法规人员可以检查它是否满足留痕要求，测试人员可以直接据此设计用例，开发人员也能判断接口与状态机边界。

总结来看，医疗软件需求工程的起点是“定义清楚”，关键是“分层与分类”，保障是“过程闭环与可追溯”。业务需求回答为什么做，用户需求回答谁要做什么，系统需求回答系统提供什么能力，软件需求回答具体怎么实现和怎么验；功能、非功能、法规、安全四类需求共同构成完整约束；获取、分析、规格说明、验证、变更管理五个活动持续循环，任何一条需求变更都能沿追溯链找到受影响的设计、测试与法规映射。做到这三点，需求文档才真正成为医疗软件质量与合规的第一道防线。