SysML Forum
All Things Related to SysML

SysML FAQ: What is SysML?, Why use SysML? Who created SysML?

General Questions

SysML FAQ: What is the Systems Modeling Language (SysML)?

The Systems Modeling Language (SysML) is general purpose visual 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 (Profile = UML customization that uses Stereotypes, Tagged Values, and Constraints.)
  • SysML is an enabling technology for Model-Based Systems Engineering (MBSE)
SysML & Visual Modeling Language Evolution

SysML & Visual Modeling Language Evolution

Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.



The SysML was originally developed as an open source specification project initiated in 2003 in response to OMG’s “UML for Systems Engineering” RFP. SysML contains nine diagram types, seven of which it shares in common with its parent language, along with one tabular notation (Allocation tables.) The SysML specification is publicly available for download, and includes an open source license for distribution and use. The most recent revision is OMG SysML v. 1.3. (See Specifications page.)

SysML Diagram Taxonomy

SysML Diagram Taxonomy

Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.


SysML FAQ: Why use SysML?

If you are a Systems Engineering and want to improve the precision and efficiency of your communications with fellow Systems Engineers and other system and business stakeholders, then SysML is an excellent choice for a lingua franca. (If on the other hand, you are a Software Developer or a Business Analyst who wants to improve communications with your peers and other system stakeholders, then UML or BPMN may be better choices.) Here's a list of reasons why Systems Engineers may want to use SysML and a Model-Based Systems Engineering approach for their work:
• 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

SysML FAQ: Who created SysML and how did it get its name?

The SysML specification was created by the SysML Partners, a group of software tool vendors and industry leaders organized in 2003 to create a dialect of UML for systems engineering called SysML (Systems Modeling Language). The SysML Partners defined SysML as an open source specification that would satisfy the requirements of the OMG's "UML for Systems Engineering" RFP, and their specifications include an open source license for distribution and use.

The SysML Partners were founded and chaired by Cris Kobryn, who previously chaired the UML 1.x and UML 2.0 specification teams. Kobryn coined the language name "SysML" (short for "Systems Modeling Language"), designed the original SysML logo, and organized the core language design team as an open source specification project. Sandy Friedenthal, chair of the OMG Systems Engineering Special Interest Group, served as Deputy Chair during the beginning of the project.

Acknowledgement In Memorium: In 2001, before the SysML Partners were organized and while Kobryn was still consumed with leading the UML2 Partners UML 2.0 submission team, David W. Oliver (1932-2011), Co-Chair of the INCOSE Model Driven Design Working Group first approached Kobryn about a UML for Systems Engineering concept. Impressed by Dave's passion and visual modeling expertise, and recognizing that software components and system engineering hardware components had more in common than they differed, Kobryn subsequently directed the software-centric UML2 Partners team to reduce gratuitous software-centric aspects of the UML 2.0 specification draft. Without this tedious but essential UML 2.0 foundation re-work, it is unlikely that the SysML open source specification project could have been completed in a timely manner.

You can find out more about the SysML Partners and other SysML contributors on the SysML Partners page of the SysML.org web.

SysML FAQ: 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 visual 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 and verification, functional analysis and allocations, 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 as 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 visual modeling and tool interoperability (e.g., SysML, UML, 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 Model-Based Systems Engineering Forum.

SysML FAQ: 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.

System Architecture Tetrad

System Architecture Tetrad


Reproduced by Permission © 2003-2013 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.
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.

SysML FAQ: What is the relationship between SysML and UML?

SysML is defined as a dialect (Profile) of UML 2.x, the industry standard modeling language for software-intensive applications. 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-2013 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 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., Communication diagram).

SYSML DIAGRAM

PURPOSE

UML DIAGRAM ANALOG

