需求、设计和测试用例都录入Jama Connect后，团队通常会规定哪些条目可以关联、关联朝哪个方向，以及哪些关系必须补齐。配置完成后，却可能发现不该存在的连接仍然保留，缺少测试用例的需求也能继续编辑。这些现象涉及不同的检查机制。排查时要分清关联是否允许建立、覆盖关系是否完整，以及旧数据是否符合新规则，才能判断配置究竟漏在了哪里。

　　一、Jama Connect如何配置需求关系规则

　　关系规则围绕条目类型建立，再应用到项目。配置前应先画清需求到验证的追踪结构，避免把目录层级直接当成关系方向。

　　1、按条目类型确定上下游

　　用户需求可以向下分解为系统需求，系统需求再关联验证条目。上下游表达的是定义、分解或验证关系，不能单凭条目放在哪个文件夹决定。

　　①使用组织管理员账号进入【ADMIN】→【Organization】→【Relationships】。

　　②在【Relationship Rule Configuration】区域选择【Add rule set】，修改【New Rule Set】名称。部分版本的配置区域显示为【Traceability Information Model Configuration】。

　　③在【Upstream】和【Downstream】中选择实际条目类型，再设置【Relationship type】，点击【Save】。

　　④按追踪链补充其余规则，逐条检查关系图中的连接方向。

　　2、单独决定哪些关系属于必需覆盖

　　①找到需求与验证条目之间的规则，按项目要求设置【For coverage】。

　　②将必须具备的追踪关系纳入覆盖检查，将仅供参考的关系保留为非覆盖关系。

　　③保存后核对关系图，检查必需关系的实线与非覆盖关系的虚线。

　　覆盖选项决定系统是否提示缺少对应关系。例如系统需求必须有验证条目，就应纳入覆盖检查。它不会检查验证内容能否证明需求，也不等于禁止保存一个暂时没有验证条目的需求。团队仍需给编写、评审和补齐追踪留出合理阶段。

　　3、将规则集应用到目标项目

　　①在规则集中选择【Add project】，添加需要使用该规则集的项目。

　　②检查【Allow any item type not mentioned in this rule set...】，按受控范围决定是否允许未列出的类型自由关联。

　　③返回目标项目，查看当前关系图，核对项目名称与规则集内容。

　　④对共享需求或验证条目的项目，核对双方采用的规则集。

　　每个项目只能应用一个规则集，再应用另一个会替换原有配置。修改公共规则集时，也应检查它关联了哪些项目，避免为某个项目增加的例外影响其他团队。

　　二、Jama Connect关系规则未拦截非法关联的原因

　　发现异常连接后，先选一对具体条目复现。记录条目类型、方向、所属项目和创建时间，比直接反复修改整套规则更容易找到原因。

　　1、关联在规则启用前已经存在

　　新规则应用到已有项目后，不会自动删除原来的关系。旧连接仍然可见，不能据此认定新建关联也能绕过限制。

　　①打开异常条目的【Relationships】，记录关联双方的条目编号、类型和方向。

　　②核对该连接的建立时间与规则应用时间。

　　③在测试项目中使用相同类型的新条目，通过【Relate to existing】重试同样的关联。

　　旧数据清理和新建关系限制应分别验证。对已有连接，应先确认它是否承载测试追踪或变更分析，再决定调整方向、替换目标或删除。

　　2、未列出的类型进入了放行范围

　　①回到【Relationships】，核对异常连接两端的真实条目类型。

　　②检查这些类型是否出现在当前规则集中，以及【Allow any item type not mentioned in this rule set...】的状态。

　　③将需要约束的新类型补入规则集，保存后重新测试允许与禁止的连接。

　　新增缺陷、任务或变更申请类型后，如果规则没有同步更新，原有放行设置就可能扩大可关联范围。条目名称相似也不代表类型相同，应以实际类型为准。

　　3、跨项目时检查了错误的规则集

　　跨项目关系按照来源项目的规则集处理。只检查目标条目所在项目，可能看不到真正决定本次关联行为的配置。

　　①记录本次关联操作的来源项目和目标项目。

　　②分别查看两个项目绑定的【Relationship rule set】，对比上下游类型与关系类型。

　　③从原操作入口重新建立测试关系，再交换操作入口复测。

　　④对长期共享条目的项目，统一相应关系规则，并重新检查跨项目连接。

　　4、页面上的规则没有成功保存

　　①打开浏览器开发者工具的【Network】，再执行规则保存。

　　②等待当前更新请求返回【200】后，再添加下一条规则。

　　③重新加载【Relationships】页面，核对规则数量、方向和覆盖选项。

　　④对刷新后缺失的规则逐条补录，保存后再次刷新验证。

　　Jama官方支持资料记录过连续快速添加规则时，页面看似保存成功、刷新后却缺失的情况。排查应以重新加载后的内容为依据；仅看到关系图当时增加了一条线，还不足以证明配置已经持久保存。

　　三、Jama Connect如何验证关系规则与追踪完整性

　　配置验收应同时检查允许建立的关系、应当限制的关系和缺少的必需关系。只测试一条正常连接，很难发现放行范围或覆盖设置中的遗漏。

　　1、用正反样例检查新建关系

　　①在测试项目准备【系统需求】、【子系统需求】和【测试用例】等实际类型的样例条目。

　　②通过【Relate to existing】建立规则允许的连接，核对生成方向和关系类型。

　　③尝试规则外的类型组合，并检查未列出类型是否按预期受到限制。

　　④对每个样例记录预期结果、实际结果和当前规则集名称。

　　样例应覆盖项目真正关心的限制。例如团队要求系统需求经过子系统需求再连接测试，就应专门验证跨层直连。测试关系宜使用独立样例，避免为检查规则而修改正式追踪链。

　　2、区分缺少覆盖与疑似关系

　　关系状态变红可能来自缺少上游、缺少下游，也可能来自上游修改后产生的疑似关系。颜色相同，处理动作却不同。

　　①在【List View】查看【Relationship Status Indicator】，悬停状态图标读取具体提示。

　　②对【Orphan Item】核对必需上游，对【Missing Downstream】核对必需下游。

　　③进入【Trace View】，检查需求到验证条目的追踪缺口。

　　④对【Suspect】关系评估上游变更的影响，完成判断后再清除疑似标记。

　　总结

　　Jama Connect关系规则的作用，需要结合条目类型、项目绑定和覆盖要求一起理解。允许建立什么连接，与需求是否已经形成完整追踪，是两件需要分别验收的事。项目初建时，可以用少量样例验证方向和限制；项目运行后，则要关注新增类型、共享项目及历史连接带来的变化。规则维护得清楚，团队在评审需求和分析变更时才更容易读懂追踪链。希望这些方法能帮助你判断异常关联的来源，后续也可以围绕具体条目类型继续细化配置。