3. 系统需求分析与临床场景定义

生命体征监测设备的需求，不能从“我想测什么”出发，而应从“谁在什么场景下、为什么需要、在什么约束下使用”出发。临床监护、家庭健康和可穿戴三类场景，对同一生理参数（如心率、血氧、血压、体温、呼吸率）的采集精度、采样率、报警策略、功耗、体积、数据归属和合规要求差异极大。需求分析的任务，就是把这些差异结构化为可验证、可追踪的条目，而不是停留在“要准、要省电、要好用”这类无法验收的表述。

一、从场景到需求：三类场景的差异定位

临床监护场景的核心是“连续、可靠、可报警”。以ICU床旁监护为例，心电通常要求多导联（如5导联或7导联）、采样率不低于250 Hz（诊断级常取500 Hz），血氧更新周期约1 s，报警响应需在数秒内触发并具备声光分级。设备通常由市电供电，网络为院内专网，数据需接入中央站并留存。其非功能需求集中在可用性（MTBF、断电续航）、报警疲劳抑制和医疗电气安全（如IEC 60601-1、60601-1-8报警系统要求）。

家庭健康场景的核心是“易用、可解释、可上传”。用户多为非专业人员，设备需在30秒内完成一次测量，界面用颜色和语音提示结果，异常时给出“建议复测/联系医生”而非直接诊断。典型参数为单导心电、指夹血氧、示波法血压和额温。非功能需求集中在误操作容忍度、蓝牙/Wi-Fi配网成功率、隐私合规（如个人信息保护法、HIPAA）以及低维护成本。

可穿戴场景的核心是“低功耗、抗运动、长期趋势”。以腕式PPG手环为例，采样率可低至25～50 Hz，通过运动传感器做运动伪影抑制，心率用于趋势而非诊断，血氧多为夜间间歇测量。功耗预算常以“典型使用7天”反推，要求平均电流在毫安级。其非功能需求集中在佩戴舒适性、防水等级（如IP67/IP68）、数据缓存与断连续传。

二、用户故事与用例建模

用户故事用“作为……我希望……以便……”的句式，把需求还原为角色目标。以临床为例：“作为ICU护士，我希望报警按危重程度分级，以便在多名患者间优先处置。”验收标准可写为：三级报警在颜色、声音节奏和屏幕位置上有可区分差异，且高优先级报警不可被低优先级覆盖。家庭场景可写：“作为独居老人，我希望测量完成后听到语音播报，以便不戴老花镜也能知道结果。”验收标准：语音播报在测量结束后3秒内开始，可重复播放，音量可调。

用例建模则进一步描述系统与外部角色的交互边界。以“家庭血氧测量”为例，主参与者是用户，次参与者是手机App和云平台。主成功场景为：用户放入手指→设备检测到有效灌注→采集PPG→计算SpO₂与脉率→本地显示→通过BLE上传App→App展示趋势。扩展场景包括：手指未放稳（提示重新放置）、灌注不足（提示保暖后复测）、蓝牙断开（本地缓存并在重连后续传）。这些扩展路径正是需求中最容易被遗漏、却最影响体验的部分。

三、需求跟踪矩阵的建立

需求跟踪矩阵（RTM）把“需求—用例—设计—测试”串成一条可审计的链。建立时先给每条需求唯一编号，再逐条关联到用例、设计模块和验证方法。例如：

矩阵的价值在于“双向可查”：从需求能查到测试，从测试能回溯到需求。若某条需求没有对应测试，说明验证缺失；若某个测试没有对应需求，说明可能存在范围蔓延。建议在项目早期就建立RTM，并在每次需求变更时同步更新，避免后期出现“做了但没验、验了但没要求”的脱节。

四、从需求到场景的落地检查

完成需求与用例后，建议做一次场景走查：选取每类场景各一个典型用户，按主成功场景和至少两个扩展场景完整走一遍，检查是否有需求遗漏、角色冲突或约束矛盾。例如临床场景中“报警静音”与“高优先级报警不可静音”可能冲突，需要在需求中明确优先级规则；家庭场景中“语音播报”与“夜间静音”也可能冲突，需要增加时段策略。走查的输出应回写到RTM，形成闭环。

最终，需求分析不是一次性文档，而是贯穿设计、实现与验证的基线。临床、家庭、可穿戴三类场景的差异，决定了功能与非功能需求的优先级排序；用户故事与用例提供了交互视角；RTM则保证每条需求都能被追踪和验证。三者结合，才能让生命体征监测设备在真实场景中既“测得准”，也“用得住”。