很多项目在需求阶段看不出问题一出问题就是大问题。比如一条“车门应能正常解锁”的需求在不同人手里会变成完全不同的东西底盘的人觉得是门锁电机的事车身的人觉得是锁体结构的事电子的人觉得是BCM车身控制模块程序的事测试的人根本不知道拿什么标准去验证。我见过不止一个项目图纸发下去了、软件也写完了才发现大家理解的“正常解锁”根本不是一回事最后只能返工改需求、改设计、改测试用例代价惨痛。DOORS 这类需求管理工具在汽车行业里被大量使用恰恰就是为了治这个病。它不是写文档的编辑器而是一条承载“从整车级愿景到子系统、再到零部件软硬件需求”的追溯链让每条需求都有来源、有去处、有验证方法。但工具只是工具真正拉开差距的是“怎么拆”。这也就是这篇博文想聊的重点结合汽车设计里的具体场景讲清楚 DOORS 里的模块化需求拆分怎么做拆到什么粒度合适链接怎么建才不会翻车以及在真实项目里最容易踩的坑。无论你是刚接手需求管理工作的工程师还是被 DOORS 折磨得想摔鼠标的项目经理这篇文章应该都能给你一些可以直接用的思路。1. 一条车门需求引发的连锁问题为什么拆需求会拆出一堆返工1.1 一个真实的口径混乱现场先还原一下我在评审会上见过的场景。OEM主机厂给供应商发了一版需求里面有一条写得特别简洁“车门应能正常解锁”。供应商那边拿着这条需求机械工程师理解成“门锁机构的开启行程要足够”电子工程师理解成“BCM要能驱动门锁电机”软件工程师理解成“解锁指令的通信协议要正确”测试工程师就更头疼——他根本不知道“正常”是怎么定义出来的最后只能凭经验自己编测试用例。这种看似“没问题”的含糊需求在汽车这种复杂产品里几乎必然引发连锁返工。为什么因为“正常解锁”背后其实藏着一大堆场景整车下电后驾驶员在车内拉动内开手柄能不能解锁车速超过某个阈值后门锁是否处于锁止状态车辆发生碰撞后门锁是否能够满足解锁要求方便救援儿童锁开启时从内侧拉手柄无法开门但外侧手柄可以这是否算“正常”长期停放后蓄电池电压偏低门锁电机能否在低压状态下可靠动作插入机械钥匙旋转时锁芯驱动机构与电控解锁是否共用一套传动路径每一条背后都对应不同的子系统、不同的设计约束、不同的测试验证方法。而这些信息如果不在需求阶段拆开、标注清楚到设计评审、测试执行的时候就是各干各的谁也说不清当初那条需求到底指向什么。这其实是需求管理里最底层的认知需求必须拆到“可验证”的粒度。如果一条需求写完你找不到一个明确的验证动作和通过准则那它就还不算需求只能算一句含糊的愿望。1.2 DOORS 在汽车需求链中的确切位置很多刚接触 DOORS 的人会把它当成一种“可以多人协作的 Excel”或者“带链接的 Word”。这种理解不能说错但它会让你用错方向。DOORS 的价值不在于“打字方便”而在于它把需求变成了一组带有属性的对象并通过链接建立起网状追溯结构。在 ASPICE 和 ISO 26262 的落地流程里DOORS 通常承担这样几个角色需求条目的唯一存放地与状态管控点所有经过评审确认的需求在 DOORS 里以对象形式存在每条对象有独立 ID、属性、基线和变更记录。系统需求到子系统、软硬件需求的追溯载体设计上游的“系统需求”通过 Derive 链接派生到下游的“子系统需求”“部件需求”每一条下层需求都能顺链找到它满足的是哪条上层需求。合规审计的证据链ISO 26262 明确要求需求具备双向可追溯性bidirectional traceability也就是从安全目标往下能追到某条需求和测试用例从某条需求和测试用例往上能追到安全目标。DOORS 的可追溯性矩阵视图就是把这些证据一键拉出来的地方。换句话说DOORS 在汽车需求链里的位置是“全链条需求对象的数据库追溯关系网”。脱离这个定位去用只在里面写大段大段的文字描述而不去建链接、不管属性、不打基线那它确实还不如一个共享盘里的 Word 好用。这也是很多项目上了 DOORS 却依然混乱的根本原因——不是软件不行是拆解和使用的思路没到位。2. 模块化拆分的骨架与链接语义先把 DOORS 里的“地图”画对2.1 先定层级骨架系统级、子系统级、组件级到底分几层我见过不少团队打开 DOORS 就开始哐哐建模块、写需求写到一半才发现层级不对有的需求写在了太上层有的设计细节混进了需求模块整个追溯链乱成一锅粥。正确做法是动手之前先画“需求层级地图”也就是规划好你打算在 DOORS 里建立哪些层级模块、每个模块放什么类型的信息。在汽车设计领域我常用的分层方式是这样的层级模块名称示例主要内容典型需求来源系统级VEH_System_Req整车系统需求整车功能、性能、安全、法规相关需求产品定义、法规、市场调研子系统级DLS_DoorLockSystem_Req门锁系统需求门锁系统的功能、性能、接口、环境需求系统级需求分解组件级DLS_BCM_Req / DLS_Lock_motor_ReqBCM 软件需求、门锁电机硬件需求子系统需求分解测试级DLS_Test_Spec测试用例模块对应需求的验证用例需求验证策略这张表看着简单但实际项目里最大的争议在于到底分几层才合适我的判断标准有两条拆到“可验证”为止。如果某条需求还无法直接对应测试用例或设计约束说明它还需要往下拆。拆到“变更影响可控”为止。如果某一层需求的每次变更会牵连几十个其他对象说明它拆得太粗如果改一个很小的设计就要动四层需求说明拆得太细。以门锁系统为例子系统级可能就写“系统应支持遥控解锁/闭锁功能”“车辆发生碰撞后门锁控制系统应解除锁止状态”。这些需求要展开成组件级需求时已经带有“安全状态”“逻辑判定”“执行机构”这些技术语境需要对应到 BCM 软件功能、门锁机械结构、通信链路等具体对象。这个拆解的过程本质上是由“功能愿景”向“技术边界”逐层落地的过程。模块的命名规则也值得在项目启动时统一比如子系统代码_模块类型_说明DLS_Req_DoorLockFunc表示门锁系统功能需求模块DLS_Trace_Verification表示门锁系统验证追溯模块。命名规则定好之后整个项目里的模块清单一目了然。2.2 属性设计让每条需求自带“上下文标签”在 DOORS 里需求对象的内容不仅仅是那一段文字属性Attribute才是支撑后续分析、过滤、导出的关键。你可以把属性理解为贴在每条需求上的标签这条需求是谁提的、属于什么类型、安全等级多高、用什么方法验证、当前状态如何、优先级多高。没有属性的需求就是一堆孤零零的文字只能靠人肉阅读去理解有了属性你才能用视图View和过滤器Filter自动把“所有 ASIL C 级且尚未验证的软件需求”拎出来。围绕汽车门锁这类零部件我一般会给需求对象建立这样一组基础属性需求类型功能需求、性能需求、接口需求、安全需求、法规需求、可维护性需求。来源客户需求、内部企划、法规条款、历史变更、平台复用。ASIL 等级QM / A / B / C / D关联到功能安全评估。这在 ISO 26262 背景下几乎是必备属性。验证方法测试Test、检查Inspection、分析Analysis、演示Demonstration。这个属性直接决定这条需求以后挂到哪种验证对象上。优先级高 / 中 / 低用于决定开发顺序和资源投入。状态草稿、已完成、已评审、已基线、已变更、已批准。责任部门/责任人便于按团队过滤和分派。属性设计听起来不复杂但真正做起来有三个细节容易翻车第一属性不是越多越好。有的人恨不得塞二十个属性结果录入负担巨大后面没人维护属性值全是空的反而变成垃圾信息。我建议核心属性控制在七个以内其他信息放到附录或说明字段里。第二属性值的枚举要提前定死。比如“验证方法”只允许四选一不要在文档里写什么“测试分析”这类模糊组合否则后面做追溯矩阵的时候数据根本没法机器过滤。第三属性要有负责人。需求对象的“状态”是谁来更新通常是需求负责人。如果这个机制没定清楚DOORS 里的状态属性会永远停留在“草稿”等于白设。2.3 链接类型怎么建Derive、Satisfy、Verify 不要混用DOORS 里最容易混乱的地方就是链接。很多团队建了链接但建得毫无章法有些链接表示“衍生”有些表示“满足”有些表示“验证”全搅在一起。等要做可追溯性分析的时候根本分不清一条链接到底是“来源于”还是“被验证”整个追溯网络就成了装饰品。我习惯在项目启动时就把链接语义定义清楚最常用的三种Derive派生上层需求分解、细化出下层需求。比如“车辆停止时门锁控制系统应允许车内解锁”派生为“BCM 在收到内开手柄信号且车速为 0 时应输出解锁控制指令”。下层需求是上层需求的技术展开不是并列关系。Satisfy满足/实现设计对象或低层需求满足高层需求。比如“门锁执行器应能在常温下承受不小于 200N 的解锁操作力”满足“门锁系统应具备可靠的机械开启功能”。Verify验证测试用例验证某条需求。比如测试用例“手动拉动内开手柄测量解锁电机电流和门锁状态”验证了“内开手柄解锁”这条需求。这三种链接各有各的用处。Derive 链路是需求精细化的过程适合做完整性检查——看看上层需求有没有漏拆出下层需求Satisfy 链路是设计对需求的承接关系适合做覆盖率分析Verify 链路是测试对需求的闭环适合做“需求-用例”追溯矩阵。在 DOORS 的链接属性里你还可以给链接本身加“链接描述”和“链接状态”比如“已评审”“待批准”。这个字段看着不起眼但在项目级评审时用处巨大你可以专门筛出所有“链接状态为待批准”的需求对逐个检查和拍板而不是每次都把整张追溯矩阵发给所有人靠肉眼找问题。2.4 完整性检查用矩阵把“断头需求”找出来拆完需求、建完链接之后不能急着开发一定要做一次完整性的“交通大检查”。DOORS 的 Traceability Matrix可追溯性矩阵视图就是干这个的。把模块拖进矩阵之后你会看到一张巨大的表格行是上层需求列是下层需求交叉点是链接标记。但这张表不是给你汇报用的而是给你“找漏洞”用的。典型的检查项有三类上层需求没有向下链接比如“车辆碰撞后应解除锁止”这条系统需求在矩阵里对应整行没有链接标记说明它没有拆解到任何下层需求也没有设计对象承接。这种需求是最大的风险点——它很可能会在开发中被遗忘直到测试阶段才发现没法执行。下层需求没有向上链接矩阵里某些对象整列没有链接标记说明它是“孤儿需求”——不知道哪里来的也不知道为什么存在。这种情况通常来自某个工程师私下添加的“自己想加的需求”未经评审就进入模块是典型的需求蔓延通道。安全需求没有 Verify 链接有些安全需求虽然拆到了组件级但测试模块里找不到对应的 Verify 链接说明测试计划根本没有覆盖这条需求。这在功能安全审计里是必须补齐的闭环。我第一次带项目做这个检查的时候矩阵拉出来几百条“断头”记录团队一下子对着屏幕沉默了。但恰恰是那次检查把很多原本会拖到装车阶段才发现的问题提前暴露了。所以我现在给所有项目的建议都是每次基线之前强制跑一遍三无检查——“无下游”“无上游”“无验证”把结果作为评审输入。这一步在 DOORS 里做起来很快但因为太快反而很多人懒得做这才是最可惜的。3. DOORS 实战操作流以“车门解锁功能”为例跑通全流程3.1 模块建立顺序与命名规则前面讲了规划这里讲实际操作。假设我们接了一个车门门锁系统的需求拆解任务目标是在 DOORS 里建立从整车到组件的需求追溯结构。我会这么操作第一步在 DOORS 里建立三个需求模块和一个测试模块。顺序上有讲究先建系统级模块VEH_Req_DoorLockFunction再建子系统模块DLS_Req_DoorLockSystem接着建组件级模块DLS_Req_BCM和DLS_Req_MotorActuator最后建测试用例模块DLS_Test_Spec。这样从上游逐级向下每条需求从哪来到哪去逻辑上是顺的。第二步在每个模块里先录入模块属性。模块属性不同于对象属性它描述的是这个模块本身的元信息比如“模块类型需求”“所属系统DLS”“适用车型项目A/B/C”。这一步很多人会跳过但它的价值在于当项目做大、模块数量到几十个之后你才能按类型、按车型快速筛选出正确的模块集合做出跨车型的派生报告。第三步确认对象属性的配置。在模块属性里把上一节说的“需求类型、来源、ASIL、验证方法、优先级、状态、责任部门”这些用户自定义属性User Defined Attribute加上去再设置哪些是必填项。比如 ASIL 和验证方法我通常会设为必填因为缺失它们后面做安全审计的时候必被挑战。模块命名的统一性也很重要。DOORS 会为模块生成对象 ID但那个 ID 是工具自增长的并不能直观表达业务语义。所以我会在模块内部用“需求编号”属性来承载业务编号规则比如DLS-SYS-001表示门锁系统需求DLS-BCM-SW-001表示 BCM 软件需求。这样外部评审时只看业务编号就能知道这条需求属于哪个层级而不需要查模块名。3.2 需求怎么“拆”从一句含糊口号到一组可验证条目新人在 DOORS 里拆需求的常见做法是把原本一句含糊的话改成稍微具体一点的几句话。这不算真正的拆分。拿上文的“车门应能正常解锁”来举例我会先把它重构成“整车系统需求”再逐级拆解。系统级需求放在VEH_Req_DoorLockFunction可能长这样VEH-SYS-012 车辆停止状态下应支持驾驶员通过遥控钥匙、内开手柄、外开手柄三种方式解锁四车门。这条需求描述的是“用户可感知的功能”不含任何技术实现方案。子系统级需求放在DLS_Req_DoorLockSystem就要把功能细化成门锁系统的边界DLS-SYS-021 门锁系统应检测遥控钥匙的解锁指令并在 300ms 内完成四个门锁执行器的解锁动作。 DLS-SYS-022 门锁系统应检测内开手柄动作信号当车速小于 5km/h 时触发对应车门的解锁动作。 DLS-SYS-027 碰撞信号触发时门锁系统应解除全车门锁止状态解锁响应时间应小于 200ms。这里能看到“拆分”的本质把一项整车级功能按照触发条件、执行对象、响应时间、边界状态等维度分解成多条独立的、可以单独验证的子系统需求。组件级需求放在DLS_Req_BCM和DLS_Req_MotorActuator此时软件和硬件开始分家。软件类的例如DLS-BCM-SW-001 BCM 软件应接收来自门锁开关的内开手柄硬线信号信号滤波时间不大于 20ms。 DLS-BCM-SW-002 BCM 软件应在车速小于 5km/h 且内开手柄信号有效时输出对应门锁执行器的解锁使能信号。硬件类的例如DLS-MTR-001 门锁执行器在 9V16V 工作电压范围内应能连续完成不小于 50 万次解锁/闭锁循环。 DLS-MTR-005 门锁执行器的解锁动作时间应不大于 180ms在 -40℃ 环境下不大于 300ms。你可以看到真正的拆分不是文字加长而是场景细化、指标量化、责任边界清晰化。到组件级时每条需求已经可以被某一位工程师拿走、按需求去实现或测试不再有“这到底归谁管”的问题。3.3 建链接把上下级关系在工具里固定下来需求录入完成后就要在 DOORS 里建立链接。实际操作上链接的方向我建议统一“从上游选到下游”先在系统级模块里选中一条需求再切换到下游模块选中对应的多条需求然后通过菜单或右键操作建立 Derivative派生链接。这样做的优点在于DOORS 会自动为下游对象建立反向链接你既能在下游对象上看到“被哪些上层需求派生”又能在上游对象上看到“拆解到了哪些下层需求”。建链接不是建完就完事。我习惯每隔一段时间就停下来问三个问题是不是每条系统级需求都至少有一条下游链接是不是每条下游需求都能沿着 Derive 链走回某条系统级需求链接的类型是不是都符合当初定义的语义有没有人把 Verify 链误建成了 Derive 链这三个问题看似机械但能帮你发现大量低级但致命的追溯错误。DOORS 里可以用 Filter 把“无链接对象”筛出来几秒钟就能拉全名单剩下的就是逐个分析和处理。3.4 用视图和过滤做日常输出不再重复造轮子DOORS 里有一个容易被低估的功能视图View和过滤Filter。说白了它就是一个“保存筛选条件”的功能但用好了能极大减少日常汇报和评审的准备工作。比如项目周会上你要汇报“当前门锁系统 ASIL C 需求的状态分布”。你不必在几十个模块里翻来翻去只需做这样一个视图模块范围DLS_Req_DoorLockSystemDLS_Req_BCM过滤条件ASIL C分组方式按“状态”属性分组显示列需求编号、需求描述、状态、验证方法保存之后每次开会前打开这个视图刷新一下就是最新状态直接截图放到周报里。再比如你要检查“所有验证方法为‘测试’但还没有对应 Verify 链接的需求”同样可以做成一个视图用来驱动测试部门补用例。我在很多项目里发现团队成员不是不会用 DOORS而是把大量时间花在“从工具里导出到 Excel然后在 Excel 里手工整理格式”上。视图和过滤用顺之后这类重复劳动至少减少一半而且导出数据的准确率高得多。3.5 基线的时机什么时候冻结需求什么时候走变更DOORS 里的基线Baseline功能是需求管理中最能体现“管控”价值的部分。它等价于给某个模块在当前时间点拍一张快照之后无论谁修改了模块内容你都可以随时回到基线对应的版本进行比对。没有基线DOORS 再强大也只是一块可以随时被覆盖的白板。那什么时候应该打基线我的经验是三个典型节点设计冻结节点系统需求完成评审、开始进入详细设计之前给系统需求模块打一条基线保证设计输入是稳定的。发标/定点节点整车项目向供应商发 SOR需求建议书或者与供应商技术定点时要把需求模块打基线作为后续合同附件和变更基准。重大变更完成节点一次需求变更走完评审流程、更新完所有受影响对象后再打一条新基线让变更前后的状态有清晰的对比依据。基线之后如果有新的需求调整就不应该直接在模块里改对象了。正确流程是在 DOORS 里发起变更先做影响分析看这个变更会通过链接影响哪些上下游需求然后提交 CCB变更控制委员会评审批准后再修改对象内容并更新状态属性最后重新打基线。这条链路看起来很繁琐但就是防止“谁都能随手改需求”的最后一道防线。4. 真正让人崩溃的从来不是软件DOORS 项目最常见的五个坑4.1 拆太细层级过深导致链接爆炸有的团队一心想把需求“模块化”结果模块建了七八层从整车到系统、子系统、子子系统、组件、硬件部件、软件架构、软件单元……每一层都建一堆链接。最后的结果是一条系统需求后面挂了几十上百个下游对象链接图密密麻麻像蜘蛛网一样。这带来两个问题第一维护成本失控。修改一条上游需求所有下行链路上的相关负责人都要被拉着确认一遍一个变更评审会开一下午会议纪要几十页。 第二追溯矩阵不再有决策价值。矩阵里全是标记反而看不出哪条需求重要、哪条链路有缺口。拆分的深度必须和项目规模与团队组织匹配。我的经验是大多数零部件项目三到四层需求就足够了。如果某一层纯粹是为了“让每个工程师都在这张网上有存在感”而设的就应该果断砍掉。你可以把组件级的信息合并到子系统或部件级让每一层需求背后都有一个可指认的负责人和至少一份可执行的验证活动。4.2 需求与设计混写一条需求里既讲“要什么”又讲“怎么做到”DOORS 模块里最让我头疼的内容是写着写着混进设计方案的“需求”。比如有人写“系统应采用 LIN 总线与门锁电机通信通信速率不低于 20kbps”。听起来很具体但这不是需求而是设计选择。为什么必须区分因为需求回答的是“系统必须做什么、做到什么程度”设计回答的是“用什么方式去实现”。如果需求里直接写死了 LIN 总线而后续验证发现 CAN 更合适或者成本部门希望换一条更便宜的通信方式这个需求就要改而如果需求写成“门锁系统应能接收来自 BCM 的解锁指令并驱动执行器完成解锁动作”你无论用 LIN 还是 CAN 实现需求本身都不用变。混写的最直接后果是需求变更频繁、基线毫无意义。因为设计优化每发生一次需求模块就要跟着改一次最后所有人都在改需求文档而不是在改设计文档。我常用的判断标准是如果这条描述删掉设计人员会失去一个实现约束但客户和系统需求依然可以被验证那它就不该放在需求模块里。设计应该放在设计文档或接口定义文件里DOORS 里保留需求即可。4.3 编号规则改来改去追溯链塌方的隐形元凶DOORS 中对象标识符Object Identifier是系统自动生成的一般不让你手工改。但很多项目会用“需求编号”这个属性来定义业务编号比如DLS-01-001。麻烦往往从这里开始。有一个项目最初编号规则是“子系统-序号”后来为了关联车型改成了“车型-子系统-序号”于是全模块几千条需求对象的编号属性被批量重写。结果呢几十个外部文件里引用的旧编号全部失效下游测试用例里的需求引用也乱了不得不花两周时间去对映射表。DOORS 里真正稳定的身份标识是系统内部的对象 ID而不是你自定义的业务编号。自定义编号本质上是给人看的改规则之前一定要评估所有下游引用场景。我的建议是编号规则在项目启动后尽量保持稳定如果确实要改通过新增一个“别名属性”记录旧编号而不是直接物理替换。这样一个新号一个旧号并存过渡期内谁都不至于找不到需求。4.4 权限和基线管控不到位实习生也能改基线模块很多团队在 DOORS 部署之初权限设置得非常随意所有人都是项目管理员所有模块都可读可写甚至能创建/删除对象。这在一个十人小团队里可能还行到二三十人、跨部门协作的时候就会出大问题。我见过一次事故是这样的某供应商工程师在给客户演示前误把客户刚打好的基线模块里的需求对象删了十几个然后保存了模块。虽然没有覆盖其他模块但那十几个对象所在基线的完整性已经被“污染”后来审计时只能通过后台记录去恢复和说明。教训就一句话能让人误操作改坏的东西一定会有人误操作改坏。所以权限设计这件事至少在“基线模块”这个层面必须收紧。你不需要对所有人都关闭写权限但至少要做到保持只读是默认状态加写权限走申请流程。基线版本的模块绝不直接在上面改需求改走变更流程。对象删除权限只对需求负责人开放普通成员只能改属性值不能删对象。工具层面的权限和流程层面的评审制度必须同时上否则光靠“大家自觉”迟早会出事故。4.5 链接只建向下、不建反向审计时才发现追溯是断的前面说过DOORS 建链接时会自动生成反向链接。但“自动生成反向链接”不等于“有人验证过反向链的完整性”。实际项目里最常见的现象是某个模块里大量需求有向下的 Derive 链接但往上一看根本找不到是哪条上层需求派生出来的。原因往往是某人从供应商模板里导入了一批下层需求直接粘贴到模块里链接没跟着生成。从下往上追溯时这条需求就成了“野需求”别人不知道它要满足什么也无法判断如果上层需求变更是该改它、删它还是保留它。解决这个问题不能靠大家自觉要靠定期的“反向追溯检查”。我通常在模块交付前跑一遍这样的检查选中整个模块。按“无入链”过滤看有哪些对象没有反向链接。对每个“无入链”对象判断它是顶层需求允许无入链还是底层需求必须有入链。对底层需求补齐缺失的 Derive 链接。这个过程最多花上一两个小时但能省掉后期审计阶段几个星期的加班。可追溯性的价值不在于“看起来好看”而在于当变更来临时你能精确知道影响范围。这个能力平时用不着一旦暴发就是救命级的。5. 把 DOORS 用成项目资产而不是“文档囚笼”的几个经验5.1 沉淀模板库让新项目从“复制粘贴”开始如果你做了几年需求管理手头应该积累了各种类型零部件或系统的需求模块。这些项目的 DOORS 模块本身就有很大的复用价值。每次新项目启动时不应该从零开始写需求而应该回到旧项目的基线上把适用本车型、本方功能范围的那部分模块复制出来再结合新项目需求做增删改。这就是模块化拆分的另一层收益好的需求模块结构本质上是一种可复用的“元需求”。比如门锁系统的系统级需求、碰撞解锁的安全需求、环境适应性需求这些在很多车型项目里是通用的。只要你在第一个项目里把结构设计好了第二个、第三个项目就能成倍节省时间而且还能保证不同项目之间需求口径的一致性。操作上你可以在 DOORS 里建一个“模板模块库”文件夹把经过多个项目验证的模块放进去每次新项目启动时从模板库拷贝模块副本。这样既避免了重复编写又保证了“模板版本”随项目经验持续迭代。5.2 与工具链配合DOORS 不是孤立使用的汽车项目的需求管理不是 DOORS 一个工具包打天下。DOORS 的强项是需求结构化与追溯但它不擅长任务跟踪、代码版本管理和问题闭环。在真实项目里DOORS 通常要和 ALM 平台、问题跟踪系统、变更管理系统协同工作。常见配合方式是需求变更在 DOORS 里发起变更评审通过后在任务管理系统里创建工作项分配给相关工程师。软件开发任务完成后通过接口工具把 DOORS 需求与代码提交记录/测试报告关联起来。测试团队在测试执行平台里跑完用例再把结果回传到 DOORS 的 Verify 链接上形成“需求-用例-结果”闭环。这些集成如果做得好每次导出追溯报告时不仅仅是“需求有了测试用例”还能看到“需求最近一次测试通过还是失败”。这才是功能安全和 ASPICE 里真正想要的追溯证据。如果你们公司目前只有 DOORS 没有集成平台也别灰心先用 Excel 导出 人工维护链接状态至少保证数据的准确性等平台建设跟上后再自动同步。5.3 有选择地学一点 DXL别让重复劳动耗尽耐心DOORS 内置的脚本语言叫 DXLDOORS eXtension Language。对大多数需求工程师来说不需要成为 DXL 专家但掌握几个常用脚本会让你少加很多班。举几个例子自动检查“无入链/无出链对象”并输出报告。批量设置某些属性的默认值。按模板导出 Word/Excel 评审文件直接套用公司模板格式。对比两个模块的差异高亮显示不同对象。我第一次接触 DXL 是被逼的。当时要在一个几百条需求的大模块里逐条核对“验证方法”属性人工检查一遍需要两个晚上。后来花了一个下午写了十几行 DXL把不符合枚举值的对象全部列出来十秒钟出结果。从那时起我意识到工具的真正威力不是“把一条条数据录进去”而是“能快速把数据变成决策信息”。但也别一头扎进脚本里出不来。DXL 的定位是辅助不是核心。核心永远是需求拆得清、链接建得对、基线管得住。工具和脚本只是帮你把这些事情做得更高效仅此而已。最后再分享一个小技巧DOORS 模块里每条需求第一行我会习惯用一句话概括本条需求的核心含义比如“碰撞后解除锁止”。这样在追溯矩阵里快速扫视时不用展开看全文就能知道这条需求在讲什么。带过的团队里凡是坚持这个习惯的在评审、审计和交接时的效率都明显高出一截。工具是死的但使用工具的人如果能把小小的习惯坚持下去整个项目的需求质量就会往上走一个台阶。
很多项目在需求阶段看不出问题一出问题就是大问题。比如一条“车门应能正常解锁”的需求在不同人手里会变成完全不同的东西底盘的人觉得是门锁电机的事车身的人觉得是锁体结构的事电子的人觉得是BCM车身控制模块程序的事测试的人根本不知道拿什么标准去验证。我见过不止一个项目图纸发下去了、软件也写完了才发现大家理解的“正常解锁”根本不是一回事最后只能返工改需求、改设计、改测试用例代价惨痛。DOORS 这类需求管理工具在汽车行业里被大量使用恰恰就是为了治这个病。它不是写文档的编辑器而是一条承载“从整车级愿景到子系统、再到零部件软硬件需求”的追溯链让每条需求都有来源、有去处、有验证方法。但工具只是工具真正拉开差距的是“怎么拆”。这也就是这篇博文想聊的重点结合汽车设计里的具体场景讲清楚 DOORS 里的模块化需求拆分怎么做拆到什么粒度合适链接怎么建才不会翻车以及在真实项目里最容易踩的坑。无论你是刚接手需求管理工作的工程师还是被 DOORS 折磨得想摔鼠标的项目经理这篇文章应该都能给你一些可以直接用的思路。1. 一条车门需求引发的连锁问题为什么拆需求会拆出一堆返工1.1 一个真实的口径混乱现场先还原一下我在评审会上见过的场景。OEM主机厂给供应商发了一版需求里面有一条写得特别简洁“车门应能正常解锁”。供应商那边拿着这条需求机械工程师理解成“门锁机构的开启行程要足够”电子工程师理解成“BCM要能驱动门锁电机”软件工程师理解成“解锁指令的通信协议要正确”测试工程师就更头疼——他根本不知道“正常”是怎么定义出来的最后只能凭经验自己编测试用例。这种看似“没问题”的含糊需求在汽车这种复杂产品里几乎必然引发连锁返工。为什么因为“正常解锁”背后其实藏着一大堆场景整车下电后驾驶员在车内拉动内开手柄能不能解锁车速超过某个阈值后门锁是否处于锁止状态车辆发生碰撞后门锁是否能够满足解锁要求方便救援儿童锁开启时从内侧拉手柄无法开门但外侧手柄可以这是否算“正常”长期停放后蓄电池电压偏低门锁电机能否在低压状态下可靠动作插入机械钥匙旋转时锁芯驱动机构与电控解锁是否共用一套传动路径每一条背后都对应不同的子系统、不同的设计约束、不同的测试验证方法。而这些信息如果不在需求阶段拆开、标注清楚到设计评审、测试执行的时候就是各干各的谁也说不清当初那条需求到底指向什么。这其实是需求管理里最底层的认知需求必须拆到“可验证”的粒度。如果一条需求写完你找不到一个明确的验证动作和通过准则那它就还不算需求只能算一句含糊的愿望。1.2 DOORS 在汽车需求链中的确切位置很多刚接触 DOORS 的人会把它当成一种“可以多人协作的 Excel”或者“带链接的 Word”。这种理解不能说错但它会让你用错方向。DOORS 的价值不在于“打字方便”而在于它把需求变成了一组带有属性的对象并通过链接建立起网状追溯结构。在 ASPICE 和 ISO 26262 的落地流程里DOORS 通常承担这样几个角色需求条目的唯一存放地与状态管控点所有经过评审确认的需求在 DOORS 里以对象形式存在每条对象有独立 ID、属性、基线和变更记录。系统需求到子系统、软硬件需求的追溯载体设计上游的“系统需求”通过 Derive 链接派生到下游的“子系统需求”“部件需求”每一条下层需求都能顺链找到它满足的是哪条上层需求。合规审计的证据链ISO 26262 明确要求需求具备双向可追溯性bidirectional traceability也就是从安全目标往下能追到某条需求和测试用例从某条需求和测试用例往上能追到安全目标。DOORS 的可追溯性矩阵视图就是把这些证据一键拉出来的地方。换句话说DOORS 在汽车需求链里的位置是“全链条需求对象的数据库追溯关系网”。脱离这个定位去用只在里面写大段大段的文字描述而不去建链接、不管属性、不打基线那它确实还不如一个共享盘里的 Word 好用。这也是很多项目上了 DOORS 却依然混乱的根本原因——不是软件不行是拆解和使用的思路没到位。2. 模块化拆分的骨架与链接语义先把 DOORS 里的“地图”画对2.1 先定层级骨架系统级、子系统级、组件级到底分几层我见过不少团队打开 DOORS 就开始哐哐建模块、写需求写到一半才发现层级不对有的需求写在了太上层有的设计细节混进了需求模块整个追溯链乱成一锅粥。正确做法是动手之前先画“需求层级地图”也就是规划好你打算在 DOORS 里建立哪些层级模块、每个模块放什么类型的信息。在汽车设计领域我常用的分层方式是这样的层级模块名称示例主要内容典型需求来源系统级VEH_System_Req整车系统需求整车功能、性能、安全、法规相关需求产品定义、法规、市场调研子系统级DLS_DoorLockSystem_Req门锁系统需求门锁系统的功能、性能、接口、环境需求系统级需求分解组件级DLS_BCM_Req / DLS_Lock_motor_ReqBCM 软件需求、门锁电机硬件需求子系统需求分解测试级DLS_Test_Spec测试用例模块对应需求的验证用例需求验证策略这张表看着简单但实际项目里最大的争议在于到底分几层才合适我的判断标准有两条拆到“可验证”为止。如果某条需求还无法直接对应测试用例或设计约束说明它还需要往下拆。拆到“变更影响可控”为止。如果某一层需求的每次变更会牵连几十个其他对象说明它拆得太粗如果改一个很小的设计就要动四层需求说明拆得太细。以门锁系统为例子系统级可能就写“系统应支持遥控解锁/闭锁功能”“车辆发生碰撞后门锁控制系统应解除锁止状态”。这些需求要展开成组件级需求时已经带有“安全状态”“逻辑判定”“执行机构”这些技术语境需要对应到 BCM 软件功能、门锁机械结构、通信链路等具体对象。这个拆解的过程本质上是由“功能愿景”向“技术边界”逐层落地的过程。模块的命名规则也值得在项目启动时统一比如子系统代码_模块类型_说明DLS_Req_DoorLockFunc表示门锁系统功能需求模块DLS_Trace_Verification表示门锁系统验证追溯模块。命名规则定好之后整个项目里的模块清单一目了然。2.2 属性设计让每条需求自带“上下文标签”在 DOORS 里需求对象的内容不仅仅是那一段文字属性Attribute才是支撑后续分析、过滤、导出的关键。你可以把属性理解为贴在每条需求上的标签这条需求是谁提的、属于什么类型、安全等级多高、用什么方法验证、当前状态如何、优先级多高。没有属性的需求就是一堆孤零零的文字只能靠人肉阅读去理解有了属性你才能用视图View和过滤器Filter自动把“所有 ASIL C 级且尚未验证的软件需求”拎出来。围绕汽车门锁这类零部件我一般会给需求对象建立这样一组基础属性需求类型功能需求、性能需求、接口需求、安全需求、法规需求、可维护性需求。来源客户需求、内部企划、法规条款、历史变更、平台复用。ASIL 等级QM / A / B / C / D关联到功能安全评估。这在 ISO 26262 背景下几乎是必备属性。验证方法测试Test、检查Inspection、分析Analysis、演示Demonstration。这个属性直接决定这条需求以后挂到哪种验证对象上。优先级高 / 中 / 低用于决定开发顺序和资源投入。状态草稿、已完成、已评审、已基线、已变更、已批准。责任部门/责任人便于按团队过滤和分派。属性设计听起来不复杂但真正做起来有三个细节容易翻车第一属性不是越多越好。有的人恨不得塞二十个属性结果录入负担巨大后面没人维护属性值全是空的反而变成垃圾信息。我建议核心属性控制在七个以内其他信息放到附录或说明字段里。第二属性值的枚举要提前定死。比如“验证方法”只允许四选一不要在文档里写什么“测试分析”这类模糊组合否则后面做追溯矩阵的时候数据根本没法机器过滤。第三属性要有负责人。需求对象的“状态”是谁来更新通常是需求负责人。如果这个机制没定清楚DOORS 里的状态属性会永远停留在“草稿”等于白设。2.3 链接类型怎么建Derive、Satisfy、Verify 不要混用DOORS 里最容易混乱的地方就是链接。很多团队建了链接但建得毫无章法有些链接表示“衍生”有些表示“满足”有些表示“验证”全搅在一起。等要做可追溯性分析的时候根本分不清一条链接到底是“来源于”还是“被验证”整个追溯网络就成了装饰品。我习惯在项目启动时就把链接语义定义清楚最常用的三种Derive派生上层需求分解、细化出下层需求。比如“车辆停止时门锁控制系统应允许车内解锁”派生为“BCM 在收到内开手柄信号且车速为 0 时应输出解锁控制指令”。下层需求是上层需求的技术展开不是并列关系。Satisfy满足/实现设计对象或低层需求满足高层需求。比如“门锁执行器应能在常温下承受不小于 200N 的解锁操作力”满足“门锁系统应具备可靠的机械开启功能”。Verify验证测试用例验证某条需求。比如测试用例“手动拉动内开手柄测量解锁电机电流和门锁状态”验证了“内开手柄解锁”这条需求。这三种链接各有各的用处。Derive 链路是需求精细化的过程适合做完整性检查——看看上层需求有没有漏拆出下层需求Satisfy 链路是设计对需求的承接关系适合做覆盖率分析Verify 链路是测试对需求的闭环适合做“需求-用例”追溯矩阵。在 DOORS 的链接属性里你还可以给链接本身加“链接描述”和“链接状态”比如“已评审”“待批准”。这个字段看着不起眼但在项目级评审时用处巨大你可以专门筛出所有“链接状态为待批准”的需求对逐个检查和拍板而不是每次都把整张追溯矩阵发给所有人靠肉眼找问题。2.4 完整性检查用矩阵把“断头需求”找出来拆完需求、建完链接之后不能急着开发一定要做一次完整性的“交通大检查”。DOORS 的 Traceability Matrix可追溯性矩阵视图就是干这个的。把模块拖进矩阵之后你会看到一张巨大的表格行是上层需求列是下层需求交叉点是链接标记。但这张表不是给你汇报用的而是给你“找漏洞”用的。典型的检查项有三类上层需求没有向下链接比如“车辆碰撞后应解除锁止”这条系统需求在矩阵里对应整行没有链接标记说明它没有拆解到任何下层需求也没有设计对象承接。这种需求是最大的风险点——它很可能会在开发中被遗忘直到测试阶段才发现没法执行。下层需求没有向上链接矩阵里某些对象整列没有链接标记说明它是“孤儿需求”——不知道哪里来的也不知道为什么存在。这种情况通常来自某个工程师私下添加的“自己想加的需求”未经评审就进入模块是典型的需求蔓延通道。安全需求没有 Verify 链接有些安全需求虽然拆到了组件级但测试模块里找不到对应的 Verify 链接说明测试计划根本没有覆盖这条需求。这在功能安全审计里是必须补齐的闭环。我第一次带项目做这个检查的时候矩阵拉出来几百条“断头”记录团队一下子对着屏幕沉默了。但恰恰是那次检查把很多原本会拖到装车阶段才发现的问题提前暴露了。所以我现在给所有项目的建议都是每次基线之前强制跑一遍三无检查——“无下游”“无上游”“无验证”把结果作为评审输入。这一步在 DOORS 里做起来很快但因为太快反而很多人懒得做这才是最可惜的。3. DOORS 实战操作流以“车门解锁功能”为例跑通全流程3.1 模块建立顺序与命名规则前面讲了规划这里讲实际操作。假设我们接了一个车门门锁系统的需求拆解任务目标是在 DOORS 里建立从整车到组件的需求追溯结构。我会这么操作第一步在 DOORS 里建立三个需求模块和一个测试模块。顺序上有讲究先建系统级模块VEH_Req_DoorLockFunction再建子系统模块DLS_Req_DoorLockSystem接着建组件级模块DLS_Req_BCM和DLS_Req_MotorActuator最后建测试用例模块DLS_Test_Spec。这样从上游逐级向下每条需求从哪来到哪去逻辑上是顺的。第二步在每个模块里先录入模块属性。模块属性不同于对象属性它描述的是这个模块本身的元信息比如“模块类型需求”“所属系统DLS”“适用车型项目A/B/C”。这一步很多人会跳过但它的价值在于当项目做大、模块数量到几十个之后你才能按类型、按车型快速筛选出正确的模块集合做出跨车型的派生报告。第三步确认对象属性的配置。在模块属性里把上一节说的“需求类型、来源、ASIL、验证方法、优先级、状态、责任部门”这些用户自定义属性User Defined Attribute加上去再设置哪些是必填项。比如 ASIL 和验证方法我通常会设为必填因为缺失它们后面做安全审计的时候必被挑战。模块命名的统一性也很重要。DOORS 会为模块生成对象 ID但那个 ID 是工具自增长的并不能直观表达业务语义。所以我会在模块内部用“需求编号”属性来承载业务编号规则比如DLS-SYS-001表示门锁系统需求DLS-BCM-SW-001表示 BCM 软件需求。这样外部评审时只看业务编号就能知道这条需求属于哪个层级而不需要查模块名。3.2 需求怎么“拆”从一句含糊口号到一组可验证条目新人在 DOORS 里拆需求的常见做法是把原本一句含糊的话改成稍微具体一点的几句话。这不算真正的拆分。拿上文的“车门应能正常解锁”来举例我会先把它重构成“整车系统需求”再逐级拆解。系统级需求放在VEH_Req_DoorLockFunction可能长这样VEH-SYS-012 车辆停止状态下应支持驾驶员通过遥控钥匙、内开手柄、外开手柄三种方式解锁四车门。这条需求描述的是“用户可感知的功能”不含任何技术实现方案。子系统级需求放在DLS_Req_DoorLockSystem就要把功能细化成门锁系统的边界DLS-SYS-021 门锁系统应检测遥控钥匙的解锁指令并在 300ms 内完成四个门锁执行器的解锁动作。 DLS-SYS-022 门锁系统应检测内开手柄动作信号当车速小于 5km/h 时触发对应车门的解锁动作。 DLS-SYS-027 碰撞信号触发时门锁系统应解除全车门锁止状态解锁响应时间应小于 200ms。这里能看到“拆分”的本质把一项整车级功能按照触发条件、执行对象、响应时间、边界状态等维度分解成多条独立的、可以单独验证的子系统需求。组件级需求放在DLS_Req_BCM和DLS_Req_MotorActuator此时软件和硬件开始分家。软件类的例如DLS-BCM-SW-001 BCM 软件应接收来自门锁开关的内开手柄硬线信号信号滤波时间不大于 20ms。 DLS-BCM-SW-002 BCM 软件应在车速小于 5km/h 且内开手柄信号有效时输出对应门锁执行器的解锁使能信号。硬件类的例如DLS-MTR-001 门锁执行器在 9V16V 工作电压范围内应能连续完成不小于 50 万次解锁/闭锁循环。 DLS-MTR-005 门锁执行器的解锁动作时间应不大于 180ms在 -40℃ 环境下不大于 300ms。你可以看到真正的拆分不是文字加长而是场景细化、指标量化、责任边界清晰化。到组件级时每条需求已经可以被某一位工程师拿走、按需求去实现或测试不再有“这到底归谁管”的问题。3.3 建链接把上下级关系在工具里固定下来需求录入完成后就要在 DOORS 里建立链接。实际操作上链接的方向我建议统一“从上游选到下游”先在系统级模块里选中一条需求再切换到下游模块选中对应的多条需求然后通过菜单或右键操作建立 Derivative派生链接。这样做的优点在于DOORS 会自动为下游对象建立反向链接你既能在下游对象上看到“被哪些上层需求派生”又能在上游对象上看到“拆解到了哪些下层需求”。建链接不是建完就完事。我习惯每隔一段时间就停下来问三个问题是不是每条系统级需求都至少有一条下游链接是不是每条下游需求都能沿着 Derive 链走回某条系统级需求链接的类型是不是都符合当初定义的语义有没有人把 Verify 链误建成了 Derive 链这三个问题看似机械但能帮你发现大量低级但致命的追溯错误。DOORS 里可以用 Filter 把“无链接对象”筛出来几秒钟就能拉全名单剩下的就是逐个分析和处理。3.4 用视图和过滤做日常输出不再重复造轮子DOORS 里有一个容易被低估的功能视图View和过滤Filter。说白了它就是一个“保存筛选条件”的功能但用好了能极大减少日常汇报和评审的准备工作。比如项目周会上你要汇报“当前门锁系统 ASIL C 需求的状态分布”。你不必在几十个模块里翻来翻去只需做这样一个视图模块范围DLS_Req_DoorLockSystemDLS_Req_BCM过滤条件ASIL C分组方式按“状态”属性分组显示列需求编号、需求描述、状态、验证方法保存之后每次开会前打开这个视图刷新一下就是最新状态直接截图放到周报里。再比如你要检查“所有验证方法为‘测试’但还没有对应 Verify 链接的需求”同样可以做成一个视图用来驱动测试部门补用例。我在很多项目里发现团队成员不是不会用 DOORS而是把大量时间花在“从工具里导出到 Excel然后在 Excel 里手工整理格式”上。视图和过滤用顺之后这类重复劳动至少减少一半而且导出数据的准确率高得多。3.5 基线的时机什么时候冻结需求什么时候走变更DOORS 里的基线Baseline功能是需求管理中最能体现“管控”价值的部分。它等价于给某个模块在当前时间点拍一张快照之后无论谁修改了模块内容你都可以随时回到基线对应的版本进行比对。没有基线DOORS 再强大也只是一块可以随时被覆盖的白板。那什么时候应该打基线我的经验是三个典型节点设计冻结节点系统需求完成评审、开始进入详细设计之前给系统需求模块打一条基线保证设计输入是稳定的。发标/定点节点整车项目向供应商发 SOR需求建议书或者与供应商技术定点时要把需求模块打基线作为后续合同附件和变更基准。重大变更完成节点一次需求变更走完评审流程、更新完所有受影响对象后再打一条新基线让变更前后的状态有清晰的对比依据。基线之后如果有新的需求调整就不应该直接在模块里改对象了。正确流程是在 DOORS 里发起变更先做影响分析看这个变更会通过链接影响哪些上下游需求然后提交 CCB变更控制委员会评审批准后再修改对象内容并更新状态属性最后重新打基线。这条链路看起来很繁琐但就是防止“谁都能随手改需求”的最后一道防线。4. 真正让人崩溃的从来不是软件DOORS 项目最常见的五个坑4.1 拆太细层级过深导致链接爆炸有的团队一心想把需求“模块化”结果模块建了七八层从整车到系统、子系统、子子系统、组件、硬件部件、软件架构、软件单元……每一层都建一堆链接。最后的结果是一条系统需求后面挂了几十上百个下游对象链接图密密麻麻像蜘蛛网一样。这带来两个问题第一维护成本失控。修改一条上游需求所有下行链路上的相关负责人都要被拉着确认一遍一个变更评审会开一下午会议纪要几十页。 第二追溯矩阵不再有决策价值。矩阵里全是标记反而看不出哪条需求重要、哪条链路有缺口。拆分的深度必须和项目规模与团队组织匹配。我的经验是大多数零部件项目三到四层需求就足够了。如果某一层纯粹是为了“让每个工程师都在这张网上有存在感”而设的就应该果断砍掉。你可以把组件级的信息合并到子系统或部件级让每一层需求背后都有一个可指认的负责人和至少一份可执行的验证活动。4.2 需求与设计混写一条需求里既讲“要什么”又讲“怎么做到”DOORS 模块里最让我头疼的内容是写着写着混进设计方案的“需求”。比如有人写“系统应采用 LIN 总线与门锁电机通信通信速率不低于 20kbps”。听起来很具体但这不是需求而是设计选择。为什么必须区分因为需求回答的是“系统必须做什么、做到什么程度”设计回答的是“用什么方式去实现”。如果需求里直接写死了 LIN 总线而后续验证发现 CAN 更合适或者成本部门希望换一条更便宜的通信方式这个需求就要改而如果需求写成“门锁系统应能接收来自 BCM 的解锁指令并驱动执行器完成解锁动作”你无论用 LIN 还是 CAN 实现需求本身都不用变。混写的最直接后果是需求变更频繁、基线毫无意义。因为设计优化每发生一次需求模块就要跟着改一次最后所有人都在改需求文档而不是在改设计文档。我常用的判断标准是如果这条描述删掉设计人员会失去一个实现约束但客户和系统需求依然可以被验证那它就不该放在需求模块里。设计应该放在设计文档或接口定义文件里DOORS 里保留需求即可。4.3 编号规则改来改去追溯链塌方的隐形元凶DOORS 中对象标识符Object Identifier是系统自动生成的一般不让你手工改。但很多项目会用“需求编号”这个属性来定义业务编号比如DLS-01-001。麻烦往往从这里开始。有一个项目最初编号规则是“子系统-序号”后来为了关联车型改成了“车型-子系统-序号”于是全模块几千条需求对象的编号属性被批量重写。结果呢几十个外部文件里引用的旧编号全部失效下游测试用例里的需求引用也乱了不得不花两周时间去对映射表。DOORS 里真正稳定的身份标识是系统内部的对象 ID而不是你自定义的业务编号。自定义编号本质上是给人看的改规则之前一定要评估所有下游引用场景。我的建议是编号规则在项目启动后尽量保持稳定如果确实要改通过新增一个“别名属性”记录旧编号而不是直接物理替换。这样一个新号一个旧号并存过渡期内谁都不至于找不到需求。4.4 权限和基线管控不到位实习生也能改基线模块很多团队在 DOORS 部署之初权限设置得非常随意所有人都是项目管理员所有模块都可读可写甚至能创建/删除对象。这在一个十人小团队里可能还行到二三十人、跨部门协作的时候就会出大问题。我见过一次事故是这样的某供应商工程师在给客户演示前误把客户刚打好的基线模块里的需求对象删了十几个然后保存了模块。虽然没有覆盖其他模块但那十几个对象所在基线的完整性已经被“污染”后来审计时只能通过后台记录去恢复和说明。教训就一句话能让人误操作改坏的东西一定会有人误操作改坏。所以权限设计这件事至少在“基线模块”这个层面必须收紧。你不需要对所有人都关闭写权限但至少要做到保持只读是默认状态加写权限走申请流程。基线版本的模块绝不直接在上面改需求改走变更流程。对象删除权限只对需求负责人开放普通成员只能改属性值不能删对象。工具层面的权限和流程层面的评审制度必须同时上否则光靠“大家自觉”迟早会出事故。4.5 链接只建向下、不建反向审计时才发现追溯是断的前面说过DOORS 建链接时会自动生成反向链接。但“自动生成反向链接”不等于“有人验证过反向链的完整性”。实际项目里最常见的现象是某个模块里大量需求有向下的 Derive 链接但往上一看根本找不到是哪条上层需求派生出来的。原因往往是某人从供应商模板里导入了一批下层需求直接粘贴到模块里链接没跟着生成。从下往上追溯时这条需求就成了“野需求”别人不知道它要满足什么也无法判断如果上层需求变更是该改它、删它还是保留它。解决这个问题不能靠大家自觉要靠定期的“反向追溯检查”。我通常在模块交付前跑一遍这样的检查选中整个模块。按“无入链”过滤看有哪些对象没有反向链接。对每个“无入链”对象判断它是顶层需求允许无入链还是底层需求必须有入链。对底层需求补齐缺失的 Derive 链接。这个过程最多花上一两个小时但能省掉后期审计阶段几个星期的加班。可追溯性的价值不在于“看起来好看”而在于当变更来临时你能精确知道影响范围。这个能力平时用不着一旦暴发就是救命级的。5. 把 DOORS 用成项目资产而不是“文档囚笼”的几个经验5.1 沉淀模板库让新项目从“复制粘贴”开始如果你做了几年需求管理手头应该积累了各种类型零部件或系统的需求模块。这些项目的 DOORS 模块本身就有很大的复用价值。每次新项目启动时不应该从零开始写需求而应该回到旧项目的基线上把适用本车型、本方功能范围的那部分模块复制出来再结合新项目需求做增删改。这就是模块化拆分的另一层收益好的需求模块结构本质上是一种可复用的“元需求”。比如门锁系统的系统级需求、碰撞解锁的安全需求、环境适应性需求这些在很多车型项目里是通用的。只要你在第一个项目里把结构设计好了第二个、第三个项目就能成倍节省时间而且还能保证不同项目之间需求口径的一致性。操作上你可以在 DOORS 里建一个“模板模块库”文件夹把经过多个项目验证的模块放进去每次新项目启动时从模板库拷贝模块副本。这样既避免了重复编写又保证了“模板版本”随项目经验持续迭代。5.2 与工具链配合DOORS 不是孤立使用的汽车项目的需求管理不是 DOORS 一个工具包打天下。DOORS 的强项是需求结构化与追溯但它不擅长任务跟踪、代码版本管理和问题闭环。在真实项目里DOORS 通常要和 ALM 平台、问题跟踪系统、变更管理系统协同工作。常见配合方式是需求变更在 DOORS 里发起变更评审通过后在任务管理系统里创建工作项分配给相关工程师。软件开发任务完成后通过接口工具把 DOORS 需求与代码提交记录/测试报告关联起来。测试团队在测试执行平台里跑完用例再把结果回传到 DOORS 的 Verify 链接上形成“需求-用例-结果”闭环。这些集成如果做得好每次导出追溯报告时不仅仅是“需求有了测试用例”还能看到“需求最近一次测试通过还是失败”。这才是功能安全和 ASPICE 里真正想要的追溯证据。如果你们公司目前只有 DOORS 没有集成平台也别灰心先用 Excel 导出 人工维护链接状态至少保证数据的准确性等平台建设跟上后再自动同步。5.3 有选择地学一点 DXL别让重复劳动耗尽耐心DOORS 内置的脚本语言叫 DXLDOORS eXtension Language。对大多数需求工程师来说不需要成为 DXL 专家但掌握几个常用脚本会让你少加很多班。举几个例子自动检查“无入链/无出链对象”并输出报告。批量设置某些属性的默认值。按模板导出 Word/Excel 评审文件直接套用公司模板格式。对比两个模块的差异高亮显示不同对象。我第一次接触 DXL 是被逼的。当时要在一个几百条需求的大模块里逐条核对“验证方法”属性人工检查一遍需要两个晚上。后来花了一个下午写了十几行 DXL把不符合枚举值的对象全部列出来十秒钟出结果。从那时起我意识到工具的真正威力不是“把一条条数据录进去”而是“能快速把数据变成决策信息”。但也别一头扎进脚本里出不来。DXL 的定位是辅助不是核心。核心永远是需求拆得清、链接建得对、基线管得住。工具和脚本只是帮你把这些事情做得更高效仅此而已。最后再分享一个小技巧DOORS 模块里每条需求第一行我会习惯用一句话概括本条需求的核心含义比如“碰撞后解除锁止”。这样在追溯矩阵里快速扫视时不用展开看全文就能知道这条需求在讲什么。带过的团队里凡是坚持这个习惯的在评审、审计和交接时的效率都明显高出一截。工具是死的但使用工具的人如果能把小小的习惯坚持下去整个项目的需求质量就会往上走一个台阶。
