Model Based System Engineering

System engineering is usually done by writing word documents to set up the system.

The main problem with this method is the Lack of connectivity between the system architecture and its demands, lack of connection between system processes operational requirements (requirements are written with no correlation to operational processes), the lack of analysis of the requirements because there is no tool to see the complex relationships between systems requirements themselves and inability to maintain a link between operational requirements to systems engineering requirements.

The method that we work in is modeling different dimensions of system engineering with different types of models. The models are based on UML languages, SYSML or other approaches such as DODAF etc. The guiding principle in all is customizing models language to the client existing language. We will try to stick to the familiar and the known and not try to teach employees new and unfamiliar language which will results in encountering many objections.

In many organizations there is a lack of reusing system components. The term reuse acceptable especially in software. The use of geometric models enables to design complex systems and entire business lines (cross projects system component) including use and allows reuse of engineering components at the level of system engineering already. Please note that today reuse occurs only at the level of software, hardware and firmware. There is a real lack of reuse at system engineering phase.

Example: If an organization develops a specific weapon and every customer receives a certain derivative of this system, we would like to have models ready for any system component and then we only will have to make integratn of existing design components rather than start from scratch each time.


System engineering model provides a definition of:

  • System architecture - new system components, reuse of existing components in organization, reusing existing services.
  • Defining requirements of each component (functionality, not functionality, and other)
  • Setting up the system processes at upper level and detailed level
  • Defining users
  • Setting information entities and operational entities
  • Setting up the system states and transitions between them
  • Defining interfaces to internal and external system

Interested in an option to order a modeling expert? Click here for more details