第2章需求分析与系统定义

第二章：需求分析与系统定义

大家好，我是你们的老朋友。今天我们来聊聊自动驾驶系统里最容易被忽视、却又最致命的一步——需求分析与系统定义。

说实话，我见过太多团队，一上来就急着写代码、调算法。结果呢？做到一半发现需求没对齐，系统边界模糊不清，最后推倒重来。嗯，我自己也踩过这个坑。

先说说功能需求。说白了，就是“系统要做什么”。比如：

这些都很直观。但真正让工程师头疼的，是非功能需求。

非功能需求，是“系统做得怎么样”。举个例子：

我在项目中遇到过一件事。有一次，我们做L4级泊车系统，功能需求都写得很清楚。但客户验收时，发现系统在雨天识别率下降严重。为什么？因为非功能需求里没写“全天候环境适应性”。

所以我的建议是：功能需求和非功能需求，必须同时写、同时审、同时验。缺一个，后面都是雷。

重要提醒：非功能需求往往比功能需求更难量化。比如“系统要安全”，这太模糊了。你得写成“在单点故障下，系统能在200ms内切换到安全状态”。

系统边界，就是你的系统管到哪、不管到哪。这听起来简单，但实际操作中经常打架。

举个例子：自动驾驶系统要不要管轮胎打滑？

我个人习惯，在项目启动时画一张系统上下文图。把外部实体（传感器、执行器、云端、驾驶员）都列出来，然后用箭头标出数据流向。

为什么要这么做？因为边界不清，会导致责任不清。我曾经见过一个项目，感知团队和规划团队互相推诿——感知说“我只要输出障碍物列表”，规划说“我需要感知告诉我障碍物的运动轨迹”。你看，这就是边界没定义好。

小技巧：用“输入-处理-输出”模型来定义每个模块的边界。输入是什么？输出是什么？处理逻辑归谁？写清楚，签个字，后面少吵架。

用例建模，是UML里最实用的工具之一。它不画代码，不画类图，只画谁和系统之间发生了什么。

比如一个“自动泊车”用例：

你想想看，这个图一画出来，整个系统的功能边界就一目了然了。哪个功能是给谁用的？哪个功能依赖哪个外部系统？全清楚了。

我记得有一次评审，我们拿着用例图给客户看。客户说：“哦，原来你们这个‘紧急接管’用例，是驾驶员主动触发的，不是系统自动触发的。” 你看，一个图就避免了一场误解。

用例建模的步骤，我一般这么走：

注意：用例图不是流程图。别把每一步操作都画进去。用例是“用户视角的目标”，不是“系统内部的步骤”。比如“用户启动车辆”是一个用例，但“用户插入钥匙、踩刹车、按启动按钮”是操作步骤，别混了。

最后，分享几个我在实际项目中总结出来的经验：

实践	说明
需求编号	每条需求都要有唯一ID，方便追溯和变更管理
需求优先级	用MoSCoW方法（Must/Should/Could/Won't）分级
需求验证	每条需求都要有对应的测试用例或验收标准
需求变更	建立变更控制流程，别让需求“悄悄变”

我曾经吃过一次大亏。项目做到中期，客户说“加一个功能吧，很简单”。我没走变更流程，直接让开发做了。结果那个功能影响了原有的时序约束，导致整个系统延迟超标。嗯，从那以后，我再也不敢跳过变更控制了。

好了，这一章的内容就到这里。需求分析看起来是“纸上谈兵”，但它是整个系统工程的基石。你想想看，如果地基没打好，后面盖再高的楼也是危楼。

下一章，我们会聊聊系统架构设计。到时候见。

核心总结：

公众号:蓝海资料掘金营，微信deep3321