Show me your Relationship diagram

[Deleted User]

Hello everyone,

I would like to start a discussion about Best practices for relationship diagrams.

What have you done that worked, and what have you tried that didn't?

I come from a company producing complex products involving structures, hardware, software, process equipment etc.

We started with a very big relationship diagram and ended up simplifying it.

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------

Barbara Haglind

Hello:

I have seen convoluted relationship diagrams and more straightforward relationship diagrams.

Sometimes I have seen folks have item types with relationships to the same item types.

This seems to make it it difficult to cleanly trace out how these systems with what I call "recursive" relationships, are connected to, and realize the upstream and downstream relationships, identify design gaps, and trace from user needs to test results.

The reason is that by relating the same item types to each other create ambiguous clusters of dependency.

Given the cluster style and the fact that for a required relationship you can (per relationship type) get flagging (in JAMA), the first example may mislead in regards to test coverage for subsystem requirements and although it may seem hierarchical (in the subsystem items) I think it becomes ambiguous in JAMA when attempting to ensure coverage unless EVERY subsystem item points to at least one subsystem item before pointing to a software item.

See examples.  I have seen groups try to do things this way, and typically discourage it.  However, I am curious if anyone has a real life example they are using and how they have handled the tracing, design gap analysis, and assurance (evidence) the product meets requirements?

I can understand in complex systems how this might seem reasonable.  Has anyone successfully used that sort of structure successfully?  If so what were the perceived benefits, pitfalls, and was there ambiguity?

Example of unusual practice:

user need -> system requirement <-> subsystem requirement a <-> subsystem requirement b <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Example of typical practice:

user need -> system requirement <-> subsystem requirement a <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement b <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Thank you,

Bj Haglind

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world.

-------------------------------------------
Original Message:
Sent: 12/20/2022 7:17:00 AM
From: Mathias Rahbek
Subject: Show me your Relationship diagram

Hello everyone,

I would like to start a discussion about Best practices for relationship diagrams.

What have you done that worked, and what have you tried that didn't?

I come from a company producing complex products involving structures, hardware, software, process equipment etc.

We started with a very big relationship diagram and ended up simplifying it.

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------

[Deleted User]

Hello

At an early stage, I was advised to make relationship diagrams as simple as possible. A rule of thumb was to not create a new item type if they would have the same attributes.
However, by not creating a hierarchy, the coverage explorer quickly gets messed up.

In the example above, the beforementioned rule of thumb would mean the sub-system requirements would be obsolete and instead, the Requirement item type would relate to itself.

One of my main struggles is that I cannot get it to understand subsets. For instance, all Design Guidelines must link to a sub-system requirement, but not all sub-system requirements need to link to a Design Guideline. This is what triggered the need to make an Interface Requirement type in the first place because otherwise, it would stay within the regular requirements item type.

How many "layers" of hierarchy has anyone successfully used? I am considering adding another layer to my model to ensure the requirement can be broken down into components.

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------
-------------------------------------------
Original Message:
Sent: 12-20-2022 04:34
From: Barbara Haglind
Subject: Show me your Relationship diagram

Hello:

I have seen convoluted relationship diagrams and more straightforward relationship diagrams.

Sometimes I have seen folks have item types with relationships to the same item types.

This seems to make it it difficult to cleanly trace out how these systems with what I call "recursive" relationships, are connected to, and realize the upstream and downstream relationships, identify design gaps, and trace from user needs to test results.

The reason is that by relating the same item types to each other create ambiguous clusters of dependency.

Given the cluster style and the fact that for a required relationship you can (per relationship type) get flagging (in JAMA), the first example may mislead in regards to test coverage for subsystem requirements and although it may seem hierarchical (in the subsystem items) I think it becomes ambiguous in JAMA when attempting to ensure coverage unless EVERY subsystem item points to at least one subsystem item before pointing to a software item.

See examples.  I have seen groups try to do things this way, and typically discourage it.  However, I am curious if anyone has a real life example they are using and how they have handled the tracing, design gap analysis, and assurance (evidence) the product meets requirements?

I can understand in complex systems how this might seem reasonable.  Has anyone successfully used that sort of structure successfully?  If so what were the perceived benefits, pitfalls, and was there ambiguity?

Example of unusual practice:

user need -> system requirement <-> subsystem requirement a <-> subsystem requirement b <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Example of typical practice:

