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.