第4章需求管理工具配置

第4章：需求管理工具配置——以DOORS或Jama为例

好，咱们进入正题。需求管理工具，说白了就是给需求安个家。我见过太多项目，需求散落在Word文档、邮件、甚至微信群聊天记录里……那场面，简直是一场噩梦。今天我就拿DOORS和Jama这两个主流工具，讲讲怎么把需求结构、属性、链接和追溯矩阵搭起来。

4.1 需求结构怎么搭？

我个人习惯，先搭骨架，再填肉。需求结构就像一棵树，得有根、有干、有枝。

DOORS里的模块化结构

DOORS里，每个需求模块就是一个独立的数据库对象。我一般这样分：

系统需求模块：放顶层系统级需求
软件需求模块：放软件层面的需求
硬件需求模块：放硬件相关的需求
测试用例模块：放对应的测试用例

每个模块内部，再用文件夹（Formal Module）做层级划分。比如软件需求模块下，可以分「功能需求」、「非功能需求」、「接口需求」这几个子文件夹。

重要提醒：千万别把所有需求塞进一个模块。我在项目中遇到过，有人图省事，一个模块里塞了3000多条需求，结果查询慢得像蜗牛，追溯矩阵根本跑不动。

Jama里的层次结构

Jama用的是「项目-集合-文档-条目」的四层结构。我建议这样配：

项目层：对应一个整车项目或平台项目
集合层：按系统、软件、硬件、测试来分
文档层：每个集合下放具体的需求文档
条目层：就是每一条需求本身

举个例子，一个ADAS项目，Jama结构可以这样：

ADAS项目
├── 系统需求集合
│   ├── 功能需求文档
│   ├── 性能需求文档
│   └── 安全需求文档
├── 软件需求集合
│   ├── 感知模块需求
│   ├── 决策模块需求
│   └── 控制模块需求
└── 测试用例集合
    ├── 功能测试用例
    └── 集成测试用例

4.2 属性配置——给需求贴上标签

属性是什么？说白了就是需求的「身份证信息」。每条需求除了正文，还得有各种元数据。

我常用的属性清单

属性名	类型	说明
需求ID	自动生成	唯一标识，DOORS用对象编号，Jama用条目ID
需求类型	枚举	功能/性能/接口/安全/约束
优先级	枚举	高/中/低
状态	枚举	草稿/评审中/已批准/已变更/已废弃
来源	文本	客户需求/法规标准/内部定义
版本	数字	需求版本号，用于基线管理
责任人	用户	谁负责这条需求的实现

我的小技巧：在DOORS里，我会给「状态」属性加一个颜色编码。比如已批准用绿色，已变更用黄色，已废弃用灰色。这样一眼扫过去，就知道哪些需求是「活的」，哪些是「死的」。

Jama里的属性配置

Jama的属性配置更灵活，支持自定义字段。我一般会加一个「ASIL等级」属性，因为做功能安全时，这个太重要了。配置路径是：管理 → 字段配置 → 添加自定义字段。

// 在Jama中配置ASIL等级属性
字段名称：ASIL等级
字段类型：下拉列表
选项：QM, ASIL A, ASIL B, ASIL C, ASIL D
默认值：QM
是否必填：是

4.3 链接与追溯——让需求「手拉手」

追溯矩阵，说白了就是搞清楚「谁跟谁有关系」。没有链接的需求，就像断了线的风筝，飞哪去都不知道。

DOORS里的链接类型

DOORS支持多种链接类型，我常用的有：

「源自」链接：从系统需求指向软件需求，表示「这条软件需求源自那条系统需求」
「实现」链接：从需求指向设计元素，表示「这个设计实现了那条需求」
「验证」链接：从需求指向测试用例，表示「这个测试用例验证了那条需求」
「派生」链接：从一条需求指向另一条需求，表示「这条需求是从那条需求派生出来的」

配置链接模块的步骤

