系统需求规格说明书（SSRD）
来源：Stage5 01 系统需求规格说明书 Software System Requirements Definition（SSRD）
| 文档编号 | EC-SW-SSRD-001 |
|---|---|
| 版本 | V1.0 |
| 日期 | 2025-12-28 |
| 负责人 | （填写：系统工程/软件负责人） |
| 密级 | 内部资料 |
文档变更记录
| 版本 | 修订日期 | 修订内容 | 修订人 | 审核人 |
|---|---|---|---|---|
| V0.1 | 2025-12-28 | 基于Stage1~Stage4输出重构SSRD骨架与首版需求条目 | （填写） | （填写） |
| V1.0 | 2025-12-28 | 补齐需求分组、编号规则、追溯关系与验证策略 | （填写） | （填写） |
1 引言
1.1 目的
本文档用于定义“受限网络工况下的生命体征监控智能手表”项目的软件系统需求（Software System Requirements Definition, SSRD）。SSRD用于在系统需求（SyRS）与软件详细需求（SRS）之间建立可追溯的“软件侧需求集合”，为架构设计（SAD/SID/ADR）与实现验证提供依据。
1.2 范围
-
覆盖对象：手表端嵌入式软件（STM32 主控固件 + nRF52840 BLE固件）及其相互协同机制；Bootloader/OTA流程；与手机APP的通信接口约束。
-
不包含：手机APP与云平台的详细产品需求（仅定义与手表交互所需的接口与约束）；硬件电路实现细节（由HRS/HW Spec/硬件设计文档定义）。
1.3 读者对象
- 产品/项目经理、系统工程师、软件架构师、嵌入式工程师、测试/QA、硬件工程师（接口协同）。
1.4 术语与缩写
术语与缩写
| 缩写/术语 | 说明 |
|---|---|
| SN | Stakeholder Needs，干系人需求 |
| UND | User Needs Document，用户需求文档 |
| BRD | Business Requirements Document，业务需求文档 |
| SyRS / SRSys | System Requirements Specification，系统需求规格说明 |
| SSRD | Software System Requirements Definition，软件系统需求定义（软件侧的系统级需求集合） |
| SRS | Software Requirements Specification，软件需求规格说明（更细、可直接实现/测试） |
| SAD | System Architecture Document，系统架构文档 |
| SID | System Interface Definition，系统接口定义文档 |
| RAM | Requirement Allocation Matrix，需求分配矩阵 |
| ADR | Architecture Decision Record，架构决策记录 |
| BLE | Bluetooth Low Energy，低功耗蓝牙 |
| OTA | Over-The-Air，空中升级 |
1.5 参考资料
-
Stage1 01 干系人需求文档（SN）
-
Stage1 02 用户需求文档（UND）
-
Stage2 03 业务需求文档（BRD）
-
Stage3 01 系统需求文档（SyRS）
-
Stage4 01 系统架构文档（SAD）
-
Stage4 04 系统接口定义文档（SID）
-
项目原理图/接口表/器件规格书（HRS/HW Spec）
2 产品与软件概述
2.1 产品背景与目标
本产品面向煤矿井下、海上平台、山区作业等“公网受限/信号不稳定”场景，提供对作业人员生命体征的持续监测与异常告警能力。系统在离线状态下仍可独立完成采集、展示、告警与存储；在具备手机网关或恢复网络时完成数据同步与告警闭环。
2.2 软件边界与分工（双MCU）
-
STM32F411 主控固件：传感器采集与预处理、UI显示与交互、本地存储与日志、电源管理、与nRF的IPC通信。
-
nRF52840 BLE固件：BLE广播/连接/GATT服务、与手机APP的可靠数据链路、OTA数据搬运与升级控制（按方案）。
-
手机APP（外部系统）：负责配对、数据上报到云、定位提供（GPS/基站/Wi‑Fi）、告警通知与管理。
2.3 运行环境与约束
-
网络约束：工作区域可能无蜂窝网络；设备侧不依赖4G/NB-IoT，默认通过BLE连接手机作为网关。
-
佩戴与交互：佩戴在腕部，可能戴手套操作；需要简单可靠的人机交互与明确的告警提示。
-
功耗约束：电池供电；需通过低功耗策略保障续航目标（具体指标见SSRD-NF-P-03）。
-
安全/合规：涉及人员安全告警，需保证告警链路可靠、数据可追溯；非医疗诊断类产品时避免宣称医疗结论（由BRD/SyRS明确）。
3 系统上下文与外部接口概览
3.1 系统上下文
系统上下文包含：手表端（STM32+nRF）、手机APP、后台平台（可选）以及外部传感器与存储器件。
图3-1 系统总体框图（参考）
3.2 外部接口清单（摘要）
| 接口对象 | 接口类型 | 用途 | 备注 |
|---|---|---|---|
| 手机APP | BLE/GATT | 配对、配置、数据同步、定位提供、告警协同 | 无NFC；GPS由手机侧提供 |
| 后台平台 | HTTPS/MQTT（由APP实现） | 数据存储、告警通知、人员管理 | 手表不直连公网 |
| 传感器簇 | I2C/SPI/GPIO | 心率/体温/运动等采集 | 由STM32驱动 |
| 外部Flash | SPI/QSPI | 离线数据与日志、升级包缓存 | 支持分区管理 |
| 双MCU IPC | UART/GPIO | STM32↔nRF命令与数据通道 | 需ACK/重传 |
4 软件系统需求（SSRD）
4.1 需求组织与编号规则
-
SSRD需求以“SSRD-<类型>-<序号>”编号：F=功能，D=数据，I=接口，NF=非功能。
-
每条需求应具备：来源追溯（SyRS/BRD/UND）、优先级（MoSCoW）、验证方式（Test/Analysis/Inspection/Demo）。
-
SSRD是软件侧“系统级需求集合”，细化到可实现/可测试的程度由SRS继续展开。
4.2 功能需求
| 需求ID | 需求名称/主题 | 需求描述（应当…） | 优先级 | 来源/追溯 | 验证方式 |
|---|---|---|---|---|---|
| SSRD-F-01 | 生命体征采集 | 系统应当支持对心率、体表温度、血氧（可选）等生命体征数据进行周期性采集，并提供采集配置（采样周期/启停/校准）。 | Must | SR-F-01 | Test |
| SSRD-F-02 | 运动/姿态采集 | 系统应当支持对三轴加速度/陀螺仪数据进行采集，用于运动量统计与跌倒/异常姿态识别（可选）。 | Should | SR-F-01 | Test |
| SSRD-F-03 | 数据预处理 | 系统应当对原始传感器数据进行去噪/滤波/异常值剔除，并输出可用于算法与展示的规范化数据格式。 | Should | SR-F-01 | Test+Inspection |
| SSRD-F-04 | 本地阈值告警 | 系统应当支持基于阈值的告警策略（如心率过高/过低、体温异常），当触发条件满足时在手表端触发声/光/振动提示并记录事件。 | Must | SR-F-02 | Test |
| SSRD-F-05 | 一键求救 | 系统应当提供一键求救入口（物理按键或UI），触发后生成求救事件并通过BLE上报手机端，离线时本地持续提示。 | Must | BR-ALERT-01 | Demo+Test |
| SSRD-F-06 | 离线运行 | 在无公网/无蜂窝网络环境下，系统应当具备离线独立运行能力：持续采集、展示、告警、存储，并在网络恢复后补发数据。 | Must | SR-F-01;SR-F-03 | Test |
| SSRD-F-07 | 实时显示 | 系统应当在屏幕上显示关键生命体征摘要（心率/体温/电量/连接状态等），并支持至少一个健康详情页面。 | Must | SR-U-01 | Demo |
| SSRD-F-08 | 交互与设置 | 系统应当支持基本交互（触控/按键）：页面切换、参数设置（阈值/采样周期/亮度/语言等）及恢复默认设置。 | Should | SR-U-01 | Demo+Test |
| SSRD-F-09 | 数据存储 | 系统应当将生命体征与事件数据保存到本地存储（片内Flash/外部SPI Flash），并包含时间戳与数据校验字段。 | Must | SR-F-03 | Test |
| SSRD-F-10 | 日志与诊断 | 系统应当提供运行日志与故障诊断能力（关键状态、异常码、重启原因等），用于现场定位问题与售后分析。 | Should | SR-R-01 | Test+Inspection |
| SSRD-F-11 | BLE连接与配对 | 系统应当支持与手机APP的BLE配对与重连流程，包含设备鉴权、连接参数管理、断连重连策略。 | Must | SR-F-03 | Test |
| SSRD-F-12 | 数据同步 | 系统应当支持将离线缓存的生命体征数据与事件数据通过BLE同步到手机端，支持断点续传与去重。 | Must | SR-F-03 | Test |
| SSRD-F-13 | 定位获取 | 系统应当支持通过BLE从手机端获取定位信息（GPS/基站/Wi‑Fi定位，由手机决定），并将定位与事件绑定。 | Should | SR-F-04 | Test |
| SSRD-F-14 | 远程上报协同 | 手机端可作为网关将手表数据上报到后台；手表侧应当提供必要的数据封包与状态字段，支持后台的告警闭环。 | Should | BR-CLOUD-01 | Test+Demo |
| SSRD-F-15 | OTA升级 | 系统应当支持通过BLE进行固件升级（至少支持应用升级；Bootloader升级可选），升级过程包含版本校验、完整性校验、回滚策略。 | Must | SR-S-01;SR-R-01 | Test |
| SSRD-F-16 | 安全机制 | 系统应当支持固件与数据的基础安全能力：升级包完整性校验、关键参数保护、通信数据的加密/签名能力（按项目策略）。 | Should | SR-S-01 | Analysis+Test |
| SSRD-F-17 | 低功耗管理 | 系统应当实现电源管理策略：空闲休眠、屏幕超时、传感器按需工作、BLE广播/连接参数优化，并提供电量估算。 | Must | SR-P-02 | Test |
| SSRD-F-18 | 异常恢复 | 系统应当具备异常恢复机制：看门狗、关键任务自检、存储与通信错误重试、不可恢复错误的安全降级与提示。 | Must | SR-R-01 | Test |
4.3 数据需求
| 需求ID | 需求名称/主题 | 需求描述（应当…） | 优先级 | 来源/追溯 | 验证方式 |
|---|---|---|---|---|---|
| SSRD-D-01 | 数据模型 | 系统应当定义统一的数据模型（生命体征记录、事件记录、配置项、版本信息），并在MCU间通信与存储中保持一致。 | Must | SR-F-03 | Inspection |
| SSRD-D-02 | 时间戳 | 系统应当为所有采集数据与事件记录提供时间戳。离线场景下允许使用本地RTC；与手机同步后支持时间校准。 | Must | SR-F-03 | Test |
| SSRD-D-03 | 数据保留策略 | 系统应当定义数据保留与覆盖策略（例如循环缓冲），并保证关键告警事件在覆盖前被优先同步或导出。 | Should | SR-F-03 | Test |
4.4 接口需求
| 需求ID | 需求名称/主题 | 需求描述（应当…） | 优先级 | 来源/追溯 | 验证方式 |
|---|---|---|---|---|---|
| SSRD-I-01 | MCU间通信协议 | STM32与nRF之间应当通过UART实现可靠通信协议：包含帧格式、序号、ACK/重传、超时与错误码。 | Must | SAD-IPC-01 | Test+Inspection |
| SSRD-I-02 | BLE GATT接口 | 系统应当定义BLE服务/特性（GATT）：设备信息、健康数据、事件告警、配置/控制、OTA传输等，并给出字段定义。 | Must | SR-F-03;SR-F-04;SR-S-01 | Inspection+Test |
| SSRD-I-03 | 手机APP接口约束 | 系统应当定义与手机APP的交互约束：配对流程、权限、数据同步策略、定位获取流程与异常处理。 | Must | BR-APP-01 | Demo+Test |
| SSRD-I-04 | 存储接口抽象 | 系统应当对外部Flash/内部Flash提供统一存储抽象接口，支持日志/数据/升级包的分区管理与磨损均衡策略（可选）。 | Should | SR-R-01 | Inspection |
| SSRD-I-05 | 传感器驱动抽象 | 系统应当采用可移植的传感器驱动接口（I2C/SPI抽象、可插拔设备实例化），以支持传感器型号变更与复用。 | Should | Maintainability | Inspection |
4.5 非功能需求
| 需求ID | 需求名称/主题 | 需求描述（应当…） | 优先级 | 来源/追溯 | 验证方式 |
|---|---|---|---|---|---|
| SSRD-NF-P-01 | 采集与告警延迟 | 从传感器采集到告警触发的端到端延迟应满足业务要求（目标≤TBD ms），并可通过测试验证。 | Should | SR-P-01 | Test |
| SSRD-NF-P-02 | 启动时间 | 系统上电到可采集与显示的启动时间应满足业务要求（目标≤TBD s）。 | Should | SR-P-01 | Test |
| SSRD-NF-P-03 | 续航目标 | 在典型工作负载下（采集+显示+周期同步），系统续航目标≥TBD 小时；提供功耗测试方法与记录。 | Must | SR-P-02 | Test+Analysis |
| SSRD-NF-R-01 | 稳定性 | 系统应当支持长期运行稳定：典型场景连续运行≥TBD 天无死机（或可自动恢复），并记录复位原因。 | Must | SR-R-01 | Test |
| SSRD-NF-R-02 | 数据完整性 | 本地存储的数据应具备基本完整性保护（CRC/序号），掉电后不应出现结构性损坏，支持恢复与校验。 | Must | SR-R-01 | Test |
| SSRD-NF-S-01 | 通信安全 | 与手机端的关键控制命令应具备鉴权机制；敏感数据传输支持加密（BLE配对加密或应用层加密）。 | Should | SR-S-01 | Analysis+Test |
| SSRD-NF-M-01 | 可维护性 | 软件应当提供模块化分层与清晰接口（BSP/Service/App），关键模块提供单元测试或可测试钩子。 | Should | Engineering | Inspection |
5 需求验证与验收策略
5.1 验证方法定义
-
Test：通过自动化/半自动测试用例验证（单元测试、集成测试、系统测试）。
-
Analysis：通过计算/推导/功耗估算/静态分析等方式验证。
-
Inspection：通过评审与文档检查验证（接口/数据结构/状态机/代码规范）。
-
Demo：通过演示场景验证（现场可视化、端到端流程）。
5.2 关键验收场景（示例）
-
离线场景：无网络、无手机网关情况下连续采集与告警，数据正确写入本地存储。
-
补发场景：恢复与手机连接后，离线期间数据可完整同步，且具备去重与断点续传。
-
告警闭环：触发阈值告警/一键求救 → 本地提示 → 手机端收到告警 →（可选）平台通知。
-
升级场景：BLE OTA升级成功率与异常回滚（断电/断连/包损坏）。
-
低功耗场景：屏幕超时、连接状态变化下的功耗测试与续航评估。
附录A：系统需求（SyRS）到SSRD追溯矩阵（示例）
| SyRS需求ID | SyRS摘要 | 映射到SSRD |
|---|---|---|
| SR-F-01 | 离线采集生命体征 | SSRD-F-01, SSRD-F-02, SSRD-F-03, SSRD-F-06 |
| SR-F-02 | 异常触发告警 | SSRD-F-04, SSRD-F-05 |
| SR-F-03 | 数据同步与补发 | SSRD-F-06, SSRD-F-09, SSRD-F-12 |
| SR-F-04 | 定位能力 | SSRD-F-13 |
| SR-P-02 | 低功耗与续航 | SSRD-F-17, SSRD-NF-P-03 |
| SR-R-01 | 可靠性与恢复 | SSRD-F-18, SSRD-NF-R-01, SSRD-NF-R-02 |
| SR-S-01 | 安全与升级完整性 | SSRD-F-15, SSRD-F-16, SSRD-NF-S-01 |
附录B：待定参数清单（TBD）
-
告警延迟目标（SSRD-NF-P-01）：需结合传感器采样率、算法复杂度与业务容忍度确定。
-
启动时间目标（SSRD-NF-P-02）：需结合上电流程、存储校验与UI初始化确定。
-
续航目标与典型负载定义（SSRD-NF-P-03）：需结合电池容量、工作模式、BLE策略与屏幕使用习惯确定。
-
稳定性指标（SSRD-NF-R-01）：需结合产品定位（试产/量产）与现场维护能力确定。