第三章：需求管理与追溯——用PREEvision打通从需求到架构的任督二脉
需求管理这事儿，说起来简单，做起来全是坑。
我刚入行那会儿，团队还在用Excel管需求。每次版本迭代，光是对齐需求文档和系统架构就要花掉两周。后来上了PREEvision，才真正体会到什么叫「双向追溯」——说白了，就是让每个需求都能找到它的「家」，让每段架构都能说清「为什么」。
3.1 需求导入：别让格式成为第一道坎
客户给的需求，格式五花八门。Word、Excel、Reqtify、DOORS……我见过最离谱的，是直接把需求写在邮件正文里。
PREEvision支持多种导入方式。我个人最常用的是ReqIF格式，这是汽车行业的标准交换格式。如果你从DOORS或Reqtify导出，选ReqIF基本不会出错。
导入步骤（我习惯的流程）：
- 在PREEvision中创建需求包（Requirement Package）
- 右键选择「Import」→「ReqIF」
- 勾选「保持层级结构」——这个选项容易漏，但很重要
- 映射属性：比如「需求ID」「优先级」「来源」
- 确认导入，检查是否有未映射的字段
小技巧：导入前先在Excel里清理一遍数据。把合并单元格拆开，把空行删掉。你想想看，PREEvision再智能，也架不住源数据一团糟。我吃过这个亏，一次导入三千条需求，结果因为格式问题卡了半小时。
3.2 需求分解：从「客户想要」到「工程师能做」
客户说「我要一个安全的制动系统」。这句话没法直接写代码。
需求分解，就是把这种顶层需求拆成可验证的子系统需求，再拆到组件需求。PREEvision里用树形结构做这件事，非常直观。
举个例子：
| 层级 | 需求内容 | 责任人 |
|---|---|---|
| 系统需求 | 制动系统在0.5秒内响应 | 系统工程师 |
| 子系统需求 | 制动控制器CAN报文延迟≤10ms | 软件工程师 |
| 组件需求 | MCU SPI通信速率≥4MHz | 硬件工程师 |
分解时要注意：每个子需求必须能追溯到父需求。PREEvision里用「Trace」链接实现这一点。我建议你养成一个习惯——每分解一条需求，立刻建立追溯链接。别攒到后面一起做，你会疯的。
避坑指南：我曾经在一个项目中，把需求分解到第三层就停了。结果测试阶段发现，有个需求根本没法验证——因为没拆到可测试的粒度。从那以后，我给自己定了个规矩：分解到能写出测试用例为止。
3.3 双向追溯：让架构和需求「互相看见」
双向追溯，是PREEvision最值钱的功能之一。
什么意思？就是从需求能查到架构，从架构也能查到需求。比如你看到一个制动控制器的软件组件，点一下就能知道它实现了哪几条需求。反过来，你看到一条需求，也能知道它被分配到了哪些组件。
具体操作：
- 在需求视图中，选中一条需求，右键「Show Traces」→ 看到关联的架构元素
- 在架构视图中，选中一个组件，右键「Show Traces」→ 看到关联的需求
嗯，这里要注意：追溯链不能有环。我见过有人把需求A追溯到B，B又追溯到A，结果查变更影响时死循环了。PREEvision会报警，但最好一开始就避免。
3.4 变更管理：需求变了，架构怎么跟？
项目做到一半，客户改需求——这种事太常见了。
PREEvision的变更影响分析功能，这时候就派上用场了。你改一条需求，系统会自动高亮所有受影响的架构元素。我一般这么操作：
- 修改需求内容或状态
- 点击「Impact Analysis」
- 查看受影响的所有追溯链接
- 逐条确认：是更新架构，还是拒绝变更？
- 在变更日志里记录决策
我的经验：变更管理最怕「悄悄改」。哪怕只改了一个标点符号，也要走变更流程。PREEvision的版本对比功能可以帮你快速定位差异——选中两个版本，右键「Compare」，一目了然。
3.5 与系统架构的一致性检查
需求分解完了，架构也画好了。怎么确保它们一致？
PREEvision提供自动化一致性检查。你可以配置规则，比如：
- 每条系统需求必须至少关联一个架构组件
- 每个架构组件必须至少关联一条需求
- 需求状态为「已实现」时，关联的组件必须已发布
运行检查后，结果会以表格形式展示：
| 检查项 | 通过/失败 | 问题详情 |
|---|---|---|
| 需求R-001未关联架构 | 失败 | 请分配至制动控制器 |
| 组件ABS_Module无需求覆盖 | 失败 | 请添加追溯或删除冗余组件 |
| 所有需求状态与架构版本匹配 | 通过 | - |
说实话，这个检查我每次发布前都会跑一遍。省得评审会上被人问住。
3.6 实战建议：从第一天就建立追溯文化
最后说点掏心窝的话。
工具再好，也架不住人不用。我见过太多团队，PREEvision装上了，需求也导入了，但追溯链接一条都没建。问就是「太忙了，后面再补」。结果呢？后面根本补不完。
我的建议：
- 项目启动第一天，就定好追溯规则。谁建链接？什么时候建？用什么模板？
- 每周花15分钟检查追溯完整性。PREEvision有Dashboard，可以设成每周自动发报告。
- 把追溯纳入评审。需求评审、架构评审、测试评审，都看一眼追溯链。不费事，但能省大事。
最后一个小提醒：PREEvision的追溯数据可以导出成Excel或PDF，方便给客户或供应商看。但记住——导出的只是快照，真正的「活数据」永远在工具里。别让Excel成为你的唯一真相来源。
好了，需求管理与追溯这部分就聊到这儿。下一章我们讲讲配置管理与变体处理——那又是一个让人头大的话题。