evil0knight's Blog

SND

20分钟阅读

干系人需求文档（SND）

← 开发流程规范 | ← 主页

来源：Stage1 02 干系人需求文档 Stakeholder Needs Document (SND)

项目代号：EC-SW (EternalChip Smart Watch)

硬件方案：STM32F411 + nRF52840（双MCU，定位由手机协同提供，不包含 NFC）

文档编号：EC-SW-SND-001

版本：V1.0

保密级别：内部

1. 文档控制（Document Control）

版本日期作者审核变更说明
V1.02025-12-28Simon—冻结：作为 Stage 1 输出，进入 Stage 2 Kano/QFD

1.1 参考输入（Inputs）

  • 《Stage1 02 用户需求文档（UND）》

1.2 术语与缩写（Terms & Acronyms）

  • SND：Stakeholder Needs Document，干系人需求文档（本文件）

  • UND：User Needs Document，用户需求文档（Stage 1-02）

  • BRD：Business Requirements Document，业务需求文档（Stage 2-03）

  • SyRS：System Requirements Specification，系统需求规格说明（Stage 3）

  • SAD：System Architecture Document，系统架构文档（Stage 4）

  • SSRD：Software System Requirements Definition，软件系统需求定义（Stage 5-01）

  • SRS：Software Requirements Specification，软件需求规格说明（Stage 5-02）

  • SN / BR / SR：分别代表 Stakeholder Need / Business Requirement / System Requirement 的编号前缀

2. 背景与问题定义（Context & Problem Statement）

目标场景：矿井、山区、海上作业平台等“受限网络/弱网/断网”环境，一线作业人员分散作业，管理侧难以及时掌握人员安全状态。传统对讲/电话等方式在信号盲区存在失效风险，同时人工点名、巡检存在周期长、不可持续、应急响应慢的问题。

本项目要解决的核心问题：在“没有公网也可能没有局域网”的条件下，仍能实现对一线人员的生命体征/安全状态感知，并提供可追溯的数据与事件记录，降低事故发现和救援响应的时间。

2.1 业务价值（Why it matters）

  • 安全：将“发现异常”从分钟级/小时级拉近到秒级/实时提示，降低重大伤害事件的概率与影响范围。

  • 管理：形成可量化的安全运营数据，支持班组管理、风险复盘、合规审计。

  • 运维：减少人工巡检与纸面记录，提升设备可维护性与现场可用性。

2.2 产品边界（Scope & Non-Scope）

  • In Scope：生命体征/安全状态监测、告警与事件记录、弱网/断网条件下的数据留存与转发、现场运维与远程升级能力。

  • Non-Scope：不包含 NFC 近场刷卡/门禁；不强制手表端集成 GPS。定位能力以“手机协同（BLE 获取）或现场定位基础设施”作为可选输入。

  • 本文件只描述“干系人想要什么/为什么要”，不提前绑定实现方案（实现策略在 SAD/ADR 阶段确定）。

3. 干系人地图（Stakeholder Map）

干系人用于描述“谁会被产品影响/谁会影响产品”。本项目至少包含以下角色：

干系人ID角色核心目标（简述）
STK-01一线作业人员（佩戴者）在不影响作业的前提下，获得安全保障与自助求救能力
STK-02班组长/现场管理快速掌握人员状态与异常事件，减少盲区与管理成本
STK-03安全管理/应急指挥对高风险人员/区域进行监控与预警，缩短救援响应时间
STK-04企业 IT/平台运维设备纳管、账号权限、数据对接与安全合规
STK-05设备运维/维修人员现场快速部署、诊断、维修与升级，降低停机与返修
STK-06企业管理层/采购成本可控、ROI 清晰、可规模化复制
STK-07监管/审计（可选）满足行业安全规范与记录留存要求（视行业/地区而定）
STK-08家属/后勤保障（可选）在重大事件发生时获得及时通知（是否开放取决于合规策略）

