3、需求分析阶段：系统级需求、功能需求、非功能需求的捕获与文档化
好，咱们进入需求分析阶段。说实话，这是整个V模型里最容易被低估的一环。很多人觉得写需求就是“把客户的话记下来”，其实远没那么简单。我在自动驾驶项目里踩过最大的坑，十有八九都出在需求没写清楚上。
3.1 系统级需求：先搞清楚“车要干什么”
系统级需求，说白了就是回答一个问题：这个自动驾驶系统，到底要解决什么场景下的什么问题？
我个人习惯，先画一个“运行概念图”。比如L2级辅助驾驶，系统级需求可能是：
- 在高速公路（0-120km/h）上，实现自适应巡航和车道保持
- 在城区道路（0-60km/h）上，实现自动跟车和紧急制动
- 系统必须能在雨、雾、夜间等常见天气下正常工作
你看，这些需求不涉及任何技术细节，只描述“系统对外表现出的行为”。我建议用用例图来辅助捕获，每个用例对应一个系统级功能。
关键点：系统级需求必须可验证。我曾经见过一条需求写“系统应具有良好的制动性能”，结果测试时大家吵了三天——什么叫“良好”？后来改成“在干燥路面、60km/h速度下，制动距离不超过20米”，这才算完。
3.2 功能需求：把“干什么”拆成“怎么做”
系统级需求定下来后，就要往下拆。功能需求描述的是系统内部各个模块应该具备的能力。
举个例子，系统级需求里有一条“实现自适应巡航”，那功能需求就要拆成：
- 感知模块：能检测前方200米内的目标车辆，输出相对距离和速度
- 决策模块：根据前车速度，计算本车目标加速度（范围-3m/s² 到 2m/s²）
- 控制模块：输出油门/刹车指令，使实际加速度与目标加速度误差小于0.2m/s²
嗯，这里要注意：功能需求不要写“怎么实现”，只写“要达成什么”。比如“使用卡尔曼滤波进行目标跟踪”这是设计，不是需求。需求应该是“目标跟踪误差小于5%”。
我的小技巧：写功能需求时，我会用“SHALL”句式。比如“The ACC system SHALL maintain a safe following distance of at least 2 seconds.” 这种句式强迫你把需求写明确，没有模糊空间。
3.3 非功能需求：那些“看不见但很重要”的东西
非功能需求，说白了就是系统的“质量属性”。自动驾驶里，这块特别容易被忽略，但出事往往就出在这。
我把它分成几类：
| 类别 | 示例 | 为什么重要 |
|---|---|---|
| 安全性 | 系统必须在100ms内检测到碰撞风险并触发制动 | 直接关系生命安全 |
| 可靠性 | 系统平均无故障时间（MTBF）不低于10000小时 | 用户信任的基础 |
| 实时性 | 感知到决策的端到端延迟不超过150ms | 高速场景下，晚1ms可能就撞了 |
| 可用性 | 系统在-20°C到60°C环境下正常工作 | 中国南北温差大，不能挑天气 |
| 可维护性 | 软件升级时间不超过30分钟 | OTA升级是常态 |
我曾经在一个项目里，功能需求写得滴水不漏，但非功能需求只写了“系统应稳定运行”。结果路测时，连续跑了4小时后系统过热降级——测试团队说“这算稳定运行吗？” 我哑口无言。从那以后，非功能需求我每条都写量化指标。
3.4 需求文档化：怎么写才不会被骂？
需求写完了，怎么组织成文档？我推荐用需求规格说明书（SRS）的格式，但别照搬国标，太死板。咱们实际项目中，我习惯这样组织：
- 引言：项目背景、术语定义、参考文档
- 系统级需求：用例图 + 需求列表，每条有唯一ID
- 功能需求：按模块分章节，每个需求包含ID、描述、优先级、来源
- 非功能需求：按类别分，同样有ID和量化指标
- 需求追溯矩阵：每个功能需求对应到哪个系统级需求，每个测试用例对应到哪个功能需求
避坑指南：我曾经见过一个团队，需求文档写了300页，但没人看。为什么？因为需求之间互相矛盾。比如一条说“系统延迟不超过100ms”，另一条说“系统必须做多传感器融合”，但没提融合算法耗时。你想想看，这两条放一起，实现上就是冲突的。所以文档化时，一定要做一致性检查。
3.5 需求评审：别一个人闷头写
需求写完后，一定要评审。我建议至少组织三轮：
- 内部评审：开发、测试、系统工程师一起过，找逻辑漏洞
- 客户评审：让客户确认“这是不是你想要的？”
- 安全评审：专门过一遍安全相关的需求，比如ASIL等级分配
评审时，我习惯用需求检查单。比如：
- 每条需求是否可测试？
- 是否有歧义？（比如“快速”、“良好”这类词）
- 是否与其他需求冲突？
- 优先级是否明确？
嗯，这里分享一个经验：评审时最容易吵起来的是“优先级”。开发说这个功能不重要，产品说这个功能必须做。我的做法是——用数据说话。比如“这个功能覆盖了多少使用场景？占用户总里程的百分之几？” 有了数据，争论就变成了讨论。
3.6 需求变更管理：唯一不变的就是变化
项目进行中，需求肯定会变。我见过最夸张的项目，一个月变了5次需求。怎么办？
我的建议是：
- 建立变更控制流程：任何变更必须走CR（Change Request）流程
- 评估影响范围：这个变更会影响哪些模块？需要重新测试吗？
- 更新追溯矩阵：变更后，所有关联的测试用例也要更新
- 通知所有干系人：别让测试团队拿着旧需求测新功能
小技巧：我习惯用版本号管理需求文档。比如V1.0、V1.1、V2.0。每次变更，在文档开头写清楚“变更记录”，包括变更内容、变更原因、变更日期、变更人。这样出了问题，能追溯到是谁改的、为什么改。
好了，需求分析阶段就讲到这里。说白了，需求就是整个项目的“宪法”。宪法写得好，后面开发、测试、集成都顺风顺水。宪法写得烂，后面全是坑。我个人觉得，花在需求上的时间，永远不亏。