3、需求捕获技术：访谈法、场景法、原型法、文档分析

说到需求捕获，很多刚入行的工程师会觉得这是「产品经理的事」。其实不然。我做了十几年ECU开发，踩过最大的坑，往往不是技术实现不了，而是需求从一开始就没搞清楚。

需求捕获，说白了就是「把客户脑子里的想法挖出来」。客户有时候自己都说不清楚想要什么。你问他「需要什么功能」，他可能说「要一个稳定的控制器」。嗯，这话说了等于没说。所以我们需要一套系统的方法，把模糊的需求变成可落地的规格。

我个人习惯把这四种技术组合着用。它们各有各的适用场景，下面我一个个讲。

3.1 访谈法：最直接，也最容易翻车

访谈法是最基础的需求捕获手段。你拿着问题清单，跟客户、系统工程师、甚至产线工人聊。但这里有个陷阱——你以为你问清楚了，其实没有。

为什么？因为人脑会「脑补」。客户说「这个信号要快」，他理解的「快」可能是10ms，你理解的可能是100ms。访谈法的核心，就是要把这些模糊的词汇量化。

访谈法的步骤其实很简单：

• 准备阶段：列出访谈提纲，明确要问哪些系统边界、性能指标、接口定义
• 执行阶段：按提纲提问，但允许对方发散。我习惯用录音笔，因为手写根本跟不上
• 整理阶段：24小时内整理纪要，把口语化的描述转成技术语言

我曾经在一次访谈中，客户说「这个ECU要能在高温下工作」。我追问了一句「高温是多少度？持续多久？」结果发现他说的「高温」是85°C，而我们的设计上限是105°C。你看，不问清楚就出大事了。

3.2 场景法：把需求放进真实故事里

场景法，说白了就是「讲故事」。你想象一个具体的用户，在具体的环境下，用你的ECU完成一个具体的任务。这个方法特别适合捕获那些「非功能性需求」——比如用户体验、异常处理、边界条件。

举个例子。我们在开发一个车窗控制器时，客户只说了「要能一键升降」。但用场景法一分析，你会发现很多隐藏需求：

• 场景1：车主在高速上行驶，误触了车窗开关——需要防夹功能
• 场景2：车辆在暴雨中，车窗电机泡水——需要防水和短路保护
• 场景3：电池电量低时，车窗升降速度变慢——需要低电压补偿策略

你看，一个简单的「一键升降」，通过场景法能挖出至少5个附加需求。我建议每个ECU开发项目，至少写10个典型场景。场景描述要包含：

场景要素	说明	示例
触发条件	什么情况下开始这个场景	用户按下车窗开关
系统状态	ECU当前的运行模式	车辆处于上电状态，车速>0
正常流程	系统如何响应	电机正转，车窗下降
异常流程	出错时怎么办	检测到堵转，立即反转并停止
后置条件	场景结束后的状态	车窗停在当前位置

我个人习惯用「用户故事地图」来组织场景。把场景按优先级排好，开发时就知道先做哪个后做哪个。你想想看，如果没有场景法，你可能会漏掉那些「客户以为你会做，但你没想到」的功能。

3.3 原型法：让客户「看见」需求

有些需求，光靠说和写是说不清楚的。尤其是HMI（人机交互）相关的需求。这时候就需要原型法——先做一个快速模型，让客户去「摸一摸、点一点」。

原型法分两种：

• 低保真原型：用纸笔或PPT画个界面，或者用Simulink搭个简单的逻辑模型。成本低，改起来快
• 高保真原型：用专业的原型工具（比如Vector的CANoe仿真，或者Qt做的模拟器），几乎跟真机一样

我记得有一次做仪表盘ECU的开发。客户说「报警灯要醒目」。我们做了三个版本的原型：红色闪烁、红色常亮、红色带声音提示。让客户在模拟驾驶环境下体验。结果客户选了红色常亮——因为闪烁会让他分心。你看，不试一下根本不知道。

原型法还有一个好处：它能暴露那些「客户自己都没意识到的矛盾」。比如客户既想要「响应快」，又想要「功耗低」。在原型上一跑，发现这两个指标是冲突的。这时候就需要坐下来谈优先级了。

3.4 文档分析：从历史中找答案

最后一个方法，也是最容易被忽视的——文档分析。很多需求其实已经写在过去的文档里了，只是没人去翻。

文档分析的对象包括：

• 历史项目文档：上一代ECU的SRS（软件需求规格书）、系统架构图、测试报告
• 行业标准：ISO 26262（功能安全）、AUTOSAR规范、OEM的接口标准
• 客户提供的技术协议：往往藏在合同的附件里，很多人签完合同就不看了
• 变更请求记录：历史项目的CR（Change Request）里，藏着大量「踩过的坑」

我个人的习惯是，每个新项目启动前，先花一周时间做文档分析。把历史文档中跟当前项目相关的需求全部提取出来，做成一个「需求基线」。然后拿着这个基线去跟客户确认：「这些需求你们还要吗？有没有变化？」

这样做的好处是：你不会漏掉那些「默认大家都知道」的需求。比如某个信号的定义，上一代产品是CAN ID 0x123，这一代如果没提，你可能就默认改了。结果客户说「我没说改啊，你怎么改了？」——嗯，这种扯皮我经历过太多次了。

3.5 四种技术的组合策略

说了这么多，你可能会问：「那我到底该用哪种？」

我的答案是：全用。但要有主次。

一般来说，我的组合策略是这样的：

项目阶段	主要技术	辅助技术	产出物
项目启动（第1-2周）	文档分析	访谈法	需求基线、问题清单
需求细化（第3-4周）	访谈法	场景法	用户故事、场景描述
需求验证（第5-6周）	原型法	场景法	可交互原型、反馈记录
需求冻结（第7周）	文档分析	访谈法	最终版SRS、签字确认

你看，每个阶段都有侧重点。文档分析打底，访谈法挖细节，场景法补遗漏，原型法做验证。这四招组合下来，基本上能把需求捕获得八九不离十。

最后说一句：需求捕获不是一次性的工作。它贯穿整个开发周期。哪怕到了测试阶段，你发现某个需求理解错了，也要重新走一遍捕获流程。别怕麻烦，怕的是到交付那天才发现问题——那时候就真的晚了。