第2章需求分析与规格解读

第二章需求分析与规格解读：如何读懂飞控需求文档、需求分解与追溯矩阵建立

说实话，我刚入行那会儿，拿到一份几十页的飞控需求文档，第一反应是——头疼。密密麻麻的术语、各种缩写、还有那些看起来像天书一样的性能指标。后来带我的老工程师跟我说了一句话，我记到现在：「需求文档不是用来读的，是用来挖的。」

什么意思呢？就是说，你得带着问题去看，带着怀疑去读。今天我就把这些年挖需求文档的经验，掰开了揉碎了讲给你听。

飞控系统的需求文档，通常分这么几类：

我个人的习惯是，拿到文档先翻到「术语定义」那一页。别笑，这一步特别重要。同一个词，不同项目组可能定义完全不同。比如「悬停精度」，有的项目指水平位置偏差，有的指高度偏差，还有的连姿态角都算进去。

⚠️ 注意： 我曾经在一个项目中，因为没仔细看术语定义，把「GPS 定位精度」和「RTK 定位精度」搞混了，导致后面测试用例全部写错。白白浪费了两周时间。

我一般把读懂需求分成三个层次，你想想看你现在在哪个层次：

举个例子。文档里写：「飞控系统应能在 -20°C 到 +60°C 环境下正常工作。」

字面层理解：哦，温度范围是 -20 到 60 度。

逻辑层理解：那低温启动呢？高温持续运行呢？温度变化速率有没有要求？

验证层理解：我得设计低温启动测试、高温老化测试、温度循环测试。还要考虑传感器在不同温度下的漂移补偿。

你看，差距就在这里。我建议你每次读需求时，都问自己三个问题：

需求分解，说白了就是把一个大需求拆成若干个小需求，直到每个小需求都能被直接验证。

比如系统级需求：「飞控系统应具备自主返航功能。」

这个需求太大了，没法直接测。你得拆：

嗯，这里要注意，分解的时候不能漏掉边界条件。比如「遥控信号丢失」怎么定义？是连续 5 秒没收到任何数据包，还是 5 秒内丢包率超过 90%？这些细节不搞清楚，后面测试就是一笔糊涂账。

💡 我的经验： 需求分解时，最好拉上系统工程师、软件工程师和测试工程师一起过。三个人看同一个需求，往往能发现三个不同的问题。我经历过太多次「我以为你懂了，你以为我懂了，结果谁都没懂」的尴尬局面。

需求追溯矩阵，英文叫 Requirements Traceability Matrix，简称 RTM。说白了，就是给每条需求建一个档案，记录它从哪来、到哪去、怎么验证。

一个标准的 RTM 长这样：

需求ID	需求描述	来源	分解子需求	验证方法	测试用例ID	状态
REQ-001	自主返航功能	客户需求	REQ-001-01 至 05	系统测试	TC-001 至 TC-010	已通过
REQ-002	CPU 占用率 ≤ 70%	系统设计	无	性能测试	TC-011 至 TC-015	待验证
REQ-003	PWM 输出频率 50Hz	接口规范	无	单元测试	TC-016	已通过

我建议你用 Excel 或者专门的工具来维护这个矩阵。别偷懒用手写或者记在脑子里，项目一复杂，你绝对会忘。

🔧 实用技巧： 每次需求变更时，第一时间更新 RTM。我曾经在一个项目中，因为需求变更后没及时更新矩阵，导致有 3 条需求被遗漏验证。还好在系统联调前发现了，不然飞上去出了问题，后果不堪设想。

下面这张图，是我自己总结的需求分析与规格解读的核心逻辑。你看一眼，基本就能把握住本章的脉络：

最后，分享几个我踩过的坑，你遇到了能绕就绕：

别信「显而易见」：需求文档里最危险的就是「显然」、「默认」、「通常」这类词。我曾经看到一个需求写「飞控默认使用 GPS 定位」，结果测试时发现默认用的是视觉定位。谁改的？没人承认。
别忽略「非功能需求」：大家往往盯着功能需求看，但可靠性、可维护性、可测试性这些非功能需求，才是后期出问题最多的。
别等到测试才看需求：我建议你在需求评审阶段就介入。那时候发现问题，改起来成本最低。等代码写完了再发现需求理解有误，那代价就大了。

好了，关于需求分析与规格解读，我就讲这么多。记住一句话：需求文档不是圣经，它是你用来和系统工程师、软件工程师「吵架」的依据。把需求吃透了，后面的测试工作才能站得住脚。

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