evil0knight's Blog

QFD

16分钟阅读

需求映射与权重分析（QFD）

← 开发流程规范 | ← 主页

来源：Stage2 02 需求映射与权重分析 Quality Function Deployment (QFD)

SW-QFD-002 | V1.0 | 2025-12-28 | 内部资料

字段内容
文档编号SW-QFD-002
版本V1.0
编写Liu Yueqi
审核（待定）
批准（待定）
项目受限网络工况下的生命体征监控手环（STM32F411 + nRF52840）
说明QFD Phase-1：将用户需求(WHAT)与业务目标(WHY)建立映射，并给出权重排序，作为 BRD/SyRS 输入。

文档变更记录

版本日期修订内容修订人审核/批准
V1.02025-12-28初版：补全 WHAT、WHY、映射矩阵、权重算法与结论；同步“无NFC、GPS由手机侧提供(通过BLE)”约束。Simon—

1. 文档目的与范围

本文件用于在产品早期把“用户说的需求(WHAT)”与“企业要达成的业务目标(WHY)”建立定量映射，通过统一的权重算法输出优先级：

  1. 哪些用户需求最值得先做；

  2. 哪些业务目标最需要被系统能力重点支撑；

  3. 为 Stage2-03 BRD、Stage3 SyRS/SRSys 的需求排序提供依据。

注：本文件不做架构与实现方案，工程实现约束将在 SAD/ADR/SSRD/SDD 中给出。

1.1 适用范围

适用于“受限网络工况下生命体征监控手环/手表”项目的 Phase-1 QFD（从 VOC 到业务目标）。对象包含：一线作业人员、班组长/监控室、安全管理部门、运维人员、采购与合规等干系人。

1.2 输入与约束

输入文档：SND、UND、KAD（Kano 结果与重要度）。

关键约束：

  • 现场存在弱网/无公网；必须在离线情况下仍能完成核心安全链路。

  • 本版本不包含 NFC；定位能力优先通过手机侧获取（BLE 与手机 App 协同）。

  • 安全相关需求优先保证可用性与可靠性，其次才考虑体验类增强。

1.3 术语与符号

本文件采用以下符号表示 WHAT 与 WHY 的相关性：

● 强相关（权重=9）：该业务目标的实现高度依赖该用户需求被满足。

○ 中相关（权重=3）：该用户需求对业务目标有明显支撑，但非唯一关键因素。

△ 弱相关（权重=1）：该用户需求对业务目标有间接贡献。

2. 业务目标（WHY）

业务目标用于回答“公司/组织为什么要做这些需求”。本阶段将业务目标数量控制在 6 个，确保矩阵可读、可算、可复盘。目标可在后续 BRD/SyRS 中进一步拆分为 KPI 与验收标准。

BG-ID业务目标说明建议KPI/度量Owner
BG-01事故发现与响应效率缩短异常发现与处置链路（检测-告警-确认-处置）异常检测到现场告警 < 1s；监控侧收到告警 < 10s（本地组网条件下）安全/生产管理
BG-02无公网可用的本地协同弱网/无网下核心功能仍可运行，数据可缓存与补传无公网条件下核心链路可用性 >= 99%；缓存数据在网络恢复后自动补传系统/通信
BG-03现场状态可视化与管控在岗/失联/区域/围栏状态对管理者可见失联/越界事件识别 ⇐ 2min；区域级定位/围栏告警 ⇐ 5s现场管理
BG-04运维与生命周期成本可控部署、配置、升级、日志、资产管理简化批量发放/绑定 ⇐ 1min/台；OTA 成功率 >= 95%；可追溯日志完整运维/研发
BG-05用户采纳与作业不打扰佩戴舒适、关键操作简单、续航与耐用性续航 >= 24h（典型班次）；关键操作 ⇐ 2 步；佩戴合规与舒适度通过现场试用产品/工业设计/研发
BG-06合规与审计安全关键事件可追溯，权限与数据安全满足合规关键事件 100% 留痕；权限分级可配置；基本链路安全（防伪造/防窃取）合规/安全/研发

3. 客户需求（WHAT）

客户需求来自 Stage1 UND，并结合 Stage2 KAD 给出“重要度(1-5)”与“预期 Kano 类型”。本表保留 UN-ID 用于后续 BRD/SyRS/SSRD 的全链路追踪。