user need -> system requirement <-> subsystem requirement a <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement b <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Thank you,

Bj Haglind

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world.

Original Message:
Sent: 12/20/2022 7:17:00 AM
From: Mathias Rahbek
Subject: Show me your Relationship diagram

Hello everyone,

I would like to start a discussion about Best practices for relationship diagrams.

What have you done that worked, and what have you tried that didn't?

I come from a company producing complex products involving structures, hardware, software, process equipment etc.

We started with a very big relationship diagram and ended up simplifying it.

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------

[Deleted User]

I also am a strong believer in making the relationship diagram as simple as possible, and a strong advocate for (in most cases) giving items with the same fields the same type.  I find that setting "for coverage" is only useful when every item of the upstream type always must have a relationship to an item of the downstream type.   Since this is commonly not true, I instead recommend using advanced filters to detect the items that do not have the desired coverage.   In that case, you can have a pick list to declare the "sub-type" of an item, and then have your coverage advanced filter take that subtype into account.   This gives you greater flexibility into how you can group items into sets, and simplifies the users initial decision of what type to give an item on creation.

------------------------------
Geoffrey Clemm
Jama Software
------------------------------
-------------------------------------------
Original Message:
Sent: 01-03-2023 02:18
From: Mathias Rahbek
Subject: Show me your Relationship diagram

Hello

At an early stage, I was advised to make relationship diagrams as simple as possible. A rule of thumb was to not create a new item type if they would have the same attributes.
However, by not creating a hierarchy, the coverage explorer quickly gets messed up.

In the example above, the beforementioned rule of thumb would mean the sub-system requirements would be obsolete and instead, the Requirement item type would relate to itself.

One of my main struggles is that I cannot get it to understand subsets. For instance, all Design Guidelines must link to a sub-system requirement, but not all sub-system requirements need to link to a Design Guideline. This is what triggered the need to make an Interface Requirement type in the first place because otherwise, it would stay within the regular requirements item type.

How many "layers" of hierarchy has anyone successfully used? I am considering adding another layer to my model to ensure the requirement can be broken down into components.

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------

Original Message:
Sent: 12-20-2022 04:34
From: Barbara Haglind
Subject: Show me your Relationship diagram

Hello:

I have seen convoluted relationship diagrams and more straightforward relationship diagrams.

Sometimes I have seen folks have item types with relationships to the same item types.

This seems to make it it difficult to cleanly trace out how these systems with what I call "recursive" relationships, are connected to, and realize the upstream and downstream relationships, identify design gaps, and trace from user needs to test results.

The reason is that by relating the same item types to each other create ambiguous clusters of dependency.

Given the cluster style and the fact that for a required relationship you can (per relationship type) get flagging (in JAMA), the first example may mislead in regards to test coverage for subsystem requirements and although it may seem hierarchical (in the subsystem items) I think it becomes ambiguous in JAMA when attempting to ensure coverage unless EVERY subsystem item points to at least one subsystem item before pointing to a software item.

See examples.  I have seen groups try to do things this way, and typically discourage it.  However, I am curious if anyone has a real life example they are using and how they have handled the tracing, design gap analysis, and assurance (evidence) the product meets requirements?

I can understand in complex systems how this might seem reasonable.  Has anyone successfully used that sort of structure successfully?  If so what were the perceived benefits, pitfalls, and was there ambiguity?

Example of unusual practice:

user need -> system requirement <-> subsystem requirement a <-> subsystem requirement b <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Example of typical practice:

user need -> system requirement <-> subsystem requirement a <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement b <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Thank you,

Bj Haglind

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world.

Original Message:
Sent: 12/20/2022 7:17:00 AM
From: Mathias Rahbek
Subject: Show me your Relationship diagram

Hello everyone,

I would like to start a discussion about Best practices for relationship diagrams.

What have you done that worked, and what have you tried that didn't?

I come from a company producing complex products involving structures, hardware, software, process equipment etc.

We started with a very big relationship diagram and ended up simplifying it.

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------

[Deleted User]

Hi Geoffrey,

Thank you for elaborating on a way forward.

Do you know if there are plans on improving the coverage explorer to include relationship rules? Alternatively, to disable the coverage alarm in the trace view until it provides valuable feedback?

