需求价值分析文档（KAD）
项目：受限网络工况下的生命体征监控智能手表（EC-SW）
方法：Kano Model（用于需求价值分层与版本优先级建议）
版本：V1.0 日期：2025-12-28
公司：ETERNALCHIP（示例文档）
1. 文档控制信息
| 字段 | 内容 |
|---|---|
| 文档名称 | 需求价值分析文档（Kano Analysis Document, KAD） |
| 文档编号 | EC-SW-KAD-001 |
| 所属阶段 | Stage 2：需求价值分析（Kano / QFD） |
| 适用产品 | 受限网络工况下的生命体征监控智能手表（EC-SW） |
| 当前版本 | V1.0 |
| 保密级别 | 内部 |
| 编写 | 系统工程团队 |
| 评审 | 产品经理 / 系统架构师 / 硬件负责人 / 软件负责人 / QA |
| 批准 | 项目经理（可选） |
2. 版本变更记录
| 版本 | 日期 | 修订内容 | 修订人 | 审核人 |
|---|---|---|---|---|
| V1.0 | 2025-12-28 | 首版：基于UND（用户需求文档）输出Kano预期分类与MVP建议，并提供问卷模板与QFD输入字段。 | Jack | Simon |
3. 背景与目标
本产品面向“受限网络/无公网”的高风险作业场景（如矿井、山区、海上平台等），通过智能手表/手环对人员生命体征与安全事件进行连续监控，并在本地网络内完成告警联动与数据闭环。
Stage 2 的目标不是写“功能清单”，而是回答：在资源有限、时间有限的情况下，哪些需求必须先做、做多好值不值、哪些是差异化卖点、哪些可以延后或砍掉。Kano 用于把需求分成不同价值类型，并输出给 QFD / Backlog。
本次KAD特别约束：
-
硬件方案：主控 STM32F411 + 蓝牙 SoC nRF52840（双MCU）。
-
不集成 NFC；定位能力优先采用 BLE 与手机协同获取（GPS 由手机提供）。
-
核心网络假设：公网不稳定或不可用，优先保障本地组网与离线可用。
4. 输入与输出（Deliverables）
输入文档：
-
Stage1-01 干系人需求文档（SND / Stakeholder Needs Document）
-
Stage1-02 用户需求文档（UND / User Needs Document，V1.0）
-
项目限制与工程假设（硬件、功耗、网络、成本、合规等）
输出文档/工件：
-
需求 Kano 分类表（预期/调研后可更新为事实数据）
-
各需求“满意度/不满意度系数”计算模板（用于量化）
-
面向 QFD 的需求权重字段（重要度、Kano系数、加权重要度）
-
MVP / Release 建议（R0/R1/R2）与风险清单
5. Kano 模型简介（用于需求价值分层）
Kano 将需求分为：基本型（Must-be, M）、期望型（One-dimensional, O）、魅力型（Attractive, A）、无差异（Indifferent, I）、反向（Reverse, R）、可疑（Questionable, Q）。它强调“同样的投入，带来的满意度提升不同”，可指导MVP与差异化策略。
常用解释：
-
基本型(M)：做了不加分，不做直接被否决（例如：续航、耐用性、安全底线）。
-
期望型(O)：做得越好越满意，线性提升（例如：定位精度、告警到达率）。
-
魅力型(A)：不做也能用，做了让用户惊喜（例如：自动开关机、智能自检）。
-
无差异(I)：用户不太在乎，做了也不明显（需谨慎投入）。
-
反向(R)：做了反而不喜欢（例如：过度打扰、频繁弹窗）。
-
可疑(Q)：问卷逻辑可能有问题或受访者理解偏差（需复核）。
Kano 定量化（可选，用于调研后）：
可计算满意度系数 CS=(A+O)/(A+O+M+I)，不满意度系数 DS=-(M+O)/(A+O+M+I)。CS 越大表示做了越能提升满意；DS 越接近 -1 表示不做会强烈不满。
5.1 Kano 评价矩阵（问卷映射规则）
| 功能性问题（如果有） \ 反功能问题（如果没有） | 喜欢 | 理所当然 | 无所谓 | 能接受 | 讨厌 |
|---|---|---|---|---|---|
| 喜欢 | Q | A | A | A | O |
| 理所当然 | R | I | I | I | M |
| 无所谓 | R | I | I | I | M |
| 能接受 | R | I | I | I | M |
| 讨厌 | R | R | R | R | Q |
6. 调研设计（建议做法）
为了把“预期分类”升级为“事实分类”，建议采用：定性访谈 + Kano 问卷。
6.1 受访者画像与样本建议
-
一线作业人员（佩戴者）：矿井/码头/钢厂等，关注可用性、舒适、告警是否真有用。
-
班组长/安全员：关注告警联动、人员状态概览、报表与追责。
-
运维/IT：关注部署成本、升级维护、日志诊断、权限与数据安全。
-
管理层/采购：关注ROI、合规风险、采购与运维成本。
样本量（课程示例建议）：
-
定性访谈：每类角色 3~5 人，快速捕捉痛点与语言体系。
-
Kano 问卷：总计 25~50 份即可支撑初版分类；若涉及采购决策可扩大管理侧样本。
6.2 问卷题目结构（示例）
每条需求对应一对问题：功能性（有该能力时你感觉如何）+ 反功能性（没有该能力时你感觉如何）。
答案选项建议固定为 5 档：喜欢 / 理所当然 / 无所谓 / 能接受 / 讨厌。
7. Kano 初版结果（基于UND的预期分类，用于启动QFD与MVP）
说明：由于当前未提供真实问卷统计数据，本节为“行业经验 + 场景约束”下的预期分类。在进入试点或客户访谈后，可用第8章模板将其更新为事实数据。
7.1 用户需求 Kano 分类与版本建议（输入 QFD）
7.1 用户需求 Kano 分类总表（预期）
| UN-ID | 用户需求 | 业务优先级 | 预期Kano类型 | 建议版本 | 分析依据 |
|---|---|---|---|---|---|
| UN-001 | 我希望手表/手环戴一整班也不硌手、不闷汗、不过敏，佩戴牢固不脱落。 | Must | 基本型(Must-be) | R0/MVP | 佩戴舒适是基本质量，否则直接弃用。 |
| UN-002 | 我希望戴手套也能完成关键操作（SOS、确认告警、查看关键信息）。 | Must | 基本型(Must-be) | R0/MVP | 现场戴手套是常态，关键操作不可缺失。 |
| UN-003 | 我希望在弱光/强光下都能看清关键告警与时间信息。 | Should | 基本型(Must-be) | R0/MVP | 可读性是最基础的可用性要求。 |
| UN-004 | 我希望设备能持续监测心率等关键生命体征，并在异常时提醒我和管理者。 | Must | 基本型(Must-be) | R0/MVP | 生命体征监测是产品存在的核心基本功能。 |
| UN-005 | 我希望能监测体温/血氧等关键指标，用于高风险作业的健康筛查与预警。 | Should | 魅力型(Attractive) | R2 | 更多指标属于增值项，早期可作为差异化。 |
| UN-006 | 我希望一键 SOS 求救，且在网络不好时也能尽最大努力把求救发出去。 | Must | 基本型(Must-be) | R0/MVP | 一键求救是安全类产品的底线。 |
| UN-007 | 我希望设备在无网络/弱网络时不丢数据：能本地缓存，恢复后自动补传。 | Must | 基本型(Must-be) | R0/MVP | 受限网络场景下数据可靠交付是底线。 |
| UN-008 | 我希望告警能够分级（紧急/重要/提示），减少误报骚扰，同时不漏掉真异常。 | Must | 期望型(One-dimensional) | R0/MVP | 事件可追溯性越强越有价值，直接影响管理效率。 |
| UN-009 | 我希望班组长/监控室能看到“谁在异常、在哪、持续多久、是否已处理”。 | Must | 基本型(Must-be) | R0/MVP | 企业侧需要人员/班组绑定，否则无法落地管理。 |
| UN-010 | 我希望能大致知道人员所在区域，进入危险区域时能提醒。 | Should | 期望型(One-dimensional) | R0/MVP | 定位/围栏精度越高越能减少误报漏报。 |
| UN-011 | 我希望上班时自动开始监测，下班后自动结束/低功耗，不需要每天手动配置。 | Should | 魅力型(Attractive) | R2 | 自动开关机提升体验与续航，属于惊喜项。 |
| UN-012 | 我希望手表电池能支撑至少一个完整班次，最好能覆盖加班/双班，电量低时提前提醒。 | Must | 基本型(Must-be) | R0/MVP | 无公网本地组网是此产品的核心能力之一。 |
| UN-013 | 我希望设备防水防尘、抗跌落、抗油污，坏了也能快速更换。 | Must | 期望型(One-dimensional) | R0/MVP | 联动通知越及时越能降低事故风险。 |
| UN-014 | 我希望设备在异常情况下有清晰的提示（震动/蜂鸣/屏显），周围很吵也能感知。 | Should | 基本型(Must-be) | R0/MVP | 续航不足会直接导致不可用。 |
| UN-015 | 我希望设备能记录事件与关键数据，事后可导出用于事故复盘与审计。 | Should | 基本型(Must-be) | R0/MVP | 企业部署必须可维护与可升级（安全修复/功能迭代）。 |
| UN-016 | 我希望设备能支持批量发放、快速绑定/解绑，适配人员轮班与临时工。 | Must | 期望型(One-dimensional) | R1 | 日志导出提升可运维性，随规模增长价值更大。 |
| UN-017 | 我希望设备出现故障能自检并提示，运维能快速定位问题（日志、版本、配置）。 | Should | 魅力型(Attractive) | R1 | 自检降低运维成本，减少现场排障时间。 |
| UN-018 | 我希望能远程升级固件（OTA），但升级不能影响现场安全与稳定。 | Must | 基本型(Must-be) | R0/MVP | 关键状态显示是基本体验。 |
| UN-019 | 我希望不同部门能按权限查看数据：个人隐私不被滥用。 | Must | 期望型(One-dimensional) | R1 | App协同提升配置与数据可视化，属于性能项。 |
| UN-020 | 我希望设备能与现有安全平台/工厂系统对接，避免重复建设。 | Should | 期望型(One-dimensional) | R1 | 平台对接越完善越能形成闭环管理。 |
| UN-021 | 我希望定位/数据上报不要强依赖手机；手机不可用时仍可通过现场网关/基站工作。 | Must | 无差异(Indifferent) | R2 | GPS从手机获取仅覆盖部分场景，需结合定位方案评估。 |
| UN-022 | 我希望手表时间准确，断电后也不会乱，方便事件对齐与追溯。 | Should | 基本型(Must-be) | R0/MVP | 工业环境下防护等级是基本门槛。 |
| UN-023 | 我希望能在手表上看到最少但关键的信息：时间、电量、连接状态、是否在监测中。 | Should | 基本型(Must-be) | R0/MVP | 佩戴舒适与UN-001同属基本质量（可合并，但保留以便追踪）。 |
| UN-024 | 我希望在极端情况下（低温/高温/高湿）设备依然可用。 | Should | 基本型(Must-be) | R0/MVP | 极端温度工况是场景约束，需满足才可部署。 |
| UN-025 | 我希望设备丢了能被发现（最后在线时间/区域），减少资产损失。 | Could | 魅力型(Attractive) | R2 | 丢失/脱落提醒能提升管理，但非最小可用必需。 |
| UN-026 | 我希望系统能生成简洁报表：出勤、告警次数、处置时长、风险趋势。 | Could | 魅力型(Attractive) | R2 | 报表属于管理层增值功能。 |
| UN-027 | 我希望系统部署与维护尽量简单：少布线、少改造、易扩容。 | Must | 期望型(One-dimensional) | R0/MVP | 成本越低越易规模化采购。 |
| UN-028 | 我希望在数据链路中有基本安全措施，避免被伪造告警或窃取数据。 | Should | 基本型(Must-be) | R0/MVP | 数据安全与权限是企业采购与合规底线。 |
7.2 面向QFD的权重字段（可直接拷贝到QFD矩阵）
| UN-ID | 重要度(1-5) | Kano系数 | 加权重要度 |
|---|---|---|---|
| UN-001 | 5 | 1.0 | 5.0 |
| UN-002 | 5 | 1.0 | 5.0 |
| UN-003 | 4 | 1.0 | 4.0 |
| UN-004 | 5 | 1.0 | 5.0 |
| UN-005 | 4 | 1.1 | 4.4 |
| UN-006 | 5 | 1.0 | 5.0 |
| UN-007 | 5 | 1.0 | 5.0 |
| UN-008 | 5 | 1.2 | 6.0 |
| UN-009 | 5 | 1.0 | 5.0 |
| UN-010 | 4 | 1.2 | 4.8 |
| UN-011 | 4 | 1.1 | 4.4 |
| UN-012 | 5 | 1.0 | 5.0 |
| UN-013 | 5 | 1.2 | 6.0 |
| UN-014 | 4 | 1.0 | 4.0 |
| UN-015 | 4 | 1.0 | 4.0 |
| UN-016 | 5 | 1.2 | 6.0 |
| UN-017 | 4 | 1.1 | 4.4 |
| UN-018 | 5 | 1.0 | 5.0 |
| UN-019 | 5 | 1.2 | 6.0 |
| UN-020 | 4 | 1.2 | 4.8 |
| UN-021 | 5 | 0.6 | 3.0 |
| UN-022 | 4 | 1.0 | 4.0 |
| UN-023 | 4 | 1.0 | 4.0 |
| UN-024 | 4 | 1.0 | 4.0 |
| UN-025 | 3 | 1.1 | 3.3 |
| UN-026 | 3 | 1.1 | 3.3 |
| UN-027 | 5 | 1.2 | 6.0 |
| UN-028 | 4 | 1.0 | 4.0 |
7.3 MVP / Release 建议（基于Kano类型与业务优先级）
为了形成可交付的最小闭环，建议按以下原则拆分版本：
-
R0/MVP：覆盖全部基本型(M)需求 + 高价值期望型(O)的最小实现，确保“能用、能部署、能运维”。
-
R1：补齐运维与平台化能力（日志、自检、App/平台协同），降低规模化部署成本。
-
R2：差异化与管理增值功能（自动开关机、更多体征扩展、报表、丢失/脱落提醒等）。
R0/MVP（建议优先实现）：UN-001, UN-002, UN-003, UN-004, UN-006, UN-007, UN-008, UN-009, UN-010, UN-012, UN-013, UN-014, UN-015, UN-018, UN-022, UN-023, UN-024, UN-027, UN-028
R1（建议迭代实现）：UN-016, UN-017, UN-019, UN-020
R2（建议延后/差异化）：UN-005, UN-011, UN-021, UN-025, UN-026
7.4 风险与待澄清问题（用于进入QFD/架构阶段前对齐）
-
定位/电子围栏在矿井等室内场景的实现方案（BLE RSSI、UWB、基站等）与精度指标尚需量化。
-
“弱网缓存与重传”需结合数据量、告警实时性与功耗预算，明确缓存深度与重传策略。
-
数据安全与权限：本地网络内的密钥管理、设备身份、升级验签、日志合规留存策略需要在ADR中决策。
-
手机协同（GPS/配置）在禁带手机场景下的可行性需要明确替代方案（如调度终端）。
8. 调研数据填充模板（用于把“预期Kano”升级为“事实Kano”）
8.1 Kano 问卷题目模板（示例）
以下为模板示例，实际问卷应从UND挑选“可表述为用户感受”的需求条目，并保持语言贴近一线作业人员。
| 需求条目 | 功能性问题（有该能力时） | 反功能性问题（没有该能力时） | 备注 |
|---|---|---|---|
| UN-004 连续监测生命体征与趋势 | 如果手表具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 如果手表不具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 建议补充“重要度评分1-5” |
| UN-006 一键SOS求救 | 如果手表具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 如果手表不具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 建议补充“重要度评分1-5” |
| UN-010 区域定位与电子围栏 | 如果手表具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 如果手表不具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 建议补充“重要度评分1-5” |
| UN-007 弱网缓存与重传 | 如果手表具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 如果手表不具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 建议补充“重要度评分1-5” |
| UN-014 电量与续航管理 | 如果手表具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 如果手表不具备该能力，你感觉如何？（喜欢/理所当然/无所谓/能接受/讨厌） | 建议补充“重要度评分1-5” |
8.2 Kano 统计表模板（每条需求一行）
统计每条需求在问卷中的分类计数，并计算CS/DS，最终确定Kano类型。
| UN-ID | A | O | M | I | R | Q | CS | DS | 最终Kano | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
| UN-001 | ||||||||||
| UN-002 | ||||||||||
| UN-003 | ||||||||||
| UN-004 | ||||||||||
| UN-005 | ||||||||||
| UN-006 | ||||||||||
| UN-007 | ||||||||||
| UN-008 | ||||||||||
| UN-009 | ||||||||||
| UN-010 |
8.3 输出给QFD的字段说明
当得到事实Kano类型后，建议按以下规则输出到QFD：
-
重要度：来自问卷“重要度评分”均值或业务优先级映射。
-
Kano系数：用于区分不同类型的价值（例如：M=1.0，O=1.2，A=1.1，I=0.6，可按组织习惯调整）。
-
加权重要度 = 重要度 × Kano系数（作为QFD的VOC权重输入）。
附录A：术语与缩写
| 缩写 | 含义（中文） | 英文 |
|---|---|---|
| SND | 干系人需求文档 | Stakeholder Needs Document |
| UND | 用户需求文档 | User Needs Document |
| BRD | 业务需求文档 | Business Requirements Document |
| SyRS | 系统需求规格说明 | System Requirements Specification |
| KAD | 需求价值分析文档 | Kano Analysis Document |
| QFD | 质量功能展开/需求映射 | Quality Function Deployment |
附录B：本版本与硬件/方案约束的对齐说明
本KAD已按最新约束更新：不集成NFC；GPS定位需求通过“手机协同（BLE）”满足。若后续出现“禁带手机”或“必须独立定位”等场景变化，应回到UND与KAD重新评估，并在ADR中记录。