3. 需求阶段的可靠性分析：可靠性指标定义、用户场景分析、可靠性需求文档评审

各位工程师，咱们今天聊聊需求阶段。很多人觉得可靠性是测试阶段的事，设计完再测就行了。说实话，这是个大坑。我做了十几年硬件，见过太多项目在后期因为需求没想清楚，导致返工、延期、甚至直接报废。

需求阶段的可靠性分析，说白了就是回答三个问题：要做到多可靠？在什么场景下用？怎么验证这些要求？ 这三个问题搞定了，后面的事就顺了。

3.1 可靠性指标定义：别拍脑袋，要算清楚

可靠性指标不是随便写的。我见过不少需求文档里写「系统要稳定可靠」，这种话等于没说。你得把它量化。

常用的指标有这几个：

• MTBF（平均无故障时间）：这个最常用。比如一个通信设备，MTBF 要求 10 万小时，意味着平均每 11.4 年才出一次故障。
• MTTR（平均修复时间）：出故障后多久能修好。对于可维修系统，这个指标很关键。
• 可用性（Availability）：MTBF / (MTBF + MTTR)。比如电信设备要求 99.999% 的可用性，也就是一年停机不超过 5 分钟。
• 可靠度 R(t)：在指定时间 t 内正常工作的概率。比如汽车安全气囊，要求 15 年内可靠度不低于 0.999。

定义指标时，我建议你考虑以下几点：

1. 对标行业标准：消费电子、汽车、军工、医疗，每个行业都有基准值。别闭门造车。
2. 考虑成本约束：可靠性不是越高越好。每提升一个 9，成本可能翻倍。你得在性能和成本之间找平衡。
3. 区分关键与非关键功能：比如手机，通话功能必须高可靠，但某个花哨的 UI 特效，偶尔卡一下可以接受。

3.2 用户场景分析：别在实验室里想当然

用户场景分析，是可靠性需求里最容易忽略、也最容易出问题的一环。你想想看，产品最终是在用户手里用的，不是在你实验室里跑的。

我曾经遇到过一个案例：一款户外监控摄像头，实验室测试全通过，结果用户装到东北，冬天零下 30 度，摄像头直接不工作了。为什么？因为需求阶段只考虑了常温场景，没做低温场景分析。

用户场景分析要覆盖哪些维度？

维度	典型问题	我的建议
环境条件	温度、湿度、盐雾、沙尘、振动	别只看典型值，要看极端值。比如沙漠地区白天 60 度，晚上可能零下。
使用习惯	频繁开关机、长时间待机、误操作	用户不会按你的说明书操作。我见过有人把工业设备当家用电器用的。
供电条件	电压波动、断电、谐波干扰	很多故障其实是供电问题。尤其是偏远地区，电网质量很差。
维护能力	用户会不会定期维护？有没有备件？	如果用户不维护，你的 MTBF 再高也没用。

怎么做场景分析？我推荐用 用例法。把用户的使用过程画成一条条路径，每条路径都标注出可能出现的应力条件。比如：

用例：户外基站设备在夏季雷雨天气下运行
- 环境温度：45°C
- 湿度：95% RH
- 供电：可能伴随电压骤降
- 振动：风力导致的低频振动
- 持续时间：连续运行 72 小时

3.3 可靠性需求文档评审：别走过场

需求文档评审，很多公司都在做。但说实话，大部分评审都是走过场。大家坐在一起，念一遍文档，然后问「有没有问题？」——没人说话，就过了。

我参与过上百次评审，总结了几条实用的方法：

1. 提前发文档，别现场读：评审会前 3 天把文档发出去，让大家有时间看。现场读文档是最浪费时间的事。
2. 用检查清单：我有一份自己的「可靠性需求检查清单」，每次评审都对照着过一遍。比如：
   • 指标是否量化？有没有单位？
   • 场景是否覆盖了极端条件？
   • 有没有考虑老化效应？
   • 测试方法是否明确？
   • 验收标准是否可执行？
3. 邀请跨部门的人：光靠硬件团队不够。叫上软件、结构、生产、售后的人。他们能看到你忽略的问题。
4. 记录并跟踪：评审出的问题要有记录，有责任人，有闭环。别开完会就忘了。

下面这张图是我自己总结的「需求阶段可靠性分析框架」，你可以参考：

最后说一句：需求阶段的可靠性分析，投入产出比是最高的。你在需求阶段花 1 小时想清楚，后期可能省下 10 小时的返工时间。这个账，你得算明白。

---

公众号:蓝海资料掘金营，微信deep3321