Model-Based Systems Engineering: From Mission to Requirements

Dennis Hansen and Jorge Orellana discuss layered definition, traceability and collaboration.

DHDennis HansenInvité
Chaîne
GOTO Conferences
Publié
28 mai 2026
Vidéo
22:46
Lecture
2 min
Original
anglais
Ouvrir sur YouTube
En faisant défiler, la vidéo se réduit en bas à droite et continue. Les sous-titres suivent votre langue de lecture.
Langue de lectureDisponible en 2 langues
Cet article n’est pas encore disponible en français ; il s’affiche dans l’original en anglais.
RÉSUMÉ

En 30 secondes

Dennis Hansen explains how to derive system requirements from a mission, use linked models to preserve design rationale and trace changes during sustainment. Jorge Orellana explores modeling as an iterative learning process.

  1. 1Start with missionDerive capabilities and activities from the mission.
  2. 2Layer the workKeep levels distinct while refining the relationships between them.
  3. 3Operational overviewAn overview can connect actors and major functions.
  4. 4Model as databaseModel elements can link requirements and rationale.
  5. 5Iterative learningModeling helps teams learn rather than merely document.
  6. 6Trace changesA maintained model supports impact analysis.
  7. 7CollaborateInvolve the relevant disciplines throughout.

À retenir

  1. Derive capabilities and activities from the mission.
  2. Keep levels distinct while refining the relationships between them.
  3. An overview can connect actors and major functions.
  4. Model elements can link requirements and rationale.
  5. Modeling helps teams learn rather than merely document.
  6. A maintained model supports impact analysis.
  7. Involve the relevant disciplines throughout.
TEXTE INTÉGRAL

Lire le texte remanié, chapitre par chapitre

Transcription seule
01

From mission to requirements

The development flow and onion model.

Jorge Orellana interviews Dennis Hansen about Model-Based Systems Engineering and Requirements Definition. Hansen draws on work in military communications and satellite ground systems to explain a structured, collaborative approach to complex systems.

Hansen begins with the user’s mission, then identifies capabilities and activities before developing technical requirements and specifications. He notes that teams may move back and forth between capabilities and activities to refine their wording.

He illustrates the hierarchy as an onion: mission, capabilities, activities, requirements, specifications and detailed design. In his experience, mixing layers prematurely can produce unnecessary or faulty requirements.

02

Views and traceability

Operational and detailed models.

An operational overview can show the mission, actors and major functions instead of serving only as an executive illustration. The satellite-ground example includes security, planning, simulation, telemetry and delivery of mission data.

More detailed system views can show operations and message flows across connected diagrams. Orellana describes using a maintained model to help trace where security requirements are addressed; a diagram alone is not proof of compliance.

An activity diagram for login links to other behavior and associated requirements. Hansen emphasizes that a modeling tool is a structured database, not merely a drawing tool: elements can retain links, requirements and design rationale.

03

Learning and sustainment

Iteration, change impact and collaboration.

Orellana describes modeling as a way to learn and refine understanding iteratively. Hansen discusses moving among operational, SysML and software views while maintaining consistency across the system.

A model remains useful during sustainment if the customer keeps it current and retains people who know how to use it. It can help trace the effects of a proposed change before a local fix creates new problems elsewhere.

To begin a complex effort, Hansen sketches the mission and its components, then works toward views that describe interfaces, messages and control flows. He connects each new detail to what came before.

His closing advice is to use an organized process and bring systems, software and security specialists together at each stage. Collaboration makes the reasoning behind decisions visible across disciplines.

Sur la même chaîne

3 diapositives39:12EN
GOTO Conferences· 28 oct. 2026Cate Huston: How Rigour Supports AI-Assisted Development VelocityCate Huston · TwillA two-person team’s experience with release gates, automated checks, prioritization and the cost of shipping faster.Leadership en ingénierie IASoftware engineeringAI agents
4 diapositives22:33EN
GOTO Conferences· 26 oct. 2026William Schor: From Unit Tests to Synthetic Canaries at NetflixWilliam Schor · NetflixHow generated workloads and production-like infrastructure help test a distributed key-value service.Software engineering
5 diapositives34:11EN
GOTO Conferences· 23 oct. 2026Anatoliy Bilenko and Alberto Carretero: Making Database Protocols Reliable with Formal Methods and AIAnatoliy Bilenko, Alberto Carretero · CanonicalCanonical’s database engineers connect executable specifications, model-based tests, failure exploration, and reconstructed execution histories—and explain why none of these techniques proves a real system correct on its own.Workflows de développement et testsCode review & verificationObservabilité et fiabilité+2
28:15EN
GOTO Conferences· 22 oct. 2026Steve Poole on Open-Source Security and AI’s Maintenance ChallengeOlimpiu Pop, Steve PooleWhy faster vulnerability discovery increases pressure on maintainers, dependency users and upgrade processes.Software engineeringAI security
5 diapositives46:36EN
GOTO Conferences· 21 oct. 2026Don Syme: Building Agentic Automation Around Human CollaborationDon Syme · GitHubContinuous AI, repository workflows and the guardrails needed for unattended software maintenance.Agent orchestrationSoftware engineeringAgents de code
28:23EN
GOTO Conferences· 19 oct. 2026Learning Ash: Declarative Elixir Apps, Testing and ExtensibilityChristian Alexander, Rebecca Le, Zach DanielRebecca Le and Zach Daniel explain how their book and the framework evolved together.Software engineering