SysML FAQ: What is SysML? Who created SysML? …

This section features Frequently Asked Questions (FAQs) about the Systems Modeling Language (SysML).

Please contact us regarding any additions or corrections to be made to this page.
What is SysML?
The Systems Modeling Language (SysML) is general-purpose architecture modeling language for Systems Engineering applications.
• SysML supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. These systems may include hardware, software, information, processes, personnel, and facilities.
• SysML is a dialect of UML 2, and is defined as a UML 2 Profile (UML customization that defines language extensions via Stereotypes, Tagged Values, and Constraints.)
• SysML is an enabling technology for Model-Based Systems Engineering (MBSE).

For answers to other frequently asked questions regarding SysML (Why use SysML?, Who created SysML?, What is the current version of SysML?, etc.) check out the SysML Frequently Asked Questions (FAQ) page.
Who created SysML?
The Systems Modeling Language (SysML) was created by the SysML Partners, an informal association of Systems Engineering experts and software modeling tool experts that was organized by Cris Kobryn in 2003 to create a profile (dialect) of the Unified Modeling Language (UML) that could be used for Systems Engineering applications.

Since Kobryn had previously successfully led the UML 1.x and UML 2.0 language design teams, two INCOSE leaders (David Oliver and Sanford Friedenthal) asked Kobryn to lead their effort to respond to the Object Management Group's UML for Systems Engineering RFP issued in March 2003. As Chair of the SysML Partners Kobryn coined the language name "SysML" (short for "Systems Modeling Language"), designed the original SysML logo, organized the SysML core language design team as an open source specification project, and served as Chief Editor of the SysML specifications.

David Oliver, Co-Chair of the INCOSE Model Driven Design Working Group and INCOSE Fellow, was a seminal contributor to the SysML Partners throughout the project. (See Acknowledgement in Memoriam below.) Sandy Friedenthal, chair of the OMG Systems Engineering Special Interest Group, served as Deputy Chair of the SysML Partners during the start of the project. Other key contributors to the SysML open source project included, but were not not limited, to Chris Sibbald (Teleogic), Thomas Wiegert (Motorola), and Brian Willard (Northrop Grumman).
Why use SysML?
If you are a Systems Engineer who seeks to improve the precision and efficiency of your communications with fellow Systems Engineers and other system and business stakeholders (e.g., Clients, Software Engineers, Electrical Engineers, Mechanical Engineers), then you should consider using an architecture modeling language standard as a lingua franca (common language). The most popular choice for Model-Based Systems Engineering (MBSE) applications is the SysML dialect of UML 2, which extends the UML standard for software-intensive applications so that it can be applied to Systems Engineering applications.

Here's a list of reasons why Systems Engineers apply an MBSE + SysML approach to their Systems Engineering applications:
• Facilitate communication among various stakeholders across the System Development Life Cycle
• Capture and manage corporate Intellectual Property related to system architectures, designs, and processes
• Compare and contrast “As Is” and “To Be” solutions
• Provide scalable structure for problem solving
• Furnish rich abstractions to manage size and complexity
• Explore multiple solutions or ideas concurrently with minimal risk
• Detect errors and omissions early in System Development Life Cycle
What is the current version of the SysML specification, and where can I download it?
The current version of the OMG SysML specification is OMG SysML v. 1.4, which is available from the SysML Specifications page of this web or can be downloaded from the OMG web.

You can find a OMG SysML v. 1.4 minor revision change summary as part of the Answer to the SysML FAQ: What is new in OMG SysML 1.4?.
Who maintains the SysML specification and how is it updated?
The Object Management Group (OMG) has adopted and maintains the OMG SysML version of the SysML specification. As with any OMG specification, minor revisions to OMG SysML are effected by Revision Task Forces (RTFs) and major revisions are effected by Requests for Proposals (RFPs). For more details regarding the OMG revision processes see the the OMG web.
What are the SysML diagram types?
The SysML specification defines nine (9) diagram types, which are shown in the SysML Diagram Taxonomy figure below, and one tabular notation (Allocation tables). Of the nine diagram types, four diagram types are considered behavioral or dynamic (Activity, Sequence, State Machine, and Use Case), four diagram types are considered structural or static (Block Definition, Internal Block, Parametric, and Package) and the remaining diagram type is reserved for declaring requirements (Requirement).

