第四章：需求分析过程概览
各位工程师朋友，今天我们来聊聊需求分析在整个DO-178C开发流程中的位置。说实话，我见过太多团队一上来就写代码，结果到验证阶段才发现需求根本不清楚。嗯，这章我们就把它彻底理清楚。
4.1 需求分析在V模型中的位置
DO-178C的核心开发模型是V模型。需求分析就在V模型的左上角，是整个开发流程的起点。我个人习惯把V模型想象成一个倒过来的「Y」字——左边是向下走的设计开发，右边是向上走的验证确认。
核心要点：需求分析是V模型的「源头」。没有它，后面的设计、编码、验证全是空中楼阁。
为什么会这样？你想想看，飞机上的飞控系统、导航系统，任何一个功能失效都可能造成灾难。需求分析就是确保我们从一开始就搞清楚「系统到底要干什么」。
4.2 需求分析的输入
需求分析不是凭空产生的。它需要明确的输入。我刚开始做DO-178C项目时，就吃过「输入不明确」的亏。后来我总结了一下，输入主要来自三个方面：
| 输入来源 | 具体内容 | 说明 |
|---|---|---|
| 系统需求 | 系统级功能需求、性能需求、接口需求 | 来自系统工程师，是软件需求的「上级」 |
| 安全需求 | 安全等级、故障条件、失效模式 | 来自安全评估过程（ARP4754A） |
| 约束条件 | 硬件限制、操作系统限制、认证要求 | 来自项目计划和认证计划 |
个人经验：我建议在需求分析开始前，先和系统工程师开一次「需求对齐会」。把系统需求逐条过一遍，确保没有歧义。我曾经因为一个「自动切换」的术语理解不一致，导致后面重写了30%的代码。教训深刻啊。
4.3 需求分析的输出
需求分析完成后，要产出哪些东西？说白了，就是让下游的设计、编码、验证团队有据可依。我把它归纳为四类输出：
- 软件需求规格（SRS）——这是核心文档。每条需求都要可验证、可追溯。
- 需求可追溯性矩阵——把系统需求映射到软件需求，再映射到测试用例。
- 需求评审记录——评审中发现的问题、修改记录、决策依据。
- 需求变更记录——需求变更的审批流程和影响分析。
注意：DO-178C要求需求必须是「可验证的」。什么叫可验证？就是你能设计一个测试用例，明确判断这条需求是否被满足。比如「系统响应要快」这种需求就不合格——快是多快？要写成「系统响应时间不超过50毫秒」。
4.4 需求分析与设计过程的接口
需求分析做完后，下一步就是设计。这里有个关键点：需求分析不是一次性工作。它和设计过程是迭代的。
你想想看，设计过程中可能会发现某些需求实现不了，或者实现成本太高。这时候就需要回到需求分析，重新审视需求是否合理。我见过一个项目，设计团队发现一条需求需要增加额外的硬件支持，但项目预算已经定了。最后通过需求分析团队和客户协商，把这条需求拆成了「基础功能」和「增强功能」两个版本。
所以，需求分析和设计之间的接口，说白了就是：
- 正向流：需求分析 → 设计 → 编码 → 验证
- 反向流：设计/编码中发现的问题 → 反馈给需求分析 → 需求变更
4.5 需求分析与验证过程的接口
验证过程是DO-178C的重头戏。需求分析为验证提供了「测试依据」。没有清晰的需求，验证团队根本不知道要测什么。
我记得有一次，验证团队拿着需求文档来找我，说：「这条需求写的是『系统应能处理异常情况』，但异常情况有哪些？处理到什么程度？」这就是需求不明确的典型例子。
需求分析给验证过程的输出，主要包括：
- 测试用例设计依据：每条需求对应哪些测试用例
- 通过/失败判据：什么样的测试结果算通过
- 覆盖率目标：需求覆盖率要达到100%（这是DO-178C的硬性要求）
核心原则：需求分析的质量，直接决定了验证工作的效率。需求写得越清楚，验证阶段就越少返工。我个人的经验是，在需求分析阶段多花20%的时间，可以在验证阶段节省50%的时间。
4.6 需求分析过程中的常见陷阱
做了这么多年DO-178C项目，我总结了几条需求分析的「坑」，分享给大家：
- 陷阱一：需求过于笼统。比如「系统应可靠运行」——什么叫可靠？MTBF（平均无故障时间）是多少？要量化。
- 陷阱二：需求与设计混淆。需求是「做什么」，设计是「怎么做」。不要把「用C语言实现」写进需求里。
- 陷阱三：忽略非功能需求。性能、安全性、可维护性这些非功能需求，往往比功能需求更难写清楚。
- 陷阱四：需求变更管理混乱。需求变了，但设计、编码、测试没跟着变，最后验证时才发现对不上。
避坑指南：我曾经在一个项目中，因为需求变更没有及时通知验证团队，导致验证团队按照旧需求写了测试用例。结果测试全部失败，最后发现是需求变了。从那以后，我要求所有需求变更必须走正式的变更控制流程，并且通知到所有相关方。
4.7 需求分析的工具与方法
工欲善其事，必先利其器。需求分析阶段常用的工具和方法，我列了一个清单：
| 工具/方法 | 用途 | 我的建议 |
|---|---|---|
| 需求管理工具（如DOORS、Jama） | 管理需求条目、可追溯性、变更历史 | 一定要用工具，别用Excel，会疯的 |
| 结构化分析方法（如SA/SD） | 将系统需求分解为软件需求 | 适合复杂系统，但别过度分解 |
| 形式化方法（如SCADE） | 用数学模型描述需求，自动生成测试用例 | 适合安全等级A/B的项目，但学习成本高 |
| 评审检查单 | 确保需求满足DO-178C的完整性、一致性、可验证性 | 我习惯自己维护一份检查单，每次评审都用 |
4.8 小结
需求分析在DO-178C开发流程中，就是那个「牵一发而动全身」的位置。它连接了系统需求和软件实现，决定了整个项目的成败。我个人觉得，做好需求分析的关键就三点：
- 清晰：每条需求都要让读的人一看就懂，没有歧义
- 可追溯：从系统需求到软件需求，再到测试用例，一条链走到底
- 可验证：每条需求都能设计测试用例来验证
嗯，这章的内容就到这里。记住，需求分析不是「写文档」，而是「建共识」。团队里每个人都对需求有统一的理解，项目才能顺利推进。
公众号:蓝海资料掘金营，微信deep3321