SysML FAQ: How can I specify SysML work artifacts for a MBSE project?
DISCLAIMER: The following content constitutes technical information; it does not constitute legal advice, and it does not establish an attorney-client relationship. If you need legal advice, please contact an attorney.
BACKGROUND - SysML-as-Executable-System-Architecture vs. SysML-as-Pretty-Pictures
Since Model-Based Systems Engineering (MBSE) technologies such as the SysML language and SysML modeling tools are frequently overhyped and underdelivered by MBSE evangelists and tool vendors, its important that you are able to distinguish between bona fide MBSE + SysML approaches that deliver quality SysML-as-System-Architecture-Blueprint work artifacts and bogus MBSE + SysML approaches that deliver SysML-as-Pretty-Pictures work artifacts. By specifying tool-independent and method-neutral Technical Requirements for your MBSE + SysML project deliverables, you can help ensure that your engineering or contractor team applies a bona fide, rather than a bogus, MBSE approach to your project.
Consider applying some variation of the following technical requirements to improve the quality of your MBSE + SysML project deliverables:
TECHNICAL REQUIREMENTS FOR MBSE + SYSML PROJECT DELIVERABLES (DRAFT)
The Systems Engineering Team (SE Team) assigned to the subject System project shall apply a rigorous Model-Based Systems Engineering (MBSE) approach that is fully documented and produces the following minimal set of project deliverables:
1.0 SYSTEM ARCHITECTURE MODEL (SAM)
The SE Team shall deliver a precise and complete System Architecture Model (SAM) as its primary project deliverable. The SAM shall serve as "system architecture truth" for all other System Development Life Cycle (SDLC) project deliverables (i.e., whenever there is a technical conflict between the SAM and another project deliverable, the former will technically prevail over the latter.). The SAM shall also demonstrate the MBSE principles and best practices described in the subsections below.
1.1 Industry Standards Compliance and Conformance: The SAM shall comply or conform with the following industry standards, which are listed in prioritized order (whenever there is a conflict among industry standards, the higher-priority industry standard will prevail):
1.2 Architecture-Centric: The SAM shall precisely and completely define the overall System Context and the System Architecture of the subject System throughout the System Development Lifecycle (SDLC). The System Context shall define the system scope in a clear and unambiguous manner for all System Stakeholders by explicitly defining the System-of-Systems of which the System is a part, as well as all other peer Systems with which the subject System interacts … The System Architecture shall be precisely and completely defined with sufficient clarity and detail so that it will be self-describing, and practical for a third party to bid and build the system without additional support materials. …
Detailed technical requirements to improve the precision and completeness of the SAM are described in the sections below …
…
1.3 Enterprise Architecture Framework Conformance: The SAM shall conform to a well-defined Enterprise Architecture Framework pattern that organizes all SAM elements into complementary SysML Views (horizontal layers of abstraction) that are rationally partitioned by SysML Packages, where all Views are defined by SysML Viewpoints (perspectives) meaningful to all System stakeholders. If an Enterprise Architecture Framework industry standard is not specified in the Industry Standards Compliance and Conformance section, the SE Team shall either adopt or adapt an industry standard Enterprise Architecture Framework, or alternatively define one precisely and completely using Views and Viewpoints …
…
1.4 Verification & Validation Support: The SAM shall demonstrate full Verification & Validation (V&V) support for all SAM model elements across the SDLC. The full V&V support shall extend to both sides (i.e., "Left Side" and "Right Side") of the industry standard System V-Model (a.k.a. System Vee Model) as specified in the System Life Cycle Process Models: Vee section of the SEBoK. As in SEBoK, the following sub-requirements refer to the "Left Side" and the "Right Side" of the System V-Model as per the original source [Forsberg, Mooz, and Cotterman 2005]:
1.5 Model-Based Simulation Support: The SAM shall demonstrate support for model-based simulations of SysML behavioral diagrams (Activity, Sequence, and State Machine diagrams) and model-based simulations of Parametric diagrams for Trade Studies applications …
…
1.6 Change Impact Analysis Support: The SAM shall demonstrate support for automated change impact analysis, whereby any change to any System Functional Requirement or Non-Functional Requirement shall result in a prioritized list of Architecture, Analysis, and Design model elements that are effected (i.e., impacted or changed) by the subject Requirement change. … The demonstration shall include one or more Allocation Tables that illustrate both the Requirement changes as well as their potential side effects (i.e., impacts) on other model elements.
…
1.N Tool-Independent & Tool-Proprietary Formats: The SAM in its entirety shall be delivered in all of the following tool-independent document formats: XMI (XML Model Interchange), HTML, RTF, and PDF. In addition, all SAM derived deliverables (see MODEL-BASED SRS, MODEL-BASED SDS, and MODEL-BASED ICDs sections below) shall be accompanied by the SAM View or specific Package from which it was derived in all the same tool-independent document formats listed above. …
Not withstanding the foregoing, the SE Team shall also provide the tool-proprietary format of the SysML compliant modeling tool used to generate the aforementioned SAM and SAM-derived deliverables in tool-independent formats. [Rationale: The System Integration Test (SIT) Team needs access to the SysML modeling tool-proprietary format for Quality Control purposes, so that they can efficiently apply model metrics and other diagnostics to the SAM to verify its correctness and completeness.] …
…
2.0 MODEL-BASED SYSTEM REQUIREMENTS SPECIFICATIONS (MODEL-BASED SRS)
All System Functional and Non-Functional requirements shall be precisely and completely specified in human-readable format in a System Requirements Specification (SRS) that is automatically generated from, or directly derived from, the SAM specified in the System Architecture Model section. At a minimum, the SRS shall define all Functional and Non-Functional Requirements as SysML Requirement elements in SysML Requirement diagrams, and it shall specify all System usage functions as SysML Use Case elements in SysML Use Case diagrams.
Both the SysML Requirement elements and SysML Use Case elements shall be hierarchically organized using the appropriate SysML relationships (Contains relationship and Includes dependency respectively). All Derived Requirements that are generated from existing Requirement shall be precisely specified using DeriveReqt dependencies…
Any semantic overlap that exists between SysML Functional Requirement elements and SysML Use Case elements shall be explicitly addressed and resolved using SysML Refine dependency relationships. …
…
3.0 MODEL-BASED SYSTEM DESIGN SPECIFICATIONS (MODEL-BASED SDS)
All System Designs shall be precisely and concisely specified in human-readable format in a System Design Specification (SDS) that is automatically generated from, or at least directly derived from, the SAM specified in the System Architecture Model section. At a minimum the SDS shall define all System and System Component static structures and dynamic behaviors in a manner that meets or exceeds the rigor described below.
3.1 System and Component Static Structures. The System and all of its Components shall be recursively specified as both black-box components and white-box components using SysML Block Definition (BDD) and SysML Internal Block Diagrams (BDD), respectively. The recursive specification of the System composition structure shall start with the System and will descend into Subsystem components, Sub-Subsystem components, etc. until the Block structures being specified are atomic (non-decomposable into SysML Parts).
All System Design structural components shall be fully specified as SysML Blocks with completely defined Properties (Part Property, Reference Properties, Value Properties), Operations and/or Signals, Constraints, Ports (Standard Ports, Proxy Ports, Full Ports), and Interfaces (Standard Interfaces, Interface Blocks). …
…
For more information regarding the precision and completeness required for specifying Ports and Interfaces, see the Model-Based ICD section …
…
3.2 System and Component Dynamic Behavior. The dynamic behavior of the System and its Components shall be precisely and completely specified by using a fully-integrated combination of SysML behavioral diagrams (Sequence, Activity, State Machine diagrams). At a minimum, all System and Component dynamic behavior shall precisely specify the following:
4.0 MODEL-BASED INTERFACE CONTROL DOCUMENTS (MODEL-BASED ICD)
All System and System Component Interfaces shall be precisely and completely specified in human-readable Interface Control Documents (ICD) which are directly derived from work artifacts specified in the SAM in general, and the Model-Based SDS in particular, …
…
4.1 Information (Data) Flow Type interfaces. The ICD shall precisely and completely specify all Information (Data) Flow type interfaces in the following manner …
All Information Flow Interfaces shall be specified as SysML Standard Interfaces, where each Standard Interface is defined as a set of fully parameterized Operations and/or Signals, and each Interfaces is provided by at least one Block (specified by a Realize Dependency) , and is required by at least one other Block (specified by a Use Dependency relationship) …
…
In addition, the ICD shall include Sequence diagrams that show how all Interface Operations and/or Signals are used in at least one Sequence diagram interaction …
…
4.2 Physical Item Flow Type interfaces. The ICD shall precisely and completely specify all Physical Item Flow type interfaces in the following manner …
…
Please contact us to provide constructive feedback to improve the quality and utility of the MBSE technical requirements examples above.
BACKGROUND - SysML-as-Executable-System-Architecture vs. SysML-as-Pretty-Pictures
Since Model-Based Systems Engineering (MBSE) technologies such as the SysML language and SysML modeling tools are frequently overhyped and underdelivered by MBSE evangelists and tool vendors, its important that you are able to distinguish between bona fide MBSE + SysML approaches that deliver quality SysML-as-System-Architecture-Blueprint work artifacts and bogus MBSE + SysML approaches that deliver SysML-as-Pretty-Pictures work artifacts. By specifying tool-independent and method-neutral Technical Requirements for your MBSE + SysML project deliverables, you can help ensure that your engineering or contractor team applies a bona fide, rather than a bogus, MBSE approach to your project.
Consider applying some variation of the following technical requirements to improve the quality of your MBSE + SysML project deliverables:
TECHNICAL REQUIREMENTS FOR MBSE + SYSML PROJECT DELIVERABLES (DRAFT)
The Systems Engineering Team (SE Team) assigned to the subject System project shall apply a rigorous Model-Based Systems Engineering (MBSE) approach that is fully documented and produces the following minimal set of project deliverables:
1.0 SYSTEM ARCHITECTURE MODEL (SAM)
The SE Team shall deliver a precise and complete System Architecture Model (SAM) as its primary project deliverable. The SAM shall serve as "system architecture truth" for all other System Development Life Cycle (SDLC) project deliverables (i.e., whenever there is a technical conflict between the SAM and another project deliverable, the former will technically prevail over the latter.). The SAM shall also demonstrate the MBSE principles and best practices described in the subsections below.
1.1 Industry Standards Compliance and Conformance: The SAM shall comply or conform with the following industry standards, which are listed in prioritized order (whenever there is a conflict among industry standards, the higher-priority industry standard will prevail):
- OMG SysML: The SAM shall be specified using the OMG SysML architecture modeling language, the de facto industry standard for graphically specifying system engineering applications. The SAM shall be specified using OMG SysML v. 1.4 or later, and it must follow OMG SysML well-formedness rules for notation (graphical syntax) and semantics. …
- INCOSE Systems Engineering Handbook and Guide to the Systems Engineering Body of Knowledge (SEBoK): …
- ISO/IEC/IEEE 15288:2015 Systems and software engineering -- System life cycle processes: …
- [Insert Enterprise Architecture Framework standard for relevant industry] (e.g., DoDAF 2, TOGAF 9, etc.)
- [Insert Functional Safety standard for relevant Industry] (e.g., ISO 26262 Road vehicles – Functional safety)
- [Insert Cybersecurity Framework Standard for relevant industry] (e.g., NIST Framework for Improving Critical Infrastructure v. 1.x)
- …
1.2 Architecture-Centric: The SAM shall precisely and completely define the overall System Context and the System Architecture of the subject System throughout the System Development Lifecycle (SDLC). The System Context shall define the system scope in a clear and unambiguous manner for all System Stakeholders by explicitly defining the System-of-Systems of which the System is a part, as well as all other peer Systems with which the subject System interacts … The System Architecture shall be precisely and completely defined with sufficient clarity and detail so that it will be self-describing, and practical for a third party to bid and build the system without additional support materials. …
Detailed technical requirements to improve the precision and completeness of the SAM are described in the sections below …
…
1.3 Enterprise Architecture Framework Conformance: The SAM shall conform to a well-defined Enterprise Architecture Framework pattern that organizes all SAM elements into complementary SysML Views (horizontal layers of abstraction) that are rationally partitioned by SysML Packages, where all Views are defined by SysML Viewpoints (perspectives) meaningful to all System stakeholders. If an Enterprise Architecture Framework industry standard is not specified in the Industry Standards Compliance and Conformance section, the SE Team shall either adopt or adapt an industry standard Enterprise Architecture Framework, or alternatively define one precisely and completely using Views and Viewpoints …
…
1.4 Verification & Validation Support: The SAM shall demonstrate full Verification & Validation (V&V) support for all SAM model elements across the SDLC. The full V&V support shall extend to both sides (i.e., "Left Side" and "Right Side") of the industry standard System V-Model (a.k.a. System Vee Model) as specified in the System Life Cycle Process Models: Vee section of the SEBoK. As in SEBoK, the following sub-requirements refer to the "Left Side" and the "Right Side" of the System V-Model as per the original source [Forsberg, Mooz, and Cotterman 2005]:
- "Left Side" of System V-Model: All System Architecture, Analysis, and Design model elements for work artifacts that comprise the "left side" of the System V-Model shall either directly or indirectly (i.e., transitively) satisfy the System Functional and Non-Functional Requirements specified in the System Requirements View of the SAM using SysML Satisfy dependency relationships. All demonstrations of System Requirement Satisfaction on the Left Side of the System V-Model shall be summarized by automated generation of appropriate Allocation Tables from the subject SAM …
- "Right Side" of V-Model: All White-Box and Black-Box Test Cases for Unit, Integration and System verification and validation on the "Right Hand" side of the System V-Model shall test, verify, and validate all model elements on the "Left Side" of the System V-Model. All demonstrations of System Verification & Validation on the Right Side of the System V-Model shall be summarized by Allocation Takes automatically generated from the subject SAM …
1.5 Model-Based Simulation Support: The SAM shall demonstrate support for model-based simulations of SysML behavioral diagrams (Activity, Sequence, and State Machine diagrams) and model-based simulations of Parametric diagrams for Trade Studies applications …
…
1.6 Change Impact Analysis Support: The SAM shall demonstrate support for automated change impact analysis, whereby any change to any System Functional Requirement or Non-Functional Requirement shall result in a prioritized list of Architecture, Analysis, and Design model elements that are effected (i.e., impacted or changed) by the subject Requirement change. … The demonstration shall include one or more Allocation Tables that illustrate both the Requirement changes as well as their potential side effects (i.e., impacts) on other model elements.
…
1.N Tool-Independent & Tool-Proprietary Formats: The SAM in its entirety shall be delivered in all of the following tool-independent document formats: XMI (XML Model Interchange), HTML, RTF, and PDF. In addition, all SAM derived deliverables (see MODEL-BASED SRS, MODEL-BASED SDS, and MODEL-BASED ICDs sections below) shall be accompanied by the SAM View or specific Package from which it was derived in all the same tool-independent document formats listed above. …
Not withstanding the foregoing, the SE Team shall also provide the tool-proprietary format of the SysML compliant modeling tool used to generate the aforementioned SAM and SAM-derived deliverables in tool-independent formats. [Rationale: The System Integration Test (SIT) Team needs access to the SysML modeling tool-proprietary format for Quality Control purposes, so that they can efficiently apply model metrics and other diagnostics to the SAM to verify its correctness and completeness.] …
…
2.0 MODEL-BASED SYSTEM REQUIREMENTS SPECIFICATIONS (MODEL-BASED SRS)
All System Functional and Non-Functional requirements shall be precisely and completely specified in human-readable format in a System Requirements Specification (SRS) that is automatically generated from, or directly derived from, the SAM specified in the System Architecture Model section. At a minimum, the SRS shall define all Functional and Non-Functional Requirements as SysML Requirement elements in SysML Requirement diagrams, and it shall specify all System usage functions as SysML Use Case elements in SysML Use Case diagrams.
Both the SysML Requirement elements and SysML Use Case elements shall be hierarchically organized using the appropriate SysML relationships (Contains relationship and Includes dependency respectively). All Derived Requirements that are generated from existing Requirement shall be precisely specified using DeriveReqt dependencies…
Any semantic overlap that exists between SysML Functional Requirement elements and SysML Use Case elements shall be explicitly addressed and resolved using SysML Refine dependency relationships. …
…
3.0 MODEL-BASED SYSTEM DESIGN SPECIFICATIONS (MODEL-BASED SDS)
All System Designs shall be precisely and concisely specified in human-readable format in a System Design Specification (SDS) that is automatically generated from, or at least directly derived from, the SAM specified in the System Architecture Model section. At a minimum the SDS shall define all System and System Component static structures and dynamic behaviors in a manner that meets or exceeds the rigor described below.
3.1 System and Component Static Structures. The System and all of its Components shall be recursively specified as both black-box components and white-box components using SysML Block Definition (BDD) and SysML Internal Block Diagrams (BDD), respectively. The recursive specification of the System composition structure shall start with the System and will descend into Subsystem components, Sub-Subsystem components, etc. until the Block structures being specified are atomic (non-decomposable into SysML Parts).
All System Design structural components shall be fully specified as SysML Blocks with completely defined Properties (Part Property, Reference Properties, Value Properties), Operations and/or Signals, Constraints, Ports (Standard Ports, Proxy Ports, Full Ports), and Interfaces (Standard Interfaces, Interface Blocks). …
…
For more information regarding the precision and completeness required for specifying Ports and Interfaces, see the Model-Based ICD section …
…
3.2 System and Component Dynamic Behavior. The dynamic behavior of the System and its Components shall be precisely and completely specified by using a fully-integrated combination of SysML behavioral diagrams (Sequence, Activity, State Machine diagrams). At a minimum, all System and Component dynamic behavior shall precisely specify the following:
- information (Data) Flow Interface interactions: All System and Component information (data) flow Interface interactions shall be precisely and completely specified using Sequence diagrams that show both synchronous and asynchronous communication sequences, as well as optional time constraints when appropriate. … As a matter of SAM architectural integrity, all Operations and Signals defined in Standard Interfaces in the Static Structural diagram must appear at least once in a Sequence diagram in the dynamic behavioral model. …
- Physical Item Flow Interface interactions: All System and Component physical item flow interactions shall be precisely and completely defined via Item Flows in at least one Block Definition Diagram (BDD) + internal Block Diagram (IBD) matched pair, and must appear in at least one collaborative behavioral diagram (either an Activity or a Sequence diagram). …
- System Critical Events. All dynamic behavior that is considered time critical, mission critical, life critical, or otherwise critical shall be precisely and completely specified by State Machine diagrams that are correctly and fully integrated with other related behavioral diagrams (e.g., Sequence and Activity diagrams).
- …
4.0 MODEL-BASED INTERFACE CONTROL DOCUMENTS (MODEL-BASED ICD)
All System and System Component Interfaces shall be precisely and completely specified in human-readable Interface Control Documents (ICD) which are directly derived from work artifacts specified in the SAM in general, and the Model-Based SDS in particular, …
…
4.1 Information (Data) Flow Type interfaces. The ICD shall precisely and completely specify all Information (Data) Flow type interfaces in the following manner …
All Information Flow Interfaces shall be specified as SysML Standard Interfaces, where each Standard Interface is defined as a set of fully parameterized Operations and/or Signals, and each Interfaces is provided by at least one Block (specified by a Realize Dependency) , and is required by at least one other Block (specified by a Use Dependency relationship) …
…
In addition, the ICD shall include Sequence diagrams that show how all Interface Operations and/or Signals are used in at least one Sequence diagram interaction …
…
4.2 Physical Item Flow Type interfaces. The ICD shall precisely and completely specify all Physical Item Flow type interfaces in the following manner …
…
Please contact us to provide constructive feedback to improve the quality and utility of the MBSE technical requirements examples above.
UML, BPMN, OMG SYSML and UPDM are trademarks of the Object Management Group.
TOGAF and ARCHIMATE are trademarks of The Open Group.
ENTERPRISE ARCHITECT is a trademark of Sparx Systems Pty Ltd. MAGICDRAW and CAMEO are trademarks of No Magic, Inc. RATIONAL RHAPSODY is a trademark of IBM.
All other trademarks are the property of their respective owners.
TOGAF and ARCHIMATE are trademarks of The Open Group.
ENTERPRISE ARCHITECT is a trademark of Sparx Systems Pty Ltd. MAGICDRAW and CAMEO are trademarks of No Magic, Inc. RATIONAL RHAPSODY is a trademark of IBM.
All other trademarks are the property of their respective owners.
© 2003-2024 PivotPoint Technology Corp. | Terms of Use | Privacy | Contact Us