Usage Note: Allocation tables are used for defining cross-cutting relationships between diagram types, and are useful to checking both semantic well-formedness rules and architectural integrity rules. A common example of a behavior-to-structure Allocation is the mapping of behavioral Activities in Activity diagrams to the structural Blocks in a Block Definition diagram via Activity Partitions (commonly referred to as "swim lanes"). A common example of a structure-to-structure Allocation is the mapping of Interface structures to the Block structures that realize or implement them.

SysML Diagram Taxonomy

SysML Diagram Taxonomy

Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.

What are the "Four Pillars" of SysML?
(What are the essential diagrams of SysML?)
The expression the Four Pillars of SysML refers to the four essential diagrams of SysML: Requirement, Activity, Block, and Parametric diagrams. The expression was coined by Cris Kobryn, the chair of the SysML Partners open source specification project, when he observed that 80+% of the time that the SysML Partners discussed SysML language features they were discussing features in these four diagrams. He further noted that, from an artificial language design perspective, the Activity and Block diagram pillars were more important than the other two, since they were based on proven UML2 diagram techniques that already successfully integrated (allocated) behaviors (functions) to structures.
What is the relationship between SysML and UML?
Short Answer:
Contrary to MBSE and tool-vendor Muddle-Driven Marketecture hype, the differences between the SysML and UML modeling languages are more lightweight and dialectical in nature than heavyweight and substantive. This should be expected since SysML was originally designed to be used by Systems Engineers collaborating with Software Engineers applying UML for software analysis and design, and SysML is defined as a modestly extended pragmatic subset of UML 2. (See SysML FAQ: Can SysML and UML model elements be combined in the same model?) Indeed, although SysML adds two useful diagram usages to UML (Requirements diagrams extend UML Class diagrams; Parametric diagrams extend UML Class & Composite Structure diagrams), the other diagrams that SysML borrows from UML are either largely reused without modification (e.g., Use Case, Sequence, State Machine diagrams) or are modestly tweaked with lightweight customizations called stereotypes that lack substantive semantics: e.g., renaming Classes as Blocks and adding lightweight syntax and semantics for physical item flows; adding stereotypes to Activity diagrams without bona fide executable semantics.

Longer Answer:
SysML is defined as a lightweight dialect (Profile) of UML 2.x, the industry standard modeling language for software-intensive applications. (The SysML Profile is lightweight in the sense that the changes that it makes to the underlying language are relatively modest in scope and extent, using a small number of simple stereotypes, tagged values and constraints. Compare and contrast with a heavyweight Profile, which could significantly impact how the underlying language is used.) The advantage of defining SysML as a UML Profile is that it can reuse the relatively mature notation and semantics of UML 2.x, which many modeling tool vendors have already implemented. The disadvantage of specifying SysML as a UML Profile is that SysML inherits many of the problems associated with UML 2.x, such as gratuitously complex notation, imprecise semantics, and a dysfunctional diagram interoperability standard (XMI).

Relationship between SysML & UML

Relationship between SysML & UML

Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.

SysML offers systems engineers the following advantages over UML for specifying systems and systems-of-systems:
• SysML expresses systems engineering semantics (interpretations of notations) better than than UML. It reduces UML's software bias and adds two new diagram types for requirements management and performance analysis: Requirement diagrams and Parametric diagrams, respectively.
• SysML is smaller and easier to learn than UML. Since SysML removes many software-centric and gratuitous constructs, the overall language is smaller as measured in diagram types (9 vs. 13) and total constructs.
• SysML model management constructs support the specification of models, views, and viewpoints that are architecturally aligned with IEEE-Std-1471-2000 (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems).
The following SysML-UML 2 Comparison table compares SysML diagrams with their UML counterparts where one exists. Where no UML diagram counterpart exists for a SysML diagram (e.g., Parametric and Requirement diagrams), it is marked N/A; similarly, where no SysML diagram counterpart exists for UML diagram it is marked N/A (e.g., UML 2 Communication diagram).

