1. 功能设计基础：功能设计概述、V模型开发流程、功能需求分析、功能架构设计原则

1.1 功能设计到底在做什么？

很多刚入行的工程师问我：功能设计不就是画几张框图、写几页文档吗？

说实话，我刚开始也这么想。直到有一次，我负责一个ADAS项目的功能定义，因为前期设计没做透，导致后期模型验证阶段推倒重来了三次。嗯，从那以后，我再也不敢小看这个环节了。

功能设计，说白了就是回答三个问题：

• 系统要干什么？ —— 功能需求
• 怎么干？ —— 功能架构
• 怎么证明干对了？ —— 验证策略

这三个问题贯穿整个开发周期。你想想看，如果连「要干什么」都没想清楚，后面的代码、测试、标定，全都是在沙滩上盖楼。

1.2 V模型开发流程——我习惯这么理解

V模型大家都不陌生。但我见过太多人把它当成一个「画在纸上的流程」，实际干活时根本不按这个来。

我个人习惯把V模型拆成两半来看：

左侧（自上而下）	右侧（自下而上）
系统需求分析	系统验收测试
功能架构设计	功能集成测试
软件/硬件设计	软件/硬件测试
代码实现	单元测试

左侧是「分解」，右侧是「验证」。每一层左侧的输出，直接对应右侧的测试用例。这就是V模型最核心的思想——验证不是最后才做的事，而是从第一天就开始设计的事。

我在项目中遇到过一种典型问题：团队左侧画得很细，但右侧的测试用例跟左侧需求对不上。结果就是——需求写了100条，测试只覆盖了60条，剩下40条全靠「人工脑补」。这其实已经偏离了V模型的初衷。

1.3 功能需求分析——别急着写文档

功能需求分析，最容易犯的错误就是「一上来就写文档」。我记得刚带项目那会儿，有个工程师花了两周写了80页需求文档，结果评审时发现——一半的需求跟系统目标没关系，另一半写得模棱两可。

为什么会这样？因为需求分析不是「写」出来的，是「问」出来的。

我一般会按这个步骤来：

1. 明确利益相关方 —— 客户、系统工程师、测试工程师、标定工程师，每个人关心的点不一样
2. 提取功能场景 —— 不要写「系统应能检测障碍物」，要写「当车辆以30km/h行驶，前方5米出现静止行人时，系统应在1秒内发出报警」
3. 定义边界条件 —— 温度范围、电压范围、电磁环境、使用寿命，这些不写清楚，后面全是坑
4. 标注优先级 —— 哪些是必须实现的（Must），哪些是最好有的（Should），哪些是锦上添花的（Could）

1.4 功能架构设计原则——少即是多

功能架构设计，就是把需求转化成模块、接口、数据流。这个环节我踩过的坑最多。

先看一个反面案例。我曾经见过一个架构图，画了30多个模块，箭头密密麻麻像蜘蛛网。评审时没人能说清楚每个模块到底负责什么。这种架构，基本等于没有架构。

我个人总结了几条原则，分享给你：

• 单一职责 —— 一个模块只做一件事，并且做好。比如「障碍物检测模块」只负责检测，不负责决策
• 接口最小化 —— 模块之间的接口越少越好。每多一个接口，就多一份耦合风险
• 可测试性优先 —— 设计架构时就想好「这个模块怎么单独测试」。如果测不了，说明架构有问题
• 分层清晰 —— 感知层、决策层、执行层，各层之间通过标准接口通信，不要跨层调用

下面这张图是我常用的功能架构分层方式，你可以参考：

你看，这个分层结构其实不复杂。但就是这种「不复杂」的结构，在实际项目中往往最管用。我见过太多团队把架构设计搞成了「炫技现场」，各种设计模式、中间件、微服务全往上堆，结果项目还没交付，架构先把自己压垮了。

1.5 功能设计阶段的交付物清单

最后，我列一个功能设计阶段应该产出的东西。你可以对照检查自己的项目：

交付物	内容说明	评审要点
功能需求规格书	功能场景、边界条件、性能指标、优先级	每条需求是否可验证？是否无歧义？
功能架构设计文档	模块划分、接口定义、数据流、状态机	模块职责是否单一？接口是否最小化？
验证策略文档	测试层级、测试用例框架、通过准则	是否覆盖所有需求？是否可执行？
功能安全分析（如适用）	危害分析、安全目标、ASIL等级	是否识别了所有合理可预见的危害？