Agile System Modeling

The concept of modeling system requirements and design in is not a new one. However, recent advances in languages and tools has created opportunities for reducing the total development effort for embedded systems, and improve quality. This article aims to present some of these opportunities, based on the authors’ experiences. Keywords are traceability, and multiple consistent requirements, design, and test views. The article gives an overview of the SysML language, its usage, and potential benefits. The article also gives advice on how to get started with system modeling along with literature recommendations.

SysML Background

The Block diagrams and flow diagrams are perhaps the de facto standards of visually describing structure and functions of embedded systems. These diagrams have good track records, but one shortcoming lies in the fact that they can not easily be integrated with other diagram types or even other diagrams of their own type using common tools. If you for example develop five block diagrams in Microsoft Visio with some common elements, you will need to maintain each of them individually. Make a change in one, and you will need to validate the others. If flow diagrams for these elements are also developed, the effort of making changes and ensuring consistency increases exponentially.
A solution to making multiple diagrams consistent, is to use a tool that integrates several diagrams and diagram types using a relational database. This was done by UML to unify the world of software modeling. UML is now a 20 year old mature software modeling language that promotes an object oriented mindset. A major strength of UML is the ability to combine diagrams showing SW Structure and SW behavior, and reuse elements. Reuse is also a key aspect of SysML, and portions of models can be reused between product generations or variants.

The most used UML diagram types are arguably the class, sequence, and use-case diagram. UML tools lets elements be reused between diagrams, and a change in one element is therefore reflected in all diagrams showing that element. This enables more aspects of a system to be documented with diagrams, for less effort. Common criticism of UML is that its “red tape” that gets in the way of coding, and UML will indeed let you describe SW all the way down to SW function level. Compared to UML, the Systems Modeling Language (SysML) is more light-weight, more general, and targeted towards modeling requirements and architecture.

In 2001, the International Consortium on Systems Engineering (INCOSE) and the Object Management Group (OMG) issued the “UML for Systems Engineering” request for proposal, with the intention of adapting UML for system specification and design. In the 16 years since, SysML (now at version 1.4) has developed into a mature and more agile language than UML, that is suitable for modeling requirements, hardware, software and processes. In addition, a SysML model gives opportunities for documenting the relationships between requirements and system components at any level of decomposition in accordance with best practices and also functional safety requirements.

SysML 1.4 and enterprise architect

The SysML language is a profile of UML, and provides both a notation in the form of diagrams, elements, and relationships, and the semantics of these. Some diagrams are directly adopted from UML, the requirements diagram and parametric diagram are new diagram types, and some UML diagrams have been left out in SysML. The authors have used Enterprise Architect from Sparx Systems for SysML modeling. It is a feature rich and flexible modeling tool with good Support for SysML 1.4.

The process of modeling an aspect of the system is to first create a diagram of a suitable type (see SysML 1.4 Diagram Types), secondly drag in any previously defined elements, and third define any new elements or relationships. After that, descriptive text and visual formatting can be added for increased readability. Enterprise Architect lets you hide relationships and element properties on a per diagram basis, so a diagram can show what you want and nothing more.

Systems modeling in Data Respons

SysML models have been used in Data Respons by the authors since 2011. The applications have ranged from concept studies, internal process descriptions, through requirements specifications and architecture descriptions. For requirements specifications, the authors have created model with full bi-directional traceability between system requirements and environmental requirements (Aviation). In the automotive industry, the authors have established bi-directional traceability in a system requirements specification down to software unit level. This has shown that SysML models can be efficient means to achieve traceability between system requirements and stakeholder requirements, and also down to low level design.

The authors have also used a SysML model for stakeholder management, capturing requirements, exploring solution concepts and developing system architecture. Capturing this information in the same model has shown the strength of using a model containing diagrams as a tool for communicating and validating design decisions in an iterative manner. The model also proved to be efficient for establishing a shared terminology and understanding of the system under development, for exploring solution concepts in team, and for documenting system architecture at multiple levels of decomposition.

Modeling Tools

There are some SysML capable tools to choose from, both with commercial and open source licenses. Googling “SysML tools” yields lists of popular tools, comparisons and feature lists. SysML underwent significant changes up till version 1.3. The current version of the standard (1.4) has been around since 2015. Some tools are better than others in implementing new SysML features, and not all tools available have mature enough SysML support for efficient system modeling. No Magic MagicDraw, Altova Umodel and Sparx Enterprise Architect are among the most popular SysML capable modeling tools.

Getting started

SysML is a language. In order to create a model in the SysML language that serves a purpose in a given project, the purpose must first be defined, this might for example be a requirements specification, consistent design diagrams, interface specifications, test management, or a full architecture description. Secondly, a suitable model structure and workflow must be established. This is arguably the most critical challenge of working with SysML models. Knowledge of Systems Engineering best practices and experience with SysML or UML and the modeling tool is recommended. A SysML model is structured using packages. These are logical containers that contains diagrams and other elements. Elements in the same or different packages can have relationships between each other. Even though the element and relationship types have defined SysML semantics, practice shows this is not always clearly enough defined. While using the semantics of the SysML standard is a good thing, we have found that the usage of diagram, elements and relationship types should not be too tied to the SysML semantics, but instead be documented on a per-model basis. Thus ensuring consistency within the model. The package diagram below shows one possible model structure with package dependencies.