SysML-UML 2 Comparison

Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.

What is Model-Based Systems Engineering (MBSE)?
Model-Based Systems Engineering (MBSE), a.k.a. Model-Based Systems Development (MBSD), is a Systems Engineering paradigm that emphasizes the application of rigorous architecture modeling principles and best practices to Systems Engineering activities throughout the System Development Life Cycle (SDLC). These Systems Engineering activities include, but are not limited to, requirements analysis, Verification & Validation (V&V), functional analysis, performance analysis, trade studies, and system architecture specification.

Model-Based Systems Engineering principles and best practices continue to evolve. The following are some additional desirable characteristics of MBSE approaches:
  • emphasize a precise and complete System Architecture Model "blueprint", typically organized using an Architecture Framework with multiple Views/Viewpoints, as the primary work artifact throughout the System Development Life Cycle (SDLC);
  • promote the use of open standards for architectural modeling and tool interoperability (e.g., SysML, UML 2, XMI, AP233), where these open standards are used to specify the System Architecture Model and to serve as a lingua franca among Systems Engineers and other stakeholders (Software Engineers, Electrical Engineers, Mechanical Engineers, Customers, etc.);
  • ensure that the System Architecture Model is requirements-driven to the extent that all model elements must be fully traceable to system and user requirements;
  • ensure that the System Architecture Model is architecture-centric to the extent that all model elements must maintain structural and functional integrity relationships, and support full derivation traceablity across all system stakeholder Views and Viewpoints;
  • combine traditional Systems Engineering best practices with visual modeling best practices.

The term Model-Based Systems Engineering is popular among Systems Engineers who advocate the use of SysML as a standard visual modeling language for Systems Engineering applications, and who want to distinguish their approach from Model-Driven Development and its variants, which tend to be software centric.

For more information about Model-Based Systems Engineering check out the MBSE.Works web.
What is the relationship between SysML and MBSE?
A recommended best practice for any Model-Based Systems Engineering approach is the synergistic application of Model-Based Languages, Model-Based Tools, Model-Based Processes, and Model-Based Architecture Frameworks.
As an open standard Architecture Description Language (ADL) for Systems Engineering applications, SysML is the Model-Based Language of choice for many MBSE endeavors. However, if you don't choose and apply the other key enabling MBSE technologies properly (Modeling Tools, Model-Based Processes, and Architecture Frameworks) your MBSE project will likely achieve poor or mixed results.

System Architecture Tetrad

System Architecture Tetrad

Reproduced by Permission © 2003-2017 PivotPoint Technology Corp.

As an open standard Architecture Description Language (ADL) for Systems Engineering applications, SysML is the Model-Based Language of choice for many MBSE endeavors. However, if you don't choose and apply the other key enabling MBSE technologies properly (Modeling Tools, Model-Based Processes, and Architecture Frameworks) your MBSE project will likely achieve poor or mixed results.
What is the relationship between MBSE and other Model-Driven/Model-Based acronym expressions (MDD, MDSE, MDE, MDA, MBE, MBSD)?
Model-Based Systems Engineering (MBSE) is frequently confused with several other acronym expressions that begin with either "Model-Based" or "Model-Driven". The short answer is that Model-Based Systems Engineering is a subdiscipline of the more generic Model-Based Engineering system development paradigm. MBE is a system development paradigm that emphasizes the use of rigorous visual modeling techniques throughout the System Development Life Cycle (SDLC); MBSE is a specialization of MBE that applies MBE principles and best practices to Systems Engineering applications.

For a longer and more thorough explanation of the relationships among Model-Based Systems Engineering, Model-Based Engineering, and related MBE subdisciplines check out the Model-Based Engineering Forum and the Model-Based Engineering Visual Glossary.
Can SysML and UML model elements be combined in the same model?
Short Theoretical Answer:
In theory SysML and UML model elements can be synergistically combined in the same model. Indeed, this was one of the language design goals of the SysML Partners' open source specification project:

