需求工程基础：需求类型、需求层级与需求属性

在基于SysML的汽车需求建模实践中，需求工程是整个开发流程的起点与基石。需求不仅是设计、实现、测试和验收的依据，更是跨团队沟通的契约。本章将围绕需求类型、需求层级和需求属性三个核心维度展开，帮助学员建立一套系统化的需求分类与结构化表达方法，为后续使用SysML需求图、用例图和内部块图进行建模打下坚实基础。

上图展示了需求工程基础框架的整体视图。需求类型回答“需求关注什么”，需求层级回答“需求处于哪个抽象级别”，需求属性回答“如何管理需求”。三者共同构成了需求建模的立体坐标系。在SysML中，需求图（Requirement Diagram）正是承载这三类信息的核心工具。下面我们将逐一深入剖析。

2.1 需求类型：功能、性能、接口与约束

2.1.1 核心原理：需求类型的划分逻辑

需求类型是根据需求所描述的系统行为或特征维度进行的分类。在汽车电子领域，通常将需求分为四大类：功能需求、性能需求、接口需求和约束需求。此外，质量属性（如可靠性、安全性、可维护性）常作为约束或独立类型处理。这种分类有助于团队在需求分析时避免遗漏，也便于在SysML中为不同类型需求分配不同的验证策略。

• 功能需求：描述系统必须执行的动作或行为。例如“当车速超过120km/h时，系统发出超速报警”。功能需求通常对应SysML中的用例或活动。
• 性能需求：描述功能执行的量化指标。例如“超速报警响应时间不超过200ms”。性能需求必须绑定到具体功能上，否则无法验证。
• 接口需求：描述系统与外部环境或其他系统之间的交互方式。包括物理接口（如CAN总线波特率、连接器引脚定义）和逻辑接口（如信号协议、数据格式）。
• 约束需求：描述设计或实现必须遵守的限制条件。例如“工作温度范围-40℃~85℃”“满足ISO 26262 ASIL B功能安全等级”。约束通常来源于法规、标准或企业规范。

2.1.2 判断方法：如何区分需求类型

在实际项目中，需求条目往往混合了多种类型。一个实用的判断方法是：先问“系统做什么”，再问“做到什么程度”，接着问“和谁交互”，最后问“有什么限制”。如果一条需求同时包含功能与性能描述，建议拆分为两条独立需求，以便于追溯和验证。例如“系统应在100ms内完成AEB制动请求”应拆分为“系统应执行AEB制动请求”（功能）和“AEB制动请求响应时间≤100ms”（性能）。

判断问题	需求类型	SysML建模元素	示例（汽车领域）
系统做什么？	功能需求	«requirement» + «refine» 到用例	系统应提供自适应巡航控制（ACC）功能
做到什么程度？	性能需求	«requirement» + 量化属性	ACC车速控制精度±2km/h
和谁交互？	接口需求	«requirement» + 接口块（IBD）	ACC模块通过CAN FD以500kbps与EMS通信
有什么限制？	约束需求	«requirement» + 约束属性	ACC系统必须满足ISO 26262 ASIL B

2.1.3 案例拆解：AEB自动紧急制动系统的需求类型划分

以AEB（自动紧急制动）系统为例，我们来看需求类型如何落地。项目初始阶段，利益相关方提出“车辆应能在危险情况下自动刹车”。这条原始需求过于模糊，无法直接用于设计。经过需求工程师分析，拆解为以下条目：

1. 功能需求：AEB系统应检测前方障碍物，并在碰撞风险超过阈值时自动触发制动。
2. 性能需求：AEB系统从检测到障碍物到输出制动请求的延迟应≤150ms；制动减速度应≥0.6g。
3. 接口需求：AEB系统应通过CAN总线接收雷达和摄像头数据，并通过FlexRay向ESC发送制动请求。
4. 约束需求：AEB系统的工作温度范围为-40℃~85℃；满足Euro NCAP 2023评分要求；功耗≤15W。

通过这种拆解，每个需求都有了明确的验证目标。在SysML中，我们可以为每条需求创建独立的«requirement»块，并通过«refine»关联到对应的用例或活动图，确保设计与需求一一对应。

2.2 需求层级：从利益相关方到子系统

2.2.1 核心原理：需求层级的意义

需求层级描述了需求从抽象到具体的纵向分解关系。在汽车V模型开发流程中，需求层级通常分为：利益相关方需求（Stakeholder Requirements）、系统需求（System Requirements）、子系统需求（Subsystem Requirements），再往下可细分为组件需求和单元需求。层级划分的核心目的是实现“可追溯性”——每一项底层需求都能向上追溯到某个高层需求，从而确保所有工作都服务于最终目标。

2.2.2 操作流程：需求层级分解方法

需求分解不是简单的文字改写，而是基于系统架构的逐步细化。推荐采用以下流程：

