第2章：需求分析与管理
说实话，很多BMS项目做砸了，不是技术不行，而是需求没搞明白。我见过太多团队，代码写了一半才发现客户要的功能跟理解的根本不是一回事。嗯，这一章我们就聊聊怎么把需求这件事做扎实。
2.1 客户需求收集
客户需求收集，说白了就是搞清楚对方到底要什么。但这里有个坑——客户自己往往也说不清楚。
我记得有一次，客户说“我要一个能监控电池的系统”。结果一细问，他要的是能精确到每颗电芯的电压、温度，还要能预测剩余寿命。你看，这差距有多大。
收集方法
- 访谈法：直接跟客户聊，最好带上技术负责人。我习惯准备一份问题清单，比如“电池包的总电压范围是多少？”“工作温度区间是什么？”
- 问卷法：适合收集大量用户的通用需求。但要注意，问卷设计不能太技术化，否则对方看不懂。
- 原型演示：做个简单的界面或功能demo，让客户“摸一摸”。这招特别管用，客户看到实物后往往会提出更具体的需求。
- 竞品分析：看看市面上同类产品有什么功能。客户可能不会主动说“我要像XX产品那样”，但你可以主动提出来。
我的小技巧：每次访谈后，当天就把记录整理成文档。隔天再发给客户确认。这样做能避免很多误解。
2.2 系统需求规格说明书（SRS）撰写
SRS是项目的“宪法”。所有后续的设计、开发、测试，都得围着它转。写SRS最忌讳的就是含糊其辞。
SRS的核心内容
| 章节 | 内容 | 示例（BMS项目） |
|---|---|---|
| 1. 引言 | 项目背景、目标、范围 | 本系统用于48V电动自行车电池包管理 |
| 2. 总体描述 | 产品特性、用户特征、约束条件 | 工作温度：-20℃~60℃ |
| 3. 功能需求 | 具体功能列表 | 过压保护：单节电芯电压>4.25V时切断充电 |
| 4. 非功能需求 | 性能、安全、可靠性 | 电压采样精度：±5mV |
| 5. 接口需求 | 硬件接口、通信协议 | CAN通信，波特率250kbps |
写SRS的黄金法则：每个需求都要可验证。比如“系统要稳定”这种话就别写了。改成“系统在连续运行72小时内，无故障率≥99.9%”。
我曾经在一个项目里，SRS里写了“电池均衡功能”。结果开发团队做了被动均衡，客户要的是主动均衡。你看，就两个字没写清楚，后面返工花了三周。
2.3 需求优先级排序
需求永远做不完。资源有限，时间有限，必须学会取舍。我个人习惯用MoSCoW方法。
MoSCoW四象限
- M - Must have（必须有）：没有这个功能，系统就不能用。比如BMS的过压保护、过温保护。
- S - Should have（应该有）：很重要，但暂时没有也能凑合。比如SOC（电量）估算精度从5%提升到3%。
- C - Could have（可以有）：锦上添花的功能。比如通过手机APP查看电池状态。
- W - Won't have（这次不做）：明确告诉客户，这个版本不做。比如电池历史数据云存储。
注意：优先级排序不是技术团队自己拍脑袋定的。一定要跟客户一起过一遍。我曾经吃过这个亏，自己觉得某个功能不重要，结果客户验收时死活不签字。
2.4 需求变更管理
需求变更是常态，不变才奇怪。但变更不能乱来，得有流程。
变更管理流程
- 提出变更：客户或内部人员填写《需求变更申请单》。
- 影响分析：评估变更对进度、成本、质量的影响。我一般会拉上硬件、软件、测试一起开会。
- 评审决策：项目经理、技术负责人、客户代表一起决定是否接受变更。
- 更新文档：如果接受，更新SRS、设计文档、测试用例。
- 通知全员：确保每个相关人都知道变更了。
避坑指南：我曾经遇到一个客户，每周提一次变更。后来我学乖了，在合同里约定“每月只接受一次变更评审，超出部分按工作量收费”。效果立竿见影。
变更的常见类型
| 类型 | 例子 | 影响程度 |
|---|---|---|
| 功能新增 | 增加蓝牙通信功能 | 高（可能需要改硬件） |
| 参数调整 | 过压保护阈值从4.25V改为4.20V | 低（改个配置文件就行） |
| 性能提升 | 采样周期从100ms改为50ms | 中（可能影响MCU负载） |
嗯，说到变更，我想起一个项目。客户在量产前两周突然要求增加“电池加热功能”。硬件上需要加加热膜和MOS管，软件要改控制逻辑。最后硬是加班两周才赶上进度。从那以后，我特别强调“需求冻结节点”——过了这个时间点，原则上不接受任何变更。
小结
需求分析与管理，说白了就是“把话说清楚，把事做明白”。收集需求时要多问几个为什么，写SRS时要精确到可验证，排优先级时要跟客户达成共识，管变更时要有流程有底线。
你想想看，如果这些基础工作没做好，后面设计、开发、测试全都是在沙滩上盖楼。所以，别嫌麻烦，把需求这块地基打牢了，后面的路才能走得顺。