[Paper] Engineering Decisions in MBSE: Insights for a Decision Capture Framework Development

Source: arXiv - 2601.07301v1

Overview

The paper Engineering Decisions in MBSE: Insights for a Decision Capture Framework Development examines how to embed engineering decisions directly into Model‑Based Systems Engineering (MBSE) artifacts. By treating each decision alternative as a “slice” of the system model, the authors propose a lightweight way to capture the rationale, context, and trade‑offs of design choices—something that traditional decision‑logging tools struggle to do efficiently.

Key Contributions

• Decision‑as‑Model‑Slice concept: Introduces a concrete representation of decision alternatives as partial views (slices) of a system model, preserving traceability to requirements, behaviors, and architecture.
• Lightweight capture framework: Outlines a minimal‑overhead workflow that integrates decision documentation into existing MBSE tools without demanding separate repositories or extensive manual annotation.
• Industry‑derived case study: Demonstrates the approach on a simplified aircraft architecture scenario, surfacing real‑world challenges such as versioning, stakeholder alignment, and context preservation.
• Preliminary solution patterns: Provides a set of design patterns (e.g., “decision anchor,” “alternative view,” “impact propagation”) that can be reused across domains.
• Roadmap for a decision capture ecosystem: Highlights the next steps needed to evolve the prototype into a full‑fledged framework, including tooling extensions and governance processes.

Methodology

1. Problem scoping: The authors start by reviewing why existing decision‑capture practices (e.g., meeting minutes, issue‑tracker comments) are costly and often lose context.
2. Conceptual modeling: They define a decision slice as a subset of the system model that contains only the elements affected by a particular alternative (e.g., a specific avionics component configuration).
3. Framework sketch: A lightweight workflow is built around three activities—Define Decision, Create Alternative Slices, and Link to Stakeholder Rationale. These activities are mapped onto typical MBSE tool actions (model branching, annotation, and traceability links).
4. Case‑study implementation: Using a toy aircraft architecture (flight‑control, navigation, power‑distribution subsystems), the team models two competing design alternatives (redundant vs. non‑redundant flight‑control computers) and records the decision rationale directly in the model.
5. Evaluation criteria: The prototype is assessed on capture effort, traceability completeness, and reuse potential, measured qualitatively through developer interviews and quantitatively via the number of manual artifacts eliminated.

Results & Findings

• Reduced documentation overhead: The case study showed a ~40 % drop in separate decision‑log entries because the alternatives lived inside the model itself.
• Improved traceability: All decision alternatives were automatically linked to the impacted requirements and behavior diagrams, eliminating orphaned trace links that often appear in traditional approaches.
• Higher reuse readiness: When a later design iteration needed to revisit the flight‑control redundancy decision, engineers could simply re‑activate the appropriate slice, saving time on impact analysis.
• Identified friction points: Version control of model slices and the need for consistent naming conventions emerged as the biggest practical hurdles.

Practical Implications

• For system architects: Embedding decisions in the model means you can run impact analyses (e.g., “What if we switch to alternative B?”) without leaving the MBSE environment, accelerating trade‑study cycles.
• For DevOps and CI pipelines: Decision slices can be version‑controlled alongside code, enabling automated checks that verify whether a new commit violates a previously captured decision constraint.
• For cross‑functional teams: The explicit links between decisions, requirements, and behaviors provide a common language for engineers, safety analysts, and certification bodies, reducing miscommunication.
• Tool vendors: The framework suggests a modest set of extensions (slice creation UI, decision‑anchor metadata, automatic trace generation) that can be added to existing MBSE platforms (e.g., Cameo, Enterprise Architect, MagicDraw) with relatively low development effort.
• Regulated industries (aerospace, automotive, medical): A systematic, model‑centric decision capture can support compliance audits by providing auditable evidence of why a particular architecture was chosen.

Limitations & Future Work

• Prototype scope: The study uses a simplified aircraft model; scalability to large, multi‑disciplinary systems remains unproven.
• Tool integration: Current implementation relies on manual slice creation; automated detection of decision boundaries is still an open problem.
• Governance: The paper notes the need for organizational policies to manage decision ownership, review cycles, and conflict resolution.
• Future directions: The authors plan to (1) develop plug‑ins for popular MBSE tools, (2) explore model‑diff algorithms to auto‑generate alternative slices, and (3) conduct longitudinal studies in real industrial projects to quantify long‑term ROI.

Authors

• Nidhal Selmi
• Jean‑Michel Bruel
• Sébastien Mosser
• Matthieu Crespo
• Alain Kerbrat

Paper Information

• arXiv ID: 2601.07301v1
• Categories: cs.SE
• Published: January 12, 2026
• PDF: Download PDF