第二章：需求分析与规格定义
好，咱们正式开始聊需求。说实话，很多工程师觉得写需求文档是产品经理的事，跟自己没关系。我当年也这么想，直到有一次……嗯，后面再说。
用户故事与用例分析
先说说用户故事。这东西说白了就是一句话：谁，想干什么，为什么。比如牙刷项目，用户故事可以写成：
作为一位上班族用户
我想要牙刷在2分钟内完成清洁
这样我早上不会迟到你看，就这么简单。但别小看它。我在项目中遇到过，团队花了两周讨论「刷牙时间该设多久」，最后发现用户真正在意的是「别耽误我出门」。所以用户故事的核心，是抓住动机。
我的习惯：每个用户故事都问三遍「为什么」。第一遍得到功能，第二遍得到场景，第三遍才能挖到真实需求。
用例分析就更具体了。用例描述的是系统跟用户的交互过程。拿牙刷举例：
- 主成功场景：用户按下启动键 → 牙刷振动 → 2分钟后自动停止
- 扩展场景：用户中途按暂停 → 牙刷停止振动 → 再按继续
- 异常场景：电量不足 → 牙刷先振动3次提示 → 然后停止
你想想看，如果不写这些，开发的时候就会漏掉「暂停」这个功能。我见过太多产品，连个暂停键都没有，用户刷到一半想漱口只能干瞪眼。
功能需求与非功能需求
功能需求好理解，就是「系统能做什么」。比如：
- 支持3种刷牙模式（清洁、敏感、美白）
- 每30秒提醒换区
- 蓝牙连接手机App
但非功能需求才是真正考验功力的地方。说白了，就是「系统做得怎么样」。举个例子：
| 需求类型 | 具体描述 | 量化指标 |
|---|---|---|
| 性能 | 牙刷响应按键延迟 | < 50ms |
| 功耗 | 待机电流 | < 5μA |
| 可靠性 | 防水等级 | IPX7 |
| 安全性 | 充电过压保护 | 4.3V截止 |
我曾经踩过的坑：有个项目功能需求写得漂漂亮亮，结果量产时发现待机电流超标。原因？没人定义「待机电流要小于5μA」。最后只能临时改硬件，成本翻倍。所以非功能需求一定要量化，别写「低功耗」，要写「小于5μA」。
技术规格书（PRD/TRS）撰写要点
PRD是产品需求文档，TRS是技术规格书。两者有重叠，但侧重点不同。PRD面向产品经理和测试，TRS面向开发工程师。
PRD撰写要点：
- 用用户故事开头，讲清楚「为什么做」
- 功能列表要完整，包括异常处理
- 界面原型或交互流程图（哪怕手绘也行）
- 验收标准要明确：什么算「做完」
TRS撰写要点：
- 硬件接口定义：引脚、电平、时序
- 软件模块划分：任务、优先级、通信协议
- 状态机描述：每个状态做什么，怎么切换
- 错误码定义：0x01代表什么故障
// 举个TRS中的状态机例子
typedef enum {
STATE_IDLE, // 待机
STATE_BRUSHING, // 刷牙中
STATE_PAUSED, // 暂停
STATE_CHARGING, // 充电中
STATE_ERROR // 故障
} BrushState_t;我个人习惯：写TRS时，先画一张系统框图。把主控、传感器、电机、蓝牙、电池画清楚，然后每个模块再展开写。这样开发的时候，每个人都知道自己负责的部分跟谁交互。
嗯，这里要注意一点：PRD和TRS不是写一次就完事的。需求会变，规格也会调。我建议用版本号管理，比如V1.0、V1.1。每次改完，在文档开头写清楚「变更记录」。别问我为什么强调这个——有一次我拿着旧版TRS去调试，折腾了两天才发现是文档没更新。
最后说一句：文档是写给未来的人看的。三个月后的你，或者接手你代码的同事，都会感谢你写得清楚。所以别偷懒，该写的表格、代码、状态机，一个都别少。