第3章 硬件功能场景建模：用户故事·环境·触发·期望
硬件功能需求不能仅靠“用户想要什么”来定义。与纯软件功能不同，硬件的行为高度依赖物理环境、操作时机和可观测的物理响应。本章将带你建立一套面向硬件功能的用户故事编写框架，把用户角色、使用环境、触发条件和期望行为四个要素结构化地融入需求描述中，从而消除硬件需求中常见的模糊地带。
本章核心目标：学会用“四要素用户故事”模板描述硬件功能，使研发、测试、生产各方对“功能到底是什么”达成一致。
3.1 硬件用户故事的特殊性
软件用户故事通常采用“As a… I want… So that…”三要素结构。硬件功能在此基础上必须增加两个关键维度：
- 使用环境（Environment） — 硬件在何种物理条件下运行（温度、湿度、振动、光照、电磁干扰等）。
- 触发条件（Trigger） — 用户操作或系统状态变化的具体时刻或事件。
因此，硬件用户故事的标准模板扩展为：
硬件用户故事模板：
作为一个 [用户角色]，在 [使用环境] 中，当 [触发条件] 时，我希望 [期望行为]，以便 [业务价值]。
作为一个 [用户角色]，在 [使用环境] 中，当 [触发条件] 时，我希望 [期望行为]，以便 [业务价值]。
3.2 四要素逐层拆解
下面逐一拆解每个要素的定义、考察维度和典型错误。
| 要素 | 定义 | 关键考察维度 | 硬件示例 |
|---|---|---|---|
| 用户角色 | 谁直接操作或依赖该硬件功能 | 技能水平、身体能力、操作频率、安全权限 | 生产线工人、维修工程师、终端消费者 |
| 使用环境 | 硬件运行时的物理与系统上下文 | 温度范围、湿度、粉尘、振动、电磁兼容、供电稳定性 | 户外-20°C冰雪环境、医院洁净室、矿山井下 |
| 触发条件 | 启动该功能的具体事件或状态变化 | 用户操作、定时任务、传感器阈值、通信指令、故障信号 | 按下启动按钮、温度超过60°C、收到CAN总线唤醒帧 |
| 期望行为 | 硬件在触发后应产生的可观测/可测量响应 | 响应时间、输出精度、声光指示、功耗变化、机械行程 | 2秒内完成自检并亮绿灯、电机转动角度误差≤0.5° |
3.3 使用环境：硬件需求的“隐形约束”
使用环境是硬件需求中最容易被忽略、但后期修改成本最高的要素。一个在实验室正常工作的传感器，在户外高湿环境中可能完全失效。定义环境时至少应覆盖以下维度：
- 气候环境：环境温度、湿度、盐雾、凝露、太阳辐射。
- 机械环境：振动频率与振幅、冲击、自由跌落。
- 电磁环境：工频磁场、射频辐射、静电放电（ESD）。
- 供电环境：电压波动、掉电保持时间、浪涌。
常见错误：用“常规室内环境”一笔带过。对于硬件产品，“常规”二字会引发后期大量争议。正确做法是直接引用国标或行业规范等级，例如“满足GB/T 2423.1低温-40°C试验”。
3.4 触发条件：明确“什么时候干活”
触发条件定义硬件从待机/空闲状态进入功能执行状态的时机。按来源可分为三类：
- 人机触发：用户按下按键、触摸屏幕、语音指令、手势识别。
- 系统内部触发：定时唤醒、传感器阈值中断、看门狗超时、通信协议事件。
- 外部环境触发：供电恢复、门磁开关闭合、光照强度变化、振动检测。
一个功能可能由多个触发条件组合激活，此时必须在用户故事中明确逻辑关系（AND / OR）。
3.5 期望行为：可量化才有验收
期望行为是四要素中唯一直接对应验收标准的要素。好的期望行为应满足“SMART-硬件”原则：
- S（Specific）：明确具体动作，避免“正常工作”“做出响应”等模糊描述。
- M（Measurable）：可测量或可观察，如“电机转速3000±50 RPM”。
- A（Achievable）：在当前硬件架构下可实现。
- R（Relevant）：与用户价值直接相关。
- T（Time-bound）：明确响应时间或持续时间约束。
量化示例：
❌ 差：门锁识别指纹后快速打开。
✅ 好：门锁在指纹识别成功后 0.8 秒内驱动电机旋转 180°，带动锁舌缩回至完全开启位置，同时蜂鸣器发出 1 声短鸣（0.2s / 2kHz）。
❌ 差：门锁识别指纹后快速打开。
✅ 好：门锁在指纹识别成功后 0.8 秒内驱动电机旋转 180°，带动锁舌缩回至完全开启位置，同时蜂鸣器发出 1 声短鸣（0.2s / 2kHz）。
3.6 完整案例：智能门锁指纹识别功能
下面用四要素模板编写一个完整的硬件用户故事：
| 要素 | 内容 |
|---|---|
| 用户角色 | 已注册指纹的家庭成员（成人手指皮肤正常） |
| 使用环境 | 住宅入户门外侧，环境温度 -10°C~55°C，相对湿度 ≤95%RH，无凝露，正面阳光直射 ≤5000Lux |
| 触发条件 | 用户将已注册指纹的手指放置在传感器感应区域，且传感器检测到手指覆盖面积 ≥80% 有效区域 |
| 期望行为 | 1. 传感器在 300ms 内完成指纹采集与比对； 2. 比对通过后，主控在 100ms 内驱动电机开锁； 3. 锁舌完全缩回时间 ≤0.8s； 4. 同时绿色 LED 常亮 2s，蜂鸣器发出 1 声短鸣； 5. 若比对失败，红色 LED 闪烁 3 次，无电机动作。 |
| 业务价值 | 用户无需携带钥匙，单手 1 秒内完成开门，提升入户便利性与安全性。 |
将上述四要素合并为完整的用户故事叙述：
作为一个已注册指纹的家庭成员，
在住宅入户门外侧（环境温度 -10°C~55°C，湿度 ≤95%RH，无凝露，阳光直射 ≤5000Lux），
当我把已注册指纹的手指覆盖传感器有效区域 ≥80% 时，
我希望门锁在 0.8 秒内完成指纹比对并驱动电机开锁，
同时给出明确的声光反馈（绿灯+短鸣），
以便我无需携带钥匙即可单手快速入户。3.7 常见误区与避坑指南
误区一：把“使用环境”写在需求文档的全局假设中，而不是附着在具体功能上。
正确做法：每个关键功能都应独立声明其运行环境，因为同一硬件的不同功能可能面向不同环境（例如，指纹识别模块在户外 vs 室内）。
正确做法：每个关键功能都应独立声明其运行环境，因为同一硬件的不同功能可能面向不同环境（例如，指纹识别模块在户外 vs 室内）。
误区二：触发条件写得太笼统，如“用户操作时”。
正确做法：写明具体操作方式、力度、持续时间、组合键等，例如“长按电源键 3 秒（允许 ±0.5s 偏差）”。
正确做法：写明具体操作方式、力度、持续时间、组合键等，例如“长按电源键 3 秒（允许 ±0.5s 偏差）”。
误区三：期望行为只写功能结果，不写时间约束和容差。
正确做法：所有信号、运动、输出必须附带“最大值/最小值/典型值”或“容差范围”。
正确做法：所有信号、运动、输出必须附带“最大值/最小值/典型值”或“容差范围”。
3.8 本章交付物模板：硬件用户故事卡片
以下卡片模板可直接用于需求评审会或需求文档中，每个功能对应一张卡片：
┌─────────────────────────────────────────────────────────────
│ 【硬件用户故事卡片】 功能编号：HUS-XXX
│
│ 用户角色：______________________________________________
│ 使用环境：______________________________________________
│ 触发条件：______________________________________________
│ 期望行为：______________________________________________
│ 业务价值：______________________________________________
│
│ 验收标准关联：☐ 环境试验 ☐ 时序测试 ☐ 精度测试 ☐ 可靠性
│ 需求来源：☐ 用户访谈 ☐ 竞品分析 ☐ 标准法规 ☐ 内部提案
│ 优先级（RICE）：Reach____ Impact____ Confidence____ Effort____
└─────────────────────────────────────────────────────────────
团队协作建议：在需求评审会上，使用本模板逐条朗读四要素，让研发、测试、生产三方分别从各自视角提出质疑，可以提前暴露 80% 以上的需求模糊点。
掌握了本章的四要素建模方法，你就拥有了将模糊的硬件“想法”转化为可讨论、可验证、可排期的功能定义的能力。下一流程环节将基于这些用户故事开展用户访谈与需求拆解。