4. 需求到Stateflow模型的追溯建立

在Stateflow模型开发中，追溯关系不是建模完成后补做的文档工作，而是从需求分解阶段就要同步建立的工程结构。本节讨论的核心问题是：一条系统需求如何逐层分解为软件需求，再落到Stateflow中的具体状态、迁移、条件动作和数据对象，并通过需求链接、注释和模型属性三种手段把这条链路固化在模型里。

一、需求分解的三个层级

需求到Stateflow元素的追溯，本质上是把自然语言描述的功能约束，映射为可执行的状态机语义。这个过程通常跨越三个层级：

• 系统需求层：描述整车或子系统级功能，例如“当车速大于30km/h且驾驶员未踩制动踏板时，巡航控制应保持激活状态”。这一层通常由系统工程师维护，标识符形如SYS_CC_001。
• 软件需求层：把系统需求细化为软件可实现的行为约束，例如“巡航控制状态机应包含Off、Standby、Active、Fault四个状态；从Standby进入Active的条件为Set按钮按下且车速在30~180km/h之间”。标识符形如SW_CC_012。
• Stateflow元素层：软件需求进一步落到具体状态、迁移、条件表达式、入口/出口动作和数据对象上。例如状态Active对应SW_CC_012，迁移Standby→Active的守卫条件[SetBtn && speed>=30 && speed<=180]也对应同一条需求。

分解的关键原则是：一条软件需求可以对应多个Stateflow元素，但每个Stateflow元素必须至少追溯到一条软件需求。不允许出现“无主”的状态或迁移，否则覆盖率分析和变更影响分析都会失去依据。

二、需求链接的建立方式

在Simulink/Stateflow环境中，需求链接通过Requirements Toolbox实现。典型操作路径是：在Requirements Editor中导入需求文档（如DOORS、Excel或ReqIF），然后在Stateflow编辑器中选中目标元素，右键选择“Requirements”→“Link to Requirement”，建立可导航的双向链接。

链接建立后，模型元素上会出现需求标记图标，点击即可跳转到对应需求条目。对于状态机，建议按以下粒度建立链接：

需要注意的是，链接不是越多越好。如果一条需求被链接到十几个元素上，反而会降低可读性。建议在软件需求层就把需求拆到“单一行为”粒度，使每条需求对应1~3个Stateflow元素。

三、注释与模型属性的辅助追溯

需求链接解决的是“可导航”问题，但链接本身在模型画布上不可见。为了让追溯关系在阅读模型时一目了然，需要配合注释和模型属性。

注释（Annotation）用于在Stateflow画布上直接标注需求编号和关键约束。例如在Active状态旁放置注释框，内容为“SW_CC_012: 巡航激活状态，车速30~180km/h”。注释不参与仿真，但能显著提升模型评审效率。建议注释格式统一为“需求ID: 简要描述”，避免写入完整需求文本导致画布拥挤。

模型属性（Model Properties）用于记录追溯元数据。在Stateflow的Model Properties→Description中，可以写入需求文档版本、追溯矩阵链接、变更记录等。对于每个状态，还可以在状态属性中填写“Documentation”字段，把该状态对应的需求ID和验收条件写进去。这些属性会随模型一起保存，在生成报告时可以被自动提取。

四、分解与追溯的完整链路

下面这张图展示了一条系统需求如何逐层分解并建立追溯关系。图中左侧是需求层级，右侧是Stateflow元素层级，中间的连线表示追溯链接的建立位置。

五、初始追溯的检查与验证

建立完初始追溯后，需要做一次完整性检查。在Requirements Toolbox中可以使用“Traceability Matrix”视图，查看所有软件需求是否都有对应的Stateflow元素链接，以及是否存在未被链接的模型元素。典型的检查项包括：

• 每条软件需求是否至少有一个Stateflow元素链接；
• 每个状态和迁移是否至少链接到一条软件需求；
• 注释中的需求ID是否与链接记录一致；
• 模型属性的Documentation字段是否填写完整；
• 需求变更后，链接是否仍然有效（可通过“Validate Links”功能检查）。

如果发现某条软件需求没有对应元素，说明分解不完整；如果发现某个状态没有链接，说明该状态可能是实现细节而非需求驱动，需要确认是否应该补充需求或删除该状态。这个检查过程在项目早期可能只需要几分钟，但能避免后期覆盖率分析时出现大量“无需求依据”的模型元素。

最后需要强调的是，追溯关系是双向的。从需求可以导航到模型元素，从模型元素也可以反查需求。这种双向性使得需求变更影响分析成为可能：当SW_CC_013的阈值从180改为150时，通过链接可以立即定位到受影响的迁移和参数对象，从而评估修改范围。这正是需求追溯在Stateflow工程中的核心价值。