• Support SysML + UML mixed language usage:
Ensure that SysML constructs can be synergistically combined with UML constructs in a model shared by Systems Engineers and Software Engineers, where the former use SysML and the latter use UML. The synergistic combination of SysML and UML should maximize requirements traceability and minimize semantic overlap between the two languages.
SysML Language Design Goals, SysML Partners

Longer Practical Answer:
In practice, unfortunately, users frequently find it confusing and problematic to combine SysML and UML model elements in the same model, just as they find it befuddling and vexing to interchange SysML and UML models across supposedly XMI (XML Model Interchange) compliant modeling tools. It appears that the Object Management Group (OMG) is following a "family of languages" visual modeling design philosophy, as opposed to the "unification of languages" design philosophy that dominated UML 1.x adoption and revisions during the late 1990's and early 2000's. This misguided and poorly executed design philosophy has resulted in a "Tower of Techno-Babble" anti-pattern for users who want to synergistically combine the OMG's most popular visual modeling languages (UML, SysML, BPMN), and it has resulted in a "Meta-Babble" anti-pattern for vendors relying on the gratuitously complex Meta Object Facility (MOF) and XMI for reliable model interchange.

So, given the "Tower of Techno-Babble" anti-pattern described above, how can a team comprised of both Systems Engineers and Software Engineers specify a model that harmoniously combines SysML and UML model elements? The following outlines a technical approach based on the transitivity of requirements traceability dependencies (notably «satisfy» and «refine»), that has proven effective on numerous large, mixed modeling language projects:
  1. Select a UML modeling tool that correctly implements SysML as a UML2 compliant profile and allows you to populate SysML diagrams with UML constructs and populate UML diagrams with SysML constructs.
    UML modeling tools that support SysML vary widely in this regard, with some being more restrictive than others since the OMG specifications generally defer this sort of implementation detail to vendors. Check out for candidate SysML modeling tools that support SysML + UML2 mixed language usage.

  2. Organize your model into well-defined Views along the lines of the following, where UML and SysML diagrams are combined in a complementary manner:
    (See SysML «view» stereotype of Package for View notation and semantics.) Modelers should feel free to modify the following Views and their contents consistent with their chosen Model-Based Systems Engineering (MBSE) and/or Model-Driven Development (MDD) methods.
    • Requirements «view»: Systems Engineers are primarily responsible for the completeness, correctness, and integrity of this View and the definition of its corresponding Viewpoint. Candidate diagram type contents include, but are not limited to, the following: UML/SysML Use Case and SysML Requirement diagrams.
    • System Analysis or Functional Analysis «view»: Systems Engineers are primarily responsible for the completeness, correctness, and integrity of this View and the definition of its corresponding Viewpoint. Candidate diagram type contents include, but are not limited to, the following: SysML Block Definition, Internal Block, Parametric, Activity, and State Machine diagrams. Other SysML diagrams may be added as needed.
    • System Design «view»: Software Engineers are primarily responsible for the completeness, correctness, and integrity of this View and the definition of its corresponding Viewpoint. Candidate diagram type contents include, but are not limited to, the following: UML Class, Composite Structure, Sequence, Timing, State Machine, Component, and Deployment diagrams.
    • ...other Views as needed for Implementation, Testing, etc.

  3. Define Requirements traceability dependencies/allocations across Views
    The modeling team should designate and consistently apply appropriate dependencies for full requirements traceability across all Views. You can synergistically effect full traceability across the complementary Views described above by applying the following traceability dependency patterns within and across Views:
    • Traceablity within the Requirements «view»: Define Refine («refine») dependencies between functional Requirements and the Use Cases that refine them.
    • Traceability between the Requirements «view» & System Analysis «view»: Define Satisfy («satisfy») dependencies between Requirements and the Activities and Blocks that satisfy them. (Optional: As per common UML best practice, you can also define a Realization or Refine dependency between a Use Case and any Activity that realizes or refines it.)
    • Traceability between the System Analysis «view» & System Design «view»: Define Refine dependencies between the SysML Blocks and Activities defined in the System Analysis «view» and the UML Classes and Sequences that refine them in the System Design «view».
    • Traceability across other Views: Since Refine is a transitive relationship, System Design «view» model elements can be further refined and traced across other Views (e.g., Implementation/Construction, Deployment, Testing, etc.).

    Combined SysML+UML Example Request: If you are interested in pursuing the technical approach outlined above, but need a combined SysML + UML example to better understand how it works, please contact us. If we receive sufficient requests for a combined SysML+UML example (say 10+ requests), we will post one to the SysML Forum.
