我不能完全遵循您的示例，因为它不是真实的示例，但是无论如何都可以。 ：）

您能否使用业务规则来表示您的"矩阵"连接，然后有一个脚本根据其所附加或不附加的业务规则来用不同的值填充扩展属性？ 您说无法对脚本中的逻辑进行硬编码，因此结果是否取决于业务规则中定义的扩展属性？ 例如 如果属性附加到三个以上带有值" M"的业务规则中，则将值设置为" M"？

感谢您的建议。

我想再说一遍-这是我们客户请求的更详细示例：

是否必须将给定属性设置为强制/有条件/可选的决定是基于几个因素（分类为"维度"）。

这些尺寸的数量非常少（三个尺寸），但是将来会扩展，并且不应该限制。

这里是一个示例：在业务伙伴类型A（维度：业务伙伴类型），业务角色类型Y（维度：业务伙伴角色）和业务类型Z的情况下（维度：业务类型） ，则将特定属性C设置为强制性。

每个维度都包含不同的标准，这些标准构成了一个目录。 每个维度的一个标准的组合形成了一组标准，这些标准将与三个分类之一（强制/有条件/可选）以及相应的属性相关联。 准则的组合是随机的（因此，每个准则可以在多个包装中），但是在包装中，每个维度只能有一个准则，而且准则的组合也必须是唯一的。

我们的想法是将标准本身表示为需求，并将其分类在按其所属的不同维度排序的文件夹中。 然后，我们将在条件需求与它们所分类的条件包之间创建可追溯性链接。这些包将被放入另一个需求模型中。 然后，这些包将通过传出的可跟踪性链接连接到属性，如果属性是强制性等，则该链接将携带信息（作为链接类型或扩展属性）。

您认为这种方法有什么问题吗？