4. 需求工程入门
在汽车电子与嵌入式系统开发中，需求工程不是“写文档”的附属工作，而是决定V模型能否闭环的源头活动。V模型左侧的每一层设计——系统架构、软件架构、详细设计——都必须能追溯到一条被正确获取、分析、规格化并受控管理的需求。如果需求阶段留下歧义、遗漏或不可验证的表述，右侧的集成与测试就会变成“猜谜游戏”，返工成本随层级上升呈指数增长。
一、需求工程的四个活动与V模型左侧的映射
需求工程通常划分为四个相互迭代的活动：需求获取、需求分析、需求规格化、需求管理。它们并非线性串行，而是螺旋推进。对应到V模型，需求获取与分析主要服务于系统需求层，规格化输出系统需求规格说明书，需求管理则贯穿整个生命周期，并在右侧验证阶段反向校验。
二、需求获取：从利益相关者到原始需求
需求获取的关键在于“找对人、问对问题、看对场景”。汽车项目的利益相关者包括整车厂、Tier1、驾驶员、乘客、维修人员、法规机构等。常用手段有访谈、问卷、现场观察、场景走查、法规解读和竞品拆解。例如开发自动紧急制动（AEB）功能时，需要获取的不只是“能刹停”，还包括触发条件、目标识别范围、驾驶员接管优先级、误触发容忍度等。
三、需求分析：把原始需求变成可决策的条目
获取到的原始需求往往存在冲突、模糊、不可实现或重复。需求分析要完成四件事：分类与归并、冲突识别与消解、可行性评估、优先级排序。常用方法包括用例分析、场景分析、功能分解、接口分析和风险分析。分析结果应回答：这条需求属于功能、性能、安全还是法规？它与哪条需求冲突？实现代价和风险如何？在资源有限时先做哪条？
四、需求规格化：写出可验证的SRS
规格化的核心是“条目化、唯一标识、可验证、无歧义”。每条需求应有唯一ID、来源、描述、验收准则、优先级和状态。描述应避免“尽量”“快速”“友好”等主观词，改用可测量的阈值。例如：
REQ-AEB-012
描述：当自车车速在 30~80 km/h 且前方目标相对速度大于 20 km/h 时，
系统应在 TTC ≤ 1.2 s 时发出碰撞预警。
验收准则：在封闭试验场，使用目标车以 20 km/h 相对速度接近，
记录预警触发时刻的 TTC，误差不超过 ±0.1 s。
优先级：高
来源：整车安全需求 SYS-SAF-007
状态：已评审 / 基线五、需求管理：贯穿V模型的追溯与变更控制
需求管理不是文档管理，而是链路管理。它包含需求追溯、基线管理、变更控制和状态跟踪。在V模型中，左侧每一条设计都应能向上追溯到需求，右侧每一条测试用例都应能向下追溯到需求。当需求变更时，必须评估对设计、代码、测试和标定的影响范围。
| 需求工程活动 | 主要输出 | 对应V模型位置 | 关键检查点 |
|---|---|---|---|
| 需求获取 | 原始需求清单、场景列表 | 系统需求层输入 | 利益相关者是否覆盖完整 |
| 需求分析 | 需求分类、冲突矩阵、优先级 | 系统架构与软件架构之间 | 冲突是否消解、是否可实现 |
| 需求规格化 | SRS、需求条目、验收准则 | 左侧设计分解的基线 | 是否可验证、是否无歧义 |
| 需求管理 | 追溯矩阵、变更记录、基线 | 贯穿左右两侧 | 变更影响是否闭环 |
六、案例场景：AEB需求的一条链路
假设整车安全需求提出“在紧急情况下降低碰撞速度”。经过获取与分析，转化为系统需求“AEB应在TTC≤1.2s时触发预警”，再分解为软件需求“雷达目标融合模块应在50ms内输出目标TTC”，接着进入软件架构与详细设计。右侧对应测试用例验证预警触发时刻、TTC计算精度和响应时间。若后期法规将TTC阈值改为1.0s，需求管理必须触发变更，评估对雷达标定、制动执行器和测试用例的连锁影响。
七、复盘要点
- 需求获取要覆盖所有利益相关者，避免“拍脑袋”需求。
- 需求分析要显式处理冲突和优先级，不能把矛盾留给下游。
- 需求规格化必须条目化、可验证、有唯一标识和验收准则。
- 需求管理要建立双向追溯，变更必须评估影响并更新基线。
- V模型左侧的每一层设计都应有需求来源，右侧的每一条测试都应有需求判据。
只有把需求工程四个活动与V模型左侧严格对齐，并用需求管理贯穿始终，才能让后续的架构设计、编码、集成和测试有据可依，真正实现“左侧可追溯、右侧可验证”的闭环开发。