If we are able to filter out items with missing relations, I would love to see that added to a coverage explorer, where multiple filters (rules) could be added for specific item types.
Taking it further, that could enable more precise coverage diagnostics (e.g. filter could tell that a verification item is missing - not only that a relation is missing).

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------
-------------------------------------------
Original Message:
Sent: 01-04-2023 17:29
From: Geoffrey Clemm
Subject: Show me your Relationship diagram

I also am a strong believer in making the relationship diagram as simple as possible, and a strong advocate for (in most cases) giving items with the same fields the same type.  I find that setting "for coverage" is only useful when every item of the upstream type always must have a relationship to an item of the downstream type.   Since this is commonly not true, I instead recommend using advanced filters to detect the items that do not have the desired coverage.   In that case, you can have a pick list to declare the "sub-type" of an item, and then have your coverage advanced filter take that subtype into account.   This gives you greater flexibility into how you can group items into sets, and simplifies the users initial decision of what type to give an item on creation.

------------------------------
Geoffrey Clemm
Jama Software
------------------------------

Original Message:
Sent: 01-03-2023 02:18
From: Mathias Rahbek
Subject: Show me your Relationship diagram

Hello

At an early stage, I was advised to make relationship diagrams as simple as possible. A rule of thumb was to not create a new item type if they would have the same attributes.
However, by not creating a hierarchy, the coverage explorer quickly gets messed up.

In the example above, the beforementioned rule of thumb would mean the sub-system requirements would be obsolete and instead, the Requirement item type would relate to itself.

One of my main struggles is that I cannot get it to understand subsets. For instance, all Design Guidelines must link to a sub-system requirement, but not all sub-system requirements need to link to a Design Guideline. This is what triggered the need to make an Interface Requirement type in the first place because otherwise, it would stay within the regular requirements item type.

How many "layers" of hierarchy has anyone successfully used? I am considering adding another layer to my model to ensure the requirement can be broken down into components.

------------------------------
Mathias Rahbek
NEL Hydrogen

Original Message:
Sent: 12-20-2022 04:34
From: Barbara Haglind
Subject: Show me your Relationship diagram

Hello:

I have seen convoluted relationship diagrams and more straightforward relationship diagrams.

Sometimes I have seen folks have item types with relationships to the same item types.

This seems to make it it difficult to cleanly trace out how these systems with what I call "recursive" relationships, are connected to, and realize the upstream and downstream relationships, identify design gaps, and trace from user needs to test results.

The reason is that by relating the same item types to each other create ambiguous clusters of dependency.

Given the cluster style and the fact that for a required relationship you can (per relationship type) get flagging (in JAMA), the first example may mislead in regards to test coverage for subsystem requirements and although it may seem hierarchical (in the subsystem items) I think it becomes ambiguous in JAMA when attempting to ensure coverage unless EVERY subsystem item points to at least one subsystem item before pointing to a software item.

See examples.  I have seen groups try to do things this way, and typically discourage it.  However, I am curious if anyone has a real life example they are using and how they have handled the tracing, design gap analysis, and assurance (evidence) the product meets requirements?

I can understand in complex systems how this might seem reasonable.  Has anyone successfully used that sort of structure successfully?  If so what were the perceived benefits, pitfalls, and was there ambiguity?

Example of unusual practice:

user need -> system requirement <-> subsystem requirement a <-> subsystem requirement b <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Example of typical practice:

user need -> system requirement <-> subsystem requirement a <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement b <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Thank you,

Bj Haglind

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world.

Original Message:
Sent: 12/20/2022 7:17:00 AM
From: Mathias Rahbek
Subject: Show me your Relationship diagram

Hello everyone,

I would like to start a discussion about Best practices for relationship diagrams.

What have you done that worked, and what have you tried that didn't?

I come from a company producing complex products involving structures, hardware, software, process equipment etc.

We started with a very big relationship diagram and ended up simplifying it.

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------

[Deleted User]

To disable the coverage alarm, unset the "coverage" flag on every relationship.

I am currently working with engineering on providing the kind of coverage diagnostics that you are looking for here ... it will take some significant infrastructure work, but when it is ready for review, we will let the community know.

------------------------------
Geoffrey Clemm
Jama Software
------------------------------
-------------------------------------------
Original Message:
Sent: 01-05-2023 00:38
From: Mathias Rahbek
Subject: Show me your Relationship diagram

