Back to SysML v2 RFP Working Group

Go to the latest update at: Latest Update

Wiki Syntax Help

• Elaborate concepts, requirements, and metrics for effective model construction that support the next generation system modeling language (SysML v2)
• Identify a set of services that support model construction, consistent with the System Modeling Environment goals

Graphics in PDF format: model_construction_graphic_rev_b.pdf

Graphics in PDF format: pdf_model_construction_concept_graphic.pdf

Graphics in PPT format:model_construction_concept_2017-03-08-b.pptx

The SME (Systems Modeling Environment) Model Construction Capability will enable intuitive and efficient model construction including,

• External resources (to the SME) model inputs (for both individual model elements and model constructs and collections)
• Adaptable Novice and Expert User input support for early phase “sketch” and later phase more rigorous high fidelity models
• External data sources and tools (structured and unstructured)
• Linked data access and updates via Model Interoperability capabilities
• Query capabilities against all model elements or model constructs via Visualization capabilities via a standardized query language
• Model execution via Model Analysis capabilities
• Text (structured language or free text), tabular and graphical representations
• Support for model patterns and pattern libraries
• Extensive reuse of model element and project libraries and their contents
• Support for process easy to use implementation scripts and/or “wizards” based GUI's via Visualization and Model Management
• Support for user help facilities integral to the systems modeling environment via Visualization and Model Management
• Collaborative, team oriented model construction via Collaboration capabilities
• Controlled, role based access to the model via Model Management capabilities
• Model change management supporting new model versions and variants via Model Management capabilities

