New views for SysML
I often hear arguments against SysML that the diagrams are not suitable for the stakeholder concerns. For example it is not a good idea to choose the requirements diagram to show thousands of requirements or a block definition diagram to show the complete mapping of the functional to the physical architecture with allocate relationships.
It can’t be mentioned enough: You must differentiate between the diagram and the repository. Although a modeler sees the model through the diagram, the most important part is the repository. The repository contains all data of the model. The diagrams are only views on the repository. You can delete all your diagrams and still have the information in the repository. You can compare it with a spreadsheet tool like Excel. The important information is in the rows and cells of your spreadsheet. You can create line charts, block charts, and so on, to display the information. The charts show only a cut-out of your information and you don’t loose it when you delete the charts. That doesn’t mean that charts and diagrams have no value.
If the SysML diagrams doesn’t suit your needs than simply choose another view. SysML itself provides two more views: tabular and matrix views. Most modeling tools have implemented them. The following figure shows a matrix in the modeling tool MagicDraw of the relationships between functional groups and activities (see the method for functional architectures for systems (FAS method) details: http://www.fas-method.org).
In addition in most modeling tools it is easy to export model information to Excel to provide table or matrix views on the data. For example the prototype of a variant configurator (see the blog post about variant modeling with SysML for details).
First think about the stakeholder concerns and how to address them with a view. Second check if SysML provides the view. If not try to implement the view with simple tool extensions or tool chains. There are more views for SysML than the 9 nine diagram types.
Hello dear Readers!
First I would like to thank Mr. Weilkiens for this topic. It addresses an important part (when not entire) of the engineer’s life: meet the stakeholder requirements! 🙂
As sometimes stated, the engineers work has to be (at some point) creative, has to generate ideas how to satisfy the requirements. All this is to create new solutions… Unfortunately what engineers tend to do in real life is to follow the rule: “if all you have is a hammer, everything looks like a nail”. So, if one really ONLY (!) knows SysML AND has no real understanding of the mental world of his/her stakeholders, then SysML will appear a dead end in the case when SysML is not the “language” of the stakeholders. This is a sad fact.
What then? I think, a trade-off of two possible ways may be a good idea: teach the stakeholders the SysML or “hire” a translator. In many cases it will be “chaper” to hire a translator. Of course one has to consider all the aspects of the participation of the stakeholders in the engineering process, which will inevitably lead to a serious trade-off. In my opinion this is the way. This activity in the engineering process is usually called “stakeholder analysis”. Seems important…
This is what Mr. Wilkiens proposes: use Excel, use N2 Diagrams, use everything suitable to represent the system concepts in scope to the stakeholders. Some of this tools are probably brought to you with your SysML tool – discover them, apply them. Generate reports and documents for document – oriented stakeholders, create excel sheets for matrix-brained ones, etc. Unfortunately all this is a work…
Putting a set of new extensions to SysML, new diagram types and symbols won’t solve the challenges by many different stakeholders.