需求正文改了，历史记录也能查到，下游对象却没有出现可疑提示，这时不能只检查链接是否存在。DOORS会根据属性设置和关联对象的变化判断可疑状态，显示结果还受到链接方向、检查范围及访问权限影响。另一个容易看错的地方是：只修改一端对象时，应到关联的另一端检查提示。以下操作适用于DOORS 9.x经典客户端中的标准对象链接。

　　一、DOORS如何识别需求变更引起的可疑关联链接

　　可疑标记用于提醒关联内容需要重新检查，并不直接说明关系已经失效。先把受影响对象找出来，再查看引起提示的具体修改。

　　1、在关联模块中显示可疑指示符

　　修改源对象后，目标对象可能出现可疑入向链接；修改目标对象后，则应在源对象检查可疑出向链接。不能只停留在刚刚编辑的那条需求上查看。

　　①打开相关正式模块，选择【分析】→【可疑链接】→【显示指示符】。

　　②按实际链接方向选择【入向链接】或【出向链接】，排查时可分别检查两个方向。

　　③将检查范围设为【所有模块】，避免仅检查已打开模块而漏掉关联对象。

　　④需要集中查看时，使用【分析】→【可疑链接】→【过滤】，选择对应方向和范围。

　　2、查看引起可疑状态的修改

　　①选择【分析】→【可疑链接】→【显示上次更改】，查看最近一次相关修改。

　　②需要完整信息时，使用【显示所有更改】，核对关联模块路径、对象编号及属性名称。

　　③根据显示的对象编号打开关联需求，比较修改后的内容及对应设计或验证要求。

　　同一个对象可能有多条可疑链接，涉及不同模块。显示全部更改后，可以查看自上次清除可疑状态以来的相关修改。若提示涉及基线，应继续查看对应历史，不能把当前列里没有展开的内容当作没有变化。

　　二、DOORS修改需求后关联链接未标记可疑如何排查

　　可以先挑一对编号明确的对象检查。保留现有链接和历史，避免通过删除、重建关系来试探，否则原来的问题条件也会被改变。

　　1、检查修改属性是否影响更改日期

　　属性定义中的“影响更改日期”决定该属性的编辑是否更新相应修改日期。生成历史记录、更新变换指示符与这个选项各有用途，不能相互替代。

　　①以【互斥编辑】方式打开模块，进入【编辑】→【属性】。

　　②选中本次实际修改的属性，点击【编辑】，打开【常规】选项卡。

　　③检查【影响更改日期（Affect change dates）】，按项目规则启用需要参与变更追踪的属性。

　　④点击【确定】并通过【文件】→【保存】保存模块设置。

　　补选该选项后，应通过新的受控修改验证效果，已有修改的影响仍需人工检查。也不宜为了让提示出现就勾选所有辅助字段，否则频繁变化的统计或维护信息可能带来大量待核对项。

　　2、确认检查的是实际对象链接

　　①核对需求对象的编号和模块完整路径，排除同名模块、复制对象或旧版本。

　　②在数据库浏览器中选择【视图】→【显示链接模块】，打开对应链接模块。

　　③在【链接集】中检查来源、目标模块及实际连接的对象。

　　正文中的超链接、属性里填写的需求编号，不等于标准对象链接。链接模块可能包含多个链接集，模块配对存在，也不代表本次修改的对象已经连到预期目标。应沿实际链接检查，不能只凭追踪表里的一段文字判断。

　　3、排除显示范围和权限造成的遗漏

　　①在【可疑链接】菜单中重新检查入向、出向及【所有模块】范围。

　　②打开关联模块，确认当前账号能够读取相关【需求对象】。

　　③检查当前视图的【过滤】条件，恢复需要查看的对象范围。

　　只能看到部分对象的账号，无法显示其无权读取对象的可疑链接信息。另一个常见误会是只检查已打开模块，而真正发生变化的关联模块尚未打开。可先用一对可读取的对象验证，再扩大检查范围。

　　4、核对是否已经清除或查看了旧版本

　　①选中修改对象，打开【对象属性】→【历史记录】，确认修改确实发生在所查看版本中。

　　②核对近期是否执行过【清除】或【全部清除】，并检查相关脚本中的清除操作。

　　③返回模块当前版本，再运行【显示所有更改】检查关联信息。

　　两端对象都发生修改时，从一端清除同一条链接的可疑状态，也会影响另一端。当前没有标记，不能反推出它从未触发过。基线则是固定版本，不应期待它持续反映当前需求的后续编辑。

　　三、DOORS怎样验证触发设置并处理已评估的可疑链接

　　配置是否有效，可以在测试模块中验证；正式需求上的标记，则应在影响评估完成后处理。两件事不要混在同一次试操作里。

　　1、用一对测试对象验证触发方向

　　①在测试正式模块中选择一对已建立标准链接的【对象】，记录双方编号和方向。

　　②选择已启用【影响更改日期】的属性，做一次明确的值修改并保存。

　　③到另一端模块执行【显示指示符】，检查对应入向或出向链接。

　　④再执行【显示上次更改】，核对提示中的属性和修改内容。

　　这次测试应使用普通需求属性，减少自定义脚本和复杂导入流程的干扰。测试对象能够触发、正式对象不能触发时，可继续比较属性定义、链接目标和版本；测试也失败，再检查共同配置及客户端版本。

　　2、完成影响评估后逐条清除

　　清除可疑状态表示这条关联已经检查过，不会自动修改下游需求或验证内容。例如性能要求收紧后，仍需确认原有测试是否覆盖新的判定条件。

　　①根据【显示所有更改】找到受影响对象，完成必要的需求、设计或测试更新。

　　②保存相关模块，选择【分析】→【可疑链接】→【清除】。

　　③在【入向链接】或【出向链接】选项卡中核对对象，清除已完成评估的链接。

　　④重新显示【可疑链接指示符】，确认剩余项目仍可继续检查。

　　首次清除需要能够在链接模块中创建相关属性，后续需要链接模块修改权限，同时还要具备来源和目标模块的修改权限。基线中的可疑状态不能直接清除，批量清除也应限定在已经完成评估的范围。

　　总结

　　可疑链接能帮助团队找出需要重新审视的关系，但它不能代替需求影响评估。项目中应明确哪些属性变化值得触发检查，也应让负责下游需求或验证的人能够看到相关对象。没有标记时，仍可通过历史和实际链接追溯变化；标记清除后，也应有相应的评估依据。希望这些方法能帮助大家减少变更遗漏。关于DOORS的相关功能与应用需求，欢迎继续交流咨询。