Can SysML and UML be used together in the same project?
Yes, SysML and UML are designed to be used together in the same project, where the Software Engineers use SysML for Requirements and System Analysis, and the Software Engineers use UML for Software Design. Unfortunately, many important details about how UML-SysML joint usage will work efficiently in practice are not addressed in the OMG SysML specification. The underlying problem is not mixed UML-SysML tool support, since many SysML tool vendors are UML tool vendors who implement SysML as a UML profile. In the more detailed answer that follows we assume that most UML-SysML tool vendors will be able to provide their users with "SysML only," "UML only," and "UML-SysML combined" usage modes or perspectives (the Eclipse term).

In order to understand the pragmatic problems of SysML-UML joint usage, let's consider the case of a large engineering project with many Systems Engineers and Software Engineers collaborating, where the former choose to specify Requirements and System Analysis in SysML and the latter select to specify Software Design in UML. The problems they encounter will range from linguistic overlap, where notations and semantics are similar, but differ in subtle yet important ways, to linguistic divergence, where there is no straightforward translation between the two. An example of relatively straightforward linguistic overlap is the translation between SysML Activity diagrams and UML Activity diagrams, where both diagram types use the same naming conventions, but the former make some modest notational extensions to the latter. UML profiles and stereotypes were designed to handle this case, so mixed teams using both SysML and UML Activity diagrams should not be confused by this mixed language usage.

Less straightforward is the linguistic overlap between SysML Block Definition/Internal Block diagrams and UML Class/Internal Structure/Component diagrams, where there are several issues involved in translating the former to the latter. These range from gratuitously different naming conventions (Blocks vs. Classes vs. Components), to more substantial issues such as adding SysML constructs with ambiguous semantics (e.g., SysML Item Flows) and diverging from UML's Class-Part-Instance trichotomy. (SysML has only recently added Instance Specifications with the SysML 1.2 minor revision and the ramifications of this change have not yet been fully worked out.)

