Part 2, Addressing the Differences
In a previous post I derived a definition of MBSE. The challenge that often comes up is, “Aren’t configuration controlled specification documents and requirements databases just another form of representation? Another form of model?” Indeed, they were the basis for models in the past, because in many cases the models resided only in the brains of the customers or designers. The only way to communicate those models were through human language and pictures, hence specifications. Nowadays specifications fail to fulfill modern systems engineering needs for a number of reasons.
First of all, specifications are not visual representations, but descriptive representations. The system is represented in words, with an occasional graphic to either clarify, or possibly confuse, the description. Descriptions rely on the underlying written language. Written language is inherently flexible in interpretation. Grammar is often flexible and dynamic, although more so in spoken language. The underlying information can easily be interpreted multiple ways, depending on the recipient. Additionally, there are no rules on how to describe a system using written language and only the most simplistic rules on the structure of a formal description.
In MBSE, the language is tightly controlled so the possibility of misinterpretation of the model is greatly reduced. Languages for MBSE, such as SysML, have specific rules for how to represent elements in the system and how language elements can interrelate. Furthermore, the graphics generally are coupled to the language, further reducing ambiguity.
Secondly, in written language the strategic information is merely described; the information has no form itself. A description of an element within the system might require many descriptive statements. An engineer can’t point to a single form of that element. At best, the engineer can point to a loose grouping of text that describes the element. Textual representations fail to give form to the information. In MBSE, the system elements and strategic information are individual entities in some type of repository or database. Those entities carry their characteristics with them. A repository of elements and information is what really makes MBSE “model based.”
For these two main reasons, legacy document-centric approaches to systems engineering simply do not meet the intent of modern model based approaches. Yet, let’s face it; textual requirements are not going away any time soon.
The Legacy Runs Deep
Systems engineers still will use textual requirements for the foreseeable future. It’s much easier to create a legal contract around a textual description than a graphical representation, even if the representation resides in a controlled database. It’s much easier to develop verification procedures and checklists around single textual statements than around pictures. Under MBSE the textual requirements get de-emphasized instead of being dropped completely.
Under MBSE, textual requirements should be derived from the content of the model. If the tools to create that model were chosen well, the syntax of the model should be well-formed and translate into textual representations fairly easily.
Summary
Documentation is inevitable, but under MBSE it changes from being the end goal of the systems engineer to being reports that describe the underlying system entities. The specifications and other documents report on the model rather than being the model. This is the essential difference between document-based systems engineering and MBSE.
Part 1, Deriving a Definition