UN-ID用户需求（VOC）业务优先级Kano 类型重要度建议版本
UN-001我希望手表/手环戴一整班也不硌手、不闷汗、不过敏，佩戴牢固不脱落。Must基本型(Must-be)5R0/MVP
UN-002我希望戴手套也能完成关键操作（SOS、确认告警、查看关键信息）。Must基本型(Must-be)5R0/MVP
UN-003我希望在弱光/强光下都能看清关键告警与时间信息。Should基本型(Must-be)4R0/MVP
UN-004我希望设备能持续监测心率等关键生命体征，并在异常时提醒我和管理者。Must基本型(Must-be)5R0/MVP
UN-005我希望能监测体温/血氧等关键指标，用于高风险作业的健康筛查与预警。Should魅力型(Attractive)4R2
UN-006我希望一键 SOS 求救，且在网络不好时也能尽最大努力把求救发出去。Must基本型(Must-be)5R0/MVP
UN-007我希望设备在无网络/弱网络时不丢数据：能本地缓存，恢复后自动补传。Must基本型(Must-be)5R0/MVP
UN-008我希望告警能够分级（紧急/重要/提示），减少误报骚扰，同时不漏掉真异常。Must期望型(One-dimensional)5R0/MVP
UN-009我希望班组长/监控室能看到“谁在异常、在哪、持续多久、是否已处理”。Must基本型(Must-be)5R0/MVP
UN-010我希望能大致知道人员所在区域，进入危险区域时能提醒。Should期望型(One-dimensional)4R0/MVP
UN-011我希望上班时自动开始监测，下班后自动结束/低功耗，不需要每天手动配置。Should魅力型(Attractive)4R2
UN-012我希望手表电池能支撑至少一个完整班次，最好能覆盖加班/双班，电量低时提前提醒。Must基本型(Must-be)5R0/MVP
UN-013我希望设备防水防尘、抗跌落、抗油污，坏了也能快速更换。Must期望型(One-dimensional)5R0/MVP
UN-014我希望设备在异常情况下有清晰的提示（震动/蜂鸣/屏显），周围很吵也能感知。Should基本型(Must-be)4R0/MVP
UN-015我希望设备能记录事件与关键数据，事后可导出用于事故复盘与审计。Should基本型(Must-be)4R0/MVP
UN-016我希望设备能支持批量发放、快速绑定/解绑，适配人员轮班与临时工。Must期望型(One-dimensional)5R1
UN-017我希望设备出现故障能自检并提示，运维能快速定位问题（日志、版本、配置）。Should魅力型(Attractive)4R1
UN-018我希望能远程升级固件（OTA），但升级不能影响现场安全与稳定。Must基本型(Must-be)5R0/MVP
UN-019我希望不同部门能按权限查看数据：个人隐私不被滥用。Must期望型(One-dimensional)5R1
UN-020我希望设备能与现有安全平台/工厂系统对接，避免重复建设。Should期望型(One-dimensional)4R1
UN-021我希望定位/数据上报不要强依赖手机；手机不可用时仍可通过现场网关/基站工作。Must无差异(Indifferent)5R2
UN-022我希望手表时间准确，断电后也不会乱，方便事件对齐与追溯。Should基本型(Must-be)4R0/MVP
UN-023我希望能在手表上看到最少但关键的信息：时间、电量、连接状态、是否在监测中。Should基本型(Must-be)4R0/MVP
UN-024我希望在极端情况下（低温/高温/高湿）设备依然可用。Should基本型(Must-be)4R0/MVP
UN-025我希望设备丢了能被发现（最后在线时间/区域），减少资产损失。Could魅力型(Attractive)3R2
UN-026我希望系统能生成简洁报表：出勤、告警次数、处置时长、风险趋势。Could魅力型(Attractive)3R2
UN-027我希望系统部署与维护尽量简单：少布线、少改造、易扩容。Must期望型(One-dimensional)5R0/MVP
UN-028我希望在数据链路中有基本安全措施，避免被伪造告警或窃取数据。Should基本型(Must-be)4R0/MVP

4. WHAT → WHY 映射矩阵（QFD Phase-1）

映射原则：

  1. 只做“目标依赖关系”的判断，不讨论实现方案；

  2. 以安全链路优先为原则（检测-告警-确认-处置）；

  3. 结合受限网络工况：离线可用、数据可补传、关键事件可追溯。

说明：定位能力本版本优先由手机侧提供（BLE 与 App 协同）；不包含 NFC。

