第二章 需求分析实战：从用户故事到PRD文档
好，咱们直接进入正题。需求分析这步，说白了就是搞清楚「到底要做什么」。我见过太多项目，开发到一半才发现需求没对齐，然后疯狂改代码。嗯，那种感觉，就像你开车上了高速才发现油箱是空的。
今天这一章，我会带着你走一遍完整的流程：从用户故事编写，到功能需求拆解，再到非功能需求定义，最后输出一份能用的PRD。我个人习惯是，先想清楚「谁在用」和「怎么用」，再谈技术实现。
2.1 用户故事：让需求「活」起来
用户故事不是写作文，是帮你和团队对齐认知的工具。格式很简单：
作为【角色】，我想要【功能】，以便【价值】。举个例子，充电桩最常见的三个场景：
- 刷卡充电：作为车主，我想要刷卡启动充电，以便快速开始充电，不用掏手机。
- 扫码充电：作为车主，我想要用App扫码充电，以便远程查看充电状态和费用。
- 即插即充：作为固定用户，我想要插枪自动充电，以便省去所有操作步骤。
我在项目中遇到过，有些团队把用户故事写成了需求说明书，又长又臭。其实用户故事的核心是「对话」，不是「文档」。你写出来，是为了和产品、测试、硬件团队吵架用的——吵明白了，需求就清晰了。
2.2 功能需求：拆解到能编码
用户故事是「做什么」，功能需求是「怎么做」。咱们拿「刷卡充电」来拆解：
| 用户故事 | 功能需求 | 优先级 |
|---|---|---|
| 刷卡启动充电 | 1. 读卡器检测到卡片 2. 读取卡号并校验 3. 校验通过后闭合接触器 4. 启动充电流程 |
P0 |
| 扫码充电 | 1. 屏幕显示二维码 2. 云端下发充电指令 3. 桩端解析指令并启动 |
P0 |
| 即插即充 | 1. 检测插枪信号 2. 匹配用户白名单 3. 自动鉴权并启动 |
P1 |
这里要注意，功能需求要写到「能编码」的程度。比如「读卡器检测到卡片」，你得明确：是ISO14443 Type A还是Type B？通信速率是多少？超时时间多长？
2.3 非功能需求：决定产品生死
功能需求决定「能不能用」，非功能需求决定「好不好用」。充电桩是户外设备，环境恶劣，非功能需求尤其重要。
2.3.1 可靠性
说白了，就是别动不动就死机。我见过一个项目，充电桩运行三天必重启一次，用户投诉到工商局。可靠性指标一般这么定：
- MTBF（平均无故障时间）：≥ 5000小时
- MTTR（平均修复时间）：≤ 30分钟
- 启动成功率：≥ 99.5%
你想想看，如果用户插枪后10次有1次启动失败，他还会用你的桩吗？
2.3.2 环境适应性
充电桩可能装在海南的湿热环境，也可能装在黑龙江的冰天雪地。环境适应性需求要覆盖：
- 工作温度：-20℃ ~ 55℃（北方要-30℃）
- 防护等级：IP54（户外最低要求）
- 盐雾腐蚀：沿海地区要72小时盐雾测试
- 振动冲击：运输和安装过程中的机械应力
2.3.3 EMC（电磁兼容性）
EMC是充电桩的「隐形杀手」。你想想，充电桩内部有大功率开关电源，外部有电网干扰，如果不处理好，轻则通信丢包，重则烧毁控制板。
EMC需求一般包括：
- 辐射发射：符合GB/T 18655 Class 3
- 传导发射：符合GB/T 18655 Class 3
- 静电放电：接触放电±6kV，空气放电±8kV
- 浪涌抗扰度：±2kV（线对线），±4kV（线对地）
嗯，这里要注意，EMC测试最好在原型阶段就做。我见过一个项目，等到量产前才做EMC，结果发现辐射超标，改板子花了两个月，错过了上市窗口。
2.4 PRD文档：把需求「锁死」
PRD（产品需求文档）是团队所有人的「契约」。写PRD不是为了好看，是为了以后吵架时有据可查。
一份合格的充电桩PRD至少包含：
- 项目背景：为什么要做这个产品？目标市场是什么？
- 用户角色：车主、运营商、运维人员、管理员
- 功能列表：所有功能需求，带优先级和验收标准
- 非功能需求：可靠性、环境、EMC、安全等
- 交互流程：用户操作流程图，状态转换图
- 接口定义：与云端、App、读卡器、电表的通信协议
- 验收标准：每个功能怎么测试才算通过
2.5 实战案例：一个「即插即充」的完整需求
咱们拿「即插即充」来完整走一遍。假设用户故事是：
作为固定车位车主，我想要插枪自动充电，以便不用每次刷卡或扫码。拆解后的功能需求：
- 插枪检测：CC信号检测，电阻值判断插枪状态
- 用户匹配：通过CP信号或蓝牙，识别车辆VIN或用户ID
- 鉴权流程：本地白名单匹配，或云端在线鉴权
- 启动充电：闭合接触器，开始充电流程
- 异常处理：鉴权失败、超时、插枪异常等场景
非功能需求：
- 鉴权响应时间 ≤ 2秒
- 插枪到启动时间 ≤ 5秒
- 白名单容量 ≥ 1000条
- 离线模式下支持至少100次充电
你看，这样写出来，开发人员拿到就能直接干活。测试人员也知道要测什么。
2.6 本章小结
需求分析不是写文档，是帮团队「对齐认知」。我个人觉得，最核心的就三件事：
- 用用户故事讲清楚「谁用、怎么用」
- 用功能需求拆解到「能编码」
- 用非功能需求保证「能活下来」
下一章，咱们会聊系统架构设计。到时候我会拿一个真实的充电桩项目，带你看看怎么把需求变成硬件和软件的架构图。嗯，那才是真正有意思的部分。