第三章：需求分析与追溯
各位工程师朋友，大家好。我是老张，在飞控安全领域摸爬滚打了十几年。今天咱们聊聊需求分析与追溯。说实话，这是整个飞控系统开发中最容易被忽视，但也是最要命的环节。
你可能觉得，需求嘛，不就是客户说啥我做啥？嗯，真这么想就危险了。飞控系统一旦上天，一个需求遗漏可能就是机毁人亡。我见过太多项目，因为需求没理清楚，后期改得面目全非。
3.1 需求层级分解
飞控系统的需求，不是一锅粥。它是有层级的。我个人习惯把它分成三层：
- 顶层需求：用户或系统级的要求。比如“飞机能在海拔5000米稳定飞行”。
- 功能需求：具体要实现什么功能。比如“高度保持模式下，高度误差不超过±5米”。
- 详细需求：技术实现层面的要求。比如“气压计采样频率不低于50Hz，滤波算法延迟不超过20ms”。
为什么要分这么细？你想想看，顶层需求是给客户看的，功能需求是给系统工程师看的，详细需求才是给咱们嵌入式工程师看的。层级不清，沟通成本就上去了。
核心原则：每个层级的需求，都要能追溯到上一层。这叫“向上可追溯，向下可分解”。
我在项目中遇到过一件事：客户说“要抗风”。顶层需求就这么一句话。结果功能需求里写成了“抗5级风”，详细需求里又变成了“PID控制器带宽不低于2Hz”。最后测试时发现，5级风和2Hz带宽根本对不上号。你看，这就是层级分解没做透。
3.2 需求可追溯性矩阵（RTM）建立
RTM，说白了就是一张表。但它不是普通的表，它是需求的“户口本”。
我建议用Excel或者专门的工具（比如DOORS、Jama）来维护。格式大概这样：
| 需求ID | 需求描述 | 层级 | 来源 | 验证方法 | 状态 |
|---|---|---|---|---|---|
| REQ-001 | 飞机能在海拔5000米稳定飞行 | 顶层 | 客户合同 | 飞行测试 | 已批准 |
| REQ-001-01 | 高度保持模式下，高度误差不超过±5米 | 功能 | REQ-001 | 仿真测试 | 已批准 |
| REQ-001-01-01 | 气压计采样频率不低于50Hz | 详细 | REQ-001-01 | 单元测试 | 已实现 |
看到没？每个需求都有唯一ID。顶层需求ID是REQ-001，功能需求是REQ-001-01，详细需求是REQ-001-01-01。这样一看就知道谁是谁的爹。
小技巧：我习惯在RTM里加一列“验证方法”。这样后期做验证确认时，直接对着表看就行，不用再翻需求文档。
为什么要做RTM？说白了，就是防止需求丢失。你想想，一个飞控系统可能有上千条需求。没有RTM，你怎么知道每条需求都实现了？怎么知道每条需求都测试了？
我曾经在一个项目中，RTM帮了大忙。客户在验收时突然问：“你们验证过在GPS信号丢失情况下的行为吗？”我打开RTM一查，发现有一条需求专门写了这个，而且对应的测试用例也通过了。客户当场就放心了。如果没有RTM，我可能得翻三天文档才能找到答案。
3.3 需求评审流程
需求写完了，不能直接开干。得评审。评审不是走过场，是真刀真枪地挑毛病。
我建议的评审流程是这样的：
- 自评：需求编写人自己先过一遍，检查有没有遗漏、矛盾、歧义。
- 同行评审：找2-3个同事，最好是不同模块的。比如写飞控算法的评审一下传感器需求，写硬件的评审一下软件需求。
- 专家评审：找资深工程师或架构师，从系统层面把关。
- 客户确认：最后让客户或系统工程师确认，确保理解一致。
注意：评审不是一次性的事。需求变更了，就得重新评审。我见过有人觉得“就改了一点点”，结果改出了大问题。
评审时重点关注什么？我个人习惯看这几点：
- 完整性：有没有漏掉什么？比如飞控系统，安全相关的需求绝对不能漏。
- 一致性：需求之间有没有矛盾？比如一个说“响应时间小于10ms”，另一个说“采样频率100Hz”，这俩可能就冲突。
- 可测试性：需求能不能被验证？比如“系统要稳定”，这就没法测。得改成“系统在连续运行72小时内无故障”。
- 无歧义：需求描述是否清晰？比如“尽快响应”，什么叫“尽快”？得改成“响应时间不超过50ms”。
嗯，这里要注意。评审时最容易犯的错是“想当然”。你觉得需求写清楚了，别人可能完全理解成另一个意思。所以评审时一定要逐字逐句地过，别怕麻烦。
3.4 需求变更管理
需求不变更？那是不可能的。飞控系统开发周期长，客户想法会变，技术方案会变，法规要求也会变。关键是，怎么管好这些变更。
我建议建立一套变更管理流程：
- 提出变更：任何人发现需求需要变更，都可以提。但必须书面化，不能口头说。
- 评估影响：变更会影响哪些模块？会增加多少成本？会延迟多少时间？这些都要评估。
- 审批：变更必须经过CCB（变更控制委员会）审批。CCB一般由项目经理、技术负责人、客户代表组成。
- 实施变更：审批通过后，更新需求文档、RTM、设计文档、测试用例等。
- 验证变更：变更实施后，要重新验证，确保没有引入新问题。
避坑指南：我曾经在一个项目中，客户口头说“把高度精度从±5米改成±3米”。我觉得小改动，就直接改了代码。结果后来发现，这个改动影响了传感器选型、滤波算法、甚至结构设计。最后项目延期了两个月。从那以后，我坚持所有变更必须走流程，哪怕只是改一个数字。
变更管理最怕什么？最怕“偷偷改”。有人觉得改个需求很简单，直接改了代码，没更新文档。结果后来别人接手时，发现代码和文档对不上，那叫一个痛苦。
所以，我建议用版本控制工具来管理需求文档。每次变更都留下记录，谁改的、什么时候改的、为什么改的，一目了然。
知识体系图
下面这张图，是我自己总结的需求分析与追溯的核心逻辑。你一看就明白了。
这张图的核心就是：需求从上往下分解，从下往上追溯。RTM是中间枢纽，评审和变更管理是保障机制。缺一个环节，整个体系就可能崩塌。
好了，关于需求分析与追溯，我就讲这么多。记住一句话：需求搞不清楚，后面全是白干。希望各位在实际项目中，能把这些方法用起来。