Duplication in SysML sub-system requirement derivation
MARK ELSON
I am seeking some opinion/discussion on the following topic. I have a provided System Requirements Specification. My objective is to provide some Sub-System Requirements Specifications. I know, in general, the view in SysML modelling seems to be that one abstraction level's design artefacts are the next level down's requirements - and so explicit requirements do not need to be modelled. However, in my scenario I am stuck with providing Sub-System Requirements Specifications to a document-centric process. I suspect this scenario crops up frequently but seems to be only touched on in the various SysML books and papers that I have read.
The figure below gives a simplified example of the process that I have followed:
1) Top Left shows a System Requirement being refined (could be satisfied, I guess) by a System Activity (could be Use Case etc);
2) Top Right shows the structural decomposition into two sub-systems (that each require their own Requirements Spec);
3) Bottom Left shows the decomposition of the System activity to a point that activities/actions can be allocated to the sub-systems. At this point I have expressed these actions as corresponding sub-system requirements.
Being new-ish to SysML I had hoped that would be enough to both implicitly i) allocate requirements to sub-systems and ii) show traceability from the System Requirement to the Sub-System Requirements. However, as I learned, SysML does not support collecting requirements that are associated with actions allocated to blocks into block “specifications”; or following a path from a requirement through an activity decomposition to sub-system requirements
If I understand correctly, the typical way forward is to show traceability explicitly in a diagram: which I have done on the Bottom Right. I have asserted that each sub-system satisfies a Reqts Spec, which contain the relevant requirements which are derived from a system requirement according to a rationale that links back to the relevant activity diagram (gasp).
What bothers me about this is the duplication of information. The traceability diagram is showing information, that has to be constructed manually, that is already implicit in the model. Apart from the extra effort there is the risk
of things getting out of synchronization. Is this the price that has to be paid for wanting document-centric requirements specs as a process output? Or is there a better way?
Thank you for your indulgence,
Mark