There are also substantive linguistic divergence problems associated with at least one of SyML's new diagram types, Parametric diagrams. The SysML provides notation, but sparse semantics for this new diagram type, which introduces a constraint-logic paradigm that is not fully integrated into UML's object-component paradigm. In addition, SysML's Allocation relationships and UML's Trace/Refine relationships are ambiguous and overlap, so it is frequently unclear how to map SysML System Analysis constructs to UML Software Design constructs. For these reasons, project teams who plan to use both SysML and UML on large project should be aware that they will likely encounter both subtle and substantive translation and traceability problems. Hopefully vendors and methodologists will work out these problems soon, after they gain more experience applying SysML to real projects.
What is the relationship between open source SysML and OMG SysML™?
SysML was originally developed as an open source specification by the SysML Partners, an informal association of tool vendors and industry leaders. The SysML Partners submitted the SysML 1.0a open source specification to the Object Management Group (OMG) in November 2005. OMG SysML™ is derived from the open source SysML specification, and is trademarked and maintained by the OMG.
What SysML modeling tools are available?
You can find a selected list of SysML modeling tools that are compliant with the current SysML specification on the SysML.Tools web.
What Model-Based methods and processes are compatible with SysML?
You can find a selected list of Model-Based methods and processes that are compatible with SysML on the MBSE Processes page.
What Model-Based architecture frameworks are compatible with SysML?
You can find a selected list of Model-Based architecture frameworks that are compatible with SysML on the Architecture Framework Forum web.
What are the strengths and weaknesses of SysML as an architectural modeling language for MBSE?
Although OMG SysML reuses many of UML2's diagrams and constructs, this new lightweight dialect (Profile) of SysML is much less mature than its linguistic parent because it exacerbates problems inherited from UML 2 and adds new problems by introducing two new diagrams types (Requirement and Parametric diagrams) that are relatively immature (v. 1.x vs. v. 2.y):
  • SYSML & UML 2 GENERAL ISSUES (Shared with UML 2.x parent language)
    • Language bloat.
      A common and fair criticism of UML 2.x is that it is gratuitously large and complex. While SysML marketecture indicates that SysML is a "smaller, simpler" language for systems engineers, the reality is that SysML itself also suffers from language bloat because it adds two new diagrams (Requirements and Parametrics) and substantially increases the number of stereotypes with imprecise semantics (see Increase of UML 2.x voodoo semantics below), while failing to explicitly exclude many redundant and software-centric UML 2 constructs from the seven UML 2 diagrams that it inherits. The bloat is exacerbated because the SysML specification provides no guidelines regarding how to combine SysML models with UML models for engineering teams that include both software engineers and system engineers.
      • Recommendations: Explicitly remove UML constructs not needed for SysML. Provide concrete guidelines regarding how to combine SysML models with UML models for engineering teams that include both software engineers and system engineers. Encourage tool vendors to support automated translation of diagrams shared between the two languages.
    • Increase of UML 2.x voodoo semantics.
      Another common and fair criticism of UML 2.x is that its semantics, including its purported executable semantics (a.k.a. the Action Semantics) are ambiguous and imprecise. While SysML marketecture indicates that SysML supports precise semantics for specifying parametric constraints, the reality is SysML defines only vague natural language semantics for ConstraintBlock, ConstraintProperty, and Context-Specific Values/Constraints. Similarly, the semantics for Activity diagram extensions related to continuous/discrete rates and probabilities lack formal precision.
      • Recommendations: Add precise semantics for Parametric and Requirement diagram constructs, and Activity diagram extensions.
  • SYSML-SPECIFIC ISSUES (Apply to SysML but not UML 2 parent language)
    • Structural constructs for Physical and Information (Standard) Interfaces are gratuitously complex and confusing.
      The semantics and notations for StandardPorts, FlowPorts, Provided & Required Interfaces, and ItemFlows were gratuitously complex and confusing in SysML v. 1.0 - 1.2 since they conflated dependency relationships with flow relationships. Unfortunately, the patches made to fix these problems with new constructs in the SysML v. 1.3 minor revision (FullPorts, ProxyPorts, InterfaceBlocks) have exacerbated these problems, rather than fixed them.

      Although Instance Specifications were recently added to SysML 1.2, Object diagrams were not, and many issues remain about their specialized usage within SysML.
      • Recommendations: Unify, simplify, and clarify the Physical and Information Interface syntax and semantics in the next major revision, SysML 2.0.
    • Instance Specifications are ambiguously defined and poorly integrated with the rest of SysML.
      Although Instance Specifications were recently added to SysML 1.2, Object diagrams are clearly an afterthought in the language, and have never been fully integrated with the rest of SysML.
      • Recommendations: Add Object diagrams as a first-class SysML diagram type, and clarify the similarities and differences between SysML and UML Instance Specification syntax, semantics, and usages.
    • Parametric constructs are ambiguously defined and poorly integrated with the rest of SysML.
      Parametric Constraint Blocks and Constraint Properties are ambiguously defined and poorly integrated with other SysML structural diagrams. The currently have the dubious distinction of being the least mature and most problematic SysML diagram to use.
      • Recommendations: Parametric Diagrams need a complete overhaul in the next SysML major revision (SysML 2.0). This overhaul should factor in lessons learned from building bi-directional bridges between SysML 1.x Parametric diagrams and 3rd party mathematical modeling & simulation tools (e.g., MATLAB/Simulink, Mathematica).
    • Requirement constructs are incomplete and confusing.
      Problems associated with Requirement diagrams include, but are not limited to, clarifying decomposition/containment semantics, categorization, defining basic properties, clarifying relationship semantics, and reducing the semantic overlap with Use Cases.
      • Recommendations: Replace Containment with Composition for Requirements decomposition. Retire Copy dependency. Provide additional Requirement properties for source, priority, risk, verifyMethod, etc.
    • Allocation relationships and tables are incomplete and ambiguous.
      With the exception of the AllocateActivityPartition stereotype the current specification fails to leverage the architectural integrity allocations of its parent language. In addition, the definitions of the Allocate and Allocated stereotypes strongly suggest conflated dependency and flow semantics, which are indicative of novice UML modelers ("which way does the arrow point?").
      • Recommendations: Replace Allocate dependencies with flows that use distinctive notation (not dashed arrows labeled with keywords). Require that implementations automatically generate Allocate dependencies for AllocateActivityPartitions.
    • ValueType-Type integration needs simplification and a SI Model Library.
      The current usage of ValueTypes with Units and QuantityKinds (formerly Dimensions) and their integration with UML DataTypes needs to be clarified and simplified.
      • Recommendations: Simplify and predefine a standard SysML ValueType model library based on International System of Units (SI) standards.
