TMS BOOK · ACADEMY 课题
需求管理与追溯（DOORS 等）
整车热管理需求从 VTS 一路分解到零部件规范再到验证项，链条一长就容易断——需求改了下游没同步，或者验证项追不回是响应哪条需求。本课教你用双向追溯把这条链管住，DOORS 只是工具，追溯逻辑才是核心。
M1-04 · 项目、质量、成本与合规 / 研发流程与项目管理
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 识别一条"良构需求"该具备的要素，挑出常见的坏需求写法
- 把整车级 VTS 需求逐级分解为 SSTS 级、零部件规范级需求
- 用双向追溯矩阵把需求、设计、验证项串成一条可查的链
- 对一条需求变更做出影响分析，找全所有受影响的下游项
内容大纲
- 良构需求的判据与写法
- 良构需求的要素（对齐 ISO/IEC/IEEE 29148 的特性清单）：主体、条件、判据、可验证，再加必要性（每条都要能说清为什么存在、追得到上游来源）、单一性（一条只说一件事，句子里出现「并且/同时」往往是两条需求挤在一起）、可追溯性（有唯一 ID，既能上溯来源也能下挂验证项）、不含实现方案
- 热管理需求常见坏味道：模糊词（"尽量""合理"）、把设计方案写进需求里
- EARS 等结构化需求写法简介
- 需求逐级分解：VTS→SSTS→零部件规范，以及它在控制方向的两处盲区
- 整车 VTS → 系统 SSTS → 零部件规范的逐级分解逻辑（承接 B1-02）
- 每一级分解都要能说清"为什么这样拆"，不是拍脑袋切
- 父需求与子需求的满足关系：全部子需求满足是否等于父需求满足
- 这条链在控制/软件方向还没到底：零部件规范之外还有一层控制功能规格（软件需求），它的条款载体与良构判据是控制特有的——判据只能引用车上真实存在或可估计的观测量、响应时间不得超出执行器的物理动作能力与任务周期上限、阈值要留标定接口而不是写成硬编码常数、模式行为要用迁移表而不是自然语言描述。本课只讲通用的分解与追溯机制，控制条款怎么写、怎么评审、怎么向 Tier1 交接见 K4-07
- 分解到零部件规范时，被控件（比例阀、电子水泵、冷却风扇、电动压缩机）除了流通能力/内漏/响应时间/噪声，还要多写一档可控性条款——回路压降分配下的阀权度前提、特性型式（线性还是等百分比）、磁滞带上限、最小可控开度与死区、重复性与批间离散上限、位置反馈的分辨率与刷新率。漏了这一档，控制工程师要到标定阶段才发现「这个阀根本控不了」，而那时规格已冻结。条款清单本体见 B1-02 与 G4-04，本课只管这一档必须进规格、进追溯链、进 DVP&R 验证矩阵
- 双向追溯链：两端定义、工具落地、边界与外部取证
- 追溯链的两端要显式登记，否则指标失真：顶层 VTS 需求属于「合法孤儿」，必须标注外部来源（法规条款号、客户输入文件号、市场输入），并在工具里把来源文档注册成模块建链——没标来源的顶层需求才算缺陷；末层需求的下游是 DVP&R 验证项而非更低一级需求。两端不先约定，追溯率永远差一截，逼着人造假链接凑分
- DOORS/Polarion 等工具的链接（Link）机制：上游追溯与下游追溯
- 轻量场景下用 Excel 追溯矩阵替代的可行边界与局限
- 追溯矩阵在产物侧的边界：软件域的产物级双向追溯链是「需求 → 模型/代码单元 → 测试用例 → 测试结果/覆盖率报告」，由 Automotive SPICE 的 SWE.4~SWE.6 过程域规定。本课只讲通用追溯工具与矩阵的维护机制，软件专有的验证层级与证据形态见 K4-03、登记进 DVP&R 的格口见 M1-03，三处不要各写一遍
- 从过程评估视角看这套追溯：本课讲的双向追溯与变更影响分析，在软件方向对应的是需求分析过程域对验证过程域的双向追溯要求；上溯率/下溯率与需求覆盖率这几个指标正是过程评估里最常被抽样取证的对象。典型失分点与本课误区一一对应——文档齐全但追溯只做了单向、变更记录与实际提交对不上、评审无记录。过程参考模型与能力等级的口径见 K4-04
- 需求基线与变更影响分析
- 需求基线（Baseline）：什么时候该冻结、冻结后怎么改
- 一条需求变更，如何用追溯链快速定位所有受影响的下游项
- 变更影响面评估：直接受影响 vs 间接波及
- 变更评审与需求重新基线化
- 高扇出需求清单怎么维护：定期从追溯矩阵里统计每条需求的下游引用次数，把排在前列的那批（多为接口需求与平台公共需求）单独列成清单并标注引用方；这张清单是变更评审的默认盯防对象，动其中任何一条都要拉全部引用方会签，而不是只通知直接下游
- 跨专业接口中的需求管理
- 接口需求（ICD）与专业内部需求的区别
- 需求管理如何支撑接口冻结与 DVP&R 验证矩阵
- 接口需求变更需双方专业共同确认，单方面改动最容易埋雷
关键公式
需求覆盖率 = 已追溯到验证项的需求数 / 需求总数
衡量需求是否"闭环"到验证，与 M1-03 的 DVP&R 覆盖率是同一指标的两个视角
上溯率 = 有合法上游（父需求，或已登记的外部来源文档）的需求数 / 需求总数；下溯率 = 有下游（子需求或验证项）的需求数 / 需求总数
把原来的一条「双向追溯完整度」拆成两个分层指标，关键是先把追溯链的两端定义清楚：顶层 VTS 需求在需求库里没有父需求，它的合法上游是外部来源文档——法规条款号、客户输入文件号，在 DOORS/Polarion 里把来源文档注册成模块再建链，即算已上溯；末层需求的下游是 DVP&R 验证项，不是更低一级需求。边界定义清楚，两个指标都能真做到 100%；边界不定义、一律按「上游=父需求」算，指标永远封顶，管理层催指标、工程师就给顶层需求硬挂假上游，反而把追溯链搞脏
变更影响面 = 受影响下游需求数 / 直接变更需求数
变更放大系数：它反映的是该需求被下游引用的扇出宽度，不是分解层级的深度。系数高的多半是被多方共用的接口需求与平台公共需求（如冷却液进液温度上限，可能被十几条零部件规范同时引用），这些才是变更评审要重点盯防的对象；五层单传的深链放大系数也只有个位数，两层但扇出宽的接口需求反而能到二十——所以优化方向是识别并管住高扇出需求，不是去压缩分解层数
关键概念
需求工程良构需求EARS 语法VTS/SSTS追溯矩阵 Traceability MatrixDOORS双向追溯变更影响分析接口需求 ICD需求基线 Baseline
推荐工具与标准
DOORS（IBM Rational DOORS） Polarion / Jama Connect Excel 追溯矩阵（轻量场景替代） PLM 系统
ISO/IEC/IEEE 15288（系统工程过程） IATF 16949（需求管理相关条款） Automotive SPICE（软件过程参考与评估模型；正文引用时须声明所依版本——3.1 与 4.0 两版并行流通，过程域名称与工作产物编号有差异，不得混引）
工程案例
某车型 VTS 中的快充降温目标上调一档，工程师用 DOORS 下游链接一次性定位受影响的 SSTS 与零部件规范条目，两天内完成影响面清单；对照另一个用 Word/Excel 手工维护追溯的项目，同类变更排查了近两周还漏项。
动手做
交付物 · 给定一条整车级 VTS 需求（如"高温环境下电池达到目标温度的时间要求"，不写具体数值），① 分解出对应的 SSTS 级需求 2~3 条；② 继续分解出零部件规范级需求 2~3 条；③ 画出这条需求链的追溯矩阵，含到验证项的链接。
常见误区
- 需求写成"应尽量满足降温要求"这种不可判定的表述，验证阶段没法对号入座
- 只做上到下的单向分解，没建反向链接，变更影响分析形同虚设
- 需求量大了还在用 Excel/Word 手工维护追溯矩阵，必然逐渐失步
- 需求基线没冻结就开始详细设计，后期变更泛滥，谁都说不清当前有效版本
- 把具体设计方案（如"用某型号电子膨胀阀"）直接写进需求里，锁死了下游设计空间
相关课题