The amount of funding to execute system modeling and systems engineering is finite; in many cases, it is zero-sum (or effectively so). To reap the benefits of a competently executed system model, what effort can/should be curtailed to fund the modeling efforts?
Since text-based requirements are, in essence, a textual projection of content that can (and should) be represented in the system model, their development can be delayed without technical penalty.
Instead of churning requirements, author and refine them at widely-spaced knowledge points or reviews. This allows them to be spawned and synchronized with a high-fidelity system model. If you attempt to keep requirements in synch with a rapidly growing and evolving system model you are wasting labor hours (adjudicating changes with all the stakeholder and decision authority drag that entails). Invest that time and effort into a higher-fidelity system model.
Axiom #1: Requirements should be derived from a system model elements; spawn and synchronize them at deliberately-chosen points in the development process.
Globally agree. With reasonable efforts spent on system model, most of system requirements can be derived from system model.
But I would not conclude for all system requirements because some types of requirements (physical constraints, safety, usability) are sometimes hard to formalize in one global system model. Instead of trying to put everything in the system model, what would lead to strong efforts and would require model specialists, as a compromise between value and efforts, I would prefer to complete system model with other artefacts (mockup, other kinds of models…) when needed.
I agree completely…future posts/videos will talk about a federation of models orchestrated by the system model.
The statement, “Requirements should be DERIVED from a system model elements,” rejects the possibility requirements could BE system model elements (without derivation of textual requirements). Seems the first axiom should not discount the possibility…
Good point…in fact, I prefer to manage textual requirements as system model elements. It saves the lag and drag of synching with a requirements tool…and emphasizes the paradigm shift I’m seeking, anyway.
Chicken or egg. Which came first?
One of the barriers I belive in the adoption of mbse it the imaturity and proliferation of tools available. Not all of which conform to the omg sysml standard. In addition to that mbse is totally focused on the architecting part of the engineering life cycle. It and the associated tools need to support test and integration in a common framework to compete with texted based requirements toolsets.
Also when an organisation goes out to tender. How to they convey that requirement. Via a textual document, maybe embellished with a few pictures, and they expect they same back as a response to evaluate one offer against the next. Don’t misunderstand what I am trying to say here. I am a great advocate of mbse but I see it all too often. Text based requirement’s are all too often answered, sometimes as directed, by texted based suspect system requirements. Making that transition from the initial text requirements spec to a structured mbse model is difficult to justify when the investment in text based requirements is made so early on in the project and offers tie in to the whole life cycle via the tools available.
Good points; I hope to answer them in an upcoming video. I want to see the model become the way information is transferred between stakeholders (no loss of fidelity vs. the “telephone/telegraph” game played with text-based requirements).
The trick is to NOT make the huge up-front investment in text but to siphon much of that effort into a higher-fidelity system model up front.
Up my to nowledge there is no common and unified definition of what a “system model” is and not, especially since the interpretation of the term system can be anything or nothing, I think you have a real problem. If you for example create a model of the Transportation Operation Application Domain where trucks, buses, trains etc. are operating in via a Use Case Model and a Domain Object Model, then the these models can form a complete problem description and the “systems” such as trucks, trains, etc have their “system models” but the requirements for these “systems” are derived from their application domain model rather than from their “system model”. But of course if you generalize very much also the application domain in this can be looked upon as a “system” and then the Use Case Model, the Domain Object Model are constituents of your “system model”. So everything is in the eye of the beholder.