Hi Geoffrey,

Thank you for elaborating on a way forward.

Do you know if there are plans on improving the coverage explorer to include relationship rules? Alternatively, to disable the coverage alarm in the trace view until it provides valuable feedback?

If we are able to filter out items with missing relations, I would love to see that added to a coverage explorer, where multiple filters (rules) could be added for specific item types.
Taking it further, that could enable more precise coverage diagnostics (e.g. filter could tell that a verification item is missing - not only that a relation is missing).

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------

Original Message:
Sent: 01-04-2023 17:29
From: Geoffrey Clemm
Subject: Show me your Relationship diagram

I also am a strong believer in making the relationship diagram as simple as possible, and a strong advocate for (in most cases) giving items with the same fields the same type.  I find that setting "for coverage" is only useful when every item of the upstream type always must have a relationship to an item of the downstream type.   Since this is commonly not true, I instead recommend using advanced filters to detect the items that do not have the desired coverage.   In that case, you can have a pick list to declare the "sub-type" of an item, and then have your coverage advanced filter take that subtype into account.   This gives you greater flexibility into how you can group items into sets, and simplifies the users initial decision of what type to give an item on creation.

------------------------------
Geoffrey Clemm
Jama Software

Original Message:
Sent: 01-03-2023 02:18
From: Mathias Rahbek
Subject: Show me your Relationship diagram

Hello

At an early stage, I was advised to make relationship diagrams as simple as possible. A rule of thumb was to not create a new item type if they would have the same attributes.
However, by not creating a hierarchy, the coverage explorer quickly gets messed up.

In the example above, the beforementioned rule of thumb would mean the sub-system requirements would be obsolete and instead, the Requirement item type would relate to itself.

One of my main struggles is that I cannot get it to understand subsets. For instance, all Design Guidelines must link to a sub-system requirement, but not all sub-system requirements need to link to a Design Guideline. This is what triggered the need to make an Interface Requirement type in the first place because otherwise, it would stay within the regular requirements item type.

How many "layers" of hierarchy has anyone successfully used? I am considering adding another layer to my model to ensure the requirement can be broken down into components.

------------------------------
Mathias Rahbek
NEL Hydrogen

Original Message:
Sent: 12-20-2022 04:34
From: Barbara Haglind
Subject: Show me your Relationship diagram

Hello:

I have seen convoluted relationship diagrams and more straightforward relationship diagrams.

Sometimes I have seen folks have item types with relationships to the same item types.

This seems to make it it difficult to cleanly trace out how these systems with what I call "recursive" relationships, are connected to, and realize the upstream and downstream relationships, identify design gaps, and trace from user needs to test results.

The reason is that by relating the same item types to each other create ambiguous clusters of dependency.

Given the cluster style and the fact that for a required relationship you can (per relationship type) get flagging (in JAMA), the first example may mislead in regards to test coverage for subsystem requirements and although it may seem hierarchical (in the subsystem items) I think it becomes ambiguous in JAMA when attempting to ensure coverage unless EVERY subsystem item points to at least one subsystem item before pointing to a software item.

See examples.  I have seen groups try to do things this way, and typically discourage it.  However, I am curious if anyone has a real life example they are using and how they have handled the tracing, design gap analysis, and assurance (evidence) the product meets requirements?

I can understand in complex systems how this might seem reasonable.  Has anyone successfully used that sort of structure successfully?  If so what were the perceived benefits, pitfalls, and was there ambiguity?

Example of unusual practice:

user need -> system requirement <-> subsystem requirement a <-> subsystem requirement b <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Example of typical practice:

user need -> system requirement <-> subsystem requirement a <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement b <-> software requirement <-> test case <-> test result

user need -> system requirement <-> subsystem requirement c <-> software requirement <-> test case <-> test result

Thank you,

Bj Haglind

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world.

Original Message:
Sent: 12/20/2022 7:17:00 AM
From: Mathias Rahbek
Subject: Show me your Relationship diagram

Hello everyone,

I would like to start a discussion about Best practices for relationship diagrams.

What have you done that worked, and what have you tried that didn't?

I come from a company producing complex products involving structures, hardware, software, process equipment etc.

We started with a very big relationship diagram and ended up simplifying it.

------------------------------
Mathias Rahbek
NEL Hydrogen
------------------------------