Activity diagram
[Behavioral diagram] An Activity diagram shows system behavior as control and data flows.
Useful for functional analysis.
Compare Flow Block Diagrams (FBDs) and Extended Functional Flow Block diagrams (EFFBDs), already commonly used among systems engineers. 
UML::
Activity diagram
Block Definition diagram
[Structural diagram] A Block Definition diagram shows system structure as components along with their Properties, Operations and Relationships.
Useful for system analysis and design.
UML::
Class diagram
Internal Block diagram
[Structural diagram] An Internal Block diagram shows the internal structures of system components, including their Parts and Connectors.
Useful for system analysis and design.
UML::
Composite Structure diagram
Package diagram
[Structural diagram] A Package diagram shows how a model is organized into Packages, Views and Viewpoints.
Useful for model management.
UML::
Package diagram
Parametric diagram
[Structural diagram] A Package diagram shows parametric constraints between structural elements. Useful for performance and quantitative analysis.
[No analogous diagram in UML]
Requirement diagram
[Requirement diagram] A Requirement diagram shows system requirements and their relationships with other elements.
Useful for requirements engineering, including requirements verification and validation (V&V).
[No analogous diagram in UML]
Sequence diagram
[Behavioral diagram] An Sequence diagram shows system behavior as interactions between system components.
Useful for system analysis and design.
UML::
Sequence diagram
State Machine diagram
[Behavioral diagram] A State Machine diagram shows system behavior as sequences of states that a component or interaction experience in response to events.
Useful for system design and simulation/code generation.
UML::
State Machine diagram
Use Case diagram
[Behavioral diagram] A Use Case diagram shows system functional requirements as transactions that are meaningful to system users.
Useful for specifying functional requirements. (Note potential semantic overlap with functional Requirements specified in Requirement diagrams.)
UML::
Use Case diagram
Allocation Table
[Mapping table; not a diagram] An Allocation Table shows various kinds of assignment relationships (e.g., requirement allocation, functional allocation, structural allocation) between model elements.
Useful for  facilitating automated verification and validation (V&V) and gap analysis.
[No analogous table in UML]
Instances (but no Object diagram)
As per the OMG SysML 1.2 minor revision, Instance Specifications, but not Object diagrams are allowed.
UML::
Object diagram
[No analogous diagram in SysML]
UML:: Communication diagram
[No analogous diagram in SysML]
UML:: Component diagram
[No analogous diagram in SysML]
UML:: Deployment diagram
[No analogous diagram in SysML]
UML::
Interaction Overview diagram
[No analogous diagram in SysML]
UML::
Profile diagram
[No analogous diagram in SysML]
UML::
Timing diagram
Many Systems Engineering processes still tend to be tend to be document centric and employ a motley mix of diagram techniques that are frequently imprecise and inconsistent. In a manner similar to how Software Engineers sought a general-purpose modeling language (UML) to precisely specify software-intensive systems during the 1990s, many Systems Engineers are now seeking a general purpose modeling language to specify complex Systems-of-Systems that include non-software components (e.g., hardware, information, processes, personnel, and facilities). UML cannot satisfy this need without modifications because of its software bias; hence the motivation for the SysML dialect of UML.

Even though SysML is based on UML, it reduces UML's size and software bias while extending its semantics to model requirements and parametric constraints. These latter capabilities are essential to support requirements engineering and performance analysis, two essential Systems Engineering activities.

SysML FAQ: What is the current version of SysML?

The current version of the OMG SysML specification is OMG SysML v. 1.3, 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.3 minor revision change summary as an Answer to the SysML FAQ "What is new in SysML 1.3?".

SysML FAQ: What is new in SysML v. 1.3?

OMG SysML 1.3 minor revision change summary:
  • Physical Flows - Deprecation of Flow Specifications
  • Physical Flows - Addition of Nested Ports and Proxy Ports.
  • Synchronization with UML 2.4.1 metamodel changes
Comments: Although Flow Specifications were known to be flawed due to their gratuitous complexity, it is odd that they are being deprecated (phased out) and replaced by two new (and unproven) physical Ports types in a minor release. Since these are significant structural changes for modeling physical flows, one would normally expect these changes to be made in a major, rather than a minor, revision.

CHANGES TO PREVIOUS VERSIONS OF OMG SysML 1.x

OMG SysML 1.2 minor revision change summary:
  • Inclusion of UML Instances, Structured Activities, and multiple Item Flow notation
  • Improvements to Value Types related to Unity and QuantityKind
  • Synchronization with UML 2.3 metamodel changes
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.
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.
Although OMG SysML reuses many of UML2's diagrams and constructs, this new dialect (Profile) of SysML is much less mature than its linguistic parent because it exacerbates problems inherited from UML 2 and adds new problems with its two new diagrams (Requirement and Parametric diagrams):
  • GENERAL ISSUES
    • Increase of UML 2.x 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 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 constructs and Activity diagram extensions.
  • SPECIFIC ISSUES
    • Structural constructs for Interfaces and Instances are complex and muddled.
      The semantics and notations for StandardPorts, FlowPorts, Provided/Required Interfaces, and ItemFlows are excessively complex and their usages are frequently counter-intuitive since they conflate dependencies with flows. 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 Ports/Interfaces/ItemFlows constructs. Add Object diagrams and clarify differences between SysML and UML Instance syntax semantics.
    • 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 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 arrrows labeled with keywords). Require that implementations automatically generate Allocate dependencies for AllocateActivityPartitions.
    • ValueType-Type integration needs simplification.
      The current usage of ValueTypes with Units and Dimensions and their integration with UML DataTypes needs to be clarified and simplified.
      • Recommendations: Simplify and predefine a standard ValueType library.

