需求获取：干系人识别与分析、用户场景挖掘、竞品分析与法规梳理
需求获取，说白了就是搞清楚「谁要什么、为什么、在什么条件下要」。这一步要是走偏了，后面所有文档、评审、测试全是白费功夫。我见过太多项目，开发到一半才发现「哦，原来这个功能不是给驾驶员用的，是给后排小孩用的」——嗯，那时候改起来就痛苦了。
这一章我们聚焦四个核心动作：干系人识别与分析、用户场景挖掘、竞品分析、法规与标准梳理。它们不是串行关系，而是并行迭代的。你想想看，干系人没找全，场景就挖不全；场景挖不全，竞品对比就漏关键点；法规没吃透，需求可能直接被砍掉重来。
2.1 干系人识别与分析
干系人识别，不是列个名单就完事了。你得搞清楚每个人的影响力和关注点。座舱系统涉及的干系人特别杂：产品经理、HMI设计师、系统架构师、测试工程师、采购、法务、甚至最终用户（驾驶员、乘客）。
我个人习惯用干系人影响力-关注度矩阵来分类。横轴是「对项目的影响力」，纵轴是「对需求的关注度」。分成四类：
- 高影响力 + 高关注度：核心决策者，必须全程参与需求评审。比如产品总监、系统架构师。
- 高影响力 + 低关注度：需要定期同步，别让他们突然跳出来说「这个不行」。比如采购、法务。
- 低影响力 + 高关注度：他们提的需求往往很细，但容易被忽略。比如HMI设计师、测试工程师。
- 低影响力 + 低关注度：保持知情即可，别花太多精力。
避坑指南：我曾经在一个项目中，漏掉了「售后维修工程师」这个干系人。结果量产之后，维修人员发现中控屏拆装需要先卸掉整个仪表台——因为没人告诉他们「维修可达性」也是需求。后来紧急改结构，成本翻了三倍。
干系人分析的结果，建议用一张表格记录下来，方便后续追溯：
| 干系人角色 | 影响力 | 关注度 | 核心诉求 | 沟通频率 |
|---|---|---|---|---|
| 产品经理 | 高 | 高 | 功能完整、用户体验好 | 每周 |
| 系统架构师 | 高 | 高 | 技术可行性、性能指标 | 每周 |
| HMI设计师 | 中 | 高 | 交互流畅、视觉一致性 | 每两周 |
| 法务 | 高 | 低 | 合规、隐私保护 | 里程碑节点 |
| 测试工程师 | 低 | 高 | 可测试性、边界条件 | 每两周 |
2.2 用户场景挖掘：用户旅程地图
用户场景挖掘，不是坐在办公室里拍脑袋想出来的。你得真正去观察用户怎么用。我建议用用户旅程地图这个工具。它能把一个完整的用车过程拆成几个阶段，每个阶段再细分成「行为」「触点」「痛点」「机会点」。
举个例子，一个「导航到充电站」的场景：
- 阶段一：出发前——用户打开手机App搜索充电站，发现App上显示「空闲桩」但实际到了发现被占用。痛点：数据不实时。
- 阶段二：上车后——用户在中控屏输入目的地，语音识别把「国网充电站」识别成「国网充电站」？嗯，有时候方言就翻车了。
- 阶段三：行驶中——导航提示「前方500米右转」，但用户没听清，错过了路口。痛点：语音播报时机不合理。
- 阶段四：到达后——充电桩需要扫码，但中控屏没有集成支付功能，用户还得掏手机。机会点：座舱内直接完成支付。
技巧：画用户旅程地图时，别只画「理想路径」。一定要画一条「异常路径」——比如网络断了、语音识别失败、蓝牙连不上。这些才是需求获取的金矿。
用户旅程地图的产出，是一张场景-需求映射表。每个痛点对应一条或几条需求。比如上面那个「语音识别方言」的痛点，对应的需求就是「语音识别系统需支持至少5种方言，识别准确率不低于90%」。
2.3 竞品分析（Benchmark）
竞品分析，不是抄作业。你得搞清楚为什么人家这么做。我见过有人把特斯拉的中控屏布局直接搬过来，结果自己的车机芯片跑不动——因为没分析人家的硬件配置。
竞品分析我一般分三步走：
- 选竞品：直接竞品（同价位、同级别）、间接竞品（不同价位但功能类似）、跨界竞品（比如把手机OS的交互逻辑搬过来）。
- 拆功能：把竞品的每个功能拆成「功能描述」「交互逻辑」「技术实现」「用户体验评分」。
- 找差距：对比自己的目标，找出「必须做」「可以做」「不做」的清单。
注意：竞品分析的结果，不要直接变成需求。我曾经在一个项目里，产品经理说「XX车有这个功能，我们也要有」，结果开发出来用户根本不用。竞品分析是启发，不是指令。
竞品分析表格示例：
| 功能 | 竞品A | 竞品B | 我们的目标 | 优先级 |
|---|---|---|---|---|
| 语音助手 | 支持连续对话 | 仅单轮指令 | 支持连续对话+上下文理解 | P0 |
| 人脸识别 | 无 | 支持驾驶员识别 | 支持多用户识别+座椅记忆 | P1 |
| 手势控制 | 仅基础手势 | 无 | 支持5种手势 | P2 |
2.4 法规与标准梳理
法规和标准，是需求获取的硬约束。你不主动梳理，它就会在评审会上突然冒出来，然后你的需求就被打回重写。座舱系统涉及的标准特别多，我重点说两个：ISO 26262 和 ASPICE。
ISO 26262 是功能安全标准。座舱系统里，哪些功能跟安全相关？比如仪表盘显示、报警音、ADAS信息融合。这些功能必须按照ASIL等级来开发。我建议在需求获取阶段，就明确每个需求的ASIL等级（QM、ASIL A/B/C/D）。这样后面做安全分析、测试用例时，才不会漏。
ASPICE 是汽车软件过程改进标准。它不直接定义「做什么」，而是定义「怎么做」。比如需求管理过程（REQ）、系统设计过程（SYS）、软件实现过程（SWE）。在需求获取阶段，ASPICE要求你可追溯——每条需求都能追溯到来源（干系人、场景、竞品、法规）。
我的经验：ISO 26262和ASPICE不是互相独立的。我习惯在需求模板里加两列：「ASIL等级」和「ASPICE过程域」。这样写需求的时候，就顺便把合规性检查做了。别等到评审会再补，那时候补起来特别痛苦。
法规梳理的产出，是一张法规-需求映射表：
| 法规/标准 | 条款编号 | 要求描述 | 影响的需求ID |
|---|---|---|---|
| ISO 26262-3 | 7.4.2 | 安全相关功能需定义安全状态 | REQ-001, REQ-002 |
| ASPICE REQ.2 | — | 需求需双向可追溯 | 所有需求 |
| GB/T 38698 | 5.2 | 车载信息终端需支持紧急呼叫 | REQ-015 |
2.5 本章知识体系总览
下面这张图，把需求获取的四个核心活动串起来了。你可以看到，干系人分析是起点，用户场景挖掘是核心，竞品分析和法规梳理是两翼。它们共同输出一份经过验证的需求清单。
嗯，到这里，需求获取的四个核心活动就讲完了。你可能会问：「这四个活动，先做哪个？」我的建议是：先做干系人识别。因为人找对了，后面的场景、竞品、法规才能找到对的人去问。别一上来就埋头画用户旅程地图，结果发现关键干系人没参与，白画。