1
General Board / SysML AbstractRequirement relationships
« on: July 05, 2022, 06:26:33 pm »
Dear KP,
I hope you found my explanations about the trace relationship useful.
After reading your latest reply:
I was about to provide further information to your latest request:
Please find below a requirement diagram I created to support my explanation to your request:

Please note that A is now the supplier, while in the previous post it was the client. Having now more clients it seemed right to start with A as supplier and then the rest as clients. I hope this doesn't create additional confusion.
The key here is that A, as a requirement, is the supplier of all those relationships drafted in the diagram.
Think of A as the main piece of information here, driving the rest (clients). Meaning that any change in A could potentially impact the rest of the elements in the diagram, but not the other way around.
Then, you would read those relationships as follows:
Please read them again, and let me know if you have any further questions.
Honestly, they all seem fine to me but, as any other human, I might be getting something wrong, in which case I would really appreciate your input.
In any case, please bear in mind that I'm here just trying to help, not a guru, not a writer of the spec, just a SysML user as any other.
Sincerely yours,
i
I hope you found my explanations about the trace relationship useful.

After reading your latest reply:
I was about to provide further information to your latest request:
Quote from: KP
Now use the same argument for /refinedBy /satisfiedBy and /verifiedBywhen I realised someone had already locked that topic, hence here it comes a new one to fulfil your request. Apologies for that, it would be simpler to continue the discussion in the original one, but it wasn't me who locked it.
Please find below a requirement diagram I created to support my explanation to your request:

Please note that A is now the supplier, while in the previous post it was the client. Having now more clients it seemed right to start with A as supplier and then the rest as clients. I hope this doesn't create additional confusion.
The key here is that A, as a requirement, is the supplier of all those relationships drafted in the diagram.
Think of A as the main piece of information here, driving the rest (clients). Meaning that any change in A could potentially impact the rest of the elements in the diagram, but not the other way around.
Then, you would read those relationships as follows:
- B traces to A, and A is traced from B.
- C satisfies A, and A is satisfied by C.
- D refines A, and A is refined by C.
- E verifies A, and A is verified by E.
Please read them again, and let me know if you have any further questions.
Honestly, they all seem fine to me but, as any other human, I might be getting something wrong, in which case I would really appreciate your input.
In any case, please bear in mind that I'm here just trying to help, not a guru, not a writer of the spec, just a SysML user as any other.

Sincerely yours,
i