SysML FAQ: 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.
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.
Yes, SysML is emerging as an attractive alternative to its parent language, UML 2, for 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."
Please email your questions using the Contact page.

SysML FAQ: How can I report a SysML issue or make a SysML change request?

The current version of OMG SysML is v. 1.3, and an OMG SysML v 1.4 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 (http://www.omg.org/issues/sysml-rtf.open.html) 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 sysml-rtf@omg.org. In addition you can submit new issues, including change requests, by sending email to issues@omg.org.

SysML Diagrams & Modeling Techniques

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.
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
As their names imply, a structural diagram emphasizes the static structures of the system entities, whereas a behavioral diagram emphasizes the dynamic behaviors of system entities.
A SysML Requirement diagram shows relationships among visual Requirements constructs, and the model elements that fulfill and verify them.

Requirement diagrams can be used for specifying and managing system functional and non-functional requirements (e.g., performance).

Usage Note: Requirement diagrams that specify functional requirements can semantically overlap Use Case diagrams defining similar functions.
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
A SysML Activity diagram shows the functional behavior of a system using a control flows and data flows.

Systems Engineers can use Activity diagrams to specify function independent of structure (form) by not using Partitions (swimlanes)
Business Analysts can use Activity diagrams to represent business processes.

Compare and contrast: SA/SD EFFBDs, DFDs; BPMN Business Process Diagrams.
A SysML Block diagram shows the static structure of a system using components called Blocks which are connected via interfaces. A Block can represent a hardware, software, and "wetware" (organizational) components.

There are two kinds of Block diagrams in SysML, and they are designed to be used in a complementary manner: Block Definition diagrams and Internal Block diagrams.

Block Definition diagrams (BDD's) are used to define "black-box" components with external interfaces, where the external interfaces can support both information flows (via Standard Ports and Interfaces) and physical flows (via Flow Ports and Flow Specifications). SysML BDDs are derived from UML2 Class diagrams.

Internal Block diagrams (IBD's) are used to show the "white-box" perspective of Block components, where Connectors show how internal Parts are "wired" to external interfaces and each other. SysML IBDs are derived from UML2 Composite Structure diagrams.
A SysML Internal Block diagram shows the internal static structure of a system using internal components called Parts which are connected via Connectors.

There are two kinds of Block diagrams in SysML, and they are designed to be used in a complementary manner: Block Definition diagrams and Internal Block diagrams.

Block Definition diagrams (BDD's) are used to define "black-box" components with external interfaces, where the external interfaces can support both information flows (via Standard Ports and Interfaces) and physical flows (via Flow Ports and Flow Specifications). SysML BDDs are derived from UML2 Class diagrams.

Internal Block diagrams (IBD's) are used to show the "white-box" perspective of Block components, where Connectors show how internal Parts are "wired" to external interfaces and each other. SysML IBDs are derived from UML2 Composite Structure diagrams.
A SysML Parametric diagram is a kind of Internal Block Diagram that shows constraint relationships between Blocks and their internal Properties or Parts.

Parametric diagrams can be used to show how a change to the value of one structural property of a system (a system Parameter) can impact the values of others. They are useful for specifying system design and architectural constraints, and are generally considered essential for specifying Trade Studies using SysML.

Parametric Diagram Example - zoom
Parametric Diagram Example
Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
Answer to be provided. (Contact us if you want this answer to be prioritzed.)
Answer to be provided. (Contact us if you want this answer to be prioritzed.)

SysML FAQ: How does SysML enable Requirements Verification and Validation (V&V)?

Since the terms verification and validation are commonly conflated among systems and software engineers, we first clarify the differences between them using Boehm's classic formal and informal definitions [Boehm 84]:
A. Definitions
Verification - to establish the truth of the correspondence between a software product and its specification. (Note: This definition is derived from the Latin word for "truth," veritas. Note also that data bases and documentation are fit subjects for verification, as well as programs.)
Validation - to establish the fitness or worth of a software product for its operational mission. (Note: This definition is derived from the Latin word for "to be worthy," valere.)
Informally, we might define these terms via the following questions:
Verification: "Am I building the product right?"
Validation: "Am I building the right product?"
Requirement Validation is typically the responsibility of system Stakeholders, who review Requirement specifications (e.g., SysML Requirement diagrams) to determine that they define "the right product" to be built,. Requirement qualities checked during Validation include, but are not limited to, the following: Correctness, Completeness, Consistency, Clarity (Unambiguousness), Conciseness, Feasibility, Necessity, and Prioritization.
SysML Support for Requirement Validation: SysML supports Requirement Validation by defining Requirements as first class visual modeling elements that can be classified (e.g., Functional, Performance, Interface, Design Constraints), organized into hierarchies (via Containment relationships), and assigned properties (TaggedValues) as needed (e.g., Risk, VerifyMethod, Priority, Level-of-Effort).

Requirement Verification is typically the responsibility of System Engineers and Systems Analysts, who (as per [Boehm 84]) "establish the truth of the correspondence between" the systems engineering product and its Requirement specification.
SysML Support for Requirement Verification: SysML primarily supports Requirement Verification via two complementary relationships:
  • Satisfy («satisfy») dependency: The client model element fulfills a supplier Requirement. e.g., An Optimize Subsystem Activity Satisfies the 2.3.5 Optimize Subsystems Functional Requirement. [See example below.]
  • Verify («verify») dependency: The client TestCase («testCase») determines whether a supplier Requirement has been fulfilled. e.g., A Test Subsystem Optimization Activity «testCase» Verifies the 2.3.5 Optimize Subsystems Functional Requirement and Tests the SmartCarController Block in the System Design «view». [See example below.]

SysML Requirements V&V

Requirements Verification & Validation


Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.



Another Requirement Verification best practice is to define a VerifyMethod property (TaggedValue) for Requirements with appropriate values (e.g., Analysis, Demonstration, Inspection, Test).
Answer to be provided. (Contact us if you want this answer to be prioritzed.)

SysML Tools & Interoperability

Answer to be provided. (Contact us if you want this answer to be prioritzed.)

Advanced SysML Topics

You can find a selected list of Model-Based methods and processes that are compatible with SysML on the Processes page.
You can find a selected list of Model-Based architecture frameworks that are compatible with SysML on the Architecture Framework Forum web.
Model Management is an umbrella term that refers to the use of Packages and related constructs to manage the complexity of large, complex Models that represent large, complex Systems. Model Management is important to a modeler because if she cannot manage the complexity of a large, complex model, there is no reason to expect she will be able to manage the complexity of a large, complex system.

Model Management uses Packages as a generic grouping construct, as well as the following stereotypes (customizations) of Package:
  • Package: Basic grouping construct for organizing model elements and diagrams that defines unique namespace semantics, as well as Import and Contains relationships. Packages can nested and stereotyped (i.e., customized) to further organize their contents.
  • Model («model»): The (system) Model stereotype organizes all model elements that describe the architecture of the system of interest, including all of its Views and Subystems.
  • View («view»)/Viewpoint («viewpoint»): The View stereotype organizes a projection (cf. set theory projection) on a Model from the perspective (Viewpoint) of a set of stakeholders (e.g., Customer, Systems Engineer, System Analyst, System Designer, Software Engineer, Test Engineer). A Model View conforms to the perspective of its Viewpoint. In SysML both View and Viewpoint are first class elements than can be precisely defined.
  • Subsystem («subsystem): The Subsystem stereotype decomposes a Model or its Views to reflect the logical or physical structure of the system of interest. Subsystems may be logical or physical abstractions, and if both types are present they should be distinguished by using stereotype keywords or some other distinctive notation. SysML and UML predefine the «subsystem» stereotype; users may define the «system» stereotype to complement the «subsystem» stereotype if the latter is not already predefined.
  • Model Library «modelLibrary»: The Model Library stereotype organizes model elements intended for reuse in a Model.
  • Framework «framework»: The Framework stereotype groups model elements that are intended to organize other models into Views, Subsystems, etc. Frameworks can conform to industry standards (DoDAF/MODAF, UPDM, TOGAF), corporate standards, or can be specified ad hoc.
  • Profile «profile»: The Profile stereotype organizes model elements used to customize domains, platforms, and processes. These model elements include Stereotypes, Tagged Values, and Constraints.


The notations for Package and its common stereotypes are shown in the figure below.

Package Constructs

Package Constructs

Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.


A SysML system model View («view») defines a projection on a Model from the perspective of a set of stakeholders (e.g., Customer, Systems Engineer, Test Engineer), where the perspective is of a set of stakeholders is defined as a Viewpoint («view»). In SysML both View and Viewpoint are first class elements than can be precisely defined. SysML defines a Viewpoint as a stereotype (customization) of Class with tagged values (properties) for stakeholders, concerns, languages, methods, and purpose. A model View conforms to the perspective of its Viewpoint, as shown by a «conform» Dependency arrow.


For example, see the Views & Viewpoints figure below.

Views & Viewpoints

Views & Viewpoints

Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.


Answer to be provided. (Contact us if you want this answer to be prioritzed.)
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.
Answer to be provided. (Contact us if you want this answer to be prioritzed.)

OMG SYSML, UML, and UNIFIED MODELING LANGUAGE are trademarks of the Object Management Group. All other product and service names mentioned are the trademarks of their respective companies.