在DOORS中创建链接模块（Link Module）
定义链接类型（比如上面那四种）
设置链接方向（单向还是双向）
配置链接属性（比如链接的创建时间、创建人）

避坑指南：我曾经犯过一个错——把所有链接都设成双向。结果追溯矩阵跑出来，密密麻麻全是线，根本看不清。后来我改成：系统→软件用单向，软件→测试用单向，只有同层级的需求之间才用双向。清晰多了。

Jama里的追溯配置

Jama的追溯更直观，直接在条目之间拖拽就能建立链接。我一般这样配：

在系统需求条目上，点击「添加关联」
选择关联类型（比如「实现」、「验证」、「派生」）
搜索并选择目标条目
保存

Jama还支持「批量追溯」，这个功能很实用。比如你有100条系统需求，需要全部链接到对应的软件需求，可以这样操作：

1. 在系统需求集合中，选中所有需要追溯的需求
2. 点击「批量操作」→「创建追溯」
3. 选择目标集合（软件需求集合）
4. 系统自动匹配同名的需求（基于需求ID或标题）
5. 确认后批量创建链接

4.4 追溯矩阵的生成与解读

追溯矩阵，是ASPICE审核时的「必查项」。审核员一看矩阵，就知道你的需求管理做得怎么样。

DOORS里的追溯矩阵

DOORS的追溯矩阵功能在「分析」菜单下。我一般这样生成：

打开系统需求模块
点击「分析」→「追溯矩阵」
选择源模块（系统需求）和目标模块（软件需求）
选择链接类型（比如「源自」）
点击生成

生成的矩阵长这样：

系统需求ID	系统需求标题	软件需求ID	软件需求标题	链接类型
SYS-001	车辆应能在3秒内从0加速到60km/h	SW-001	加速控制算法应支持目标加速度计算	源自
SYS-002	制动距离应小于40米（60km/h时）	SW-002	制动控制模块应计算目标制动压力	源自
SYS-003	系统应支持OTA升级	—	未追溯	缺失

注意看第三行：SYS-003没有对应的软件需求，这就是「追溯缺失」。审核员看到这个，一定会问：「这条系统需求谁来实现？」所以每次生成矩阵后，我第一件事就是找那些「未追溯」的条目。

Jama里的追溯视图

Jama的追溯视图更可视化，像一张网络图。我一般用「追溯树」视图：

选中一条系统需求
点击「追溯」选项卡
选择「树形视图」
系统会展示：这条需求 → 对应的软件需求 → 对应的设计元素 → 对应的测试用例

嗯，这里要注意：Jama的追溯树默认只显示三层。如果你需要更深层的追溯，得在设置里调整「追溯深度」参数。我一般设成5层，够用了。

4.5 我的配置心得

做了这么多年，我总结了几条铁律：

结构先行：先搭好模块和文件夹结构，再往里填需求。别边填边改结构，会乱。
属性标准化：整个团队用同一套属性定义。我见过一个项目，有人用「优先级」，有人用「重要程度」，还有人用「P1/P2/P3」……那追溯矩阵根本没法看。
链接要克制：不是所有需求之间都需要链接。只链接那些有直接追溯关系的。链接太多，矩阵就成了蜘蛛网。
定期检查追溯完整性：我每周五下午都会跑一次追溯矩阵，看看有没有「孤儿需求」（没有链接的需求）或者「断链」（链接指向了已删除的条目）。

最后分享一个实用技巧：在DOORS里，你可以用DXL脚本自动检查追溯完整性。比如写一个脚本，扫描所有系统需求，找出那些没有「源自」链接到软件需求的条目，然后自动生成报告。这样就不用人工一个个查了。

好了，需求管理工具的配置就讲到这里。下一章，咱们聊聊配置管理工具——Git和SVN在ASPICE流程里该怎么用。到时候我会讲讲怎么用分支策略来管理基线，那可是个有意思的话题。

📚 课程目录