• Services to create, update, and delete
  • model elements
  • links between tools or file system or databases
  • patterns (pattern is assumed to be a “model or model element”
  • model queries (overlaps with Visualization / Model Management)
  • transformations to/from SysML models (allocated to Model Management)
• Services to execute (allocated to Model Analysis)
  • model elements
  • patterns
  • model queries
  • transformations to/from SysML models
• Services to export (allocated to Model Management/Visualizatio)
  • unstructured data
  • structured data

May 2017 Model Construction Requiremnts Document

Some of the feedback included.

• A core requirement is to create, update, and delete a data set with 1 or more data elements
• Replace the service requirement to import and transform multiple elements in batch mode with a transaction service. This includes a requirement to read a list of structured data elements and its associated schema, and another requirement to transform the structured data to model elements.
• When creating an element or other model construct, create the element id (i.e., UUID)
• When transforming structured data, optionally set the id depending on whether one is specified
• When deleting an element, ensure the final state is consistent with the deletion semantics.
• When deleting an element, retain and reserve its uuid. (This may be a model management function)
• Add a service requirement to apply a pattern.
• Consider how to construct models through elaboration and refinement to transition from one level of abstraction to another, while preserving the earlier abstraction. (Note: this may be considered a transformation of one abstraction level to another that can be viewed in different viewpoints.)
• Consider usability issues that were identified in the usability discussion below

Action: Ron to update model construction service requirements with pre and post conditions. Send requirements to Geoffrey Biggs and Andy Ko for review.

• 1.1 Functional Requirements Overview
  • Model construction is the ability to create, update, and delete individual model elements or sets of model elements or model constructs including metadata elements.
  • Model construction applies to model patterns, queries, rules and expressions, transformations, links to external data elements, interface layers, and any other constructs that are used to support the construction of the system model.
  • The goal is for the SysML v2 specification to enable adaptable, efficient and intuitive model construction for a broad range of users (novice to expert). SysML v2 should not limit the use of current and future technologies that support model construction.
  • Model construction can be performed in complementary ways that include
    • interactively, using the adaptable graphical interface provided by the modeling environment via Visualization Services.
    • data group mode, by importing data/resources from an external file, database or software application, and transforming it to the corresponding SysML model constructs.
  • The model may be constructed using different forms that include textual, graphical, or tabular entry or a combination.
  • The requirements for model construction have interdependencies with other requirements related to model visualization, model management, workflow and collaboration, and model analysis.
    • Model construction uses services provided by these other capability areas, and the other capability areas use the model construction services.
  • It is expected that all interactions with the SME be in the context of a transaction that provides the ability to ensure all SME operations are either completed successfully or the SME can be rolled back to a prior consistent state.
  • Deletion Semantics: It is expected that the submitters will define the semantics associated with the deletion of model elements or constructs.
• 1.2 Create
  • SysML v2 shall provide the ability to create model elements and other model constructs interactively via Visualization Services using textual, graphical, and/or tabular entry.
  • SysML v2 shall provide the ability to create a set of model elements and other model constructs from an external source, and transforming the source data to the corresponding model elements or constructs being created.
  • SysML v2 shall create the element id (e.e. UUID) when crating an element or other model construct.
  • SysML v2 shall optionally set the element id depending on whether one is specified, when transforming structured data.
• 1.3. Update
  • SysML v2 shall provide the ability to update model elements and other model constructs interactively via Visualization Services using textual, graphical, and/or tabular entry.
  • SysML v2 shall provide the ability to update a set of model elements and other model constructs based on data obtained from an external source, and transforming the source data to the corresponding model elements or constructs being updated.
• 1.4 Delete
  • SysML v2 shall provide the ability to delete model elements and other model constructs interactively via Visualization Services using textual, graphical, and/or tabular entry.
  • SysML v2 shall provide the ability to delete model elements and other model constructs based on data obtained from an external source, and transforming the source data to the corresponding model elements or constructs being deleted.
  • SysML v2 shall preserve the unique identifiers (UUID) for the deleted model elements and constructs
  • SysML v2 shall define model element and construct deletion semantics.
  • SysML v2 shall ensure the final state is consistent with the deletion semantics, when deleting a model element or construct.
• 1.5 Apply
  • SysML v2 shall provide the ability to apply patterns, model library content, or other model element source data to the model under construction.
• 1.6 Crosscutting
  • SysML v2 shall manage unique identifiers for all model elements and constructs.
  • SysML v2 shall provide a transaction mechanism for all operations on the system modeling environment.
  • SysML v2 shall consider how to construct models through elaboration and refinement to transition from one level of abstraction to another, while preserving the earlier abstraction. (Note: this may be considered a transformation of one abstraction level to another that can be viewed in different viewpoints.)
  • SysML v2 shall consider usability issues as defined in the usability section of the SysML v2 RFP.

• 2.1 Service Requirements Overview
  • Model construction services further specify each of the functions defined by the functional requirements above and provide a definition of the signatures associated with each of the functions.
• 2.2 Create
  • Pre Condition: Model element being created does not exist with the specified id (i.e. UUID)
  • Post Condition: The model is updated to include the new model element and remains in a consistent state.
  • return value: Single UUID or collection of UUID's of the model elements that were created
  • Function Name: createModelElements
  • Function Parameters:
    • Collection of “Attribute”, attribute type, name and value quadruplets
    • Collection of operations
      • “Operation” type
      • return type,
      • operation name and
      • operation parameter type and name pairs
    • Collection of “Relationship”, relationship type, relationship name and related element UUID quadruplets
  • Example: createModelElements( { {Attribute, String, Name, “MyName”}, {Attribute, String, Description, “My description”}, {Operation, Integer, Sum, updatemodelelements_myuuid_myattributename1_newvalue1_myuuid_myattributename2_newvalue2)
• 2.4 Delete
  • Pre Condition: Model element being deleted exists with a uniue id.
  • Post Condition: The model is updated without the deleted element and remains in a consistent state.
  • Return value: Boolean (true if deleted successfully, false if error condition)
  • Function Name: deleteModelElements
  • Function Parameters:
    • Collection of UUIDs
  • Example: first retrieve a collection of model element UUID's and then invoke the deleteModelElements service using the UUID collection as a parameter.
• 2.5 Apply
  • Pre Condition: The pattern being applied is complete and self consistent.
  • Post Condition: The model is updated to include the new pattern remains in a consistent state.
  • Return value: TBD
  • Function Name: applySourceData
  • Function Parameters: TBD
  • Example: apply a pattern from the pattern library to the current workspace and instantiate the model elements associated with the pattern.

• SysML v2 shall provide a platform independent modeling language and selected platform specific bindings to create, read, update, and delete model queries.
• SysML v2 shall provide a platform independent language and selected platform specific bindings to create, read, update, and delete model transformations.
• SysML v2 shall provide a platform independent language and selected platform specific bindings to create, read, update, and delete expressions.
• SysML v2 shall provide a platform independent language and selected platform specific bindings to create, read, update, and delete viewpoint methods.

• 4.1 Concept Definitions Overview
  • The concepts defined in this section clarify the meaning of terms used in the requirements sections above.
• 4.2 Core concepts related to model construction
  • Model - (refers to existing definition)
  • Model Element – (refers to existing definition)
  • Model Construct – A model element or other entity used to construct a system model that includes model patterns, queries, rules and expressions, transformations, and links to external data elements
  • Model Collection - A collection of model elements and/or modeling constructs used to construct the system model
  • UUID (Universal Unique Identifier) - A globally unique identifier for each model element (refer to existing definition?)
  • Interactive - User initiated operations using the graphical interface of the SysML user interface
  • Batch Mode - User initiated operations using an external collection of model element properties, operations and- or relationships
  • External (Resource) Collection - A file based or database or link based mechanism to persist descriptions of model elements
  • Transaction - A mechanism to ensure an operation applied to the SME maintains the SME in a consistent state.
  • Deletion Semantics - The rules associated with deletion of model elements or constructs.

The next-generation modeling language and tools shall

• enable more intuitive and efficient model construction where intuitive is defines as: when users understand the user interface behavior and effect without use of reason, experimentation, assistance, or special training; and efficient is defined as: when users are enabled to perform an action with a minimum amount of effort.
• minimize clicks to capture a core concept in a model.
• include a more streamlined and efficient user interface in order to reduce the time and effort to build and maintain a model.
• provide the ability to repeat common modeling patterns with reduced user input (e.g., table-based entry) in order to increase modeling productivity and understanding.
• enable the import of external model data from files (text, tables, databases, graphics, graph formats)
• enable the import of external model data from other tools
• enable the import of external model data from other repositories (e.g. PLM or PDM)
• enable linked data references
• enable text and graphical representations of the model
• provide for extensive use of libraries
• support process implementation mechanisms (e.g. wizards, automation scripts)
• provide for user help facilities integral to the systems modeling tasks
• provide for a collaborative, team oriented model construction environment
• provide controlled, role based access to the model
• provide for model change management supporting new model versions and variants
• provide for constructing a model in a visual graphic language format
• provide for constructing a model in a standard textual language format
• enable the creation, deletion and update of model queries
• enable the creation, deletion and update of model validation rules
• enable the creation, deletion and update of model patterns
• enable the creation, deletion and update of viewpoints and views
• enable the creation, deletion and update of analytic models
• enable the creation, deletion and update of workflow scripts
• enable the creation, deletion and update of model based notifications

• Ability to efficiently and intuitively construct models
  • Efficiency metrics
    • Mouse/Keyboard interactions (e.g. # interactions to create, delete, modify model element, pattern, variant or model validation rule)
    • Lifecycle task productivity (e.g. requirements linking, use case behavior modeling)
    • Bulk data load rate (e.g. model elements/sec)
  • “Intuitive” Metrics
    • Learning Curve (e.g. time and complexity)
    • Tailorability to Organizations Processes/Procedures (e.g. OOSE, Harmony, SYSMOD tailoring)
    • Utility of “Help” functions
    • Effectiveness of standardized symbology or concrete syntax to distinguish model elements (e.g. action vs state)
    • Level of support for visual graphic and textual orientations of users
• Level of alignment with industry user interface and modeling standards
• Level of tool and tool vendor coupling of model construction techniques
• Flexibility of model construction capabilities related to user experience level (novice to expert)

Source: http://www.uxdesignedge.com/2010/06/intuitive-ui-what-the-heck-is-it/

Definition: A UI is efficient when users are enabled to perform an action with a minimum amount of effort

A UI is efficient when it has an appropriate combination of:

• Efficiency The UI enables users to perform an action with a minimum amount of effort. If the intention is clear, the UI delivers the expected results the first time so that users don’t have to repeat the action (perhaps with variations) to get what they want.
• Contextual The UI enables a well defined context or state associated with the task at hand. If the user is within a specific diagram workspace, only those operations associated with that diagrams context are available. All non-relevant commands/operations/graphics/etc. are filtered out of the view based on the diagram context. If the user focuses on a specific model element (either within the model browser, command palette or diagram work area) via a mouse button click or touch point, only those commands relevant to the model element in context of the browser, diagram or palette appear in a “pop up” command window. All other commands/operations are filtered out.

Source: http://www.uxdesignedge.com/2010/06/intuitive-ui-what-the-heck-is-it/

Definition: A UI is intuitive when users understand its behavior and effect without use of reason, experimentation, assistance, or special training.

A UI is intuitive when it has an appropriate combination of:

• Affordance Visually, the UI has clues that indicate what it is going to do. Users don’t have to experiment or deduce the interaction. The affordances are based on real-world experiences or standard UI conventions.
• Expectation Functionally, the UI delivers the expected, predictable results, with no surprises. Users don’t have to experiment or deduce the effect. The expectations are based on labels, real-world experiences, or standard UI conventions.
• Efficiency The UI enables users to perform an action with a minimum amount of effort. If the intention is clear, the UI delivers the expected results the first time so that users don’t have to repeat the action (perhaps with variations) to get what they want.
• Responsiveness The UI gives clear, immediate feedback to indicate that the action is happening, and was either successful or unsuccessful.
• Forgiveness If users make a mistake, either the right thing happens anyway or they can fix or undo the action with ease.
• Explorability Users can navigate throughout the UI without fear of penalty or unintended consequences, or of getting lost.
• No frustration Emotionally, users are satisfied with the interaction.

Model Construction OMG Orlando June 2016 Update

• Status of the effort (including whether Wiki is current)
  • Wiki is current
  • Updates made to Concept Model references SECM Concepts
    • Suggest a Use Case / Services driven walk through of the Concept Model by each lead to check for completeness
  • Link to common supporting services wiki page completed
  • Services and Use Cases consistent Model Construction Use Cases

• Effectiveness measures and driving requirements
  • Ease of use (model construction complexity measures)
  • Automation opportunities (import of external data)
  • Validation aspects (correctness, completeness of the model construction)
  • Model Quality Analytics (e.g. assessment of complexity, depends on method profile employed (SysMOD, Harmony, OOSE, etc.)

• Limitations of current SysML
  • Executable aspects of the system model (linkage to simulation, physics & dynamic models)
  • Constraints language for typical systems engineer (beyond OCL)
  • Parametrics equations (free text is inadequate….reference a standard and incorporate in tools)
  • Temporal modeling (some hooks, but should go much further to adequately model “time”
  • Spatial modeling (relative, logical and geospatial)
  • Viewpoint and View definitions and mechansims
  • Accommodation of Patterns
  • Support for non-model data import (tables, text, etc.)
  • Ease of creating new “sub profiles” that are tailored to problem domains (vocabulary, constraints, patterns, etc.)
  • Availability of a human readable/understandable language to represent SysML (XMI is for machines not humans)

• Key features of the concept
  • Automation mechanisms for structured & unstructured data import
  • Linkage with advanced visualization
  • Linkage with Model Management
  • Linkage with Collaborative Model Development

• Service requirements (e.g. functions)
  • see list at Interoperability Working group
  • Model Construction Services Archive Page
  • A complete list of services is included in the spreadsheet

• Illustration of how the concepts supports the Hybrid SuV scenario
  • see explanation below Hybrid SuV scenario

Change Scenario Example - Model Construction Focus

• Plans for prototypes to demonstrate feasibility
  • No plans as yet, suggest combining with Model Lifecycle Management prototype plans

• Consider combining the 3 model construction use cases for the purposes of a practical illustration. However, keep them distinct in terms of specifying the requirements on the SME.
  • The 3 use cases include:
    • Constructing a model from scratch
    • Reusing an existing model
    • Importing unstructured legacy data (e.g. word, excel)

• The idea of relating the methodology/workflow to model construction was an excellent insight.
  • A specific methodology may include a combination of profiles, patterns, and wizards
  • Need to differentiate the overall workflow requirements from the model construction specific requirements
  • Develop a specific use case addressing the construction of a model in the context of a workflow process/engine/manager
  • In model construction the services supporting task automation, pattern use, library access, model structure template access, etc. are emphasized
  • In workflow, the documentation of the methodologies available, the tracing and linkage to relevant tools, the transformation of models within the workflow, and the tailorable steps necessary to complete modeling tasks are provided as services

• Provide a capability to perform a batch create, read, update, or delete to a set of model elements which are specified by some criteria (all blocks, a particular package, etc.)

• Emphasize the need to support a textual input to the model

• Provide a capability to perform a batch create, read, update, or delete to a set of model elements which are specified by some criteria (all blocks, a particular package, etc.

• Constructing a model from scratch
  • Pre Condition: Patterns, Model Libraries, Model Quality Rules, System Level Requirements Tables are available
  • Scenario: “Outside In” / “Top Down” Approach
    • Step: Import a table of requirements as a set of “Requirement” elements (structure in packages by function, performance, SOW, etc.)
    • Step: Functional Analysis. Create “System Function” elements and trace to “Requirement” elements
    • Step: Architecture/Design: Create “System/SubSystem” model elements and allocate “System Functions” to each
    • Step: Architecture/Design: Create state and performance attributes for each “System/Subsystem” element
    • Step: Requirements Analysis: Create “Use Case” model elements and trace to “Requirement” elements
    • Step: Resource Analysis: Create “Resource” and/or “Information” elements and trace to “Requirement” elements
    • Step: Resource Exchange Analysis: Create “Resource Exchange” model elements and trace to “Requirement” and “System Function” elements
    • Step: Use Case Analysis: Create scenarios and reference “System Function” elements for each step in the scenario
    • Step: Create a process flow and data flow Views of the resulting scenario steps
    • Step: Create a message sequence View of the primary and alternate scenario steps
    • Step: Create a state machine View for each “System/Subsystem” element
    • Step: Create “Constraint” elements with embedded parameters and equations
    • Step: Create “Value Binding” relationship between the constraint parameters and element attributes
    • Step: At each step in the scenario run “Validation Rule”, “Model Quality Rule” checks and correct the model if needed
    • Step: Use automation to auto create ports, interfaces, connections and flows between the “System/Subsystem” elements
    • Step: Execute the completed model to determine end to end completeness of the behavior threads
  • Post Condition: New patterns created, New model elements created, Complete model with Requirements traceability is validated and quality checked and constraints are bound to relevant model elements
• Reusing an existing model
  • Pre Condition: Existing model available in one of several formats (XMI export, Structured Text format, Repository Reference, Link to external Tool)
  • Scenario: Access existing model
    • Step: Authenticate with the tool and underlying model repository
    • Step: Credentials allow access to model based on authorization profile
    • Step: Visualize and review model elements
    • Step: Add, remove, update elements as needed
    • Step: Save model
  • Post Condition: Updated model saved with new version identifiers, tagged with credentials of the user
• Importing unstructured legacy data (e.g. word, excel)
  • Pre Condition: Unstructured legacy data available on local file system or accessible in remote repository; Content includes either Requirements, Architecture or Design Descriptions
  • Scenario: Parse the legacy data based on underlying meta model (based on the SECM concepts)
    • Step: Identify parsing rules for structure, behavior, requirements, parametrics, constraints, etc.
    • Step: Identify the problem domain to assist in mapping to domain specific concepts (e.g. platform type, sensor, effector, communication protocols, etc.)
    • Step: Generate a straw man model of the structural elements (blocks, parts, ports, interfaces) based on the legacy data descriptions
    • Step: Generate a straw man model of the behavioral elements (states, sequences, messages, activities, actions, data exchanges, etc.) based on the legacy descriptions
    • Step: Capture requirements (shall statements or equivalent) and “recommend” traceability links to other model elements based on context of the unstructured description
    • Step: Generate constraint blocks and parameters and bind to model element properties based on context of the unstructured descriptions
    • Step: Run validation, consistency, completeness model checkers on the resulting strawman model
    • Step: Manually update the model to resolve model checker exceptions
  • Post Condition: Completed model consistent with the unstructured requirements/architecture/design description

• A specific methodology may include a combination of profiles, patterns, and wizards
• Need to differentiate the overall workflow requirements from the model construction specific requirements
• Develop a specific use case addressing the construction of a model in the context of a workflow process/engine/manager
• In model construction the services supporting modeling task automation, pattern use, library access, model structure template access, model manipulation, model transformation within a task context, etc. are emphasized
• In workflow, the documentation of the methodologies available, the tracing and linkage to relevant tools, the transformation of models across the workflow services, and the tailorable steps necessary to complete modeling tasks are provided as services

See the Workflow Wiki page at: Collaboration & Workflow Working Group

• Human Readable Language Constructs
  • Map the Concept Model vocabulary into a structure language
  • Context Free Grammar based
  • Examples include: Modelica, OPM, AADL, etc.
  • SysML as a Domain Specific Language
    • Block myBlock { attribute: myAttribute: OMString; operaton: myOperation {returns: OMString; parameter: myParam OMString } }
    • Block anotherBlock { attribute: myAttribute: OMString; operaton: myOperation {returns: String; parameter: myParam OMString } }
    • Association blockAssociation from: myBlock {multiplicity: 1 roleName: itsMyBlock} to: anotherBlock {multiplicity: 1 roleName: itsAnotherBlock}
    • …

• Structured Text Parsing
  • Examples include System Requirements Document (outline structure and “shall” statements)

• Unstructured Text Parsing
  • Natural Language Processing with a domain specific vocabulary NLP Research Example PTC Integrity Process Director

The context for the model construction use cases and services is highlighted in the following conceptual architecture for the Systems Modeling Environment (SME).

The construction of a systems model can be initiated in three basic ways: i) via a “rich” model editor client, ii) via a “web” model editor client or iii) via an external interface mechanism including programmatic (e.g. via a programming language graph representation), tabular input (e.g. MS Excel), graphics (e.g. MS Visio or PowerPoint) or textual (e.g. text document). The task of construction a system model ranges from being a purely manual process to a semi-automated process that loads the external representation of the model content, parses through the external description, transforms the description based on the System Model's concept model and/or metamodel and finally provides a visualization of the resulting model (in both textual and graphical representations.).

• Standard is limited to model element definition for both abstract and concrete syntax
• Focuses on the “visual” programming, interactive model construction style, one element at a time
• No standards reference for importing external data (exclusive of XMI representation)..vendors take proprietary approaches (if at all)
• Emphasizes “model based” vs “document based” but doesn't address construction of the model from existing “documents”
• Defines a “rudimentary” requirement object, but does not address importing or linking to external requirements repositories or management tools
• No reference to importing from structured natural language sources such as legacy CONOPS, SRD, SSS, etc.
• No reference to importing and linking external Whole Life or Speciality/Quality Engineering models
• Much systems engineering work is done in tables / spreadsheets, no standard reference to import tabular data and link with model elements

• Systems engineers and other discipline engineers contribute to the development and update of the system model throughout the lifecycle to support system specification, design, analysis, and verification activities
  • Lifecycle Phase: Meta Concept Development
  • Lifecycle Phase: Concept Development
  • Lifecycle Phase: Requirements Analysis
  • Lifecycle Phase: Architecture Refinement
  • Lifecycle Phase: System Design
  • Lifecycle Phase: Analysis of Alternatives
  • Lifecycle Phase: Quality Attribute Assessment
  • Lifecycle Phase: Performance Assessment
  • Lifecycle Phase: IV&V
  • Lifecycle Phase: Transition to Development Disciplines

SECM Concept Definitions Snapshot (1/28/2016)

See the Interoperability Working Group Wiki Page for a complete set of Services (including Model Construction) at: Interoperability Working group

Model Construction Services Archive Page

• Ability to efficiently and intuitively construct models
  • Efficiency metrics
    • Mouse/Keyboard interactions (e.g. # interactions to create, delete, modify model element, pattern, variant or model validation rule)
    • Lifecycle task productivity (e.g. requirements linking, use case behavior modeling)
    • Bulk data load rate (e.g. model elements/sec)
  • “Intuitive” Metrics
    • Learning Curve (e.g. time and complexity)
    • Tailorability to Organizations Processes/Procedures (e.g. OOSE, Harmony, SYSMOD tailoring)
    • Utility of “Help” functions
    • Effectiveness of standardized symbology or concrete syntax to distinguish model elements (e.g. action vs state)

• The next-generation modeling language and tools must enable much more intuitive and efficient model construction.
• It often requires several clicks to capture a core concept in a model.
• More streamlined and efficient user interfaces could reduce the time and effort to build and maintain a model.
• The ability to repeat common modeling patterns with reduced user input (e.g., table-based entry) is another capability to increase modeling productivity and understanding.

The following Hybrid SUV Change Scenario will be used to illustrate the concept:

• Vehicle design unable to meet a requirement (e.g., stopping distance, safety, stability)
• Propose Requirement Change
• Assess potential impact
• Propose update to system design
• Implement/update design
• Verify system meets requirement

Assumption:  Assume physics based analysis / simulation run:   From the design model, generate the simulation, get results, compare with original requirements 		
Model Construction:  (Services, Description)		
	(Query, Inspect design features)	Determine design features relevant to the requirement
	(Export design features)	 Export features to analysis/simulation tool
	(Import assessment)	Import assessment
	(Link assessment)	Link the assessment to the requirement and design features

Assumption:  Change could be functional, performance, environmental		
Model Construction:  (Services, Description)		
	(Create req variant)	Create a variant of the requirement		

Assumption:   Original requirement,  requirement dependencies  and design features are the starting point		
Model Construction:  (Services, Description)		
	(Create Temporary Working Viewpoint)	 Gather all dependent model elements into a working package  
	(Update change impact flag and note)	Determine impact on other requirements
	(Update change impact flag and note)	Determine impact on design features
		

Assumption:  Two paths to get here, i)  no requirement change  or ii) requirement change, leading indirectly to a design change.		
Model Construction:  (Services, Description)		
	(Append proposed change request)	Append proposed change requirest to relevant design features
	(Generate CM change notification)	Notify  the CCB of the proposed change
	(Query proposed change package)	CCB gathers relevant change information to assess impact
	(Approve change)	CCB approves proposed changes
	(Deny change)	CCB denies proposed changes
	(Import CCB assessment)	Import the CCB assessment to the model
	(Link assessment)	Link the CCB assessment to the requirement variant
		

Assumption:  CCB approved requirement change and subsequent design change or only the design change		
Model Construction:  (Services, Description)		
	(Add new baseline requirement)	Requirement variant added to the baseline, overriding the original requirement (if needed)
	(Create design feature variant)	Update the design baseline with new design features variants to reflect the CCB approved changes
		
		

Assumption:   Existing test suite updated to reflect design changes		
Model Construction:  (Services, Description)		
	(Create test plan variant)	Test plan may need to be updated (assuming the plan is in the model)
	(Create test scenario variant)	Test scenarios may need to be updated (assuming the ascenarios are represented  in the model)
	(Create test procedure variant)	Test procedures may need to be updated (assuming the test procedures are represented  in the model)
	(Verify system design)	Execute any relevant system tests to ensure verification

Construct SE Model Overview - August 2015

Formal Specification level: Towards Verfication-driven Design Based on natural Language Processing

Construct SE Model Overview - August 2015

Construct SE Model Overview - September 2015

Construct SE Model Overview - December 2015

Back to SysML Assessment and Roadmap Working Group