3.2 干系人关注点（Concerns）

  • 佩戴者：舒适/安全、误报/漏报、隐私、操作负担、续航。

  • 管理侧：可视化/告警准确性、覆盖范围、定位与事件闭环、统计报表。

  • 运维侧：可部署、可诊断、可升级、可追溯、返修成本。

  • 公司层面：合规/风险、成本与交付周期、供应链可持续。

4. 需求获取方法（How needs were captured）

  • 场景走访/访谈：对矿井/山区/海上平台等典型受限网络场景进行假设建模与痛点梳理。

  • 角色工作流分析：以“班次”为单位拆解佩戴/巡检/告警/救援/交接班流程。

  • 风险驱动：从‘人身安全’出发提炼 must-have 的监控与告警能力。

  • 工程可行性反馈：结合功耗/通信/存储等约束，识别高风险点与待决策项（记录到风险与 ADR）。

5. 干系人需求（Stakeholder Needs List）

说明：下表中的需求以‘需要/希望/必须’描述，可被验证；优先级采用 MoSCoW（Must/Should/Could/Won’t for now）。定量指标为目标值/门槛值，具体数值会在 SyRS/SSRD 阶段进一步冻结。

SN ID分类需求陈述（Need Statement）原因/价值可验证指标（初稿）优先级主要关联干系人
SN-001安全与健康系统需要在受限网络条件下仍可对佩戴者的关键生命体征与安全状态进行持续监测。弱网/断网环境是主场景，不能依赖公网实现安全闭环。关键指标：采样/判定不中断；异常事件可本地留存。MustSTK-01/02/03
SN-002安全与健康当发生异常（如生命体征异常、跌倒/长时间静止、人工求救）时，系统需要提供即时告警并引导处理。告警是缩短救援响应的核心杠杆。告警触达：本地≤1s 提示；有链路时管理侧可收到事件。MustSTK-01/02/03
SN-003安全与健康系统需要支持“确认/消警/升级”的事件闭环，避免告警无人处理或重复骚扰。现场管理需要明确责任与进度。事件状态：新建/确认/处理/关闭；全程可追溯。MustSTK-02/03
SN-004安全与健康系统需要支持离线情况下的“自助求救”与“就近求援”能力。矿井/隧道等可能完全无信号，必须尽可能把求救信号送出。离线求救：至少可被附近设备/现场基站接收并转发（实现方式 TBD）。MustSTK-01/03
SN-010网络与覆盖系统需要在弱网/断网环境具备数据留存与‘恢复后补传’能力。安全事件与健康记录需完整可追溯。断网留存：本地保存≥N天（N待定）；恢复后自动补传。MustSTK-02/03/04
SN-011网络与覆盖系统需要支持现场多设备并发接入与组网扩展，避免单点瓶颈。矿区/平台人员多且分散，需要可扩展。容量：支持≥X 人/站点（X待定）。ShouldSTK-02/04/06
SN-012定位与救援系统需要提供人员位置/区域信息以辅助救援，但应允许多种定位来源（手机协同/现场基站/手动区域登记）。定位对救援关键，但硬件集成 GPS 未必可行或成本过高。位置来源可配置；定位精度/刷新率在 SyRS 冻结。ShouldSTK-02/03/04
SN-020佩戴与易用性设备需要满足长时间佩戴的舒适性与安全性，不影响 PPE 与日常作业动作。佩戴负担会直接导致弃用。舒适度：连续佩戴≥8h；皮肤接触安全；佩戴方式适配工装。MustSTK-01/06
SN-021佩戴与易用性关键操作需要足够简单，避免依赖复杂菜单或手机才能完成。紧急情况下操作越少越好。求救/消警：≤2步完成；关键状态一眼可见。MustSTK-01
SN-022佩戴与易用性设备需要在强噪声/强光/手套环境下仍可被感知与操作。工业现场常见限制。提示方式：屏幕+震动+蜂鸣（是否具备由 HW Spec 决定）。ShouldSTK-01/02
SN-030可靠性与环境设备需要适应工业现场环境（粉尘、水汽、振动、跌落、温差），并保持稳定工作。否则现场不可用、维护成本高。环境指标：防护/抗跌落/工作温度在 HRS 冻结。MustSTK-01/05/06
SN-031可靠性与环境系统需要对异常状态具备自诊断与降级策略，避免‘沉默失效’。最危险的是看似工作但实际失效。健康自检：关键传感器/通信链路状态可见；异常可告警。MustSTK-05/04/03
SN-032可靠性与环境系统需要具备可恢复能力（看门狗/异常复位后状态保护），避免关键事件丢失。现场无法频繁人工干预。异常恢复：重启后关键配置与事件记录不丢。MustSTK-05/04
SN-040功耗与续航设备需要满足班次级别续航，并在空闲时尽可能降低功耗。工业现场充电不便。续航：≥1班次（8-12h）为底线；目标≥多天（待 SyRS 冻结）。MustSTK-01/06
SN-041功耗与续航设备需要提供清晰可理解的电量/充电状态，避免关键时刻没电。减少不可用风险。电量估算误差阈值在 SyRS 冻结；低电量提前告警。ShouldSTK-01/02
SN-042功耗与续航系统需要支持安全的电源管理与低电量保护，避免数据损坏。现场更换/充电频繁，掉电风险高。掉电保护：关键数据写入完整性保证。ShouldSTK-05
SN-050数据与安全系统需要对个人健康数据进行访问控制与加密保护，满足企业安全要求。健康数据属于敏感数据。权限：最小权限；传输/存储加密策略在 ADR/SSRD 冻结。MustSTK-04/06
SN-051数据与安全系统需要提供数据留存策略与可审计能力（谁在何时查看/导出/修改）。面向监管与事故复盘。审计日志：包含主体/时间/动作；留存周期可配置。ShouldSTK-04/07
SN-052数据与安全系统需要具备设备身份与密钥管理能力，避免被伪造设备接入。工业现场安全攻击不可忽略。设备身份：出厂唯一标识；绑定/解绑流程可追溯。ShouldSTK-04/05
SN-060部署与运维系统需要支持批量部署与设备纳管（入库、绑定人员、分组、策略下发）。否则规模化成本很高。纳管：批量导入/导出；策略分组；远程配置（范围待定）。MustSTK-04/06
SN-061部署与运维系统需要支持远程升级/现场升级能力，并保证升级安全与可回滚。现场分布广，不可能逐台返厂。升级：支持安全升级与失败回滚；升级日志可追溯。MustSTK-05/04
SN-062部署与运维系统需要支持现场快速诊断（日志导出、状态灯/屏提示、故障码）。缩短维修时间。诊断：一线可执行‘自检’并导出日志。ShouldSTK-05
SN-063部署与运维系统需要明确备件与维修策略（电池/表带/传感器模块等），降低 TCO。工业设备生命周期长。可维护性策略在 HRS/HW Spec 与 SDD 冻结。ShouldSTK-06/05
SN-070集成与扩展系统需要支持与企业现有平台/告警系统对接（接口可扩展）。避免信息孤岛。接口：标准化 API/消息格式在 SID 冻结。ShouldSTK-04/03
SN-071集成与扩展系统需要支持后续功能扩展（新增传感器/新增告警策略/新增场景）。不同客户差异大。扩展点：策略/驱动可插拔（设计目标）。CouldSTK-06/04
SN-080成本与合规在满足关键安全目标的前提下，方案需要控制硬件与运维成本，适配规模化采购。成本决定是否能落地。目标成本范围由采购/管理层定义（BRD 阶段冻结）。ShouldSTK-06
SN-081成本与合规系统需要满足目标行业的安全与数据合规要求（如记录留存、权限审计等）。决定能否进入招投标。合规条款列表由项目经理/法务提供（BRD/SyRS）。MustSTK-06/07

