MBSE, requirements management and AI address different parts of engineering work. Models describe the system and support analysis; requirements management controls obligations, revisions and evidence; AI can help engineers navigate and check the connected information. They fit together when every important fact has an identified owner, every proposed change has a clear status, and approval remains tied to the configuration actually reviewed.
For a spacecraft team, the integration problem is concrete. A payload engineer changes a design estimate, an architecture model displays the updated value, and a requirements export still shows the approved limit. Those records may all be correct in their own context. The danger begins when someone treats them as interchangeable. Adding an AI assistant can make the inconsistency easier to discover, but it can also make an incorrect reconciliation sound persuasive.
Three responsibilities that need to stay connected
MBSE means treating models as engineering artefacts used to describe and reason about the system. A model might represent functions, operational states, physical structure, interfaces or relationships to verification. Its value comes from the decisions those representations support and from maintaining their meaning as the programme changes.
The NASA Systems Modeling Handbook shows how modelling can support stakeholder expectations, requirements and verification and validation work products. It also distinguishes the modelling language from methodology and model organisation. The practical lesson for this article is to choose the work products a team needs before deciding how much model to create.
Requirements management answers a different set of questions: which obligation applies, where it came from, who owns it, what changed and what demonstrates acceptance. NASA’s requirements-management guidance covers traceability, controlled baseline changes and consistency with design. A requirement displayed inside a model still needs those controls. Equally, a controlled requirement database does not by itself explain an architecture’s behaviour.
AI assistance can retrieve relevant records, identify apparent inconsistencies and draft engineering work. It should expose the evidence and the missing context behind its suggestions. It does not establish that a model is physically valid, that a requirement is contractually acceptable or that an analysis proves compliance. Those are separate engineering questions with their own evidence and authorities.
Decide where each kind of engineering truth lives
A programme does not need every piece of information in one editor. It needs to know which record is authoritative for a particular purpose. The matrix below is an original starting point for agreeing that ownership. Tailor the roles and systems to the programme; the examples do not prescribe a tool architecture.
| Information | Authority | Other systems consume | Change rule |
|---|---|---|---|
| Requirement text and approval status | Named requirements authority | Stable identity and applicable revision | New text is proposed before approval |
| Function and component structure | Architecture owner | Published structure and allocation relationships | Review architecture changes with affected allocations |
| Interface obligations | Authorities on both sides of the boundary | Agreed limits, modes and measurement definitions | Resolve two-sided consequences before release |
| Analysis input and result | Responsible discipline engineer | Versioned value, units, assumptions and provenance | Re-run or assess applicability when an input changes |
| Verification closure | Authorised verification process | Accepted result and applicable configuration | Reassess affected evidence after change |
| AI finding or draft | Assigned engineer for disposition | Clearly labelled proposal with source references | Acceptance follows the owned record’s normal route |
Authority can differ by field within one object. A requirements workspace might own approved wording while a specialist model owns the functional allocation. That arrangement is workable if both sides preserve the shared identifier and the meaning of the relationship. It becomes fragile when both can edit the same field and the last synchronisation silently wins.
Access also matters. An occasional reviewer should be able to inspect a controlled view without becoming a modelling specialist. The view must include enough baseline context to show what the reviewer is approving. Accessibility is part of the engineering process: a technically rich model has limited value if the people responsible for decisions cannot interpret its relevant output.
Write a synchronisation contract before connecting tools
A synchronisation contract explains how information crosses a tool boundary. Begin with identities and owned fields, then specify revision mapping, relationship types, units, allowed direction, exchange timing and conflict handling. Record which party investigates a failed exchange and how the programme knows whether both sides have received an approved change.
For example, a requirement export should include its stable identifier, revision, source baseline and lifecycle state. If an architecture tool returns a proposed allocation, it should identify the model revision and the requirement revision it used. A comparison based on yesterday’s model must remain distinguishable from one based on today’s model even if the requirement text is unchanged.
Plan explicitly for disconnection. Suppose a supplier works from an export while the programme updates the same interface. The returned file is an input for reconciliation, with its original baseline attached. It is not automatically the latest authority. Keep the conflict visible until the responsible engineers agree how the two sets of changes fit together.
Documents remain legitimate outputs. Specifications, review packs and interface agreements can be generated or assembled from controlled records, provided the output identifies its source configuration. Avoid editing an exported document as an unofficial master. If external reviewers must mark up a document, define how those comments return to the authoritative records and how their disposition is recorded.
What SysML 2.0 and model APIs contribute
OMG publishes the SysML 2.0 specification, including language and machine-readable artefacts. Its separate Systems Modeling API and Services specification describes services for model data, including projects, versioning and queries. These are useful foundations for connecting modelling environments and other engineering software.
They do not settle programme ownership or establish that two chosen tools exchange all relevant information correctly. Evaluate the supported implementation using a small representative model. Check whether an exchange preserves identities, relationship direction, quantities, configuration references and proposed versus approved state. Check failures as well as successful transfers: an unsupported relationship should produce a visible exception rather than disappear without notice.
An AI system could conceptually use a model API to inspect an allocation or request a permitted query. That is an implementation pattern, not evidence that a particular product has a suitable connector, schema mapping or execution engine. Confirm those capabilities for the intended deployment before designing an engineering process around them.
Worked example: keep the limit separate from the estimate
Fictional 6U Earth-observation CubeSat example. Baseline BL-03 contains PAY-PWR-014 revision B, with a payload peak-power cap of 20 W. The current design estimate is 18 W. A proposed design raises that estimate to 24 W and includes a draft requirement revision C for discussion. The relevant interface is ICD-EPS-PAY-02 and the verification activity is VER-PWR-07. These records illustrate a workflow, not a customer result.
The architecture owner first identifies where the 18 W estimate is represented and which operating condition it describes. The requirements owner confirms that 20 W is still the approved cap. Those two numbers have different roles. An assistant asked to “make the values consistent” must not replace the cap with 24 W simply because the design has changed.
The initial check finds a 6 W increase in design demand and a 4 W exceedance of the current cap. In a simplified instantaneous budget with a pre-change margin of 5 W, all other quantities fixed in the same condition, the revised margin is negative 1 W. This arithmetic exposes a conflict. It does not determine electrical transients, battery energy, thermal behaviour or the feasibility of changing the operating concept.
The change package therefore carries several distinct proposed actions: revise the design estimate, assess the power budget, review the interface and determine whether any requirement revision is justified. The model owner and requirement owner can disagree legitimately while options are being investigated. Their tools should preserve that open state rather than hide it behind a common number.
Before accepting an option, reviewers inspect its effect on ICD-EPS-PAY-02 and the conditions in VER-PWR-07. A previous test may remain valid for the former design yet fail to address the proposed one. Retain its historical result while recording the new applicability assessment. Rejecting revision C or returning it for rework is a complete engineering disposition; synchronisation should convey that decision too.
Use AI to prepare reconciliation that people can inspect
A useful AI assignment compares the controlled requirement, the published model view and the proposal, then produces a discrepancy list. For each finding, require the record identities, revisions, field meanings, supporting passage and affected owner. Distinguish a confirmed inconsistency from a possible issue that needs a missing source or an engineer’s interpretation.
In the CubeSat case, the assistant could flag that a report presents 24 W without labelling it proposed, or that a model view cites revision B while displaying wording from revision C. These are information-consistency findings. The decision to accept 24 W remains a separate technical and programme decision, supported by analysis beyond the comparison.
Structured checks should handle rules that are already explicit, such as missing revision identifiers or incompatible units. Use language assistance where interpretation adds value, such as comparing a supplier’s description of peak demand with the programme’s measurement definition. Keep both kinds of result available to the reviewer. A fluent summary should not conceal that a required structured check failed or could not run.
Start with one interface and one complete evidence path
A small team can begin with the payload power interface: the operational condition, allocated requirement, architecture relationship, input estimate and verification activity. Agree the authority matrix for those records. Then run a proposed change through the full path, including rejection, rework and a controlled export.
Evaluate whether reviewers can identify the exact source of each value, understand the difference and locate the evidence required for their decision. Measure the effort to maintain the links as well as the effort saved during review. If the workflow depends on a specialist manually repairing every exchange, simplify the boundary before expanding the model.
Preserve derived requirements explicitly when an architecture decision creates a new obligation. Record the rationale, originating analysis or decision, owner and relationship to higher-level intent. A useful model can expose such obligations; requirements control keeps them from remaining private assumptions in a discipline tool. The change-impact analysis guide develops the review package around that work.
Where Arc fits in the combined workflow
Arc’s connected programme model holds requirements, architecture, interfaces and verification records, while its change controls support branches, differences, review and merge. Its human-controlled AI can check records and propose work within configured permissions.
Use those capabilities to evaluate ownership and reconciliation against your actual information flow. Arc’s integration reference requires deployment-specific confirmation of connections and interchange behaviour. This article does not claim that Arc supplies a complete SysML modelling suite, a named SysML connector or the physical analysis used in the example. Continue with digital thread versus digital twin to distinguish the connected record from the models it informs.
Frequently asked questions
What is the difference between MBSE and requirements management?
MBSE uses managed models to represent and reason about a system. Requirements management controls engineering obligations, their sources, revisions, relationships and acceptance. They overlap where requirements connect to architecture, analysis and verification, but a diagram alone does not establish an approved requirement baseline.
Should requirements be stored in the modelling tool?
They can be, provided the environment supports the programme’s authorship, review, configuration and evidence needs. A connected requirements workspace can also work. Define ownership for each field and a controlled route for changes so that the two environments do not become competing editable masters.
Does using SysML 2.0 guarantee interoperability?
No. A specification provides a basis for compatible implementations, but teams still need to confirm supported versions, exchanged information, relationship semantics and revision handling in their actual tools. Arc’s public reference does not establish a named SysML connector or a particular conformance claim.
Can AI keep requirements and models synchronised automatically?
AI can help identify inconsistent records or draft a proposed reconciliation. Authoritative synchronisation still needs explicit identifiers, field ownership, configuration rules and conflict handling. A language model should not resolve two approved but conflicting sources by silently choosing one.
How much modelling should a small spacecraft team start with?
Model one decision that requires several disciplines, such as a payload electrical interface. Connect its requirements, assumptions and verification path, then exercise a real change. Expand after the team can maintain the model and use its outputs in an actual engineering review.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.