第四章：可靠性需求分析
大家好，我是你们的老朋友。今天咱们聊聊可靠性需求分析。
说实话，很多工程师一听到「需求分析」四个字就头疼。觉得这是产品经理的事，跟技术没关系。但我告诉你，可靠性需求分析要是没做好，后面所有工作都是空中楼阁。我在FCC项目里吃过这个亏，所以今天想好好跟你聊聊。
4.1 用户需求收集：别闭门造车
用户需求收集，说白了就是搞清楚「谁在用、怎么用、用多久」。我见过太多团队，上来就定指标，结果产品做出来用户根本不买账。
为什么会这样？因为你没搞清楚用户真正的痛点。
核心原则：用户说的不一定是真需求，用户做的才是。
我个人习惯用三种方法收集需求：
- 访谈法：直接找目标用户聊。别问「你想要什么可靠性」，要问「你上次设备出故障是什么情况」。
- 观察法：看用户实际怎么操作。我在一个项目中，发现用户总在高温环境下使用设备，但设计时根本没考虑散热。
- 数据分析：如果有历史产品，看看售后数据。哪个部件坏得最多？哪个故障模式最致命？
小技巧：收集需求时，记得区分「基本需求」和「期望需求」。基本需求不满足，用户直接骂娘；期望需求不满足，用户只是有点遗憾。
4.2 可靠性指标定义：把模糊变清晰
用户说「我要可靠的产品」，这等于没说。你得把这句话翻译成工程语言。
常用的可靠性指标有哪些？我列个表给你看：
| 指标 | 含义 | 适用场景 |
|---|---|---|
| MTBF | 平均无故障时间 | 可修复产品 |
| MTTF | 平均失效时间 | 不可修复产品 |
| 可靠度 R(t) | 在t时间内正常工作的概率 | 所有产品 |
| 失效率 λ | 单位时间内失效的概率 | 电子元器件 |
| 可用度 A | 系统正常工作的时间占比 | 通信系统 |
嗯，这里要注意：指标不是拍脑袋定的。你得结合用户需求、行业标准、成本约束来定。
避坑指南：我曾经在一个项目中，客户要求MTBF达到10万小时。我们按这个指标设计，结果成本翻了三倍。后来才发现，客户实际只需要5万小时，多出来的5万小时是销售随口说的。所以，指标一定要跟用户确认，别自己瞎猜。
4.3 需求文档编写：把话说清楚
需求文档是干什么用的？就是让所有人对「要做什么」达成共识。
我写需求文档有个习惯：先写框架，再填内容。框架长这样：
1. 项目背景
2. 用户画像
3. 使用场景
4. 可靠性指标（量化）
5. 环境条件（温度、湿度、振动等）
6. 寿命要求
7. 维修策略
8. 验收标准举个例子，一个FCC模块的可靠性需求文档片段：
3.2 使用场景
- 场景A：室内基站，温度范围0~40°C，连续运行
- 场景B：户外机柜，温度范围-20~55°C，含振动
- 场景C：车载环境，温度范围-40~85°C，随机振动
4.1 可靠性指标
- MTBF ≥ 50,000小时（25°C，60%置信度）
- 10年寿命期内，可靠度 ≥ 0.95
- 可用度 ≥ 0.9999关键点：每个指标都要写清楚「测试条件」和「置信度」。没有条件的指标就是耍流氓。
4.4 需求评审与确认：别怕吵架
需求写完了，不是终点，是起点。评审环节才是真正考验人的地方。
我参加过无数次评审会，总结出三条铁律：
- 铁律一：评审会必须有决策权的人在场。否则讨论半天，最后一句「我回去问问领导」就白费了。
- 铁律二：每个指标都要有「为什么」。比如MTBF为什么是5万小时？因为用户每年只维修一次，5万小时约等于5.7年，留点余量。
- 铁律三：评审结果要签字确认。别嫌麻烦，这是保护自己的最好方式。
个人经验：评审时最容易吵起来的是「指标太高」和「成本太高」的矛盾。我的建议是：先定一个「最低可接受值」和一个「目标值」。最低值必须满足，目标值尽量靠近。这样大家都有台阶下。
最后，需求确认后，记得归档。我见过太多项目，需求改来改去，最后谁都不记得最初定的是什么。文档管理做不好，后面全是坑。
再啰嗦一句：需求分析不是一次性的。随着项目推进，可能会有新的发现。但每次变更，都要走正式的变更流程，别口头说改就改。我曾经因为一个口头变更，导致整个测试方案重做，加班两周才补回来。
好了，这一章就聊到这儿。下一章咱们讲可靠性设计，那才是真正动手的时候。
公众号:蓝海资料掘金营，微信deep3321