第二章 需求捕获与分析：利益相关方识别、用户需求调研、功能需求定义、非功能需求定义
各位工程师同仁，大家好。今天我们聊聊座舱显示系统全生命周期里，最容易被轻视、但后果最严重的一个环节——需求捕获与分析。
我见过太多项目，开发到一半才发现需求没对齐。返工？那都是轻的。有一次，我们一个舱段因为需求定义漏了一条“夜间模式色温不超过3000K”，结果试飞员反馈屏幕太刺眼，整个HMI设计团队加班三周重绘。嗯，从那以后，我再也不敢在需求阶段偷懒了。
2.1 利益相关方识别：谁在说话？谁在拍板？
做座舱显示系统，你首先得搞清楚：这个屏幕到底给谁看？谁说了算？
我个人习惯，在项目启动的第一周，先拉一张利益相关方清单。别小看这个动作，它决定了你后续所有需求的来源是否靠谱。
典型的利益相关方包括：
- 最终用户：飞行员、副驾驶、乘务员。他们是最直接的“吐槽源”。
- 客户代表：航空公司运控部门、采购部门。他们关心的是成本和维护性。
- 适航当局：比如CAAC、FAA、EASA。他们只关心安全，不关心你界面好不好看。
- 系统集成商：负责把显示系统装进飞机的人。他们关心接口、重量、散热。
- 内部团队：硬件、软件、测试、生产、售后。每个部门都有自己的“小九九”。
关键点：利益相关方不是一成不变的。项目进入详细设计阶段，可能还会冒出新的干系人。我建议每两个月重新审视一次这张清单。
你想想看，如果连“谁需要这个功能”都没搞清楚，后面的需求调研就是无源之水。
2.2 用户需求调研：别坐在办公室里猜
很多工程师喜欢闭门造车。我刚开始做座舱系统时也犯过这个错——自己觉得某个显示逻辑很合理，结果飞行员一看就说“这玩意儿我飞的时候根本来不及看”。
用户需求调研，说白了就是去现场、去模拟机、去跟飞行员聊天。我个人常用的方法有：
- 情境访谈：跟着飞行员走一遍完整的飞行任务，从起飞前检查到落地后关车。记录他们每一步的操作、犹豫、抱怨。
- 焦点小组：把3-5个飞行员聚在一起，讨论某个显示概念。你会发现，老飞和新飞的需求差异很大。
- 原型验证：拿一个低保真原型（甚至纸面原型）让用户点一点。别等到代码写完了才给用户看。
我的小技巧：调研时带一个录音笔，但一定要征得同意。很多关键信息是在闲聊中冒出来的，比如“其实我从来不看那个高度带旁边的数字”。
调研结束后，你会得到一堆原始需求。这时候需要做一件事：分类和优先级排序。我习惯用MoSCoW方法——Must have, Should have, Could have, Won't have。别想着什么都做，座舱系统最忌讳功能堆砌。
2.3 功能需求定义：把“想要”变成“要做”
用户说“我想要一个更清晰的导航地图”。这句话不能直接写进需求文档。你得把它翻译成可验证的功能需求。
举个例子：
| 用户原始表述 | 功能需求定义 |
|---|---|
| 地图要清晰 | 系统应支持至少5级缩放，在最大缩放级别下，跑道标识符字体高度不小于4mm |
| 告警要醒目 | 主警告红色闪烁频率应为2-4Hz，占空比50%，且不可被用户关闭 |
| 操作要简单 | 常用功能（如航向选择、高度设定）应在3次按键内完成 |
这里要注意：功能需求必须可测试。如果写“系统应具有良好的响应速度”，那测试人员怎么测？应该写成“从用户按下按键到画面更新，延迟不超过100ms”。
避坑指南：我曾经在一个项目中，需求里写了“系统应支持多种语言”。结果开发团队只做了中英文，交付时客户要求支持阿拉伯语——因为飞机要飞中东航线。从那以后，我要求所有“多语言”需求必须明确列出具体语种。
功能需求定义时，我建议用用户故事的格式来写：
作为 [飞行员]
我希望 [在进近阶段自动显示跑道延长线]
以便 [减少手动操作，提高情景意识]这种写法，开发人员能理解“为什么做”，而不是“做什么”。
2.4 非功能需求定义：那些看不见但会要命的东西
功能需求决定了系统“能不能用”，非功能需求决定了系统“好不好用”以及“能不能安全地用”。
座舱显示系统的非功能需求，我个人认为比功能需求更难搞。因为很多非功能需求是隐性的，用户不会主动提，但出了问题就是大事。
常见的非功能需求类别：
- 性能：画面刷新率、启动时间、数据加载延迟。我记得有个项目，客户要求“冷启动时间不超过30秒”，结果我们用了固态硬盘才勉强达标。
- 可靠性：MTBF（平均无故障时间）、冗余切换时间。座舱显示系统通常要求MTBF不低于10000小时。
- 可用性：字体大小、颜色对比度、操作容错。比如，关键按钮的尺寸不得小于20x20mm，防止飞行员戴手套误触。
- 安全性：防误操作、故障降级、数据完整性。举个例子，如果主显示器故障，备份显示器必须在1秒内接管显示。
- 环境适应性：温度范围、振动、电磁兼容。座舱里的电子设备，工作温度通常要求-15℃到+55℃。
核心原则：非功能需求一定要量化。不要写“系统应稳定可靠”，要写“系统在连续运行72小时内，不应出现任何非计划重启”。
你想想看，如果非功能需求定义得模棱两可，到了验收阶段，你说“系统很稳定”，客户说“我觉得不够稳定”，双方都没错，但项目就卡住了。
2.5 需求验证与确认：别等到交付才发现错了
需求写完了，不代表就完事了。我见过太多项目，需求文档写得漂漂亮亮，结果开发出来的东西跟用户想要的完全两码事。
为什么会这样？因为需求没有被验证和确认。
我个人习惯的做法：
- 同行评审：拉上系统工程师、测试工程师、甚至飞行员代表，逐条过需求。别怕花时间，这个时间省不得。
- 原型验证：用快速原型工具（比如Figma、Axure）做一个可交互的界面，让用户实际操作一遍。你会发现，用户看到原型后，往往会说“哦，原来是这样，那我想要的是另一种”。
- 需求追溯矩阵：把每条需求跟它的来源（用户调研记录、会议纪要、适航条款）关联起来。这样万一需求变更，你能快速知道影响了谁。
我的经验：需求验证时，一定要让用户签字确认。不是我不信任用户，而是人的记忆会模糊。三个月后用户说“我没提过这个需求”，你拿出签字记录，大家都省事。
最后说一句：需求捕获与分析，不是一次性工作。随着项目推进，你会发现有些需求不合理、有些需求遗漏、有些需求优先级变了。没关系，迭代是正常的。但每一次变更，都要走正式的变更控制流程。
嗯，这一章就到这里。下一章我们聊聊系统架构设计——怎么把需求变成一张能落地的蓝图。