Modeling Guide
Knowledge Guides /How do you start a SysML v2 project? Must existing SysML models be rebuilt entirely?
Last updated: · New Horizon Digital Outsourcing Team
Start a SysML v2 project with a reviewable system slice, rather than defaulting to a complete rebuild. Assess current model quality, target tool support, interface exchange, and review methods before deciding which assets to retain, convert, or rebuild. A language upgrade and a change in engineering methods are separate efforts requiring separate acceptance.
What does SysML v2 add, and what can it not replace?
- OMG's SysML v2 material emphasizes language semantics, textual and graphical notation, and standard APIs. Its engineering value is making models easier to inspect, exchange, and integrate with tools, rather than giving existing diagrams a new appearance. Each editor's support for views and APIs still needs individual verification.
- A standard does not automatically fill missing requirements, resolve ambiguous interfaces, or prove a design correct. Before starting, list the decisions the model should support, such as requirements-coverage reviews, interface-change analysis, or option comparisons, rather than measuring completion solely by diagram count.
Which inputs should be prepared before migration?
- Organize the original modeling tools and versions, package structure, extension specifications, object identifiers, requirement sources, and external links. PDF screenshots alone are usually insufficient to assess conversion feasibility; state whether the original project is accessible.
- Choose a representative slice containing requirements, structure, behavior, and interfaces. Record pre-migration relationships and review conclusions as a comparison baseline. A two-node demonstration does not represent the complexity of a full engineering project.
How should implementation be phased and scope controlled?
- In the first phase, check semantic mappings and tool capabilities. In the second, model the slice and establish traceability. In the third, verify import/export and downstream interfaces. List elements without equivalent mappings as issues for the project team to resolve.
- While old and new projects coexist, specify which version is the review baseline. Do not edit both independently and judge consistency only from screenshots. Before extending to other subsystems, stabilize naming rules, package structures, versions, and difference-checking methods.
What should acceptance check?
- Open the model in the agreed tool environment, spot-check paths from requirements to functions, structures, and verification items, and compare key relationships before and after migration. Verify consistency between objects expressed textually and graphically, and whether exported content can be read back as agreed.
- Recommended handover items include the model project, migration mapping table, unresolved differences, tool versions, and reproduction steps. Successful conversion does not mean review approval; domain owners must still confirm the results.