第3章：需求管理工具配置：DOORS / Polarion 的安装与项目初始化、需求属性模板设置
好，咱们直接进入正题。需求管理工具，说白了就是功能安全开发的“地基”。你想想看，ISO 26262 从头到尾都在强调“需求可追溯”，没有一套趁手的工具，光靠 Excel 和 Word 去维护几百上千条安全需求，那简直是给自己挖坑。
我个人习惯用 DOORS 和 Polarion。这两款工具在汽车电子圈里占有率很高。DOORS 是老牌劲旅，稳定、严谨，但界面嘛...嗯，有点复古。Polarion 则更现代，Web 化做得不错，适合分布式团队。今天我就把这两款工具的安装要点、项目初始化流程，以及最关键的——需求属性模板设置，掰开了讲清楚。
3.1 DOORS 安装与项目初始化
先聊 DOORS。我记得第一次装 DOORS 时，差点被它的许可证机制搞疯。这里给你几个关键点：
- 数据库选择：DOORS 依赖一个中央数据库（通常是 Oracle 或 SQL Server）。千万别图省事用默认的本地数据库，团队协作时你会哭的。我在项目中遇到过因为数据库连接池配置太小，导致多人同时编辑需求时频繁锁表的情况。建议把连接池上限调到 50 以上。
- 客户端安装：每个工程师的机器上都要装 DOORS 客户端。注意，9.6 及以上版本对 Java 环境有要求，JDK 11 是标配。我曾经见过有人装了 JDK 17，结果 DOORS 直接打不开，报了个莫名其妙的 DXL 错误。
- 项目初始化：安装完后，第一件事是创建项目模块。在 DOORS 里，一个“项目”其实是一个文件夹，下面可以挂多个“模块”。每个模块对应一个需求文档。我个人习惯这样建：
项目名称: ASIL_D_BCM_Project
├── 01_安全目标 (Safety Goals)
├── 02_功能安全需求 (FSR)
├── 03_技术安全需求 (TSR)
├── 04_硬件安全需求 (HSR)
└── 05_软件安全需求 (SSR)
为什么要这么分？因为 ISO 26262 要求不同层级的需求要独立管理，方便做 Impact Analysis。你想想看，如果所有需求都塞在一个模块里，后期变更影响分析时，光筛选就要花半天。
3.2 Polarion 安装与项目初始化
再说 Polarion。这玩意儿比 DOORS 友好多了，毕竟是 Web 端的。安装时注意两点：
- 部署方式：Polarion 本质上是一个 Java Web 应用，跑在 Tomcat 上。建议用 Linux 服务器部署，Windows Server 也能跑，但性能会打折扣。我建议至少给 Polarion 分配 8GB 内存，否则项目一多，查询速度会让你抓狂。
- 项目模板：Polarion 自带了很多模板，比如“ASPICE”、“ISO 26262”。但别直接用！那些模板太通用，缺少很多实际工程需要的字段。我通常的做法是：基于“ISO 26262”模板复制一份，然后自定义。
项目初始化时，我会在 Polarion 里创建一个“Project Group”，然后按功能域划分子项目。举个例子：
Project Group: 智能驾驶域控
├── 01_感知需求
├── 02_规划控制需求
├── 03_系统安全需求
└── 04_测试验证需求
每个子项目里，再按 ASIL 等级建立“Work Item”分类。这样后期做 ASIL 分解和剪裁时，一目了然。
3.3 需求属性模板设置（核心）
好，到了最关键的部分。工具装好了，项目建起来了，但如果没有一套标准化的需求属性模板，那跟用 Excel 没啥区别。功能安全开发中，每条需求都必须携带足够的“元数据”，才能支撑后续的追溯、评审、变更管理。
我个人习惯，无论是 DOORS 还是 Polarion，需求属性模板至少要包含以下几类：
| 属性类别 | 属性名称 | 说明 | 示例值 |
|---|---|---|---|
| 标识信息 | 需求ID | 全局唯一编号，自动生成 | REQ_BCM_00123 |
| 标识信息 | 需求标题 | 简短描述，50字以内 | BCM 应检测大灯开路故障 |
| 安全属性 | ASIL等级 | QM / A / B / C / D | ASIL B |
| 安全属性 | 安全状态 | 故障发生时系统应进入的状态 | 大灯关闭，点亮仪表报警灯 |
| 安全属性 | FTTI（容错时间间隔） | 从故障发生到安全状态的时间 | ≤ 100ms |
| 追溯信息 | 上级需求 | 链接到父级需求（如安全目标） | SG_BCM_001 |
| 追溯信息 | 实现方式 | 软件/硬件/系统 | 软件 |
| 状态管理 | 需求状态 | 草稿 / 评审中 / 已批准 / 已实现 / 已验证 | 已批准 |
| 状态管理 | 变更历史 | 记录每次变更的版本和原因 | V1.2: 修改FTTI从150ms改为100ms |
3.4 在 DOORS 中配置属性模板
DOORS 里配置属性模板，是通过修改模块的“Attribute Types”来实现的。具体步骤：
- 打开模块，进入 Tools > Manage Attributes。
- 点击 New，创建自定义属性。比如“ASIL_Level”，类型选“Enumeration”，然后填入 QM、A、B、C、D。
- 对于“上级需求”这种链接属性，类型选“Object Link”，然后指定链接模块。
- 设置属性的默认值。比如“需求状态”默认设为“草稿”。
- 最后，通过 DXL 脚本批量应用模板到所有模块。
这里分享一个我常用的 DXL 片段，用于批量创建属性：
// 批量创建需求属性模板
Module m = current
AttributeType at
at = create("ASIL_Level", "Enumeration", m)
at.enumerationAdd("QM")
at.enumerationAdd("A")
at.enumerationAdd("B")
at.enumerationAdd("C")
at.enumerationAdd("D")
at = create("Safety_State", "String", m)
at.defaultValue = "TBD"
at = create("Req_Status", "Enumeration", m)
at.enumerationAdd("Draft")
at.enumerationAdd("Review")
at.enumerationAdd("Approved")
at.defaultValue = "Draft"
3.5 在 Polarion 中配置属性模板
Polarion 的配置更直观，毕竟有 Web 界面。步骤如下：
- 进入 Administration > Work Items > Types。
- 选择“Requirement”类型，点击 Custom Fields。
- 添加字段，比如“ASIL_Level”，类型选“Enum”，填入选项。
- 在 Layout 里，拖拽字段到表单的合适位置。我习惯把安全属性放在表单顶部，这样工程师打开需求第一眼就能看到。
- 设置字段的“Required”属性。比如“ASIL_Level”设为必填，如果用户没选，保存时会报错。
Polarion 还有一个强大的功能——Enumeration Dependencies。比如，当 ASIL 等级选为“QM”时，“安全状态”字段自动隐藏或置灰。这个功能在 DOORS 里需要写 DXL 脚本才能实现，Polarion 直接点几下鼠标就行。
3.6 避坑指南与个人经验
最后，聊几个我踩过的坑：
- 属性命名规范：团队内部一定要统一命名。比如“ASIL等级”还是“ASIL_Level”？“安全状态”还是“Safety_State”？我建议全用英文，因为 DOORS 的 DXL 脚本和 Polarion 的 REST API 对中文支持都不太好。
- 不要过度定制：我见过一个团队，给需求加了“创建人邮箱”、“最后修改时间戳”、“评审人部门”等十几个字段。结果呢？没人填，最后全成了垃圾数据。记住，属性模板是为流程服务的，不是为展示“我们很专业”服务的。
- 定期审计属性完整性：每个月跑一次脚本，检查所有需求的必填属性是否都有值。在 DOORS 里可以用 DXL 写个报告，在 Polarion 里直接用“Report”功能生成。我习惯在项目例会上展示这个报告，谁的需求没填全，一目了然。
嗯，关于需求管理工具的安装、项目初始化和属性模板设置，核心内容就这些。你想想看，工具只是载体，真正重要的是你定义的那套属性模板，它决定了你的需求能不能被有效追溯和管理。下一章，我会讲如何建立需求之间的追溯矩阵，那才是功能安全开发的“灵魂”。