第二章：需求分析阶段——需求捕获技术、需求文档编写（PRD/用例）、需求评审与确认

大家好，我是你们的老朋友。今天咱们聊聊嵌入式项目里最容易被轻视、但坑最多的环节——需求分析。

说实话，我见过太多项目，开发到一半才发现需求没搞清楚。然后就是返工、加班、吵架。嗯，这滋味不好受。所以这一章，我把自己踩过的坑和总结的经验，都掏出来给你们。

2.1 需求捕获技术：别等着用户告诉你

很多人觉得，需求就是用户说啥我做啥。其实不是。用户往往说不清楚自己要什么。你想想看，一个做智能家居的客户，他只会说“我要一个能远程控制的灯”，但不会告诉你“断电后要保存状态”、“响应时间不能超过200ms”。

我个人习惯用三种方法组合来捕获需求：

• 用户访谈：别只问“你想要什么”，要问“你现在怎么做的”、“哪里最烦”。我在做车载项目时，访谈司机才发现，他们最痛恨的不是导航不准，而是屏幕反光看不清。
• 现场观察：去实际环境看用户怎么用设备。有一次我去工厂看设备操作，发现工人为了省事，经常跳过自检流程。这就是一个隐藏需求——必须强制自检。
• 原型演示：拿个简陋的Demo给用户看。用户看到实物才会说“哦，这个按钮应该放在右边”。

2.2 需求文档编写：PRD与用例

需求捕获完了，得写下来。不然过两周你自己都忘了。嵌入式项目里，我主要写两种文档：PRD（产品需求文档）和用例。

2.2.1 PRD怎么写？

PRD不是写小说，别啰嗦。我一般按这个结构来：

章节	内容	我的经验
1. 项目背景	为什么要做这个产品	写清楚，不然半年后没人记得初衷
2. 功能列表	所有功能点，编号管理	每个功能加优先级：P0/P1/P2
3. 非功能需求	功耗、响应时间、内存限制	这块最容易漏，我吃过亏
4. 接口定义	硬件接口、通信协议	最好画个图，文字说不清
5. 约束条件	成本、尺寸、认证要求	写清楚，不然硬件选型会出问题

2.2.2 用例怎么写？

用例说白了就是讲一个故事：谁在什么场景下，做了什么，系统怎么反应。我习惯用这个模板：

用例编号：UC-001
用例名称：用户通过手机App远程开锁
前置条件：门锁已联网，App已登录
主流程：
  1. 用户在App点击“开锁”按钮
  2. App发送开锁指令到云端
  3. 云端转发到门锁
  4. 门锁验证指令合法性
  5. 门锁驱动电机开锁
  6. 门锁返回“开锁成功”状态
  7. App显示“门已开”
异常流程：
  2a. 网络超时：App提示“网络异常”
  4a. 指令校验失败：门锁返回错误码，App提示“操作失败”
后置条件：门锁状态更新为“已开锁”

我曾经在一个项目中，用例写了200多个。开发看到想打我。但后来测试阶段，bug少了一半。值不值？你自己掂量。

2.3 需求评审与确认：别让需求变成“悬案”

文档写完了，得评审。不评审就开干，那是赌博。

我组织评审会时，有个原则：让开发、测试、硬件、产品经理都到场。少一个人，就可能漏掉一个视角。

评审会怎么开？

1. 提前发文档：别在会上才让人看。提前两天发，让大家带着问题来。
2. 逐条过需求：别跳着看。我习惯用投影仪，一条一条过。
3. 记录争议点：有分歧很正常。记下来，会后找拍板的人决定。
4. 签字确认：听起来老土，但有用。签了字，后面扯皮就有依据。

需求确认的“三问法”

每次评审完，我都会问三个问题：

• 这个需求，开发能看懂吗？ 如果开发说“有点模糊”，那就回去改。
• 这个需求，测试能验证吗？ 如果测试说“不知道怎么测”，那需求就不够具体。
• 这个需求，用户真的需要吗？ 如果产品经理说“可能是需要的”，那就砍掉。模糊的需求就是毒药。

2.4 我的需求分析“避坑清单”

最后，分享一个我用了多年的清单。每次项目开始前，我都会过一遍：

检查项	常见坑	我的对策
需求是否完整	漏了边界条件	用“如果...那么...”句式穷举
需求是否一致	前后矛盾	用工具做交叉检查
需求是否可测试	写得太虚	每个需求配一个测试用例
需求是否可实现	技术不可行	提前做技术预研
需求优先级是否明确	什么都想要	用MoSCoW法分类

嗯，这一章内容不少。但说真的，需求分析花的时间，会在后面十倍百倍地省回来。我见过太多项目，需求阶段省了三天，后面返工花了三周。你算算这笔账。

下一章，咱们聊聊系统设计。到时候我会讲讲怎么把需求变成架构，以及那些年我画过的“废图”。