3. 硬件系统架构
需求分析这步，说白了就是搞清楚客户到底想要什么。我见过太多项目，前期需求没聊透，后期改得人仰马翻。你想想看，一块座舱域控制器，从客户最初那句「我要一个流畅的智能座舱」，到最终输出一份可量产的SRD，中间要经历多少轮博弈？
我个人习惯把需求分析分成四个阶段：收集、分解、定义、评审。每个阶段都有坑，咱们一个一个聊。
3.1 客户需求收集与分解：别信客户说的第一句话
客户说「我要开机快」，你得追问：快是多少秒？冷启动还是热启动？要不要考虑休眠唤醒？我曾经遇到一个客户，说「开机要3秒以内」，结果最后发现他指的是从按下启动键到仪表盘亮起，而不是整个系统完全就绪。你看，一字之差，硬件选型差出好几档。
需求收集阶段，我建议你准备一份需求捕获清单，至少覆盖以下维度：
| 维度 | 典型问题 | 我的踩坑经验 |
|---|---|---|
| 功能场景 | 用户会在什么场景下使用这个功能？ | 有一次客户说「要支持语音唤醒」，结果没说是行车中还是停车时，噪声条件完全不同 |
| 性能边界 | 最差情况下的性能要求是什么？ | 「导航流畅」——流畅的定义是60fps还是30fps？差一倍算力 |
| 环境约束 | 工作温度、振动、EMC等级？ | 车规级芯片和消费级芯片，价格差3倍，别选错 |
| 法规合规 | 出口哪些国家？需要哪些认证？ | 欧洲的eMark和中国的CCC，测试项目不一样 |
需求分解时，我习惯用功能树的方式。把客户的一句话需求，拆成可量化的子需求。比如「智能座舱体验好」可以拆成：
- 仪表显示：分辨率1920x720，刷新率60fps，延迟<100ms
- 中控交互：触控响应<50ms，多点触控支持10点
- 语音交互：唤醒率>95%，识别延迟<200ms
- 多屏互动：投屏延迟<30ms，同步误差<1帧
嗯，这里要注意：分解后的每个需求，必须能被测试验证。不能验证的需求，就是耍流氓。
3.2 功能需求与非功能需求：硬件工程师的「显性」和「隐性」工作
功能需求好理解——屏幕要能显示、麦克风要能收音、喇叭要能出声。但真正让硬件工程师头疼的，是非功能需求。
我画了一张图，帮你理清这两类需求的关系：
非功能需求里，我特别想强调降级策略。座舱系统不可能永远不出故障，关键是要定义清楚：当某个硬件失效时，系统该怎么表现？比如主芯片过热降频，屏幕刷新率从60fps降到30fps，用户能接受吗？这些都要写在需求里。
3.3 硬件规格定义（SRD）：把需求变成工程师能看懂的语言
SRD（System Requirements Document）是硬件团队的「宪法」。它把客户需求翻译成硬件工程师能直接用来做设计的参数。
一份合格的SRD，至少包含以下章节：
- 系统概述：产品定位、使用场景、目标用户
- 功能规格：每个功能模块的详细参数
- 接口定义：电气接口、机械接口、通信协议
- 性能指标：算力、功耗、启动时间、响应延迟
- 环境规格：温度范围、防护等级、EMC等级
- 可靠性规格：MTBF、保修年限、降级策略
- 认证要求：各国法规、行业标准
举个例子，屏幕规格在SRD里长这样：
3.2.1 中控显示屏规格
- 尺寸：12.3英寸（对角线）
- 分辨率：1920 x 720
- 亮度：≥1000 cd/m²（典型值）
- 对比度：≥1000:1
- 视角：水平≥170°，垂直≥170°
- 响应时间：≤25ms（灰阶切换）
- 工作温度：-40℃ ~ +85℃
- 触摸类型：投射电容式，支持10点触控
- 盖板玻璃：康宁大猩猩玻璃，厚度1.1mm
- 防眩光处理：AG涂层，反射率≤1.5%写SRD时，我有个原则：每个参数都要有「来源」和「依据」。为什么亮度要1000cd/m²？因为客户要求在强光下可读。为什么响应时间要25ms？因为人眼对拖影的感知阈值就在这个附近。没有依据的参数，评审时会被挑战得体无完肤。
3.4 需求评审与基线管理：把需求「锁死」的艺术
需求评审不是走过场。我参加过几十次评审会，最怕听到的话是「这个需求先写上，后面再改」。你想想看，硬件一旦投板，改一次就是几十万的成本。
评审会我建议分三轮：
| 评审轮次 | 参与角色 | 评审重点 | 我的建议 |
|---|---|---|---|
| 第一轮：内部评审 | 硬件团队内部 | 技术可行性、参数合理性 | 带上竞品分析数据，别拍脑袋 |
| 第二轮：跨部门评审 | 硬件+软件+测试+采购 | 接口对齐、测试可行性、成本 | 软件团队一定要来，接口定义最容出问题 |
| 第三轮：客户确认 | 客户代表+项目经理 | 需求理解是否一致、变更流程 | 让客户签字确认，这是后面扯皮的依据 |
评审通过后，就要做基线管理。说白了，就是把当前版本的SRD「锁死」，后续任何变更都要走正式的变更流程。
基线管理的核心要素：
- 版本号：V1.0、V1.1、V2.0，别用「最终版」「最终版2」这种命名
- 变更记录：谁、什么时间、改了哪里、为什么改
- 影响分析：每次变更都要评估对硬件、软件、测试、成本、进度的影响
- 审批流程：变更必须经过CCB（变更控制委员会）审批
记住一句话：没有基线的需求，就是没有锚的船。风平浪静时还好，一旦起风，你就不知道漂到哪里去了。
嗯，需求分析做到这个份上，基本就稳了。下一阶段就是拿着这份SRD，开始真正的硬件设计。但那是后面章节的事了，咱们先把需求这关过好。