Model-Based Systems Engineering: From Mission to Requirements

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

DHDennis Hansen게스트
채널
GOTO Conferences
게시일
2026년 5월 28일
영상
22:46
읽기
2분
원문
영어
YouTube에서 열기
스크롤하면 영상이 오른쪽 아래로 작아져 계속 재생됩니다. 자막은 읽기 언어를 따릅니다.
읽기 언어2개 언어로 읽을 수 있음
이 글은 아직 한국어 번역이 없어 영어 원문으로 표시합니다.
요약

30초 요약

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.

핵심 정리

  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.
전문

챕터별로 다듬은 전문 읽기

원본 자막만 보기
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.

같은 채널의 다른 글

슬라이드 3장39:12EN
GOTO Conferences· 2026년 10월 28일Cate 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.AI 엔지니어링 리더십Software engineeringAI agents
슬라이드 4장22:33EN
GOTO Conferences· 2026년 10월 26일William 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장34:11EN
GOTO Conferences· 2026년 10월 23일Anatoliy 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.개발 워크플로와 테스트Code review & verification관측 가능성과 안정성+2
28:15EN
GOTO Conferences· 2026년 10월 22일Steve 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장46:36EN
GOTO Conferences· 2026년 10월 21일Don Syme: Building Agentic Automation Around Human CollaborationDon Syme · GitHubContinuous AI, repository workflows and the guardrails needed for unattended software maintenance.Agent orchestrationSoftware engineering코딩 에이전트
28:23EN
GOTO Conferences· 2026년 10월 19일Learning 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