2. 需求追溯基础
在 Stateflow 模型开发中，需求追溯不是“把需求文档和模型放在同一个文件夹里”这么简单。它要解决的核心问题是：当一条需求发生变更时，能否快速定位到受影响的 Stateflow 元素；当模型覆盖率出现缺口时，能否反向说明是哪条需求没有被充分验证。这要求需求条目与模型元素之间建立可查询、可维护、可验证的显式链接。本节围绕需求标识、需求层级、追溯链、双向追溯和追溯矩阵五个核心概念展开，并给出 Stateflow 元素与需求条目的映射方法。
需求标识：追溯的唯一锚点
需求标识（Requirement ID）是追溯链的起点。它必须满足三个条件：唯一、稳定、可引用。唯一意味着在整个项目范围内不重复；稳定意味着需求内容修订时 ID 不随之改变；可引用意味着模型、测试用例、评审记录都能用同一个 ID 指向它。
常见的标识方案是“层级前缀 + 序号”，例如 REQ-BMS-CHG-012：REQ 表示需求，BMS 表示电池管理系统，CHG 表示充电功能域，012 是域内序号。这种结构让 ID 本身携带层级信息，便于按域筛选和批量追溯。需要强调的是，ID 一旦发布就不应复用；需求作废时应标记为 Obsolete 而非删除，否则历史追溯链会断裂。
需求层级：从整车到状态机
需求通常不是平铺的，而是分层分解的。以充电功能为例，可以划分为四层：
- 整车级需求：车辆应支持交流慢充和直流快充两种模式。
- 系统级需求：BMS 应在充电枪连接后 200 ms 内完成握手信号检测。
- 软件级需求：充电状态机应在
Handshake状态停留不超过 5 s，超时进入Fault。 - 模型级需求：Stateflow 中
ChargingSM图的Handshake状态需配置after(5, sec)超时迁移。
层级分解的关键在于每层需求都能向上追溯到父需求，向下分解到子需求。上层需求回答“做什么”，下层需求回答“怎么做”。Stateflow 模型通常对应软件级和模型级需求，但追溯链必须一直向上打通到系统级甚至整车级，否则无法评估需求变更的完整影响范围。
追溯链与双向追溯
追溯链（Traceability Chain）是需求条目之间、需求与模型元素之间、需求与测试用例之间的有向连接。单向追溯只能回答“这条需求被哪些模型元素实现”，而双向追溯还要回答“这个模型元素为什么存在”。
双向追溯包含两个方向：
- 正向追溯（Forward）：需求 → 设计 → Stateflow 元素 → 测试用例 → 覆盖率结果。用于确认需求已被实现和验证。
- 反向追溯（Backward）：覆盖率缺口 → 测试用例 → Stateflow 元素 → 设计 → 需求。用于确认每个模型元素都有需求依据，没有“孤儿逻辑”。
Stateflow 元素与需求条目的映射关系
Stateflow 的层次结构与需求层级有天然的对应关系，但并非一一对应。实际工程中，一条需求可能映射到多个模型元素，一个模型元素也可能服务多条需求。常见的映射粒度如下：
| Stateflow 元素 | 典型映射需求类型 | 追溯关注点 |
|---|---|---|
| Chart（图） | 软件级功能需求 | 图是否覆盖该功能的全部模式 |
| State（状态） | 工作模式、故障模式需求 | 状态是否存在需求依据 |
| Transition（迁移） | 切换条件、时序约束需求 | 迁移条件是否可追溯到参数需求 |
| Entry/During/Exit Action | 动作、输出、计算需求 | 动作是否完整实现需求描述 |
| Junction（连接节点） | 条件分支、优先级需求 | 分支逻辑是否与需求判断一致 |
| Simulink Function / Graphical Function | 算法、接口需求 | 函数输入输出是否满足接口需求 |
映射时建议采用“需求 ID 标注 + 追溯矩阵记录”双轨方式。在 Stateflow 中，可以通过状态或迁移的描述字段写入需求 ID，例如在 Handshake 状态的描述中填写 [REQ-BMS-CHG-012]；同时在外部追溯矩阵中维护结构化记录。这样既能在模型内部快速定位，又能在需求管理工具中批量查询。
追溯矩阵：结构化查询的核心工具
追溯矩阵（Traceability Matrix）是双向追溯的落地载体。它以表格形式记录需求与模型元素、测试用例之间的多对多关系。一个可用的最小矩阵应包含以下字段：
需求ID | 需求层级 | 需求描述摘要 | Stateflow元素路径 | 元素类型 | 测试用例ID | 覆盖率状态
REQ-BMS-CHG-012 | 软件级 | 握手超时5s进入故障 | ChargingSM/Handshake | State | TC-CHG-007 | 已覆盖
REQ-BMS-CHG-013 | 软件级 | 故障状态输出DTC | ChargingSM/Fault | State | TC-CHG-008 | 已覆盖
REQ-BMS-CHG-014 | 模型级 | 充电完成迁移条件 | ChargingSM/Charging->Complete | Transition | TC-CHG-009 | 未覆盖
矩阵的价值在于可查询和可审计。当需求 REQ-BMS-CHG-012 从 5 s 改为 3 s 时，通过矩阵可以立即定位到 ChargingSM/Handshake 状态和测试用例 TC-CHG-007，从而评估修改范围。当覆盖率报告显示 Charging->Complete 迁移未被覆盖时，反向查询矩阵可知它对应 REQ-BMS-CHG-014，进而判断是测试用例缺失还是需求本身需要调整。
落地要点与常见问题
建立追溯关系时，最容易出现的问题是映射粒度过粗。例如只把整张 Chart 映射到一条需求，导致覆盖率缺口无法定位到具体状态或迁移。建议至少细化到 State 和 Transition 级别，对关键动作和条件分支进一步细化到 Action 和 Junction。
另一个常见问题是追溯关系只建不维护。需求变更后模型元素路径可能改变，测试用例可能被替换，矩阵若不更新就会失效。工程上应把追溯矩阵纳入配置管理，并在每次需求基线发布、模型版本冻结、测试用例更新时同步刷新。对于 Stateflow 模型，可以在模型描述或状态描述中保留需求 ID 标注，作为矩阵之外的冗余校验手段。
总结来说，需求标识提供唯一锚点，需求层级提供分解路径，追溯链连接需求与模型，双向追溯保证正向实现和反向依据都成立，追溯矩阵则把这一切变成可查询、可审计的结构化数据。在 Stateflow 工程中，把 Chart、State、Transition、Action、Junction 等元素与需求条目建立明确映射，是后续覆盖率分析和需求变更影响评估的基础。