4、SYS.1 需求挖掘：利益相关方识别、需求获取技术（访谈/原型/场景）
4.1 利益相关方识别——别漏了“沉默的干系人”
做需求挖掘，第一步不是写文档，而是找人。
找谁？利益相关方。说白了，就是所有跟这个产品有关系的人。我见过太多项目，需求搞到一半才发现“哦，原来生产部门也有要求”、“售后那边还有一堆抱怨”。嗯，这时候再改，代价就大了。
我个人习惯，在项目启动阶段先拉一张利益相关方清单。这张清单至少包括：
- 客户/用户：最终开车的人，或者车队管理者。他们的痛点最直接。
- 系统工程师：负责把需求转化成技术方案的人。他们关心可行性。
- 软件开发/测试：实现需求的人。他们关心需求是否清晰、无歧义。
- 生产/制造：关心能不能造出来，成本高不高。
- 售后/维修：关心故障好不好排查，好不好修。
- 法规/安全：关心是否合规，是否安全。这一块在ASPICE和ISO 26262里是硬性要求。
4.2 需求获取技术——三种核心手段
人找到了，怎么把需求“挖”出来？我常用的三种技术：访谈、原型、场景。它们各有各的适用场景，我一个个说。
4.2.1 访谈——最直接，也最容易被带偏
访谈是最古老、最有效的需求获取方式。你面对面跟利益相关方聊，听他们抱怨、听他们描述理想状态。
但这里有个坑：用户说的，不一定是他真正想要的。你想想看，用户说“我想要一个更快的自动泊车”，其实他真正想要的是“停车时不用来回倒腾，一把进”。这两个需求，实现路径完全不同。
我建议访谈时注意三点：
- 开放式问题为主：别问“你是不是想要A功能？”，问“你平时停车最烦什么？”
- 追问“为什么”：用户说“我要一个报警灯”，你追问“为什么？”，他可能说“因为上次没注意撞了”。这时候你才知道，他真正需要的是“碰撞预警”，而不是一个灯。
- 记录原始语句：别急着翻译成技术术语。用户说“这车起步太肉了”，你就记“起步肉”，而不是“加速度不足”。原始语句能帮你保留真实场景。
4.2.2 原型——让需求“看得见”
有些需求，光靠嘴说不清楚。比如HMI交互逻辑、仪表盘显示风格。这时候，原型就派上用场了。
原型可以是纸面的，也可以是可交互的。我个人习惯在需求早期用低保真原型（比如Axure画个线框图），快速验证交互流程。等需求稳定了，再上高保真原型。
举个例子：
场景：用户想要一个“自适应巡航设置界面”
低保真原型：
- 一个简单的列表：设定速度、跟车距离、开启/关闭
- 用户点击“跟车距离”，弹出三个选项：近、中、远
- 用户反馈：“我想要一个滑块，可以微调距离”
- 好，需求更新：跟车距离支持连续调节（1-5档）
你看，一个原型，几句话就暴露了真实需求。如果光靠文档描述，可能到开发阶段才发现“哦，原来用户要的是滑块不是按钮”。
4.2.3 场景——把需求放进“故事”里
场景法，说白了就是编故事。但这个故事不是瞎编的，它描述了用户在使用产品时的完整流程。
我常用的是“用户故事”+“场景描述”的组合。比如：
| 元素 | 内容 |
|---|---|
| 用户角色 | 新手司机，女，30岁，刚拿驾照 |
| 目标 | 在商场地下车库安全停车 |
| 前置条件 | 车辆已启动，导航已开启，车库光线较暗 |
| 正常流程 | 1. 用户按下自动泊车按钮 2. 系统搜索车位 3. 系统提示“发现车位，是否泊入” 4. 用户确认 5. 系统自动控制方向盘、油门、刹车 6. 泊入完成，系统提示“泊车完成” |
| 异常流程 | 1. 系统搜索车位失败（无空位） 2. 系统提示“未找到合适车位，请手动泊车” 3. 用户手动操作 |
| 非功能需求 | 泊车时间不超过30秒；光线不足时仍能识别车位线 |
场景法的好处是：它把需求串起来了。你不再面对一堆零散的功能点，而是看到一个完整的使用故事。哪个步骤不合理、哪个功能缺失，一目了然。
4.3 三种技术的组合使用
你可能会问：这三种技术，到底用哪个？
我的答案是：都用，分阶段用。
- 项目早期：先访谈，快速了解利益相关方的痛点和期望。这时候别纠结细节，抓大放小。
- 需求分析期：用场景法，把访谈得到的碎片信息整理成完整的使用故事。你会发现很多矛盾点（比如用户A和用户B对同一功能的理解完全不同）。
- 需求验证期：用原型，把场景中的关键交互做出来，让用户“摸一摸”。这时候你会发现，用户嘴上说的和实际操作的，往往不一样。
4.4 小结
需求挖掘，说白了就是“找人、聊天、做模型、讲故事”。听起来简单，但每一步都有坑。
利益相关方识别，别漏了生产、售后、法规这些“沉默的干系人”。
访谈时，多问“为什么”，别被用户带偏。
原型时，保持低保真，聚焦逻辑。
场景时，把异常流程和非功能需求也写进去。
嗯，做到这几点，你的需求挖掘基本就稳了。下一章我们聊聊怎么把这些“挖”出来的需求，写成规范的、可验证的需求规格。