M1-04 需求管理与追溯（DOORS 等）
课程代码 M1-04 · 板块 M 项目、质量、成本与合规 / 研发流程与项目管理 时长 约 3.5 小时（9 讲） 前置 B1-01/B1-02 热负荷与需求分解基础 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 M1-04 大纲的完整展开版
按任务导航
| 你手上的事 | 直接看 | 还要配 |
|---|---|---|
| 审一份 SSTS 或零部件规范草案 | 第 2 讲：条目级与集合级两遍审，七类坏味道各配一条改写判据 | 第 1 讲（条目五块属性）· 第 4 讲（被控件的可控性一档） |
| 算一次需求变更的影响面 | 第 8 讲：下游需求条目与非需求对象分两栏统计，直接受影响 vs 间接波及的判据 | 第 5 讲（链的两端）· 第 9 讲（接口需求） |
| 回答「追溯率为什么上不去」 | 第 5 讲：三个指标的分子分母一次定死，两条失真路径 | 第 7 讲（状态与分母）· 第 6 讲（死链接反查） |
| 判本项目还能不能继续用 Excel 追溯矩阵 | 第 6 讲：四条可行边界与四条失步机理 | 第 5 讲（指标）· 第 7 讲（版本联动） |
| 写需求管理计划里的基线与冻结条款 | 第 7 讲：基线＝版本快照＋批准记录，冻结时点的判据 | 第 3 讲（层级名称与层数须书面对齐） |
⛔ 本课不覆盖：
【栏一 · 不讲哪些题目】需求内容本身怎么算出来（热负荷、预算分配律与裕度）→ B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件；验证项本体（验证方式、试验层级、判定准则、不合格出口）→ M1-03 DVP&R 与验证计划管理；控制功能规格的条款写法与向 Tier1 交接 → K4-07 热管理控制功能规格（软件需求）的编写、评审与向 Tier1 交接，软件产物级追溯 → K4-03 MIL/SIL/HIL 验证流程，软件版本与配置管理 → K4-04 软件版本、配置与变量管理；DFMEA 条目 → I7-01 热管理系统/零部件 DFMEA 实操；量产阶段 4M 变更与断点切换 → M2-06 量产阶段变更控制：4M 变更申报、再验证范围判定与量产断点切换；APQP 阶段与门禁评审 → M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑；任何一款工具的操作步骤、界面、脚本与许可证方案 → 工具厂商现行文档与本企业系统管理员。
【栏二 · ⛔ 真正不给的数】四份外部文件（ISO/IEC/IEEE 29148、ISO/IEC/IEEE 15288、IATF 16949、Automotive SPICE）的条款原文、条款号所对应的内容与特性清单的逐字措辞——本课未逐字取得原文 → 经正规渠道购买或查阅现行版本，引用前须核版次与适用范围；被控件可控性六项的限值与典型区间 → B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件、G4-04 比例阀/流量分配阀与回路调节；本课不设任何验收阈值（例如「追溯率须达到某个百分比」）→ 本项目需求管理计划 ＋ 顾客特殊要求，节点出口条件见 M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑；全课示范需求链里出现的一切数值均为教学假设值，⛔ 不对应任何平台、⛔ 不得取用。
引言：改一条需求，你怎么知道要动哪些东西
某车型整车级的一条热管理目标上调一档，落到你桌上的问题只有一句：这一改，还有哪些东西要跟着动？本课引用的一组项目观察给出过一个刺眼的对照——一个项目靠工具里的下游链接一次性把受影响条目全部拉出来，两天内交出影响面清单；另一个用文档加手工表格维护追溯的项目，同类变更排查了近两周还漏项。⚠ 这是单个案例的观察值，⛔ 不是行业典型区间、⛔ 不是可承诺的效率提升比，它只说明一个方向：两者差着一个数量级。★ 更要紧的一句必须并排写出来——这个差别不来自分析方法，来自分析开始之前那几年的登记质量。索引的价值只在变更那一刻兑现，而那一刻恰恰是最没时间去补索引的时候。
钉子 A：需求管理管的不是那句话，是那条条目。一条需求由「文本 ＋ 唯一 ID ＋ 版本 ＋ 状态 ＋ 上游链接 ＋ 下游链接 ＋ 责任人 ＋ 适用范围」构成，句子只占其中一格。本课全部动作——良构判据、逐级分解、双向追溯、基线冻结、变更影响分析、接口确认——都作用在条目这个对象上，⛔ 不作用在文本上。由这一条能当场推出四件事：① 没有唯一 ID 的句子不是需求，它无法被别的对象指向，因而追不到上游、挂不上验证项、也不会被变更分析找到；② 改了文本而没让条目版本前进，在系统里等于什么都没发生——下游没有任何一个人会收到通知；③ 一句话里出现「并且／同时」，往往是两条条目挤在一个 ID 下，后果不是文风，是这两件事的验证项、责任人与变更影响面被强行绑死，动其一必动其二；④ 把设计方案写进需求文本，锁死的不是一句话，是这条条目下游的整个解空间。★ 这根钉子的可操作形式是一句自检问句，每一讲末尾都要拿出来用一次：我刚才做的这个动作，落在条目的哪一格上？答不出格子，说明这个动作在系统里没有留下任何痕迹——而没有痕迹的动作与没做过，在追溯矩阵上长得一模一样。
⚠ 因此本课全程把「需求」拆成三个词用，⛔ 不裸写：需求条目（带唯一 ID 与版本的那个对象，本课全部动作作用于它）· 需求文本（条目里那句话，它只是条目的一格）· 需求集合（某一层需求在某一时刻的全体；完整性、一致性、无冗余这类性质只在集合上才判得了）。★ 这套三分是本课为把上面那根钉子讲成可判的事而定的，⛔ 不是任何标准既有的分类。
钉子 B：追溯链的两端必须先被显式定义，指标才可能是真的。本课把两端一次定死——上溯端有三类合法终点：父需求／已在工具里注册成模块的外部来源文档（法规条款号、客户输入文件号、市场输入）／设计决策记录；下溯端有两类：子需求／DVP&R 验证项。⇒ 顶层整车级需求在库里没有父需求，它是合法孤儿；它缺的不是父需求，是外部来源登记。两端不定义，指标在结构上就封顶：分母里混着一批不可能有上游的条目，百分比永远差一截；于是管理层催指标，工程师就给顶层需求硬挂一个假父需求——数字上去了，链子脏了，法规一改，没有任何人会被这条假链接找到。★ 它的可操作形式同样是一句问句：这条链的两头分别落在哪一类对象上，那类对象在工具里注册过没有？
两钉的关系：钉 A 管「这条条目在系统里立没立住」（对象完整性），钉 B 管「这条链两头接在哪」（链路端点定义）。⛔ 别把两者合成一句「把需求管起来」——立住的是条目，接住的是端点，两件事各有各的失败方式，而它们的失败在报表上都表现成同一个漂亮的百分比。
先打一针预防针——这是本课要点破的主要误读：「变更影响面大，说明需求分解层级太深；少分一层，改一次要动的东西就少了。」这句话听起来完全成立，而照它去做，你会做出一个方向相反的动作：为了压低变更成本，把系统级这一层压掉或大幅合并，让整车级需求直接挂零部件规范。⚠ 变更放大系数反映的是扇出宽度（一条条目被多少个下游对象引用），⛔ 不是层级深度：五层单传的深链，放大系数也只有个位数；两层但扇出宽的接口需求（例如一条冷却液进液温度上限，可能被十几条零部件规范同时引用），反而能到二十。⚠ 这两个数是量级参照，⛔ 不是验收依据，且都随平台移动（随架构分层方式与共用件比例而变），你要用自己库里的数复核这个对比还成不成立；★ 但结论本身不依赖具体取值——把两个数换成符号，「扇出宽度而非层级深度主导影响面」这个论证照样成立。⇒ 压层级对真正贵的那一类变更（宽扇出的接口需求与平台公共需求）一点作用都没有，却确实会造成三件坏事：颗粒度断层（中间「为什么这样拆」的论证没有落点，父子满足关系无从核对）· 责任断层（分配论证掉到没有全局视野的人身上）· 扇出不降反升（一条整车级需求直接扇出到几十条零部件规范）。⇒ 正确动作是识别并管住高扇出：定期从追溯矩阵统计每条条目的下游引用数，把排在前列的那一批单独列成清单并标注引用方，动其中任何一条都要拉全部引用方会签（第 8 讲），⛔ 不是去压缩层数。
本课的射程：本课管「需求这个对象怎么被管理」——怎么写得可判、怎么逐级往下拆、怎么把链的两端接住、怎么冻基线、怎么在变更时把牵连找全、怎么在跨专业接口上让两侧对齐。⛔ 它不管需求内容本身怎么算出来（→ B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件），也不管验证项本体怎么做（→ M1-03 DVP&R 与验证计划管理）；工具只是承载追溯逻辑的容器，本课不教任何一款工具的操作步骤。
九讲的路线：第 1 讲把「条目」这个对象立起来，是钉 A 的落点；第 2 讲讲良构——条目级与集合级要审两遍，逐句读只审得了其中一遍；第 3 讲讲逐级分解，重点是父与子之间到底是哪一种关系；第 4 讲补两处沿层级往下数必然数不到的盲区（控制功能规格这一层、被控件的可控性一档）；第 5 讲立钉 B——两端定义与三个追溯指标怎么算、算出来怎么读；第 6 讲讲链接在工具里究竟是什么，以及手工表格从哪一刻起必然失步；第 7 讲讲基线与冻结，把「冻结＝禁止变更」这个误读拆掉；第 8 讲是全课的兑现时刻——一次变更的影响面怎么算、非需求对象怎么单列；第 9 讲收在跨专业接口上，两根钉子在这里合钉。
★ 读完本课，你应当能带走三件今天就能用的东西：一张条目属性对照表（拿现用的需求文档逐条比对缺哪几格）· 一套链两端的定义（据此判本项目指标的分母干不干净、分子实不实）· 一份高扇出清单的做法（用相对排序，⛔ 不需要任何门槛数）。
第 1 讲 需求管理管的是「条目」，不是那句话
先说一件容易被跳过的事：这门课后面八讲要教的所有动作——判良构、逐级分解、建双向追溯、冻基线、做变更影响分析、确认接口——没有一个作用在文字上。它们全部作用在一个叫「需求条目」的对象上。如果这个对象在你的项目里还没有立起来，后面八讲讲得再细，落到你手上都是无处安放的。所以第 1 讲不讲工具、不讲矩阵，只做一件事：把「需求」从一段文字变成一个可以被引用的对象，并给你一份当天就能拿去体检的五问清单。
本讲开头先定死三个词（全课通用）。本课把「需求」拆成三个所指，全课不再裸写这两个字：
- 需求条目（requirement item）——带唯一 ID 与版本的那个对象。本课全部动作作用于它。
- 需求文本——条目里的那句话。它只是条目的一格。
- 需求集合——某一层需求条目在某一时刻的全体。只有在它上面，才判得了完整性、一致性、无冗余、可负担、有界这几件事（第 2 讲展开）。
⚠ 这套三分是本课为了把后面的判据讲成可执行的动作而定的，⛔ 不是任何标准或任何工具既有的分法。你的项目可以另定名字，但必须事先定死一套，⛔ 不许在评审会上临时按方便切换所指——本课后面会看到，大量争论其实是三个人各自在说三样东西。
1.1 一条需求是一个对象，句子只占其中一格
钉子①：一条需求条目由「需求文本 ＋ 唯一 ID ＋ 版本 ＋ 状态 ＋ 上游链接 ＋ 下游链接 ＋ 责任人 ＋ 适用范围」构成，句子只是其中一格。
为什么必须先立这个对象？因为后面每一个动作都需要一个能被引用的把手。由这一条直接推出四条可以当场执行的判据：
- 没有唯一 ID 的句子不是需求条目。它无法被别的条目指向，于是既追不到上游、也挂不上验证项，变更影响分析也永远找不到它。
- 改了需求文本而没有让条目版本前进，在系统里等于什么都没发生。下游没有任何一个人会收到通知。
- 一句话里出现「并且／同时」，往往是两条条目挤在一个 ID 下。它的后果不是文风问题：这两件事的验证项、责任人与变更影响面被强行绑在一起了，动其一必动其二（第 2 讲会把这条展开成可判的写法）。
- 把设计方案写进需求文本，锁死的不是一句话，是这条条目下游的整个解空间。
⇒ 这根钉子的可操作形式是一句问句，本课每一讲末尾都要拿它自检：
我刚才做的这个动作，落在条目的哪一格上？
答不出格子来，说明那个动作在系统里没有留下任何痕迹——而没有痕迹的动作与没做过，在追溯矩阵上长得一模一样。这不是修辞：追溯矩阵读的是链接与状态这几格，你在会上达成的共识、在邮件里确认的口径、在图纸上改掉的尺寸，如果没有回落到某一格里，矩阵看不见它们，而矩阵是变更那天唯一被信任的东西。
本条不给任何数——它是一条结构判据。但有一个可数的东西值得你现在就去数：属性格子的数量（本课把它归成文本＋四类元数据，展开成具体字段通常在十个上下，见 1.2）。拿一份你现用的需求文档，逐条比对缺哪几格，就是第 1 讲要你动手做的第一件事。
为什么这件事在整车项目上尤其要紧，看一眼规模就明白：整车级 VTS 里与热管理相关的条目通常在几十条量级；展开到系统级 SSTS 进到数百条；再展开到零部件规范级（含各被控件的可控性条款那一档，第 4 讲）通常进到上千条。多数量产项目的热管理需求库落在上千条这一档。⚠ 典型量级，⛔ 不是验收依据；它随需求库的边界划法（含不含软件需求、含不含供应商内部规格）变化极大，来源等级＝工程实践观察，本课未取得公开统计原文。→ 拿到它的路：在你自己的需求库里按层级过滤计数，并先写明这一次统计把哪些东西计入了，否则两次统计不可比。⇒ 这个量级的意义只有一个：在上千条这个规模上，任何依赖「人逐条对照」的机制都会在第一次变更时失效——这是第 6 讲要判 Excel 边界的前提。
易错点：把「需求评审」理解成一群人坐下来逐句读文字。⚠ 逐句读只审得了单条条目内部的性质；集合级特性（完整性、一致性、无冗余）与元数据完整性（ID／版本／状态／链接／owner）读一万遍句子也发现不了——它们根本不在句子里。第 2 讲会把这件事拆成两遍不同的评审。
1.2 属性全集：五块，判据是「删掉这一格，哪一个动作立刻做不了」
先看枚举线索的陷阱。沿「需求文档里有什么」往下数，你只会数到需求文本：编号、标题、正文。四类元数据整类不出现——不是漏了几项，是这条线索上根本没有它们的位置，因为它们不打印在纸上。
本课把需求条目的属性归成五块（⚠ 本课归纳的分块，⛔ 不是任何工具的数据模型、也不是任何标准既有）：
| 块 | 内容 | 删掉它，立刻做不了的动作 |
|---|---|---|
| 需求文本 | 显示编号、标题、需求正文 | 谁都读不懂这条要什么 |
| 身份与版本 | 唯一 ID、条目版本、变更记录 | 删 ID → 追溯做不了；删版本 → 变更通知发不出 |
| 状态 | 已提议／已评审／已批准／已基线化／已废止，以及「本条正在变更中」 | 基线冻不住（第 7 讲） |
| 关系 | 上游链接、下游链接、横向链接（接口对侧条目、FMEA 条目、变更单） | 追溯矩阵建不起来，变更影响分析找不全下游 |
| 治理 | 责任人 owner、优先级、适用车型与配置、来源等级 | 删 owner → 需求掉地上，没人回答「这条现在归谁」 |
为什么是这五块，而不是别的分法：因为本课四条学习目标各自依赖其中一块——判良构依赖需求文本＋ID；逐级分解依赖关系；建追溯矩阵依赖关系＋状态；做变更影响分析依赖版本＋关系＋治理。⇒ 建轴的判据就是那一列：每一格都要能说出「删掉它，哪一个动作立刻做不了」。说不出来的格子，是本地治理需要，不是必备属性。
今天就能用的一件事：打开你项目现用工具的条目模板，逐字段对照这五块，缺哪一块补哪一块。展开成具体字段通常在十个上下；各家工具的实际字段数常远多于此（多出来的多半是本地治理需要，例如成本影响、法规标记、变更批次）。⚠ 典型量级，⛔ 不是验收依据，⛔ 更不是「字段越多越好」的暗示；来源等级＝工程实践观察。→ 拿到它的路：本项目工具的条目模板 ＋ 你们的需求管理计划里对必填项的规定。★ 本课的判据是结构判据而不是计数：五块必须都在，字段数是多少不重要。
易错点：把 owner 写成部门名（「热管理科」「电子电气部」）。⚠ 部门不会被追责、也不会收到通知，owner 必须是一个人。这与 B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件 里「没有唯一责任人，需求就掉地上」是同一件事，本课从条目属性的角度再钉一次：owner 这一格空着或写成部门，等于这条条目在变更那天没有人接。
1.3 ID_需求：一经分配终身不变、不回收、不重排
ID_需求是需求条目的唯一标识。本课固定一条纪律：ID 一经分配终身不变、不回收、不重排——条目废止时保留 ID 并把状态置为「已废止」，⛔ 不把它腾出来给新条目用，⛔ 也不在整理文档时按新顺序重编。
为什么这条要写成硬纪律：ID 是一条对外契约。它被上游链接、下游链接、历次变更记录、DVP&R 验证项、供应商技术协议、已发布的评审纪要与申报材料同时引用。重排会一次性打断这几条链，而其中大部分不会报错，只会静默指向错的条目：一个被回收的 ID 指向的是另一件事，链接依然「存在」，报表依然全绿。⇒ 这类故障的可怕之处不在于它发生，而在于它的外观与「一切正常」完全一致，通常要到集成或验证阶段有人问「这条为什么挂着这个试验」时才暴露。
⛔ 本课不给编号规则的具体格式（各家不同）。给的是一条可判的结构要求：
ID 里不许编码任何会变的信息。⛔ 不许把层级、章节号、责任部门、车型代号编进 ID——因为那些东西一变，就会诱发重排的冲动，而重排是不可逆的。
易错点：把文档章节号当 ID 用（「3.2.7 冷却液进液温度上限」）。⚠ 章节号会随文档改版而移动，于是每一次重排版都在静默地改 ID。这是 Word／Excel 形态最常见的一处断链根因，第 6 讲会回到它。
可以当天做完的 ID 体检（三问）：① 随便挑一条条目，它的 ID 在最近三版文档里是同一个吗？② 找一条已废止的条目，它的 ID 还在库里吗，还是被腾走了？③ 打开 ID 的编码规则，里面有没有出现层级号、章节号或部门代号？三问里有一问答错，你的库里已经存在指向错误的链接，只是还没有人踩到。
1.4 V_条目 与「文档版本」是两个东西
V_条目是需求条目的版本号。它与「文档版本」是两个东西，本课全课不许互相代替：
- 条目版本记录的是这一条什么时候被改过、改了什么、谁批的；
- 文档版本记录的是这一份发布物的快照编号。
一份 SSTS 文档发布 V3.0 时，里面几百条条目各自处在各自的 V_条目 上：有的还是初版，有的已经改过五次。变更通知是按 V_条目 前进触发的，⛔ 不按文档版本。
为什么这条不能含糊：下游关心的是「我引用的那一条变了没有」，而不是「那份文档又发了一版」。若系统里只有文档版本，下游收到 V3.0 之后要自己逐条对照才知道跟自己有没有关系——在 1.1 说的上千条规模上，这件事没有人会真的做，于是变更通知在实际上失效（形式上发过了，实质上没人收到）。⇒ 由此得到一条可以当场判的结论：
如果你的系统只能回答「文档改了」，却回答不了「哪几条条目改了」，那么它没有变更通知能力。第 8 讲的变更影响分析在它上面做不了。
⛔ 本课不给「一条需求在项目周期里平均改几版」这类数——它随项目成熟度与客户风格变化极大，本课未取得可信区间。替代物是一条可以自查的结构：随便挑一条需求条目，你能不能在五分钟内列出它历次版本的改动内容与批准人？答不出来，就说明「变更记录」这一格是空的——而它空着的时候，1.1 那个自检问句在整条链上都答不出来。
易错点：把「勘误」也让 V_条目 前进，或者反过来，把改了口径的修改当勘误处理。本课的判据是：凡改动会使这条条目的「可验证内容」发生变化的，算变更，必须让 V_条目 前进并触发下游通知；仅修正不改变可验证内容的表述缺陷（错别字、格式、标点、纯粹的措辞润色）算勘误，记入变更记录但不前进版本、不触发通知。⚠ 有三类边界情形一律算变更，⛔ 不算勘误——单位写错、口径写错、把「≤」写成「<」，因为它们改变了验证时的判定结果。★ 这条判据是本课定的，⛔ 不是标准既有；各项目可以另定，但必须事先定死，⛔ 不许事后按方便判。第 7 讲讲基线与变更流程时会把它接到状态机上。
1.5 本课与相邻课的划界：本课管「这个对象怎么被管理」
需求管理这门课与它周围几门课是相邻到会重叠的。不先划界，你会以为本课没讲透，或者在两门课里读到两套口径。这里一次说清六条边界，每一条都写成一句可执行的话——你现在要做的这件事，属于哪一门课，去那里拿判据：
- 需求的内容怎么来（温度／压降／功率预算怎么分配、裕度怎么留、零部件规范里各参数各管什么）→ 去 B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件。本课只管一件事：分配理由必须作为条目属性被记下来（第 3 讲）。
- 验证项本体（验证方式全集、试验层级怎么选、样件状态、抽样与统计口径、判定准则怎么写、不合格出口与再验证触发）→ 去 M1-03 DVP&R 与验证计划管理。本课只管需求条目挂没挂到验证项 ID 上、以及挂没挂上怎么统计，⛔ 一个判定限值都不给。
- 控制功能规格（软件需求）的条款怎么写、怎么评审、怎么向 Tier1 交接 → 去 K4-07 热管理控制功能规格（软件需求）的编写、评审与向 Tier1 交接。本课只讲通用的分解与追溯机制（第 4 讲会指出这条链在控制方向还没到底）。
- 软件域的产物级追溯（需求 → 模型／代码单元 → 测试用例 → 测试结果／覆盖率报告）与它的验证层级 → 去 K4-03 MIL/SIL/HIL 验证流程；这些产物登记进 DVP&R 的格口 → 去 M1-03 DVP&R 与验证计划管理。
- 量产阶段的 4M 变更申报与断点切换 → 去 M2-06 量产阶段变更控制：4M 变更申报、再验证范围判定与量产断点切换。本课的变更管理停在产品开发阶段。
- APQP 阶段划分与门禁评审、冻结节点的定义 → 去 M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑。本课给的是「什么时候该冻」的通用判据（第 7 讲），⛔ 不给节点名称、⛔ 不给日期。
⚠ 划界不是免责声明。上面每一条都是「去那里拿判据」，⛔ 不是「这些不重要」——恰恰相反，第 8 讲你会看到，一次变更真正的成本大半落在这六条边界的另一侧。
顺带把外部标准的引用方式也在这里定死（这是本讲的最后一段口径声明）：本课涉及四份外部文件——ISO/IEC/IEEE 29148（需求工程过程与需求特性）、ISO/IEC/IEEE 15288（系统工程过程）、IATF 16949（需求管理相关条款）、Automotive SPICE。本课未逐字取得其中任何一份的原文 ⇒ 一律只写「它管什么、去哪查」，⛔ 不写任何条款号所对应的具体内容、⛔ 不写任何限值、⛔ 不逐字引用特性清单的原文措辞。⚠ 本课第 2 讲讲的良构特性清单是本课按工程实践归纳、并对齐这些文件的精神写成的，⛔ 不得当成任何一份的条款转述。⚠ 引用 Automotive SPICE 时须声明所依版本——3.1 与 4.0 两版并行流通，过程域名称与工作产物编号有差异，⛔ 不得混引；过程参考模型与能力等级的口径整体去 K4-04 软件版本、配置与变量管理。⚠ 版次与日期一律以现行目录为准，引用前须核，⛔ 不得钉死年份。→ 拿到它的路：通过正规渠道购买或查阅现行版本；同一条内容在不同出处给出不同说法时，两个都记、各带出处，⛔ 不得只留一个。
1.6 入口练习：从一句「电芯不超温」到一条可管理的条目
拿一句典型的坏需求当场补全，是本讲最短、也最能说明问题的一步。原句：
「电芯不超温。」
按 1.2 的五块把它补成一条条目，要补七件事：
| 要补的 | 补之前 | 补之后（教学假设值，⛔ 不对应任何平台、⛔ 不得取用） |
|---|---|---|
| 主体（谁应满足） | 空 | 电池热管理系统 |
| 条件（什么工况） | 空 | 环境温度 40 ℃、直流快充功率按本项目定义的峰值充电曲线 |
| 判据（判到什么程度、怎么测） | 「不超温」不可判 | 电芯最高单体温度 ≤ 某上限值，测点与测量方式按验证项定义 |
| 唯一 ID | 空 | 由需求库分配，终身不变（1.3） |
| 上游 | 空 | 来自整车级 VTS 的快充能力条款（或某份客户输入文件） |
| 下游占位 | 空 | 将来挂到某一类 DVP&R 验证项上（本体见 M1-03 DVP&R 与验证计划管理） |
| owner | 空 | 一个人的名字（⛔ 不是部门，1.2） |
⚠ 上表右列的一切取值都是教学假设值，⛔ 不对应任何平台、⛔ 不得取用。本课全程使用一条脱敏的示范需求链（整车级一条 → 系统级两到三条 → 零部件规范级两到三条），其中出现的所有数值一律照此标注。⚠ 之所以必须逐处标注：这条示范链会写成看起来很完整的规范条款形态（有主体、有条件、有判据、有单位），它比一段散文更容易被直接抄走。★ 本课要教的不是那个数，而是每一个数应当从哪里来——法规、客户输入、对标、物理上限反推、上一级分配；判据来源的正当清单在 B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件 与 M1-03 DVP&R 与验证计划管理，本课只给去向。
补完之后请回头看一眼。原来那句话之所以没法验，不是因为写得不好听，是因为有四个必填格子是空的（条件、判据、上游、owner）。⇒ 这就是本课把「识别良构要素、挑出坏需求写法」这件事从「认识几个形容词」变成「补齐几个格子」的地方——形容词是主观的，格子空不空是可以当场数出来的。
易错点：补格子时顺手把方案写进去（「应采用液冷板，使电芯不超温」）。⚠ 那正是钉子①第 4 条推论说的事——你锁死的不是一句话，是这条条目下游的整个解空间。第 2 讲会正面处理它，并给出一条可判的检查方法。
1.7 本讲自检：五问体检，以及「先立条目、再导工具」的次序
拿一份你现在手上正在用的需求文档，逐条问五个问题：
① 它有唯一 ID 吗？ ② 它有条目版本吗？ ③ 它有 owner（一个人）吗？ ④ 它的上游指向哪？ ⑤ 它的下游指向哪？
五问全空的那一批，本课后面八讲对它全部无效——注意措辞：不是「做得差」，是结构上做不了。追溯、基线、变更影响分析这三件事都需要一个能被引用的把手，把手不存在时，它们没有可以附着的对象。
⇒ 由此得到本讲最实用的一条次序判据：
先立条目（ID ＋ owner ＋ 上下游占位），再导工具。⛔ 反过来做的代价是历史引用全断。
为什么次序不能反：跳过这一步直接上工具，得到的是把一堆没有 ID 的句子导进需求管理工具——工具会自动给它们分配 ID，而那些 ID 与历史文档里的编号对不上，于是所有历史引用（评审纪要、技术协议、已发布报告里写的编号）全部作废。⚠ 常见的想法是「反正要上工具，工具会帮我分配 ID」——工具确实能分配，但它不知道哪条句子对应历史上的哪条编号；这层映射只有人做得了，而且必须在导入之前做完。⛔ 本课不给「导入前该整理多久」这类工时数（未取得可信区间）；能给的就是这条次序，以及一句判断标准：映射表没做完之前，不要开始导入。
一组值得记住的观察对照：有一个项目在整车级需求上调一档之后，用需求管理工具的下游链接一次性定位受影响的系统级与零部件规范级条目，两天内交出影响面清单；另一个用文字处理软件与电子表格手工维护追溯的项目，同类变更排查了近两周还漏项。⚠⚠ 这是单个案例的观察值，⛔ 不是行业典型区间、⛔ 不是可承诺的效率提升比——⛔ 不得据此写成「上工具可提速 N 倍」；它只说明方向：两者差一个数量级。★ 更要紧的一句必须并排写出：这个差别不来自分析方法，来自分析开始之前那几年的登记质量。第二个项目的失败点并不是「用了电子表格」，而是它的条目没有 ID，只有一行行文字——同样的工具，如果每条句子都有终身不变的 ID、有 owner、有上下游占位，那两周里的绝大部分时间本来是不必花的。→ 拿到它的路：在你的项目上做一次实测——选一条真实变更，记录从收到变更到交出完整影响面清单所花的时间与漏项数；这个数比任何外部对照都有用。
本讲小结：本课全部动作作用在需求条目这个对象上，需求文本只是它的一格。条目由五块构成——文本、身份与版本、状态、关系、治理——建轴判据是「删掉这一格，哪一个动作立刻做不了」。ID 终身不变、不回收、不重排，因为重排造成的断链不报错；条目版本与文档版本是两个东西，变更通知按条目版本前进触发。本课管的是这个对象怎么被管理，需求内容怎么来去 B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件、验证项本体去 M1-03 DVP&R 与验证计划管理、控制条款去 K4-07 热管理控制功能规格（软件需求）的编写、评审与向 Tier1 交接。带走一件今天能用的：五问体检，以及「先立条目、再导工具」这条次序。⇒ 每一讲末尾都回到那句话：我刚才做的这个动作，落在条目的哪一格上？
后面还有 8 讲正文 · 关键公式 · 案例拆解 · 常见误区 · 动手做