需求工程基础：需求类型、需求属性与需求层次
在ASPICE（Automotive Software Process Improvement and Capability Determination）框架中，需求工程是连接客户期望与软件实现的核心枢纽。需求不仅是开发活动的起点，更是验证与确认（V&V）活动的基准。许多项目失败的根本原因并非编码能力不足，而是需求层面的模糊、缺失或层级错乱。本章将深入剖析需求工程的基础结构：利益相关方需求、系统需求与软件需求的类型划分，需求属性的完整定义，以及需求层次之间的追溯关系。理解这三者之间的逻辑链条，是实施ASPICE、通过过程评估以及实现高质量汽车软件交付的前提。
3.1 需求类型的定义与边界
3.1.1 核心原理：三类需求的本质区别
在ASPICE的SUP.10（需求获取）与SYS.2（系统需求分析）等过程域中，需求被严格划分为三个层次。这种划分并非简单的文档拆分，而是基于抽象层级与责任主体的不同。利益相关方需求（Stakeholder Requirements）描述的是“为什么做”和“做什么价值”，它不关心技术实现路径；系统需求（System Requirements）描述的是“系统级怎么做”，它定义了系统边界内的功能、性能与约束；软件需求（Software Requirements）则进一步细化到“软件组件怎么做”，它必须具体到可被软件架构和代码直接实现的程度。
一个常见的误区是将客户提供的原始描述直接当作软件需求进行开发。例如，客户说“希望车辆在雨天自动关闭天窗”，这是利益相关方需求。系统需求应转化为“当雨量传感器检测到降雨强度大于X mm/h时，天窗控制单元应在Y秒内执行关闭动作”。而软件需求则需进一步明确“软件组件RainSensor_Handler应每100ms读取ADC通道3的雨量值，若连续3次超过阈值，则通过CAN总线发送天窗关闭指令”。没有这种逐层细化，开发团队将面临巨大的理解偏差风险。
3.1.2 判断方法：如何正确归类一条需求
在实际项目中，需求工程师可以通过以下三个问题快速判断需求层级：
- 问题一：这条需求是否描述了业务价值或用户可感知的体验？如果是，则属于利益相关方需求。
- 问题二：这条需求是否涉及多个系统组件（如传感器、执行器、控制器）之间的交互与约束？如果是，则属于系统需求。
- 问题三：这条需求是否可以被软件架构师直接分配到一个或多个软件组件，并据此进行编码？如果是，则属于软件需求。
此外，还需关注需求的可验证性。利益相关方需求通常难以直接测试，而系统需求和软件需求必须具有明确的验证方法。例如，“系统应具有良好的操控性”是不可验证的利益相关方需求，应细化为“系统在车速80km/h时，转向响应延迟不超过150ms”这一可验证的系统需求。
3.1.3 案例拆解：ACC自适应巡航的需求分解
以自适应巡航控制（ACC）功能为例，展示三类需求的典型表达与转换过程。初始阶段，客户提供的利益相关方需求为：“车辆应能在高速公路上自动跟随前车，减轻驾驶员疲劳。”这一描述缺乏量化指标。系统需求分析后，形成如下条目：
| 需求层级 | 需求ID | 需求内容 | 验证方法 |
|---|---|---|---|
| 利益相关方 | STK-001 | ACC功能在车速30-180km/h范围内，应能自动保持安全跟车距离 | 实车路测 |
| 系统需求 | SYS-001 | 系统应通过前向毫米波雷达与摄像头融合，输出目标车辆相对速度与距离，精度误差≤±2% | HIL台架测试 |
| 软件需求 | SW-001 | 软件组件ACC_Controller应每10ms读取融合目标列表，当目标距离小于安全阈值时，输出减速度请求值（范围-3.5m/s²至0） | 单元测试/集成测试 |
从上述案例可见，每一层需求都增加了技术细节与量化指标，同时保持了向上追溯的清晰路径。若在测试阶段发现SW-001无法满足SYS-001的精度要求，则需回溯至系统架构层面调整传感器选型或融合算法，而非仅修改软件代码。
3.1.4 常见误区与总结复盘
总结复盘时，建议团队在项目启动阶段即建立需求层级评审检查单，逐条确认每条需求的层级归属。同时，应明确各层需求的负责人：利益相关方需求由系统工程师与客户对接，系统需求由系统架构师主导，软件需求由软件架构师与需求工程师共同编写。这种职责分离有助于保持各层需求的纯粹性与一致性。
3.2 需求属性的完整定义
3.2.1 核心原理：为什么需求属性至关重要
需求属性是描述需求本身特征的数据项，它如同需求的“元数据”。在ASPICE中，需求属性不仅是文档管理的需要，更是实现需求追踪、变更影响分析和质量度量的基础。没有属性的需求只是一行文字，而具备完整属性的需求才是可管理、可度量的工程资产。常见的需求属性包括：唯一标识符（ID）、需求来源、优先级、状态、稳定性、复杂度、验证方法、风险等级、ASIL等级、创建人、创建日期等。
在汽车功能安全（ISO 26262）背景下，ASIL等级作为需求属性尤为重要。一条需求若被标记为ASIL D，则其对应的软件组件必须采用相应的安全机制（如ECC、双通道比较），且验证深度需达到“形式化方法”级别。若属性缺失，安全工程师将无法判断该需求的安全完整性等级，进而导致功能安全目标无法闭环。
3.2.2 操作流程：定义与维护需求属性的步骤
在需求管理工具（如DOORS、Polarion、Jama）中，需求属性的定义应遵循以下流程：
- 第一步：属性模板定制。根据项目类型（如动力域、底盘域、座舱域）裁剪属性集。例如，动力域项目必须包含“ASIL等级”和“故障响应时间”，而座舱域项目可能更关注“UI响应延迟”和“分辨率适配”。
- 第二步：属性值域定义。明确每个属性的允许值。例如，“优先级”只能取“高/中/低”，“状态”只能取“草稿/已评审/已批准/已实现/已验证”。避免自由文本导致的混乱。
- 第三步：属性填写责任分配。需求作者负责填写ID、来源、内容；评审者负责确认优先级、风险等级；测试人员负责补充验证方法。
- 第四步：属性变更控制。当需求内容变更时，其属性（如状态、复杂度）必须同步更新，并记录变更历史。
3.2.3 实战场景：属性驱动的需求质量度量
某Tier 1供应商在开发BMS（电池管理系统）软件时，利用需求属性进行质量预测。他们统计了所有软件需求的“复杂度”属性（高/中/低）与“缺陷密度”的关系。结果显示，标记为“高复杂度”的需求，其缺陷密度是“低复杂度”需求的4.2倍。基于此数据，项目经理在排期时对高复杂度需求额外分配了30%的测试资源，并在代码评审时要求高级工程师重点审查。这一属性驱动的决策显著降低了发布后的现场故障率。
此外，需求属性中的“状态”字段可用于生成实时看板。例如，当“已批准”状态的需求占比低于80%时，不允许进入编码阶段。这种基于属性的过程门禁，是ASPICE中“过程度量”理念的具体落地。
3.2.4 常见误区与总结复盘
复盘时，团队应反思：属性是否真正被用于决策？如果“优先级”属性从未影响过开发排序，那么该属性就是无效的。需求属性不是摆设，而是驱动项目计划、资源分配、风险评估的输入数据。
3.3 需求层次与追溯性
3.3.1 核心原理：需求层次的结构逻辑
需求层次并非简单的“三明治”结构，而是一个复杂的网状追溯模型。利益相关方需求可以追溯到一条或多条系统需求；一条系统需求可以分解为多条软件需求；同时，一条软件需求也可能服务于多条系统需求（如“系统时钟同步”需求被多个功能模块复用）。ASPICE要求建立双向追溯性：正向追溯（从利益相关方需求到软件需求）确保所有客户期望都被实现；反向追溯（从软件需求到利益相关方需求）确保所有软件需求都有存在的理由，防止“镀金需求”或“孤儿需求”。
在系统需求与软件需求之间，还存在系统架构设计的中间层。系统架构将系统需求分配给硬件、软件、机械等元素，软件需求则是从分配给软件元素的系统需求中细化而来。因此，需求层次实际上与架构设计紧密耦合，需求工程师必须与架构师紧密协作。
3.3.2 操作流程：建立与维护追溯矩阵
建立追溯矩阵是ASPICE实施中的关键活动。推荐采用以下步骤：
- 步骤1：定义追溯粒度。通常以“需求条目”为最小追溯单元，而非整个文档。例如，将SYS-001与SW-001、SW-002建立链接。
- 步骤2：在工具中建立链接。使用需求管理工具的“链接”功能，创建“满足/实现”和“验证/派生”两种链接类型。
- 步骤3：定期执行追溯完整性检查。利用工具生成追溯报告，找出“无上游来源的需求”（孤儿需求）和“无下游实现的需求”（悬空需求）。
- 步骤4：变更影响分析。当某条利益相关方需求变更时，通过追溯矩阵快速定位受影响的系统需求和软件需求，评估变更工作量。
3.3.3 案例拆解：追溯矩阵在变更管理中的应用
某项目在开发过程中，客户提出变更：将ACC的最高车速从180km/h提升至200km/h。需求工程师通过追溯矩阵发现，该变更影响SYS-001（传感器探测距离需增加）、SYS-004（制动执行器响应时间需缩短）、SW-001（控制算法参数需调整）、SW-007（仪表显示逻辑需更新）。进一步分析发现，SYS-004的变更涉及硬件选型，无法在软件层面解决，因此需要与客户重新协商或增加硬件成本。这一分析过程仅耗时2小时，而如果没有追溯矩阵，该变更可能需要2周才能评估完整，且存在遗漏风险。
该案例展示了追溯矩阵的三大价值：影响范围可视化、跨层级联动分析、成本与风险早期暴露。在ASPICE评估中，审核员会随机抽取一条需求，检查其双向追溯是否完整。若发现断链，将开具不符合项。
3.3.4 常见误区与总结复盘
总结复盘时，团队应关注追溯矩阵的“健康度”。可以设定指标：追溯覆盖率（已建立链接的需求/总需求数）应≥95%，孤儿需求数应≤1%。定期召开追溯评审会议，由系统工程师、软件工程师和测试工程师共同确认追溯的正确性。需求层次与追溯性不仅是文档要求，更是项目风险管理的核心工具。
通过本章的讲解，我们明确了需求类型的边界、需求属性的定义方法以及需求层次之间的追溯机制。这三者构成了ASPICE需求工程的基石。在实际项目中，需求工程师应像“翻译官”一样，将客户的声音准确转化为系统语言，再细化为软件指令，同时确保每一步都有据可查、有迹可循。下一阶段，我们将深入探讨需求 elicitation（获取）技术与需求分析的具体方法，敬请期待。