3. 需求分类与分层：用户需求 vs 系统需求 vs 软件需求、功能需求 vs 非功能需求、MoSCoW 优先级划分
做座舱需求管理，第一关就是搞清楚需求到底长什么样。
很多人一上来就写「用户要一个流畅的导航」，然后扔给开发。结果开发做完了，测试说「这导航是流畅了，但地图数据加载时黑屏了两秒」。你看，问题出在哪？
出在需求没分层，也没分类。我做了十几年座舱系统，踩过最大的坑就是需求混在一起写。今天这一章，咱们就把这件事彻底理清楚。
3.1 需求分层：用户需求 → 系统需求 → 软件需求
先问一个问题：用户说「我要一个安全的座舱」，这句话能直接交给开发吗？
不能。因为「安全」太抽象了。你得把它拆成系统能理解的东西。
我个人习惯把需求分成三层：
- 用户需求：用户用自然语言表达的期望。比如「我想用语音控制空调温度」。
- 系统需求：系统级的技术描述。比如「语音识别模块需支持中文普通话，识别准确率 ≥ 95%，响应时间 ≤ 1.5s」。
- 软件需求：软件模块的具体实现要求。比如「语音服务 API 需提供 setTemperature(int value) 接口，调用后 200ms 内返回成功码」。
我在一个项目中遇到过，产品经理直接把用户需求写进了开发任务单：「用户希望导航能避开拥堵」。开发照着做了个实时路况功能，结果测试发现，车机在隧道里没信号，功能直接挂了。为什么？因为系统需求里没写「离线场景下的备选策略」。
核心原则：用户需求是「为什么做」，系统需求是「做什么」，软件需求是「怎么做」。三层之间必须可追溯。
举个例子，你想想看：
| 层次 | 示例 | 责任方 |
|---|---|---|
| 用户需求 | 「我想在开车时安全地接电话」 | 产品经理 / 用户研究 |
| 系统需求 | 「蓝牙电话功能需支持 HFP 协议，来电时自动降低媒体音量 50%，通话期间媒体暂停」 | 系统工程师 |
| 软件需求 | 「AudioManager 模块提供 setVolume(streamType, level) 接口，媒体音量降低到当前值的 50%」 | 软件工程师 |
嗯，这里要注意：每一层都要有明确的验收标准。用户需求可以模糊一点，但系统需求和软件需求必须可测试。
3.2 功能需求 vs 非功能需求
分完层，还得分类。最基础的分法就是功能需求和非功能需求。
功能需求：系统「做什么」。比如「支持导航」、「播放音乐」、「调节座椅」。这些是用户能直接感知到的。
非功能需求：系统「做得怎么样」。比如「性能」、「安全」、「体验」。这些往往决定了用户会不会骂娘。
我曾经接手过一个项目，功能需求写得密密麻麻，但非功能需求几乎为零。结果呢？车机开机要 45 秒，用户投诉说「这车机比我爷爷还慢」。后来我们花了两个迭代专门优化启动时间，才把开机压到 8 秒以内。说白了，非功能需求才是决定产品口碑的关键。
常见的非功能需求包括：
- 性能：响应时间 ≤ 1s，帧率 ≥ 30fps，内存占用 ≤ 512MB
- 安全：驾驶过程中禁止视频播放，紧急电话优先接通
- 体验：触控反馈延迟 ≤ 50ms，语音唤醒成功率 ≥ 98%
- 可靠性：系统连续运行 7 天无崩溃，OTA 升级失败可回滚
- 可维护性：日志系统支持远程诊断，模块间接口变更需兼容旧版本
我的经验：非功能需求最好用「量化指标 + 测试场景」来描述。别写「系统要流畅」，要写「从点击到界面响应 ≤ 200ms，连续操作 100 次无卡顿」。
你可能会问：功能需求和非功能需求哪个更重要？
都重要。但非功能需求往往被忽视，直到出了问题才想起来。我建议在需求评审时，专门留一个环节过非功能需求，哪怕只花 15 分钟。
3.3 需求优先级划分：MoSCoW 方法
需求永远做不完。资源有限，时间有限，你必须学会取舍。
MoSCoW 方法是我最常用的优先级划分工具。它把需求分成四类：
- M - Must have（必须有）：没有这个功能，产品无法发布。比如「刹车信号必须实时响应」。
- S - Should have（应该有）：很重要，但可以等下一个版本。比如「语音控制天窗」。
- C - Could have（可以有）：锦上添花，有更好，没有也行。比如「氛围灯随音乐律动」。
- W - Won't have（不会有）：明确不做，但记录下来供后续参考。比如「车内 KTV 功能」。
我在一个座舱项目中，产品经理把所有需求都标成了 Must have。结果开发团队一看，30 个 Must have，根本做不完。后来我们用 MoSCoW 重新梳理，发现真正的 Must have 只有 8 个，剩下的要么是 Should have，要么是 Could have。项目才顺利推进下去。
避坑指南：我曾经见过一个团队，把「Won't have」直接删掉了。结果半年后客户又问起这个功能，团队完全忘了当初为什么不做。所以，Won't have 也要记录原因和上下文。
MoSCoW 的决策逻辑其实很简单：
- 先列出所有需求
- 问自己：没有这个，产品能发布吗？能 → 不是 Must have；不能 → Must have
- 剩下的需求，按重要性和紧急程度排 Should have 和 Could have
- 明确标记 Won't have，并写清楚理由
下面这张图是我自己总结的 MoSCoW 决策流程，你可以参考：
MoSCoW 的好处是，它逼着你做取舍。你不可能把所有需求都塞进 Must have。如果 Must have 超过总需求的 60%，说明你还没想清楚什么是真正的核心。
实战建议：每次迭代开始前，用 MoSCoW 重新排一次优先级。需求会变，优先级也要跟着变。
3.4 三者如何协同工作
分层、分类、优先级，这三件事不是孤立的。它们是一套组合拳。
举个例子：
用户需求：「我想在开车时安全地看导航」
- 分层：用户需求 → 系统需求（导航信息需在驾驶员视野 15° 内显示）→ 软件需求（HUD 模块渲染导航箭头，刷新率 ≥ 30fps）
- 分类：功能需求（显示导航箭头）+ 非功能需求（刷新率 ≥ 30fps，延迟 ≤ 50ms）
- 优先级：Must have（安全相关）
你看，一个简单的用户需求，经过三层分解、两类划分、一级优先级，就变成了可执行、可测试、可排期的开发任务。
我建议你在需求管理工具里，给每条需求都打上这三个标签：层次、类型、优先级。这样后续做变更影响分析时，一眼就能看出改了什么、影响多大。
小技巧：用颜色区分优先级。Must have 标红色，Should have 标黄色，Could have 标绿色，Won't have 标灰色。看板上一目了然。
好了，这一章的内容就这些。记住：需求分类分层不是形式主义，它是让团队少走弯路的基础。下次写需求时，先问自己三个问题：这是哪一层？是功能还是非功能？优先级排第几？