Model-based systems engineering and requirements management solve related but different problems. MBSE uses models to describe and analyse the system, while requirements management controls what the system must do, why, for which configuration and with what verification evidence. They work best when requirements, architecture, interfaces, analyses and tests share explicit links and one clear baseline authority.
Teams often ask whether an MBSE platform can replace a requirements tool, or whether a requirements database makes modelling unnecessary. Both questions flatten the problem. A spacecraft programme needs controlled intent and a coherent representation of the solution. The practical challenge is deciding where each kind of information is authoritative and how changes move between them.
What is model-based systems engineering?
Model-based systems engineering is the formalised use of models to support systems-engineering work across the lifecycle. Models can represent operational concepts, functions, logical and physical architecture, interfaces, states, behaviours, parameters, analyses and verification relationships.
The NASA Systems Modeling Handbook explains how systems modelling can support stakeholder expectations, technical requirements, design, verification and validation within NASA's systems-engineering processes. The important word is support. A model helps engineers reason, communicate and produce evidence; it does not remove the need for technical judgement or programme control.
MBSE is not synonymous with one tool or diagram. SysML is a common language, but teams also use executable models, parameter networks, architecture databases, simulations and domain-specific representations. The method is model-based when those representations are treated as managed engineering artefacts rather than presentation pictures.
What is requirements management?
Requirements management controls the lifecycle of requirements. It records their sources, text, rationale, attributes, owners, relationships, applicability, maturity, baselines, changes and verification closure. It should make it possible to answer what the programme is obligated to build, where each obligation is allocated and what evidence shows that the delivered configuration conforms.
A requirement can appear on a model diagram, but that does not automatically mean it is well managed. The programme still needs authority, version history, approval state, traceability semantics and a controlled response when the requirement changes. The same is true in reverse: a beautifully controlled requirement database can still fail to show whether the architecture is coherent.
How do MBSE and requirements management overlap?
| Engineering question | Requirements management contribution | MBSE contribution |
|---|---|---|
| Why does this obligation exist? | Source, rationale and parent trace | Operational context and stakeholder model |
| Where is it implemented? | Allocation and satisfaction links | Functional, logical and physical architecture |
| What crosses the boundary? | Controlled interface requirements | Ports, exchanges, flows and interface views |
| What happens if it changes? | Baseline diff and affected trace links | Architecture, behaviour and parameter consequences |
| How will it be proven? | Verification method, case, result and evidence | Behavioural scenarios, analysis and verification relationships |
The overlap is valuable because each view tests the other. A function with no requirement may reveal an undocumented design assumption. A requirement with no architectural allocation may be incomplete or premature. A modelled interface with no controlled acceptance criteria can remain ambiguous between teams.
Where should requirements live in an MBSE workflow?
There are three common patterns. Requirements can be authored and controlled inside the modelling environment, managed in a dedicated system and referenced by the model, or synchronised between both. None is universally correct.
A single environment reduces exchange boundaries, but it may be difficult for occasional contributors, customer reviewers or suppliers who do not work in the model. A connected specialist tool can give requirements and verification teams a more accessible workflow, but the integration must preserve identifiers, relationship meaning, status and version context.
Bidirectional synchronisation sounds attractive but can create two editable masters. The team should define field-level ownership. For example, the requirements workspace may own approved text, rationale and lifecycle status, while the architecture model owns function and component structure. Links connect them, and changes cross the boundary through a reviewed workflow.
Why do MBSE programmes still suffer from document drift?
A model does not eliminate documents. Contracts, specifications, review packs, interface documents, test procedures and compliance reports still need controlled outputs. Drift appears when an exported view becomes an unofficial working copy or when the model changes without the downstream deliverable being regenerated and reviewed.
The answer is not to ban exports. It is to label the authoritative source, include baseline and configuration context, and make generated outputs reproducible. If a supplier must receive a document, the programme should know which model and requirement versions produced it and how returned changes will be reconciled.
Flow's webinar summary on MBSE and iterative systems engineering correctly highlights communication and adoption as central challenges. The model only improves collaboration when the people making decisions can understand and update the relevant view without routing every question through a modelling specialist.
How should changes move between requirements and models?
A change should begin as a proposal against known baselines. If a requirement changes, the programme identifies affected functions, components, interfaces, parameters, analyses and verification items. If an architecture trade creates a new constraint, the team records the derived requirement and rationale rather than leaving it implicit in the model.
For complex models, configuration management is not optional. NASA's account of configuration and data management for an MBSE model discusses the balance between controlled model trunks and working areas or branches. The same pattern is useful across the connected record: engineers need room to explore without silently altering the programme baseline.
How does MBSE support verification?
Architecture and behavioural models can expose what needs to be verified and under which conditions. State machines can identify transitions that require test coverage. Interface models can reveal boundary cases. Parameter models can support analysis-based verification. Simulation can retire uncertainty before full hardware exists.
Requirements management preserves the formal evidence chain. It distinguishes the intended verification method, the planned case, the applicable test article, the executed procedure, the result, anomalies and approved closure. A simulation linked to a requirement is useful, but the link should say whether it is exploratory analysis, formal verification evidence or one input to a wider closure decision.
What does a practical integrated workflow look like?
- Define one programme vocabulary for requirements, functions, components, interfaces, verification items and relationship meanings.
- Choose the authoritative system for each object type and field rather than declaring every tool a source of truth.
- Connect stakeholder and mission intent to system requirements, then to functional and physical architecture.
- Record derived requirements when architecture and analysis create new obligations.
- Prepare changes in a working area, inspect the cross-model impact and merge only approved updates.
- Generate controlled views and documents with baseline, configuration and provenance attached.
- Trace verification activity and evidence back to both the requirement and the model context it exercised.
How should a small space team adopt MBSE?
Start with a decision, not a tool rollout. Choose one subsystem or interface where the current documents make a trade difficult to understand. Model the relevant operational scenario, functions, boundary and key parameters. Connect the existing controlled requirements and one verification path.
Run a real change through the combined workflow. Can an engineer see what the requirement means in the architecture? Can a reviewer understand the diff? Can the team regenerate the required output? Can test evidence be traced to the applicable model and requirement baseline? Those questions reveal value and operating cost quickly.
A small model that helps the team make a better decision is a stronger foundation than an enterprise ontology built before contributors know how they will use it. Expand by repeated value, not diagram count.
How Arc connects requirements management and system context
Arc is not a full SysML modelling suite. It provides a flexible programme model where requirements, architecture, systems, interfaces, tests and evidence can be structured and connected. Teams can define the object and relationship types their process needs, then connect specialist models without forcing every contributor into one notation.
Branch-based changes let engineers propose updates, compare diffs and review cross-programme impact before the baseline moves. Agents can help identify missing links and affected verification work, while engineers remain responsible for model meaning and approval.
Related reading
Use the space requirements management guide for the complete control process, and read requirements change impact analysis for a practical cross-model change workflow.
Frequently asked questions
What is the difference between MBSE and requirements management?
MBSE uses formalised models to support requirements, architecture, analysis, verification and other lifecycle activities. Requirements management controls requirement sources, attributes, ownership, traceability, baselines, changes and closure. They overlap but neither replaces the other.
Does MBSE require SysML?
No. SysML is a widely used modelling language, but MBSE is an approach rather than one notation. A team can use several modelling methods if meanings, relationships, authority and exchange are controlled.
Should requirements live inside an MBSE model?
They may live in the model or in a connected requirements system. The important decision is which source owns requirement text, status and approval, and how model relationships remain synchronised without creating competing baselines.
Can a small space team use MBSE?
Yes, but it should model the decisions and relationships the team genuinely needs. A small, trusted architecture slice connected to requirements and verification is more useful than a large model nobody maintains.
How do MBSE and verification connect?
Models can represent functions, interfaces, states and expected behaviour that inform verification cases. Requirements management then preserves the trace from approved intent to planned activity, result, evidence and closure.