UN-IDImpBG-01BG-02BG-03BG-04BG-05BG-06
UN-0015.0●
UN-0025.0●●
UN-0034.0○●
UN-0045.0●○○
UN-0054.0○○
UN-0065.0●○
UN-0075.0●○△
UN-0085.0●○
UN-0095.0○●○
UN-0104.0○●
UN-0114.0○●
UN-0125.0○●
UN-0135.0○○
UN-0144.0●○
UN-0154.0○○●
UN-0165.0●○
UN-0174.0●○
UN-0185.0○●○
UN-0195.0●
UN-0204.0○●
UN-0215.0●○○
UN-0224.0△○○
UN-0234.0○●
UN-0244.0△○○
UN-0253.0○○△
UN-0263.0●○○
UN-0275.0○●○
UN-0284.0△○●

4.1 权重算法

计算规则：

  1. 相关性权重：●=9，○=3，△=1，空白=0；

  2. 单条需求对某个业务目标的贡献 = 需求重要度(1-5) × 相关性权重；

  3. 业务目标总权重 = 所有需求对该目标贡献之和；

  4. 需求总分 = 对所有业务目标贡献之和；

  5. 输出排序：按“需求总分”排序得到优先级建议；按“业务目标总权重”得到战略重心。

5. QFD 结果输出

5.1 业务目标权重（由 WHAT 驱动）

BG-ID业务目标总分占比
BG-05用户采纳与作业不打扰34223.0%
BG-04运维与生命周期成本可控33722.7%
BG-01事故发现与响应效率30220.4%
BG-06合规与审计安全20013.5%
BG-03现场状态可视化与管控18312.3%
BG-02无公网可用的本地协同1208.1%

5.2 需求优先级（按 QFD 加权）

UN-IDTop VOC（摘要）ImpQFD总分
UN-002我希望戴手套也能完成关键操作（SOS、确认告警、查看关键信息）。590
UN-027我希望系统部署与维护尽量简单：少布线、少改造、易扩容。575
UN-004我希望设备能持续监测心率等关键生命体征，并在异常时提醒我和管理者。575
UN-021我希望定位/数据上报不要强依赖手机；手机不可用时仍可通过现场网关/基站工作。575
UN-009我希望班组长/监控室能看到“谁在异常、在哪、持续多久、是否已处理”。575
UN-018我希望能远程升级固件（OTA），但升级不能影响现场安全与稳定。575
UN-007我希望设备在无网络/弱网络时不丢数据：能本地缓存，恢复后自动补传。565
UN-015我希望设备能记录事件与关键数据，事后可导出用于事故复盘与审计。460
UN-006我希望一键 SOS 求救，且在网络不好时也能尽最大努力把求救发出去。560
UN-008我希望告警能够分级（紧急/重要/提示），减少误报骚扰，同时不漏掉真异常。560
UN-016我希望设备能支持批量发放、快速绑定/解绑，适配人员轮班与临时工。560
UN-012我希望手表电池能支撑至少一个完整班次，最好能覆盖加班/双班，电量低时提前提醒。560

5.3 结论与对下一阶段的建议

  1. 第一优先级集中在“安全链路闭环 + 离线可用 + 运维可落地”。典型高权重需求包括：戴手套可关键操作/确认告警(UN-002)、离线缓存补传(UN-007)、现场部署与维护简化(UN-027)、无公网可用但仍能通过网关/基站工作(UN-021)、监控侧可见并可处置闭环(UN-009)、安全 OTA 与稳定性(UN-018)。

  2. 体验类需求（佩戴舒适、可读性、关键状态展示、续航）在工业场景中属于“必须可用”的门槛，虽不直接体现为业务收益，但决定了采纳率与长期运行稳定性，应纳入 MVP 验收。

  3. 本 QFD 输出将作为 BRD 的排序输入：BRD 应将上述 Top 需求转换为可交付的业务能力项，并在 SyRS 中进一步量化为可测试的系统需求（含离线工况、告警时延、数据留痕与权限）。

6. 交付物与追踪规则

6.1 向 BRD 的交付

交付内容：

  1. Top 需求清单（UN-ID + QFD 总分）作为 BRD 的优先级输入；

  2. 业务目标权重（BG-xx）作为 BRD 的战略约束；

  3. 映射矩阵作为“为什么要做/不做某需求”的复盘依据。

6.2 向 SyRS/SAD/SSRD 的追踪

追踪要求：

  1. 每条 UN-ID 在 SyRS 中必须至少映射到 1 条系统需求（SR-xxx），并在 RAM 中体现分配到 SW/HW；

  2. 安全链路与离线工况相关的 SR 必须具备可验证的验收标准（测试用例/仿真工况）；

  3. 任何删改需求必须在 ADR 中记录理由（成本、风险、依赖、合规）。

附录 A：符号与权重对照

符号含义权重
●强相关9
○中相关3
△弱相关1
（空）无相关0

关系图谱

反向链接