3. 医疗软件需求工程与可测试性

医疗软件的需求工程与普通商业软件最大的区别在于：需求不仅要回答“系统做什么”，还要回答“凭什么证明它做对了”。监管审核、临床使用和上市后追溯都要求需求本身具备可验证性。因此，需求工程的核心目标不是把需求写得多，而是把需求写成可分解、可追溯、可验收的工程对象。

一、四类需求：功能、性能、安全、法规

医疗软件需求通常按四个维度组织，它们不是并列的文档章节，而是同一系统在不同约束下的表达：

• 功能需求：描述系统对输入产生什么输出，如“当医生提交处方时，系统校验药物过敏史并给出警示”。功能需求必须包含触发条件、处理逻辑和可观察结果。
• 性能需求：描述在给定负载下的时间、吞吐和容量边界，如“在200并发用户下，影像调阅首帧响应时间≤3秒”。性能需求必须绑定负载条件，否则无法验收。
• 安全需求：既包括患者安全（如剂量上限拦截），也包括信息安全（如访问控制、审计日志、数据加密）。安全需求往往以“禁止发生什么”的形式表达，验收时用异常路径验证。
• 法规需求：来自法规、标准或注册要求，如电子病历的修改留痕、数据可导出、软件版本可识别。法规需求通常不可协商，且必须映射到具体功能或设计约束。

四类需求在测试视角下的差异很明显：功能需求用正常与异常用例覆盖；性能需求用负载模型和阈值判定；安全需求用攻击面和权限矩阵验证；法规需求用检查表和审计证据确认。需求类型识别错误，会直接导致测试设计遗漏。

二、从用户需求到系统需求：分解与可测试化

用户需求（User Needs）用临床语言描述期望，系统需求（System Requirements）用工程语言描述实现边界。分解的关键动作是把模糊期望转化为可测量条件。例如：

• 用户需求：“护士希望快速看到患者过敏信息。”
• 系统需求：“患者详情页加载后1秒内显示过敏标识；过敏标识在页面顶部固定区域；无过敏史时显示‘无已知过敏’。”

分解时常用“条件—行为—指标”结构：在什么条件下，系统执行什么行为，达到什么可测量指标。对于无法直接测量的需求，需要引入替代指标或分解为多个子需求。例如“系统应安全可靠”无法验收，应分解为“登录失败5次锁定账户10分钟”“关键操作写入审计日志”“数据库每日备份且恢复时间≤2小时”等。

三、需求追溯矩阵：让每条需求都有来路和去路

需求追溯矩阵（RTM）是需求工程的骨架。它至少建立三层链接：用户需求→系统需求→测试用例。医疗软件还常增加风险项和法规条款两列，形成“需求—风险—法规—测试”的闭环。RTM 的价值不在于表格本身，而在于暴露三类问题：无来源的需求（可能是过度设计）、无测试的需求（验收缺口）、无需求覆盖的测试（冗余或遗漏）。

实际维护时，建议每条系统需求分配唯一编号，如 SRS-FUNC-012、SRS-PERF-005、SRS-SEC-003、SRS-REG-007。测试用例编号与需求编号建立多对多关系，并在每次需求变更时同步更新矩阵。变更影响分析时，从需求编号出发即可定位受影响的测试集和风险项。

四、验收标准编写：从“应该”到“判定”

验收标准（Acceptance Criteria）是需求可测试性的最终体现。好的验收标准具备三个特征：可测量、有边界、可复现。编写时推荐使用 Given-When-Then 结构，但医疗软件更强调阈值和证据形式。

以“处方过敏警示”为例，验收标准可以写成：

Given 患者档案中存在“青霉素过敏”记录
When 医生开具含青霉素类药物处方并提交
Then 系统在提交前弹出警示，警示内容包含过敏原名称
And 医生必须选择“修改处方”或“填写理由后继续”
And 继续操作写入审计日志，日志包含医生ID、时间戳、处方ID
And 若医生选择修改，处方不进入收费流程

性能类验收标准必须绑定负载和统计口径，例如：“在200并发用户、持续10分钟的压力下，影像调阅接口P95响应时间≤3秒，错误率<0.1%，CPU利用率≤80%。”这里的P95、错误率、CPU阈值都是可采集的判据，测试报告直接引用即可。

安全类验收标准常用“禁止”句式：“未授权用户访问患者数据时，系统返回403且不泄露任何患者字段；连续5次登录失败后账户锁定10分钟，锁定期间正确密码也无法登录。”法规类验收标准则强调证据：“系统保留所有电子病历修改记录，记录包含修改前后值、修改人、时间戳，且记录不可删除，可通过审计界面导出。”

五、需求变更与追溯维护

医疗软件需求变更频繁，可能来自临床反馈、法规更新或缺陷修复。每次变更都应走“变更申请→影响分析→更新RTM→调整测试用例→回归验证”的路径。影响分析时，从变更的需求编号出发，沿RTM向上查用户需求和法规条款，向下查测试用例和风险项，确保没有遗漏。若变更涉及安全或法规需求，还需重新评估风险等级并保留变更记录，作为审计证据的一部分。

需求工程做得好，测试就不再是“对着界面点”，而是“对着需求和判据验证”。四类需求分类清楚、用户需求分解到可测量、RTM保持双向可追溯、验收标准写到可判定，医疗软件的测试体系才有稳固的起点。