Model setup recommendations

SysML models should be structured on a per project basis in order to meet project specific requirement. However, the experience of the authors is that following some general rules when setting up the model results in it being more readable and maintainable.

Diagram Legends can be defined once and used in several diagrams. Use Legends and Element colors consistently to help make the model readable.

All diagrams should have a text box, describing what aspect of the system the diagram shows. For improved readability, do not rely solely on SysML notations like the diagram header.

Document the usage of SysML element and connector “Types” and “Stereotypes”, and make sure the meaning is unique. This is a prerequisite for a consistent model, improves traceability, and enables complex model searches.

Use a “package” diagram to establish a package structure and document package dependencies. This serves as an overview of the model, and helps in managing changes to the model.

Define a logical system break-down, and structure all information in accordance with this. The items in the breakdown structure should represent logical parts of the system (housing, power module, controller SW etc). Break down as many levels as needed.

Manage the model scope, and stop to consider return on investment before modeling below “architecture level”.

Quick visualization of relationships benefits from a properly structured model. Make sure you understand the visualization capabilities of the modeling tool before deciding on model structure. For Enterprise Architect this is the “Traceability view”, the “Relationship Matrix”, and “Insert Related Elements” feature.’

Traceability, Reporting and Visualization

Projects may require traceability between stakeholder requirements, system requirements, components, test-cases and tests at different levels. As long as the “Model Setup Recommendations” are followed, custom searches can be saved and performed quickly on the model without the need for documenting complex relationships directly. Examples of possible custom searches are listen below:

Passed test-cases at SW component level tracing to a set of stakeholder requirements.

Components impacted by changes in a requirement, and tests that must be re-run.

List of stakeholder requirements not yet verified at component level.

Sometimes, there are better ways to present or share information than using diagrams. Most SysML capable modeling tools have several options for reporting and presenting data. Enterprise Architect has a customizable report generator for MS Word and PDF, .html generator and an .XMI import/export function in addition to version control integration. Also, relationships in packages can be presented using the relationship matrix, and any diagram can be presented on list format. This makes it possible to generate different but consistent reports and visualizations.

SysMod – the systems modeling toolbox

SysML provides a language with notation and semantics, but do not advise on the process of system modeling. SysMod is a framework for modeling the system from stakeholder requirements to a product architecture. SysMod uses examples with SysML and Enterprise Architect. This can be a good starting point for determining the scope of the modeling effort and model structure. SysMod describes at a high level what should be modeled and the relationship between packages. See Literature Recommendations for a description of SysMod.


SysML with supporting tools provides opportunities for reducing the documentation effort and increase quality in all stages of development projects. In the initial phases of a project, a SysML model can improve communication and help validate requirements and design decision. Inconsistency will be easier to discover by the use of visual models.

The project manager can track progress using custom searches across complex relationships. For example by the number of customer requirements that are verified at component level. After traceability between requirements, design and test has been established, use-cases or user stories can be prioritized for each phase of development more efficiently. Impact analysis diagrams can be generated and used for change management. Use case or user-story based development can benefit from giving the developer auto generated views of requirements and architecture. This provides relevant information for the specific use case or user story.

The ability to document relationships from system objective, through requirements and design makes it possible to trace all functionality back to customer requirements and business value. This is also valuable for testing, as test coverage can be easily measured. Diagrams showing complex relationships can be auto generated based on custom searches.

At project delivery, customer documentation or internal documents can be auto generated from the model, using custom templates. For example design descriptions, interface descriptions and test reports. Consistency is ensured when all reports are generated from the same model. The model can also be reused for future generations of the product to speed up the initial phases of a project.

If a model is structured in a manner that facilitates its purpose, the results can be requirements and architecture descriptions that are more consistent and less time consuming to develop and maintain than document based specifications. The visual notation of SysML gives the model user a quicker understanding of requirements and architecture, this can make collaboration with stakeholders and within the development team more efficient. A prerequisite for this is that some modeling guidelines are followed in structuring and developing the model. The model structure decided on initially will impact its usability later on in the project. Consideration of the models’ purpose and potential scope must therefore be given as early as possible. This article gives some recommendations for structuring system models. To get a clearer picture of the opportunities and limitations of SysML models and the Enterprise Architect modeling tool, we recommend the literature listed at the end of this article. SYSMOD – The System Modeling toolbox gives an overview of the modeling process, and can be great input for deciding on the modeling scope and structure.

Literature Recommendations

A Practical Guide to SysML
Description: The SysML Language, Author: Friedenthal, Moore, Steiner

SYSMOD – The Systems Modeling Toolbox
Description: A Systems Engineering process based on best practices, that uses SysML. Author: Tim Weilkiens

50 Enterprise Architect Tricks
Description: Useful tips and tricks for modeling in Sparx Enterprise Architect. Author: Peter Doomen


INCOSE – International Council on Systems Engineering

UML – Unified Modeling Language