第二章：需求分析与规格定义
好，咱们正式开始干活了。做麻醉机这种跟人命打交道的设备，第一步不是画电路板，也不是写代码。第一步是什么？是搞清楚你到底要做什么。
我见过不少团队，上来就开干，结果做到一半被临床医生骂回来——"你这玩意儿我根本没法用"。嗯，这种坑我踩过不止一次。所以今天咱们聊聊，怎么把需求这件事做扎实。
一、用户需求：临床医生到底想要什么？
说白了，麻醉机是给麻醉医生用的。你设计的再好，医生用着不顺手，那就是废铁。我个人习惯，做需求分析时先把自己当成一个"小白医生"。
临床医生的核心诉求其实就几条：
- 操作要直观——手术室里分秒必争，没人有空翻说明书。按键布局、屏幕显示，最好一看就懂。
- 参数要清晰——潮气量、呼吸频率、气道压力这些关键数据，必须一眼能扫到。字号太小？颜色太花？医生会骂人的。
- 报警要靠谱——不是乱叫，也不是该叫不叫。我遇到过一台机器，稍微有点压力波动就"滴滴滴"响个不停，结果医生直接把报警关了——这多危险。
- 模式要够用——容量控制、压力控制、SIMV……不同手术、不同病人，需要的模式不一样。你不能只给两个模式就完事。
关键点：用户需求不是你想出来的，是"问"出来的。我建议你至少跟3-5位一线麻醉医生聊一聊，最好能进手术室看他们实际操作一次。你会发现，他们抱怨最多的点，往往就是你的设计机会。
二、系统需求：安全、精度、实时性
用户需求是"做什么"，系统需求是"做成什么样"。这里我重点讲三个维度：安全、精度、实时性。这三个词，是麻醉机嵌入式系统的命根子。
1. 安全——底线中的底线
麻醉机出问题，病人可能就醒不过来。所以安全设计不是加分项，是必须项。
- 冗余设计：关键传感器至少双路。我一个项目里，氧浓度传感器坏了一个，系统立刻切换到备用通道，同时报警。这叫"故障安全"。
- 看门狗：MCU死机了怎么办？外部看门狗定时器必须在100ms内复位系统。我曾经见过一个团队，看门狗超时设了2秒——结果机器卡死了，医生还在等它恢复……
- 参数边界检查：所有输入参数都要做上下限检查。比如潮气量设置范围是20ml-1500ml，你设个2000ml？系统直接拒绝，并提示"超出安全范围"。
注意：安全不是靠一个功能实现的，是靠一整套机制。我曾经吃过亏，只做了软件层面的安全检查，结果硬件故障时软件根本不知道——从那以后，我坚持"软硬结合"的安全策略。
2. 精度——差一点就是事故
麻醉机的精度要求，比普通医疗设备高一个量级。举个例子：
| 参数 | 典型精度要求 | 我的经验值 |
|---|---|---|
| 潮气量 | ±10% 或 ±20ml | 实际要做到 ±5% 才保险 |
| 氧浓度 | ±3% | 传感器校准周期不能超过6个月 |
| 气道压力 | ±2 cmH₂O | 采样率至少100Hz |
| 呼吸频率 | ±1 次/分钟 | 定时器误差要小于0.1% |
为什么会这么严？你想想看，给新生儿做麻醉，潮气量可能只有30ml。误差20%？那就是6ml，对婴儿来说可能就缺氧了。所以精度不是数字游戏，是命。
3. 实时性——慢了就是事故
麻醉机的控制周期，通常在10ms-50ms之间。什么意思？就是每10ms你要完成一次"采集-计算-输出"的循环。
我个人的经验是：
- 传感器采样：1ms内完成
- 控制算法计算：5ms内完成
- 执行器输出：2ms内完成
- 剩余时间：留给通信、显示、日志等
如果某个环节超时了怎么办？嗯，这里有个小技巧：设置一个"软实时"和"硬实时"的分界线。软实时任务可以偶尔超时，硬实时任务（比如安全阀控制）必须严格按时完成。
避坑指南：我曾经在一个项目里，把显示刷新和呼吸控制放在同一个中断里。结果显示刷新卡了一下，呼吸控制也跟着延迟了——病人气道压力瞬间飙高。后来我学乖了：把实时任务和非实时任务彻底分开，用不同的优先级。
三、功能规格与性能指标
需求分析完了，接下来要写成"白纸黑字"的规格文档。这个文档，是开发、测试、注册、生产所有人的"圣经"。
功能规格——它应该能做什么？
我习惯用"用例"的方式来写功能规格。比如：
- 用例1：容量控制通气
- 用户设置：潮气量500ml，呼吸频率12次/分，吸呼比1:2
- 系统行为：按设定参数送气，实时显示气道压力曲线
- 异常处理：气道压力超过40 cmH₂O时，自动切换为压力控制模式
- 用例2：手动通气
- 用户操作：按压"手动通气"按钮
- 系统行为：关闭自动控制，打开手动皮囊通路
- 安全机制：15秒无操作，自动报警
每个功能都要写清楚"正常流程"和"异常流程"。我见过太多文档只写正常情况，结果测试时一遇到异常就崩了。
性能指标——它应该做到多好？
性能指标是量化的，不能含糊。比如：
| 指标项 | 要求值 | 测试方法 |
|---|---|---|
| 系统启动时间 | ≤ 10秒 | 从上电到进入待机界面 |
| 报警响应延迟 | ≤ 2秒 | 从异常发生到报警触发 |
| 数据记录容量 | ≥ 72小时 | 连续记录所有参数 |
| 电池续航 | ≥ 60分钟 | 满电状态下，纯电池供电 |
这些指标不是拍脑袋定的。我一般会参考三个来源：
- 行业标准——比如ISO 80601-2-13对麻醉机的要求
- 竞品分析——看看别人家做到什么水平
- 临床反馈——医生觉得"够用"和"好用"之间的差距
我的习惯：性能指标一定要留余量。比如标准要求报警延迟≤5秒，我内部定2秒。为什么？因为测试环境和实际使用环境不一样，留点余量，心里踏实。
四、需求文档的"潜规则"
最后说点文档之外的东西。需求文档写完了，不是锁进柜子里就完事了。它需要：
- 评审——拉上硬件、软件、测试、临床、注册的人，一起过一遍。我见过太多需求在评审时被推翻重写的。
- 版本管理——需求会变，但每次变更都要有记录。谁改的？为什么改？影响范围是什么？
- 可追溯性——每个需求都要能追溯到测试用例。测试通过了，才算需求实现了。
嗯，说到这我想起一个教训。有次我图省事，没写需求变更记录。结果三个月后，谁也说不清某个功能到底要不要做——最后只能全部重测一遍。那叫一个酸爽。
好了，第二章就聊到这。需求分析看着枯燥，但它是整个项目的根基。根基不稳，后面全是白干。下一章咱们聊聊系统架构设计——怎么把这些需求变成实实在在的硬件和软件方案。