3、需求工程概述：需求的定义、分类（功能/非功能/约束）、需求工程生命周期（获取、分析、规格化、验证、管理）
在汽车软件系统开发中，需求工程是连接用户期望与最终软件实现的桥梁。与普通IT系统不同，汽车软件运行在一个安全至上的物理环境中，其需求不仅要描述“系统做什么”，还必须精确刻画“系统在何种边界条件下做到什么程度”。本章作为方法论课程的开篇，将系统性地建立需求工程的基础框架，明确需求的定义、分类维度以及贯穿项目始终的生命周期活动，为后续章节中具体的建模、分析与验证技术奠定概念基础。
3.1 需求的定义与本质
核心原理：需求是“问题域”到“解系统”的契约
在汽车软件工程语境下，需求并非简单的“用户想要什么”的罗列，而是一份具有严格语义的技术契约。它必须同时回答三个问题：系统提供什么能力（功能）、能力达到何种水平（性能与质量）、在何种边界条件下有效（约束与假设）。例如，一条关于“自动紧急制动（AEB）”的需求，不能仅描述“车辆能自动刹车”，而必须明确：在车速 10-80 km/h 范围内、相对速度差不超过 50 km/h、路面附着系数大于 0.6 时，系统应在 300ms 内输出制动请求，且误触发率低于 0.01 次/万公里。这种精确性源于汽车软件失效可能带来的安全风险，因此需求本质上是可验证的工程规范，而非愿景描述。
判断方法：如何识别“真需求”与“伪需求”
在实际项目中，需求工程师常面临来自市场、管理层、甚至开发人员的各种“诉求”。判断一条输入是否为有效需求，可采用以下三条准则：
- 可验证性：是否存在客观的测试方法或度量指标来确认需求被满足？例如“操作流畅”不可验证，而“触摸响应时间 ≤ 100ms”可验证。
- 原子性：该需求是否描述了一个单一、独立的行为或属性？若一条需求包含多个条件或动作，应拆分为多条。
- 可追踪性：能否向上追溯到业务目标或用户场景，向下追溯到设计实现和测试用例？无源之水式的需求应被剔除。
此外，需区分需求与方案。例如“使用 CAN FD 总线传输数据”是方案，而“在 10ms 内将传感器数据可靠传输至域控制器”才是需求。过早绑定技术方案会限制设计空间。
案例拆解：从“提升驾驶体验”到可落地的需求条目
某主机厂在开发新一代智能座舱时，产品经理提出“提升驾驶体验”的模糊目标。需求工程师通过用户访谈和场景分析，将其拆解为以下需求条目：
| 原始诉求 | 需求条目（示例） | 验证方法 |
|---|---|---|
| 导航更智能 | 系统应能根据实时路况，在预计到达时间延迟超过 10 分钟时，自动提供备选路线建议 | 仿真测试：输入预设路况数据，检查提示触发逻辑 |
| 语音更灵敏 | 在车速 120km/h、空调风量最大时，语音唤醒成功率 ≥ 95% | 实车噪声环境测试 |
| 界面更简洁 | 常用功能（如空调温度、音量）在首页的点击路径不超过 2 步 | UI 原型走查 + 可用性测试 |
这一过程体现了需求工程的核心价值：将主观期望转化为可设计、可测试、可追踪的工程条目。
常见误区与总结
误区二：混淆“客户需求”与“系统需求”。客户需求描述问题域，系统需求描述解空间，二者需明确映射关系。
误区三：忽视需求的优先级排序。在资源受限时，必须基于价值、风险和成本进行 MoSCoW 或 Kano 模型排序。
3.2 需求的分类体系：功能、非功能与约束
核心原理：三类需求的协同与冲突
汽车软件需求可划分为三大类：功能需求定义了系统“做什么”，是行为的直接描述；非功能需求定义了系统“做得怎么样”，是质量属性（如性能、安全、可靠性、可维护性）；约束条件则限定了设计与实现的自由度，包括技术标准、法规、接口协议、成本与时间限制。三者并非孤立存在，而是相互制约。例如，一项功能需求“实现 360° 环视影像拼接”必须同时满足非功能需求“从启动到显示首帧图像时间 ≤ 2 秒”以及约束“使用现有 SoC 芯片，内存占用 ≤ 512MB”。
分类操作框架：如何系统化梳理需求
建议采用以下步骤进行需求分类，确保无遗漏：
- 场景驱动识别功能需求：基于用例或用户故事，提取系统必须响应的动作序列。
- 质量属性推导非功能需求：参考 ISO 25010 质量模型，从性能效率、兼容性、安全性、可靠性等维度逐项审视。
- 环境与法规识别约束：梳理适用的行业标准（如 ISO 26262、UN ECE R155）、硬件平台限制、通信协议要求。
- 交叉验证：检查每个功能需求是否都有对应的非功能需求（如精度、时间）和约束（如接口协议）支撑。
案例拆解：AEB 系统的需求分类实践
以自动紧急制动（AEB）系统为例，展示三类需求的典型条目：
| 类别 | 需求条目示例 | 来源/依据 |
|---|---|---|
| 功能需求 | 当检测到前方障碍物且驾驶员未采取制动时，系统应自动激活制动执行器，使车辆减速直至停止或碰撞风险消除。 | Euro NCAP 测试场景 |
| 非功能需求 | 从目标识别到制动请求输出的系统延迟 ≤ 150ms；系统误触发率 ≤ 0.01 次/万公里；在 -20°C 至 +60°C 环境温度下功能正常。 | ISO 26262 ASIL B 分解 |
| 约束条件 | 必须使用现有前视摄像头（分辨率 1280x960）和毫米波雷达（探测距离 150m）；制动执行器接口遵循 AUTOSAR 4.4 规范；开发周期不超过 12 个月。 | 项目立项书 / 平台规划 |
该案例表明，清晰分类有助于在需求评审时快速定位遗漏项，并为架构设计提供输入。
常见误区与总结
误区二：非功能需求描述过于笼统，如“系统应具有高可靠性”。应量化：MTBF ≥ 5000 小时，或 ASIL 等级达到 B 级。
误区三：忽略需求之间的冲突。例如高性能与低功耗往往矛盾，需在分类后显式进行冲突分析。
3.3 需求工程生命周期：从获取到管理
核心原理：生命周期是迭代与递归的工程过程
需求工程并非线性瀑布，而是一个迭代演进、持续验证的过程。其生命周期包含五大活动：获取（Elicitation）、分析（Analysis）、规格化（Specification）、验证（Validation & Verification）、管理（Management）。在汽车行业中，由于功能安全标准要求可追踪性，这些活动通常与 V 模型开发流程紧密结合。例如，需求分析的结果直接输入到系统架构设计，而需求验证则与测试用例设计相对应。
操作流程：五大活动的输入、输出与关键方法
| 活动 | 核心目标 | 常用方法/工具 | 关键输出 |
|---|---|---|---|
| 获取 | 从干系人（用户、法规、市场）收集原始需求 | 访谈、工作坊、原型演示、场景分析、法规研究 | 干系人需求清单、用例模型 |
| 分析 | 检查需求质量，解决冲突，建立优先级 | 需求评审、冲突分析、可行性验证、优先级排序（MoSCoW） | 分析后的需求集、风险清单 |
| 规格化 | 将需求编写为无歧义的正式文档 | 自然语言模板、SysML/UML 建模、基于属性的需求编写 | 系统需求规格说明书（SyRS） |
| 验证 | 确认需求正确、完整且可测试 | 同行评审、原型验证、测试用例设计、可追踪性矩阵 | 验证报告、需求基线 |
| 管理 | 控制需求变更，维护可追踪性 | 变更控制委员会（CCB）、需求配置管理、工具链（如 DOORS、Jama） | 变更请求记录、需求基线版本 |
案例拆解：ADAS 域控制器需求变更管理闭环
某项目在开发中期，客户提出新增“交通拥堵辅助（TJA）”功能。需求管理流程如下：
- 变更请求提交：产品经理提交变更申请，附上市场分析报告和初步场景描述。
- 影响分析：需求工程师评估对现有功能（ACC、LKA）的接口影响，估算新增 3 个功能需求、2 个非功能需求（如系统延迟增加 ≤ 50ms），并识别出与现有“驾驶员监控”需求的冲突。
- CCB 评审：由项目经理、架构师、测试经理和功能安全经理组成 CCB，基于风险、成本和进度权衡，批准变更但要求降低 LKA 的介入灵敏度以平衡性能。
- 基线更新与追踪：更新需求基线至 v2.3，并在 DOORS 中建立新需求与设计模块、测试用例的追踪关系。
- 验证与回归：新增 15 条测试用例，并对受影响的 LKA 功能执行回归测试。
该闭环展示了需求管理如何控制项目风险，确保变更受控且可追溯。
常见误区与总结
误区二：规格化时过度依赖自然语言，导致歧义。应结合图形化建模（如状态机、序列图）补充语义。
误区三：验证活动滞后，直到测试阶段才暴露需求缺陷。应在规格化后立即进行静态验证和原型走查。
误区四：需求管理仅关注变更记录，忽视版本间差异分析。每次基线更新应附带变更影响说明。