6. 约束、假设与风险（Constraints / Assumptions / Risks）

6.1 关键约束（Constraints）

  • 主使用环境存在弱网/断网，不能将‘安全闭环’完全依赖公网。

  • 一线人员可能佩戴手套/口罩/耳罩，交互能力受限；作业任务优先于设备操作。

  • 现场维护资源有限：需要低维护成本、可远程/批量运维。

  • 隐私与合规：健康数据属于敏感信息，必须可控可审计。

6.2 假设（Assumptions, 可在 BRD/SyRS 校验）

  • 作业现场至少存在一种“告警可达的链路”——例如：局部组网、现场网关、或在部分区域可恢复公网。

  • 人员佩戴设备是流程要求的一部分（有管理制度约束），否则需要额外激励机制。

  • 定位信息可由手机/现场基础设施提供；手表侧只需接入并展示/上报（具体策略待定）。

6.3 风险（Risks）

  • 误报：告警过多导致‘告警疲劳’，最终被忽略。

  • 漏报：关键异常未被捕获，造成安全事故风险。

  • 功耗与体验冲突：高采样/高频通信 vs 续航。

  • 部署复杂度：一旦需要大量现场配置，落地成本会显著上升。

7. 需求冲突与权衡（Initial Trade-offs）

  • 安全性 vs 续航：采样率、算法复杂度、无线通信频率需要在 SyRS/ADR 中做权衡。

  • 隐私安全 vs 易用性：强身份认证可能增加现场操作成本，需要设计‘管理员模式/批量操作’。

  • 成本 vs 可靠性：更高防护等级/冗余设计提升成本，需要在 BRD 中明确目标客群与预算。

  • 定位精度 vs 可用性：在无 GPS 情况下需选择‘足够好’的定位策略（手机协同/基站/区域打卡）。

