4、需求管理：使用Jira管理ADAS系统需求（如AEB、LKA），需求层级与关联
做ADAS开发这几年，我最大的感触就是——需求管理做不好，后面全是坑。你想想看，一个AEB功能，从系统级到软件级再到硬件级，层层分解下去，如果没有一套工具把这些关系理清楚，那开发过程中肯定会出现各种对不上的情况。
我个人习惯用Jira来管ADAS需求。为什么？因为它能很好地解决需求层级和关联的问题。今天我就把这块的经验掰开了揉碎了讲给你听。
4.1 ADAS需求的层级结构
先说说ADAS需求长什么样。以AEB（自动紧急制动）为例，需求通常分这么几层：
- 系统需求：整车层面的功能定义，比如“车辆在30km/h时速下能识别前方静止车辆并触发制动”
- 子系统需求：分配给感知、决策、执行等子系统的需求，比如“感知子系统需在100ms内输出目标物距离和速度”
- 软件需求：具体到某个模块或算法的需求，比如“AEB算法模块需支持TTC（碰撞时间）计算，阈值设为2.6秒”
- 硬件需求：对传感器、控制器等硬件的约束，比如“前向毫米波雷达探测距离需≥150米”
我在项目中遇到过一种情况：系统需求写得很漂亮，但分解到软件层时发现根本实现不了。为什么？因为硬件能力跟不上。所以需求层级之间必须建立清晰的关联关系，这样一旦某个底层需求变更，上层能立刻感知到影响。
4.2 在Jira中建立需求层级
Jira里怎么建这个层级？我推荐用“Epic - Story - Sub-task”这套结构来映射：
| Jira层级 | 对应ADAS需求层级 | 示例 |
|---|---|---|
| Epic | 系统需求 | AEB系统需求：实现自动紧急制动功能 |
| Story | 子系统/软件需求 | 感知子系统：输出目标物列表，更新频率≥20Hz |
| Sub-task | 详细设计/实现任务 | 实现TTC计算模块，单元测试覆盖率达到90% |
嗯，这里要注意：不是所有需求都要拆到Sub-task。我个人习惯是，Story这一层就够细了，Sub-task更多是开发任务而非需求本身。
4.3 需求关联：用Jira的“链接”功能
光有层级还不够，需求之间还有各种横向关联。比如LKA（车道保持辅助）的某个软件需求，可能同时依赖感知模块和转向控制模块的需求。
Jira提供了几种链接类型，我常用的有：
- “is decomposed into”：父需求分解为子需求，用于上下层级
- “relates to”：两个需求有关联，但不属于父子关系
- “depends on”：一个需求依赖另一个需求先完成
- “is tested by”：需求关联到对应的测试用例
举个例子，我在做LKA项目时，有个需求是“车道线识别准确率≥95%”。这个需求同时关联了“摄像头标定需求”和“图像处理算法需求”。我用“relates to”把它们连起来，这样任何一方变更，相关方都能收到通知。
关键点：需求关联不是摆设，它是影响分析的基础。我曾经因为漏掉一个关联关系，导致AEB的制动策略改了，但感知模块的接口没同步更新，结果联调时出了大问题。
4.4 实战：在Jira中创建AEB需求树
下面我带你走一遍实际操作。假设我们要创建一个AEB系统需求树：
步骤1：创建Epic
项目：ADAS_Platform
问题类型：Epic
摘要：AEB系统需求 - 自动紧急制动功能
描述：车辆在5-80km/h时速范围内，能识别前方静止/运动车辆及行人，并自动触发制动以避免或减轻碰撞。步骤2：创建子需求Story
问题类型：Story
父级：AEB系统需求（Epic）
摘要：感知子系统 - 目标物检测与跟踪
描述：感知子系统需在100ms内输出前方目标物列表，包含距离、速度、加速度、类型（车辆/行人/自行车）等信息。
链接：relates to 摄像头标定需求步骤3：添加验收标准
每个Story我都习惯加上验收标准，用Jira的Checklist插件或者直接在描述里写：
验收标准：
- [ ] 目标物检测距离≥150米（车辆），≥60米（行人）
- [ ] 目标物输出频率≥20Hz
- [ ] 目标物分类准确率≥95%
- [ ] 漏检率≤2%（在标准测试场景下）小技巧：我建议在Jira中给需求加上“需求类型”自定义字段，比如“功能需求”、“性能需求”、“安全需求”、“接口需求”。这样筛选和统计时特别方便，一眼就能看出哪些是安全相关的关键需求。
4.5 需求变更管理
做ADAS开发，需求变更是家常便饭。我记得有一次，客户突然要求把AEB的触发速度上限从80km/h提高到100km/h。这个变更看似简单，但影响面很大——感知距离、制动执行器响应时间、甚至控制器的算力都可能需要重新评估。
在Jira中处理需求变更，我遵循这几个原则：
- 变更必须走审批流程：用Jira的工作流控制，不能直接改需求内容
- 变更影响分析：通过需求关联关系，列出所有受影响的下游需求和任务
- 版本控制：保留需求的历史版本，方便追溯
- 通知相关方：Jira会自动通知所有关注该需求的成员
避坑指南：我曾经犯过一个错误——为了赶进度，直接在生产环境的需求上改了内容，没有走变更流程。结果测试团队拿着旧版本的需求做验证，发现对不上，白白浪费了两天时间。从那以后，我严格规定：需求变更必须新建一个变更请求Issue，审批通过后再更新原需求。
4.6 需求追踪矩阵
最后说说需求追踪矩阵。ISO 26262和ASPICE都要求做需求追溯，说白了就是要能回答“这个代码对应哪个需求”、“这个需求有没有被测试覆盖”。
在Jira里，我通常用两种方式实现：
- Jira的“Issue链接”：把需求、设计、代码、测试用例全部用链接串起来
- 外部工具集成：比如用Jira+TestRail或者Jira+Enterprise Architect，自动同步关联关系
我个人更推荐第一种，因为简单直接，团队成员不需要学习额外工具。你只需要在创建测试用例时，用“is tested by”链接到对应的需求Story就行。
举个例子：
需求Story：AEB-123 感知子系统目标物检测
↓ is tested by
测试用例：TC-AEB-001 前方静止车辆检测测试
↓ is tested by
测试用例：TC-AEB-002 前方运动车辆检测测试
↓ relates to
代码模块：perception_object_detection.cpp这样，当你点击任何一个需求，都能看到它被哪些测试用例覆盖，对应哪些代码模块。做影响分析时，一查一个准。
好了，关于用Jira管理ADAS需求，核心就是这几块：层级结构、关联关系、变更流程、追溯矩阵。你把这些搞明白了，需求管理这块基本就稳了。下一章我们聊聊怎么用Jira管理ADAS的测试用例和验证活动，那个也很有意思。