1. 收集利益相关方需求：通过访谈、问卷、法规分析等方式，获取客户、用户、法规、企业内部等各方期望。这些需求通常以自然语言描述，可能包含冲突和歧义。
2. 定义系统需求：将利益相关方需求转化为技术可实现、可验证的系统级需求。系统需求应使用“系统应……”的句式，并包含量化指标。
3. 分配子系统需求：根据系统架构（如动力域、底盘域、座舱域），将系统需求分配到各子系统。例如“整车制动距离≤35m（60km/h）”可分解为“制动子系统提供最大减速度≥0.8g”“轮胎附着系数利用≥0.9”等。
4. 建立追溯链：在SysML中，使用«deriveReqt»关系连接不同层级的需求，形成需求树。

2.2.3 案例拆解：智能座舱系统的需求层级分解

以智能座舱的“语音控制”功能为例，展示需求层级分解过程。

层级	需求内容	示例
L1 利益相关方	用户期望通过语音控制空调温度	“驾驶员应能通过语音指令调节车内温度”
L2 系统需求	座舱系统应支持语音识别与执行	“系统应识别中文普通话语音指令，并在500ms内执行空调温度调节”
L3 子系统需求	语音识别子系统、空调控制子系统各自承担职责	“语音识别子系统应支持至少95%的指令识别准确率”“空调控制子系统应支持0.5℃步进调节”

在SysML中，L1需求通过«deriveReqt»关联到L2，L2再关联到L3。如果L3的某个需求无法满足，可以沿着追溯链向上分析影响范围。这种追溯能力在变更管理中尤为重要。

2.3 需求属性：让需求可管理、可验证

2.3.1 核心原理：需求属性的作用

需求属性是附着在需求条目上的元数据，用于支持需求的管理、优先级排序、风险控制和验证活动。没有属性的需求只是一行文字，无法支撑工程决策。在SysML中，需求属性通过«requirement»块的属性槽（如id、text）以及自定义的tag或value property来表达。

2.3.2 关键属性清单

以下是在汽车项目中推荐使用的核心需求属性集：

• 标识属性：ID（唯一编号）、名称、版本、创建日期、修改日期、作者。
• 管理属性：状态（草稿/评审中/已批准/已实现/已验证）、优先级（高/中/低或MoSCoW）、责任人、评审人。
• 技术属性：需求来源（客户/法规/内部）、验证方法（测试/分析/演示/检查）、风险等级（高/中/低）、稳定性（稳定/易变）。
• 追溯属性：父需求ID、子需求ID、关联设计元素、关联测试用例。

2.3.3 操作流程：在SysML中定义需求属性

在SysML需求图中，可以通过以下步骤定义需求属性：

1. 创建«requirement»块，在块定义图中定义属性（如 priority: PriorityType, risk: RiskLevel, verificationMethod: String）。
2. 为每个具体需求实例填充属性值。
3. 使用«verify»关系关联测试用例，确保每条需求都有验证手段。

// SysML 需求属性定义示例（文本表示）
requirement AEB_001 {
  id = "AEB-001";
  text = "系统应检测前方障碍物并触发制动";
  kind = "functional";
  priority = "High";
  risk = "Medium";
  verificationMethod = "Test";
  source = "Euro NCAP 2023";
  status = "Approved";
}

2.3.4 案例拆解：需求属性驱动的优先级决策

假设某OEM在开发一款纯电动SUV，共有1200条系统需求。项目经理希望优先实现与“安全”和“法规合规”相关的需求。通过查询需求属性，筛选出priority=High且source=“法规”的需求共85条，再结合risk等级，最终确定首批30条需求进入详细设计。这一过程完全基于属性数据，避免了主观判断的偏差。

2.4 常见误区与总结复盘

2.4.1 误区一：需求类型与层级混淆

初学者常将“功能需求”与“系统需求”混为一谈。实际上，功能需求是“横向分类”，系统需求是“纵向层级”。一个系统需求可以是功能性的，也可以是性能性的。例如“系统应实现AEB功能”既是功能需求，也是系统需求。正确做法是：先确定层级，再确定类型。

2.4.2 误区二：需求属性缺失导致追溯断裂

很多项目在初期不重视属性定义，导致后期无法回答“这条需求为什么存在”“如何验证”等问题。例如，一条需求没有关联验证方法，测试团队只能凭经验设计测试用例，可能遗漏关键场景。建议在需求创建时强制填写“验证方法”和“来源”属性。

2.4.3 误区三：需求分解粒度不统一

有的团队将系统需求分解到很细的组件级，而有的团队只分解到子系统级，导致需求树不平衡。建议以“可验证性”为粒度标准——每条需求都应能被某个测试用例或分析方法验证。如果一条需求无法验证，说明粒度太粗；如果一条需求需要多个测试用例才能覆盖，说明粒度太细。

2.4.4 总结复盘

本章的核心要点可归纳为：需求类型解决“关注什么”，需求层级解决“在哪一层”，需求属性解决“如何管理”。在SysML中，三者通过需求图统一表达，形成完整的需求模型。实际项目中，建议每周进行一次需求评审，检查需求类型是否齐全、层级是否完整、属性是否准确。只有将需求工程基础打牢，后续的架构设计、仿真验证和测试活动才能高效开展。