2. 康复设备需求工程与架构驱动

康复设备与普通消费电子最大的区别在于：它的“用户”从来不是一个人。一台下肢康复机器人，治疗师关心的是减重调节是否顺手、训练参数能否快速切换；患者关心的是绑带会不会压痛、起步时有没有恐惧感；科室主任关心的是设备利用率与治疗记录能否导出；而工程师还要面对电机扭矩、关节限位、急停响应时间等硬约束。需求工程的任务，就是把这些来自不同角色、不同抽象层级的声音，收敛成一组可验证、可分配、可追溯的工程条目，再驱动架构决策。

一、临床需求采集：从“访谈”到“可测量条目”

临床需求采集不能停留在“希望设备更安全、更好用”这种表述。有效的做法是分层采集：先做情境观察，在治疗室跟随治疗师完成 3～5 例真实训练，记录操作顺序、等待时间、口头指令和中断点；再做半结构化访谈，围绕“最费力的环节”“最担心的风险”“最想省掉的步骤”追问；最后用问卷量化，让多名治疗师对候选需求打分。

采集到的原始语句必须转写为需求条目。转写规则是：角色 + 触发条件 + 期望行为 + 可测量指标。例如原始语句“患者体重差别很大，调减重太慢”，可转写为：“治疗师在患者坐入设备后，应能在 30 秒内完成 0～80 kg 范围内的减重调节，调节分辨率不低于 1 kg，且调节过程中患者髋部垂直位移不超过 10 mm。”这条需求同时包含了操作者、时间指标、量程、精度和副作用约束，后续可以直接设计测试用例。

二、用户画像与场景建模

用户画像不是给角色起名字、贴标签，而是把能力边界写清楚。康复设备至少要建立三类画像：治疗师（熟练操作者，但可能同时照看多名患者）、患者（运动功能受限，可能存在认知或言语障碍）、维护工程师（关注故障定位与备件更换）。每类画像应记录：典型任务频率、可接受的认知负荷、身体尺寸与力量范围、对错误的容忍度。

场景建模则把画像放进时间线。推荐使用“主场景 + 异常场景”成对描述。主场景如“治疗师为一名 65 kg 偏瘫患者设置减重 30 kg、步速 0.6 m/s 的步行训练”；异常场景如“训练中患者突发膝软，设备应在 200 ms 内检测到异常力矩并停止驱动，同时保持减重支撑不坠落”。异常场景往往直接决定安全架构，比主场景更有架构驱动力。

三、需求到架构的映射

需求不能直接“变成”架构，中间需要一次分配。常用做法是建立需求—功能—组件三层映射：每条需求先落到一个功能（如“减重补偿”），功能再分配到具体组件（伺服电机、力传感器、控制器、机械限位）。映射过程中会出现冲突，例如“调节快”要求高增益，“患者舒适”要求低加速度，这时就要在架构层引入轨迹规划器作为折中模块，而不是在需求层简单取舍。

下图给出一个简化的映射与追溯关系，左侧是需求条目，中间是功能模块，右侧是承担该功能的物理/软件组件，箭头表示分配与验证路径。

四、需求优先级与可追溯性

优先级不能只靠“重要/不重要”投票。工程上常用MoSCoW + 风险加权：Must（不做就无法通过安全或注册要求）、Should（显著影响体验或效率）、Could（锦上添花）、Won't（本期不做）。在此基础上叠加两个权重：安全影响与实现风险。例如“急停响应时间”属于 Must 且安全影响极高，即使实现成本高也必须保留；“界面主题色”属于 Could，可延后。

可追溯性要求每条需求都有唯一编号，并能向下追踪到设计、代码、测试用例，向上追踪到临床来源。实践中可用一张追溯矩阵维护，字段至少包括：需求编号、来源角色、优先级、分配组件、验证方法、当前状态。状态建议用“已提出—已评审—已分配—已实现—已验证—已关闭”六态管理，避免需求在传递中丢失。

五、典型需求案例：减重步行训练设备

以一台减重步行训练设备为例，说明需求如何驱动架构。假设临床提出：患者体重范围 40～100 kg，减重比例 0～50%，训练中需实时显示实际减重值，且患者出现异常时应自动卸载。经分析，可形成如下关键需求与架构响应：

这里的关键判断是：REQ-02 不能只靠软件实现，因为软件本身可能失效。架构上必须把安全功能独立成一条硬件链路，主控只负责“请求”，安全回路负责“最终执行”。这就是需求驱动架构的典型体现——需求的安全等级决定了模块的隔离方式，而不是先画架构再补需求。

综上，康复设备需求工程的核心链路是：临床采集获得原始声音，画像与场景界定使用边界，转写与优先级形成可管理条目，映射与追溯把条目分配到架构并保持双向可查。只有这条链路完整，后续的详细设计、验证与注册申报才有稳定依据。