4、需求分析与可靠性：需求规格说明、可靠性需求提取、需求评审与验证

各位工程师，咱们今天聊聊火控软件的需求分析。说实话，我见过太多项目栽在需求阶段。你想想看，地基没打好，楼盖得再漂亮也是白搭。火控系统更是如此——需求里一个模糊的表述，到了靶场上可能就是一颗打偏的炮弹。

4.1 需求规格说明：把“人话”翻译成“机器话”

需求规格说明，说白了就是一份“合同”。甲方说“我要打得准”，你得把它变成“在XX距离上，CEP不大于XX米”。我个人习惯，拿到原始需求后，先做三件事：

• 消除歧义：比如“快速响应”这种词，必须量化成“从接收到目标数据到输出射击诸元，不超过50ms”。
• 明确边界：系统在什么温度、湿度、海拔下工作？输入信号的电压范围是多少？
• 定义异常：如果传感器失效了，系统该怎么做？是降级运行还是直接报错？

我在项目中遇到过一件事。某次我们写需求，写了一句“系统应能自动识别目标”。结果开发团队理解成了“识别所有可见目标”，测试团队理解成了“识别指定类型的目标”。最后扯皮了两个月。从那以后，我要求所有需求必须用“输入-处理-输出”的格式写清楚。

4.2 可靠性需求提取：别让“可靠性”变成一句空话

很多团队写可靠性需求，就一句话：“系统应具有高可靠性”。这跟没说一样。可靠性需求必须具体、可量化、可验证。

我建议从以下几个维度提取：

维度	示例需求	验证方法
可用性	系统连续运行72小时，不出现非计划重启	长时间压力测试
完整性	数据传输过程中，误码率不超过10^-9	CRC校验+统计
安全性	单点故障不应导致系统输出错误射击诸元	FMEA分析+故障注入测试
可恢复性	系统掉电后重新上电，应在2秒内恢复到掉电前状态	掉电恢复测试
容错性	当GPS信号丢失时，系统应能使用惯性导航继续工作至少5分钟	信号屏蔽测试

嗯，这里要注意。可靠性需求不是越多越好。我曾经见过一份需求文档，写了200多条可靠性需求，结果项目组根本测不过来。最后大部分需求都成了摆设。我的建议是：抓大放小，先保证那20%的关键需求被100%验证。

4.3 需求评审与验证：把问题扼杀在摇篮里

需求评审，是我认为整个开发过程中最重要的环节。为什么？因为修复一个需求阶段的错误，成本是编码阶段的10倍，是测试阶段的100倍。

我个人习惯的评审流程是这样的：

1. 自审：写需求的人自己先过一遍，检查有没有遗漏、矛盾、歧义。
2. 同行评审：找2-3个没参与这个模块的工程师，让他们从“找茬”的角度看需求。
3. 专家评审：请系统工程师、可靠性工程师、测试工程师一起参加，从各自专业角度提意见。
4. 客户确认：让甲方代表签字确认，避免后期扯皮。

需求验证，我推荐用“需求跟踪矩阵”这个工具。说白了，就是一张表，把每个需求都对应到具体的测试用例上。比如：

需求ID | 需求描述                     | 测试用例ID | 测试结果
R-001  | 系统应在50ms内输出射击诸元   | TC-001     | 通过
R-002  | 系统应支持3种目标跟踪模式    | TC-002~004 | 通过
R-003  | 系统掉电后应在2秒内恢复      | TC-005     | 失败（实际恢复时间3.2秒）

有了这个矩阵，你就能清楚地知道：哪些需求已经验证了，哪些还没测，哪些测了没通过。我每次做项目汇报，第一件事就是展示这个矩阵。领导一看就明白项目状态。

4.4 一个真实的教训

最后，跟大家分享一个我亲身经历的教训。某次我们做一款车载火控系统，需求里写了一句“系统应能在颠簸路面正常工作”。当时大家都没在意，觉得“正常工作”嘛，不就是能运行吗？结果到了路试阶段，车一颠，屏幕闪了，数据丢了，操作员差点把炮弹打到自家阵地上。

后来复盘，问题出在需求没量化。“颠簸路面”是什么等级？是铺装路还是越野路？振动频率是多少？振幅多大？这些都没写清楚。从那以后，我要求所有跟环境相关的需求，必须引用国军标或者行业标准里的具体等级。

比如，现在的写法是：“系统应能在GJB 150.16A-2009规定的‘轮式车辆-越野路面’振动环境下，连续工作4小时，不出现数据丢失、界面闪烁或功能异常。”

你看，这样写，测试团队就知道该用什么标准去测，开发团队也知道该按什么等级去设计。这才是靠谱的需求。