第二章：需求管理工具搭建——DOORS与Jama的实战配置

说实话，做预期功能安全（SOTIF）这么多年，我踩过最大的坑就是需求管理混乱。你想想看，一个自动驾驶系统动辄上千条安全需求，要是没有一套趁手的工具来管，那简直就是灾难。今天我就把我在DOORS和Jama上积累的经验，掰开了揉碎了讲给你听。

2.1 工具选型：DOORS还是Jama？

先说说我的个人习惯。DOORS是老牌劲旅，在传统汽车电子领域根深蒂固。Jama呢，是后起之秀，界面更现代，协作功能更强。怎么选？我建议你看团队规模。

• 团队小于20人：Jama更合适。部署快，学习成本低。
• 团队大于50人：DOORS更稳妥。权限管理细，历史追踪强。
• 介于之间：看客户要求。很多OEM指定用DOORS。

2.2 DOORS安装与配置要点

DOORS安装其实不复杂，但有几个坑你得注意。我在项目中遇到过好几次因为配置不当导致性能崩盘的情况。

2.2.1 安装前准备

# 系统要求（以DOORS 9.7为例）
操作系统：Windows Server 2016/2019 或 Windows 10 Pro
内存：至少16GB（我建议32GB）
硬盘：SSD，剩余空间50GB以上
数据库：DOORS自带Derby或外接Oracle/SQL Server

2.2.2 核心配置步骤

1. 数据库配置：我建议用Oracle，稳定。Derby适合单机测试。
2. 用户权限设置：分三级——管理员、编辑者、只读用户。
3. 模块模板创建：提前定义好属性字段，比如“需求ID”、“安全等级”、“验证状态”。
4. 基线管理：每周自动创建基线，方便回溯。

2.3 Jama安装与配置实战

Jama安装比DOORS简单多了。说白了，它就是一套Web应用，部署在Tomcat上就行。

2.3.1 快速部署

# 使用Docker部署（我推荐这种方式）
docker run -d \
  --name jama \
  -p 8080:8080 \
  -v /data/jama:/var/lib/jama \
  -e JAMA_DB_URL=jdbc:postgresql://db:5432/jama \
  jamasoftware/jama:latest

你看，三行命令就搞定了。不过要注意，Jama对PostgreSQL版本有要求，我用的是12.5版本，稳定运行了两年没出过问题。

2.3.2 配置要点

• 项目结构：按功能域划分，比如“感知”、“决策”、“控制”。
• 字段自定义：添加“ASIL等级”、“验证方法”、“责任人”。
• 工作流设置：需求状态从“草稿”→“评审中”→“已批准”→“已实现”→“已验证”。

2.4 需求结构化方法

工具装好了，接下来就是重头戏——怎么把需求写得清清楚楚。我见过太多人把需求写成散文，那叫一个乱。

2.4.1 需求结构三要素

要素	说明	示例
唯一标识	每个需求有独立ID	SOTIF-REQ-001
层级关系	父需求→子需求→子子需求	系统需求→功能需求→技术需求
属性标签	安全等级、验证状态等	ASIL B, 已批准

2.4.2 我的结构化模板

# 需求模板示例
## 需求ID: SOTIF-REQ-0042
## 标题: 前向碰撞预警触发条件
## 层级: 功能需求
## 父需求: SOTIF-REQ-0010 (前向碰撞预警功能)
## 描述: 
   当自车速度 > 30km/h 且 
   目标车辆相对速度 > 15km/h 且 
   TTC < 2.5s 时，
   系统应在 200ms 内发出视觉和听觉报警。
## 属性:
   - ASIL等级: B
   - 验证方法: 仿真测试 + 实车测试
   - 状态: 已批准
   - 责任人: 张三

你想想看，这样的需求，谁看了都明白。测试工程师拿到手就能直接写用例。

2.5 需求追溯矩阵建立

追溯矩阵，说白了就是一张大表，告诉你每条需求从哪来、到哪去。ISO 26262和SOTIF标准都明确要求这个。

2.5.1 矩阵结构

需求ID	来源	设计实现	测试用例	验证结果
SOTIF-REQ-0042	ISO 21448 §5.3.2	FCW算法模块 v2.1	TC-FCW-001 ~ 010	通过
SOTIF-REQ-0043	系统架构文档 §3.2	传感器融合模块 v1.5	TC-FUS-005 ~ 008	部分通过

2.5.2 在DOORS中建立追溯

// DOORS DXL脚本示例：自动建立追溯链接
Link createLink(srcModule, "SOTIF-REQ-0042", 
                tgtModule, "TC-FCW-001", 
                "验证关系")
// 这样一条命令，就把需求和测试用例绑在一起了

2.6 知识体系总览

下面这张图，是我做这个章节时画的。它把需求管理工具搭建的核心逻辑串起来了。

这张图你看懂了吗？从上到下，就是咱们搭建工具链的完整路径。先选工具，再安装配置，最后做结构化和追溯。每一步都不能少。

2.7 避坑总结

最后，我把自己这些年踩过的坑总结一下，你记好了：

• 别贪多：一开始别想着把所有需求都塞进去。先做核心安全需求，再慢慢扩展。
• 命名规范：需求ID的命名规则一定要提前定好。我见过有人用“REQ-001”、“REQ-002”这种，后来需求一多，根本分不清谁是谁。
• 定期备份：DOORS的数据库每周备份一次。我曾经有个同事，不小心删了整个模块，还好有备份，不然就完蛋了。
• 培训跟上：工具再好，人不会用也是白搭。我建议每个新项目开始前，花半天时间做工具培训。