第2章需求管理工具搭建

第2章：需求管理工具搭建：基于DOORS/Polarion的需求结构设计、属性定义与追溯矩阵配置

好，咱们直接进入正题。需求管理工具，说白了就是整个ASPICE流程的「地基」。地基没打好，后面设计、测试、验证全得乱套。我见过太多项目，需求写得像散文，属性定义随心所欲，追溯矩阵一塌糊涂——最后评审时被审计师问得哑口无言。

今天咱们就聊聊，怎么用DOORS或者Polarion，把需求管理这块「硬骨头」啃下来。我个人习惯用Polarion多一些，但DOORS的老用户也别急，核心思路是通用的。

2.1 需求结构设计：别让需求「躺平」

你想想看，一个汽车项目，需求少则几百条，多则上万条。如果全塞在一个文件夹里，那跟没管理有什么区别？

我建议按「功能域-子系统-功能模块」三层来组织。举个例子：

项目根目录
├── 01_功能域_动力系统
│   ├── 01_子系统_发动机控制
│   │   ├── 01_功能模块_燃油喷射
│   │   ├── 02_功能模块_点火控制
│   │   └── 03_功能模块_怠速控制
│   └── 02_子系统_变速箱控制
│       ├── 01_功能模块_换挡逻辑
│       └── 02_功能模块_离合器控制
├── 02_功能域_底盘系统
│   ├── 01_子系统_制动控制
│   └── 02_子系统_转向控制
└── 03_功能域_车身系统
    ├── 01_子系统_车门控制
    └── 02_子系统_灯光控制

为什么要这么分？因为ASPICE要求需求有层级关系。高层需求（系统需求）要能分解到低层需求（软件需求、硬件需求）。你结构搭好了，追溯自然就清晰了。

我的小经验： 在Polarion里，我习惯用「工作包」来对应功能模块。每个工作包下再建需求条目。这样后期做变更影响分析时，一眼就能看出改了哪个模块。

2.2 属性定义：给需求贴上「标签」

光有结构还不够。每条需求还得有属性。属性是什么？就是需求的「身份证」。我见过最惨的项目，需求只有标题和描述，其他啥也没有。审计师问「这条需求的状态是什么？」「谁批准的？」「优先级多高？」——全答不上来。

我建议至少定义以下属性：

属性名	类型	说明	示例值
需求ID	自动生成	唯一标识，不可修改	REQ-00123
需求类型	枚举	区分功能/非功能/接口需求	功能需求
状态	枚举	草稿/评审中/已批准/已变更	已批准
优先级	枚举	高/中/低	高
来源	文本	客户需求/内部定义/法规	客户SOR
责任人	用户	谁负责这条需求	张三
批准人	用户	谁批准了这条需求	李四
版本	数字	需求版本号	1.2
创建日期	日期	自动记录	2024-01-15

注意： 属性别定义太多。我曾经有个项目，定义了30多个属性，结果没人填。最后审计时，一半属性是空的。记住：属性是给人用的，不是给审计师看的。够用就行。

2.3 追溯矩阵配置：把「孤岛」连起来

追溯矩阵，是ASPICE里最核心的东西之一。它要回答一个问题：你的需求是怎么一步步变成代码和测试用例的？

我习惯建立三层追溯：

客户需求 → 系统需求：证明客户要的东西，我们都考虑到了。
系统需求 → 软件/硬件需求：证明系统设计被正确分解了。
软件/硬件需求 → 测试用例：证明每条需求都被测试覆盖了。

在Polarion里配置追溯矩阵，其实很简单。你只需要在需求条目里添加「链接」字段，指向对应的上下游条目就行。但要注意：

双向追溯：从需求能查到测试，从测试也能查到需求。别只做单向的。
覆盖度检查：定期跑报告，看看有没有「孤儿需求」（没有测试覆盖的需求）和「孤儿测试」（没有对应需求的测试）。
变更影响分析：当一条需求变了，所有关联的测试用例都要重新评估。这个在工具里可以自动提醒。

我曾经踩过的坑： 有个项目，需求改了，但测试用例没更新。结果测试报告全绿，实际上功能已经变了。后来我强制要求：需求状态变更为「已变更」时，自动给所有关联的测试用例负责人发邮件。这才堵住了漏洞。

2.4 工具配置实战：Polarion 示例

嗯，这里我拿Polarion举个实际配置的例子。DOORS用户也别走，思路是一样的。

首先，在Polarion里创建一个「需求工作项」类型，配置好上面说的属性。然后：

1. 创建需求结构树（用文件夹和模块）
2. 为每个模块配置「链接角色」：
   - 上游：客户需求
   - 下游：测试用例
3. 创建「追溯矩阵」报表模板
4. 设置自动化规则：
   - 需求状态变更时，通知关联人员
   - 测试用例通过率低于100%时，需求状态自动变为「待验证」

配置好之后，你每天上班第一件事，就是打开追溯矩阵报表。看看有没有红色的「未覆盖」条目。如果有，赶紧处理。别等到项目后期再补，那时候成本就高了。

我的习惯： 每周五下午，我会花半小时跑一次「需求健康度检查」。看看哪些需求状态还是「草稿」，哪些需求没有测试覆盖。这个习惯帮我避免了好几次项目延期。

2.5 避坑指南

最后，分享几个我亲身经历的教训：

别用Excel当需求管理工具：Excel没有版本控制，没有追溯，没有权限管理。我见过用Excel管理需求的项目，最后版本混乱到谁也说不清哪个是最新的。
属性值别用自由文本：比如「状态」字段，一定要用下拉菜单。否则有人写「已完成」，有人写「完成」，有人写「Done」——统计时全乱套。
追溯别只做一层：有些团队只做了「系统需求→测试用例」的追溯，忽略了客户需求。结果客户问「我提的第5条需求你们实现了吗？」——答不上来。
工具只是工具，流程才是核心：DOORS也好，Polarion也好，都只是载体。真正重要的是你定义的需求管理流程。工具可以帮你自动化，但流程设计得靠人。

好了，这一章就聊到这儿。下一章咱们讲配置管理工具——Git和SVN在ASPICE里怎么用。到时候见。

📚 课程目录