What is the best way to learn SysML?
Learning any new language is challenging, whether it is a natural language (e.g., Japanese, Swahili, English) or an artificial language, such as SysML. Since SysML is a dialect (Profile) of UML 2, if you are fluent in UML 2and understand how Parts, Ports and Connectors support component-based designyou should be able to learn the SysML dialect relatively quickly. On the other hand, if you have only dabbled with UML 1 and have succumbed to UML 1 worst practices (e.g., Use Case Abuse), your previous bad exposure to UML 1 may be a liability rather than an asset.

In order to increase your likelihood of achieving SysML language fluency, you may want to consider a multi-pronged approach to learning SysML. For example, if you have the opportunity you may want to start off with basic SysML hands-on training, followed up by expert coaching (mentoring) for On The Job training, which in turn is followed up with advanced SysML hands-on training. For the best learning experience, ensure that all your SysML training is taught by expert practitioners with extensive application experience on large projects, and includes frequent hands-on practice sessions and Q&A sessions.

In addition, you should also also read voraciously about SysML techniques and best practices, so that you can further benefit from the experience (and mistakes) of others.

You can find a listing of selected SysML training resources on the SysML Training page of this web.

You can find a listing of selected SysML tutorials on the SysML Tutorials page of this web.

You can find a listing of selected SysML publications (including books, papers, and articles) on the SysML Publications page of this web.
Which language is easier to learn, SysML or UML?
The answer likely depends on whether you are a Systems Engineer or a Software Developer. If you are a Systems Engineer, you should expect SysML to be easier to learn, since it is smaller language and it is customized for your systems engineering applications. If you are a Software Developer, you will likely prefer UML's software-centric bias.
Can SysML be used as an Agile Architecture & Design (Agile Modeling) language?
Yes, SysML is emerging as an attractive alternative to its parent language, UML 2, for Agile Architecture & Design (a.k.a. Agile Modeling) applications.

Why is SysML an attractive alternative to UML? Consider that SysML is substantially smaller than UML 2.x, so it is easier to learn and apply, yet it is more semantically expressive than UML 2.x, so you can specify visual Requirements and Parametric Constraints as well as Analysis and Design artifacts. Stated otherwise, SysML is more agile and more semantically powerful, while UML is plodding and less semantically powerful. So it shouldn't be surprising that many software engineers and developers are looking at SysML as a "better UML."
How can I report a SysML issue or submit a SysML change request?
The current version of OMG SysML is v. 1.4, and an OMG SysML v 1.5 Revision Task Force (RTF) is working on proposed improvements to OMG SysML based on feedback from the SysML tool vendor and user communities. The OMG SysML v. 1.4 RTF's Issue List ( is public, contains issues dating back to 2006, and is organized into open and closed issues.

You can comment on any open issue by sending email to In addition you can submit new issues, including change requests, by sending email to
How can readers submit new questions for this FAQ?
Please email your request for new questions to be answered using the Contact page.
Systems Modeling Language and SysML are not usable as trademarks (see SysML open source project Legal Notices). Unified Modeling Language, UML and OMG SysML are trademarks of the Object Management Group. All other product and service names mentioned are the trademarks of their respective companies.