8. 验证思路（How to validate at Stage 1 level）

  • 现场可用性试验：戴手套、强噪声、强光环境下的告警感知与操作成功率。

  • 断网演练：无公网条件下产生告警事件→本地留存→网络恢复后补传→平台闭环。

  • 续航测试：典型班次场景（采样+显示+告警）下的工作时长与低电量告警阈值验证。

  • 可靠性测试：跌落/振动/温度循环（指标由 HRS 冻结）与故障自检能力。

9. 与后续阶段的衔接（Traceability & Next Steps）

SND 的输出将作为 Stage 2（Kano / QFD）输入，用于确定需求优先级与权重；随后在 BRD/SyRS/SSRD/SRS 中逐层细化并冻结。

9.1 需求编号使用规则（建议）

  • SN-xxx：干系人需求（本文件）；用于描述‘想要什么/为什么要’。

  • BR-xxx：业务需求（BRD）；用于描述‘业务目标/业务范围/业务流程’。

  • SR-xxx：系统需求（SyRS）；用于描述‘系统必须具备的能力/性能/约束’，可测试可验收。

  • 后续需求分解时保持一对多可追溯：SN → BR → SR → SSRD/SRS → 设计 → 测试用例。

9.2 SND→UND（粗粒度映射）

  • SN-001~SN-004：对应 UND 中的‘安全与健康监测’、‘紧急求助’类用户需求。

  • SN-010~SN-012：对应 UND 中的‘弱网/断网可用’、‘定位与救援’类用户需求。

  • SN-040~SN-042：对应 UND 中的‘续航与电量管理’类用户需求。

  • SN-060~SN-062：对应 UND 中的‘运维/升级/日志’类用户需求。

附录 A：需求质量检查清单（SND Checklist）

  • 是否避免了过早的实现方案绑定？（如指定某协议/芯片/框架）

  • 每条 SN 是否包含明确的‘原因/价值’？

  • 每条 SN 是否具备可验证的指标雏形？

  • 是否识别了关键风险与冲突？

  • 是否为后续 Kano/QFD 留出了可量化的评价维度？

关系图谱

反向链接