2. 代码生成环境搭建

说实话，很多工程师觉得写需求是项目经理的事。我自己刚入行那会儿也这么想——给我一个需求文档，我直接开干Simulink建模不就行了？结果呢？模型改了三版，客户说“这不是我要的”。

后来我才明白，需求分析才是整个V模型的起点。起点歪了，后面全白干。这一章，我就带你把这套需求管理的套路捋清楚。

2.1 需求文档到底长什么样？

需求文档不是写作文，更不是写小说。它是一份“契约”——客户、系统工程师、软件工程师、测试工程师，所有人都得认同一件事：文档里写的，就是我们要交付的。

我习惯把需求文档分成三个层次，每个层次对应不同的读者和关注点：

你看，每个层次都有明确的边界。客户需求说“我要一个自动紧急制动功能”，系统需求就要拆成“雷达检测距离≥150m、制动响应时间≤200ms”，软件需求再细化成“当目标相对速度>30km/h且碰撞时间<2.5s时，输出制动请求信号”。

2.2 需求层级划分：从“客户想要”到“代码实现”

需求层级划分，说白了就是“翻译”的过程。客户说的是人话，工程师要翻译成技术语言。这个翻译过程，我建议分三步走：

1. 客户需求层：记录客户的原始诉求，不做过多的技术解读。比如“车辆在雨夜能看清前方障碍物”。
2. 系统需求层：把客户需求分配到子系统。比如“前视摄像头在0.1lux照度下可识别50m内行人”、“大灯自动切换远光模式”。
3. 软件需求层：把系统需求转化为软件可实现的逻辑。比如“当环境光传感器输出<50lux且车速>40km/h时，激活远光灯”。

这里有个坑，我踩过好几次——层级跳跃。有些工程师喜欢直接从客户需求跳到代码，跳过了系统需求层。你想想看，没有系统需求，你怎么做硬件选型？怎么做系统架构？

2.3 需求追溯矩阵：让每行代码都有“户口”

需求追溯矩阵（RTM），听起来很高大上，其实就是一个“对照表”。它记录了每个需求从诞生到实现再到验证的全过程。

我习惯用表格来管理RTM，结构大概是这样的：

你看，通过这个矩阵，你可以从任何一个需求出发，向上追溯到客户原始诉求，向下追踪到代码实现和测试验证。这就是所谓的“双向追溯”。

2.4 需求管理中的常见“坑”

做需求管理这么多年，我总结了几条血泪教训，分享给你：

• 需求模糊：“系统响应要快”——多快？100ms还是1s？一定要量化。
• 需求冲突：“成本要低”和“性能要高”往往冲突。这时候需要优先级排序。
• 需求遗漏：非功能性需求（安全性、可靠性、可维护性）经常被忽略。
• 需求变更失控：客户今天加一个功能，明天改一个参数，没有变更流程的话，项目必乱。

嗯，这里要特别说一下需求变更。我建议团队建立“变更控制委员会”，任何需求变更都要经过评审。不是不让改，而是要有记录、有影响分析、有成本评估。

2.5 本章知识结构图

下面这张图，把需求管理的核心逻辑串起来了。你可以把它当作本章的“地图”：

2.6 实战建议：从零搭建需求管理体系

如果你现在要开始一个新项目，我建议你按这个步骤来：

1. 第一步：和客户一起确认CRS，逐条评审，确保没有歧义。
2. 第二步：系统工程师把CRS分解成SRS，分配硬件、软件、机械各子系统。
3. 第三步：软件工程师把SRS中分配给软件的部分，细化成SWRS。
4. 第四步：建立RTM，把CRS、SRS、SWRS全部关联起来。
5. 第五步：在Simulink模型中，通过需求链接功能，把模型模块和SWRS条目一一对应。

嗯，这里要提醒你：Simulink本身是支持需求链接的。你可以在模型里右键一个模块，选择“Requirements”->“Link to Requirement”，然后关联到你的需求条目。这样，模型改了，需求变更了，都能自动提醒。

最后说一句：需求管理不是“一次性”的工作。它贯穿整个V模型开发周期。你花在需求上的每一分钟，都会在后面的建模、代码生成、测试阶段省回来。相信我，这是性价比最高的投入。