用户需求文档（UND）
项目名称
受限网络工况下的生命体征监控智能手表（STM32 + Nordic 方案）
文档信息
| 字段 | 内容 |
|---|---|
| 项目/产品 | 受限网络工况下的生命体征监控智能手表（内部代号：EC-SW） |
| 文档编号 | EC-SW-UND-001 |
| 文档阶段 | Stage 1 - User Needs |
| 版本 | V1.0 |
| 编写人 | Jack、Simon |
| 评审人 | 产品经理 / 系统工程师 / 系统架构师 / 软件负责人 / 硬件负责人 / QA |
| 发布日期 | 2025-12-28 |
修订记录
| 版本 | 日期 | 修订内容 | 修订人 | 评审/批准 |
|---|---|---|---|---|
| V1.0 | 2025-12-28 | 更新完整的用户需求。 | Simon | 待评审 |
1. 文档目的（Purpose）
本《用户需求文档（User Needs Document, UND）》用于描述“用户真正想要什么”，以自然语言陈述需求，避免过早落入实现细节。UND 的输出将作为后续 Stage 2（Kano / QFD / BRD）和 Stage 3（SyRS）输入，并通过需求编号建立可追踪链路：SN → UN → BR → SR。
注意：本阶段不讨论具体芯片/协议栈/线程设计，也不定义精确指标（如 1Hz 采样、±3BPM 等），这些属于后续 System Requirements（SyRS）与 Software Requirements（SSRD/SRS）。
2. 术语与缩写
| 缩写/术语 | 含义 | 备注/与本项目关系 |
|---|---|---|
| SN | Stakeholder Needs（干系人需求） | 来自客户/甲方、安全管理、运维等“利益相关者”的诉求与约束。 |
| UN / UND | User Needs / User Needs Document（用户需求/文档） | 来自一线用户与使用场景的需求陈述，是本文件主体。 |
| BR / BRD | Business Requirements / Business Requirements Document（业务需求/文档） | 将用户需求抽象成可交付的业务目标与范围边界。 |
| SR / SyRS | System Requirements / System Requirements Specification（系统需求/规格说明） | 把业务目标落到系统能力与可验证指标（含软硬件边界）。 |
| SSRD | Software System Requirements Definition（软件系统需求定义） | 从系统需求分解得到的软件侧需求定义（偏“定义/边界/行为”）。 |
| SRS | Software Requirements Specification（软件需求规格说明） | 更强调可验证与可追踪的规格化软件需求（可与 SSRD 合并或并行）。 |
| SAD | System Architecture Document（系统架构文档） | 系统分层/模块/部署/接口的架构说明。 |
| RAM | Requirement Allocation Matrix（需求分配矩阵） | 把 SR 分配到 HW/SW/APP/Cloud 的责任边界。 |
| ADR | Architecture Decision Record（架构决策记录） | 记录关键架构取舍与原因。 |
| SID | System Interface Definition（系统接口定义） | 定义系统级接口（电气/通信/数据/协议）。 |
3. 背景与应用场景
目标场景：矿井、隧道、山区、海上作业平台、化工/冶金等“通信受限/安全要求高/应急响应窗口短”的作业现场。
典型现状：
- 现场蜂窝网络覆盖差，甚至完全无信号；依赖手机 App 的方案无法稳定工作，且部分场景手机禁入。
- 传统对讲/广播可“喊人”，但无法持续采集生命体征与趋势；事故发生后缺少事后追溯数据。
- 人员密集、班组轮换频繁，设备管理（发放、绑定、维护、升级）成本高。
因此，本产品以“可穿戴 + 近距离组网/网关 + 离线容错”为核心方向，提供生命体征监控、异常告警、区域定位与应急联动能力。
4. 用户与干系人画像
说明：UND 重点关注“直接使用者（用户）”，但为后续追踪，也列出关键干系人（非直接用户）。
| 角色 | 典型人群/岗位 | 主要目标 | 典型痛点 | 使用频率 |
|---|---|---|---|---|
| U1 一线作业人员 | 矿井作业人员 / 隧道施工人员 / 海上平台维护人员 | 安全回家、减少误报骚扰、操作简单不影响干活 | 戴手套难操作、强噪声/弱光、网络不稳定、设备易磕碰进水 | 每日/全班次 |
| U2 班组长/带班 | 班组长、领班 | 快速发现异常、快速定位人、减少管理成本 | 信息分散、告警不集中、难判断“真异常” | 每日/多次 |
| U3 监控室/应急指挥 | 安全监控员、调度员 | 统一看板、分级告警、应急联动 | 告警闭环难、缺少证据链、跨系统对接复杂 | 持续值守 |
| U4 设备运维/IT | 运维工程师、设备管理员 | 设备批量管理、稳定升级、快速排障 | 设备版本碎片化、现场升级困难、定位问题缺少日志 | 每周/按需 |
| S1 客户/甲方 | 安全负责人、项目经理 | 降低事故风险、满足合规与审计 | 投入产出难量化、采购周期、合规压力 | 项目周期 |
5. 用户旅程（User Journey）与关键场景
- J1 配发与绑定：设备入库→分配到人/班组→首次绑定（手机/网关/工卡）→检查固件版本与电量
- J2 日常佩戴与监测：上班佩戴→自动开始采集→数据本地缓存/间歇上报→用户低打扰
- J3 异常告警与确认：超过阈值/跌倒/SOS→手表本地提示→通过近距离组网/网关上报→班组长/监控室确认
- J4 应急处置与救援：定位到区域→调度救援→持续跟踪生命体征→事件记录留存
- J5 班次交接与复盘：下班归还/交接→数据补传→生成报表/复盘→设备充电与维护
6. 用户需求列表（输入 Stage 2 的 Kano / QFD）
说明：以下需求以“用户视角”描述，后续会在 Kano/QFD 阶段得到优先级与权重，并在 BRD/SyRS 中被进一步规格化。优先级采用 MoSCoW（Must/Should/Could/Won’t）。
| UN-ID | 需求（用户语言） | 价值/动机 | 优先级 | 主要使用者 | 依赖/备注 |
|---|---|---|---|---|---|
| UN-001 | 我希望手表/手环戴一整班也不硌手、不闷汗、不过敏，佩戴牢固不脱落。 | 长期佩戴的基础体验，直接影响采纳率。 | Must | U1 | 材质/结构与 PPE 兼容。 |
| UN-002 | 我希望戴手套也能完成关键操作（SOS、确认告警、查看关键信息）。 | 现场经常戴手套，触控不可用时仍需操作。 | Must | U1 | 交互形式：实体键/大触控区域/震动反馈。 |
| UN-003 | 我希望在弱光/强光下都能看清关键告警与时间信息。 | 提升可用性与可靠性。 | Should | U1 | 背光/对比度/字号。 |
| UN-004 | 我希望设备能持续监测心率等关键生命体征，并在异常时提醒我和管理者。 | 提前发现风险，缩短响应时间。 | Must | U1/U2/U3 | 具体指标在 SyRS 定义。 |
| UN-005 | 我希望能监测体温/血氧等关键指标，用于高风险作业的健康筛查与预警。 | 增强风险识别维度。 | Should | U1/U3 | 传感器选型与算法。 |
| UN-006 | 我希望一键 SOS 求救，且在网络不好时也能尽最大努力把求救发出去。 | 关键救命能力。 | Must | U1/U3 | 需离线容错与重试策略。 |
| UN-007 | 我希望设备在无网络/弱网络时不丢数据：能本地缓存，恢复后自动补传。 | 受限网络场景的核心诉求。 | Must | U3/U4 | 存储容量、补传窗口。 |
| UN-008 | 我希望告警能够分级（紧急/重要/提示），减少误报骚扰，同时不漏掉真异常。 | 降低告警疲劳，提高处置质量。 | Must | U2/U3 | 阈值/规则需可配置。 |
| UN-009 | 我希望班组长/监控室能看到“谁在异常、在哪、持续多久、是否已处理”。 | 形成告警闭环。 | Must | U2/U3 | 需要看板/通知链路。 |
| UN-010 | 我希望能大致知道人员所在区域，进入危险区域时能提醒。 | 安全管理与电子围栏。 | Should | U2/U3 | 定位方式：受限环境下基于 BLE 信标/网关；室外可由手机提供 GPS（BLE 协同）。 |
| UN-011 | 我希望上班时自动开始监测，下班后自动结束/低功耗，不需要每天手动配置。 | 减少操作成本。 | Should | U1 | 班次策略与低功耗。 |
| UN-012 | 我希望手表电池能支撑至少一个完整班次，最好能覆盖加班/双班，电量低时提前提醒。 | 可用性与安全冗余。 | Must | U1/U4 | 具体续航目标在 SyRS 定义。 |
| UN-013 | 我希望设备防水防尘、抗跌落、抗油污，坏了也能快速更换。 | 工业现场可靠性。 | Must | U1/U4 | 等级在 HRS/SyRS 定义。 |
| UN-014 | 我希望设备在异常情况下有清晰的提示（震动/蜂鸣/屏显），周围很吵也能感知。 | 提升告警触达率。 | Should | U1 | 多模态提示。 |
| UN-015 | 我希望设备能记录事件与关键数据，事后可导出用于事故复盘与审计。 | 证据链与管理闭环。 | Should | U3/S1 | 数据留存周期与权限。 |
| UN-016 | 我希望设备能支持批量发放、快速绑定/解绑，适配人员轮班与临时工。 | 降低管理成本。 | Must | U4 | 绑定方式待 BRD/SyRS 细化。 |
| UN-017 | 我希望设备出现故障能自检并提示，运维能快速定位问题（日志、版本、配置）。 | 缩短 MTTR。 | Should | U4 | 需要诊断与日志机制。 |
| UN-018 | 我希望能远程升级固件（OTA），但升级不能影响现场安全与稳定。 | 持续迭代与维护。 | Must | U4/S1 | 升级策略、回滚与安全在 SSRD/SAD 定义。 |
| UN-019 | 我希望不同部门能按权限查看数据：个人隐私不被滥用。 | 合规与信任。 | Must | U1/S1 | 权限模型在 BRD/SyRS 定义。 |
| UN-020 | 我希望设备能与现有安全平台/工厂系统对接，避免重复建设。 | 降低集成成本。 | Should | U3/S1 | 接口与协议在 SID 定义。 |
| UN-021 | 我希望定位/数据上报不要强依赖手机；手机不可用时仍可通过现场网关/基站工作。 | 受限网络/禁入手机场景。 | Must | U3/S1 | 系统部署形态在 SAD 定义。 |
| UN-022 | 我希望手表时间准确，断电后也不会乱，方便事件对齐与追溯。 | 数据可信。 | Should | U3/U4 | RTC/校时策略。 |
| UN-023 | 我希望能在手表上看到最少但关键的信息：时间、电量、连接状态、是否在监测中。 | 降低学习成本。 | Should | U1 | 界面信息架构。 |
| UN-024 | 我希望在极端情况下（低温/高温/高湿）设备依然可用。 | 环境适应性。 | Should | U1/S1 | 目标范围在 SyRS/HRS 定义。 |
| UN-025 | 我希望设备丢了能被发现（最后在线时间/区域），减少资产损失。 | 资产管理。 | Could | U4 | 需要后台/日志支撑。 |
| UN-026 | 我希望系统能生成简洁报表：出勤、告警次数、处置时长、风险趋势。 | 管理价值。 | Could | U2/U3/S1 | 报表粒度在 BRD 定义。 |
| UN-027 | 我希望系统部署与维护尽量简单：少布线、少改造、易扩容。 | 项目落地成本。 | Must | S1/U4 | 架构与部署策略在 SAD/ADR。 |
| UN-028 | 我希望在数据链路中有基本安全措施，避免被伪造告警或窃取数据。 | 安全与可信。 | Should | S1/U4 | 安全方案在 ADR/SSRD。 |
7. 不在本阶段承诺的内容（Non-goals）
- 不承诺具体的性能指标与精度（将于 SyRS/HRS/SRS 中定义与验证）。
- 不承诺具体实现方案（如 BLE Mesh / 私有 Sub-1G / Wi-Fi），仅描述用户所需能力。
- 本版本删除 NFC 相关需求；定位能力优先采用现场部署与手机协同方案，GPS 由手机侧提供并通过 BLE 协同获取（如适用）。
8. 需求追踪说明（Traceability）
在 Stage 2/3/5 中维持以下链路，确保“做什么”和“为什么做”可追溯：
- SN-xxx（干系人需求） → UN-xxx（用户需求） → BR-xxx（业务需求） → SR-xxx（系统需求） → SSRD/SRS-xxx（软件需求） → SDD/Code/Tests（设计/代码/测试）。
在 Git 维度，每个需求条目应对应：需求条目 ID（如 UN-006）→ Epic/Story → 分支 → 合并请求 → 版本基线（Tag/Release Notes），以便审计与回归。