MBSE · Open Source · On-Premise oder Cloud

RePoSyD – Requirements Engineering,
Project Management and System Design

Ein Prozessmodell und Software-Tool für modellbasierte Systementwicklung, das den gesamten Systemlebenszyklus abdeckt – von der ersten Idee bis zur Entsorgung.

Zum RePoSyD-Wiki Workbook lesen
IEEE 1220 ISO 15288 Single Source of Truth Keine proprietären Formate

Überblick

Was ist RePoSyD?

Systems Engineering als durchgängiger, nachvollziehbarer Prozess – statt verstreuter Dokumente in unterschiedlichen Werkzeugen.

RePoSyD ist zugleich Prozessmodell und Software-Werkzeug für systems-engineering-basierte Entwicklungsprozesse. Es folgt dem „Single Source of Truth"-Prinzip. So bleiben Anforderungen durchgängig bis zur konkreten Umsetzung nachverfolgbar (Traceability).

Technisch ist RePoSyD eine Single-Page-Application mit RESTful-Webservices und offenen Schnittstellen. Sie läuft wahlweise on-premise oder in der Cloud und ist für verteilte Teams an unterschiedlichen Standorten ausgelegt.

RePoSyD ist Open Source und wird kostenlos bereitgestellt. Auch die Datenformate sind offen – ein Anbieter-Lock-in durch proprietäre Formate entsteht nicht.

Idee
Anforderungen
Design
Verifikation
Betrieb
Entsorgung

Konzeptdarstellung des Systemlebenszyklus, den RePoSyD durchgängig abbildet.

Grundprinzip

Ein semantisches Metamodell statt starrer Tabellen

Objekte in RePoSyD sind nicht nur verlinkt, sondern über benannte, bidirektionale Beziehungen miteinander verbunden – jede Verknüpfung trägt eine fachliche Bedeutung.

Requirement
specifies → ← specified by
System
verifies / verified by allocates / allocated to contains requires / required by applies to / applies emerges from defines / defined by has inputs / has outputs summarizes / summarized in leads to / follows from
Ausschnitt aus dem RePoSyD-Referenzmodell um das Element Anforderung

Ausschnitt aus dem echten RePoSyD-Referenzmodell: „Anforderung" bildet den zentralen Knoten und ist über benannte Beziehungen mit nahezu allen anderen Objekttypen verbunden – von Funktion und Normatives Dokument bis Arbeitspaket und Vorgang. Die Grundlage für durchgängige Traceability. Zum vollständigen Modell anklicken.

Referenzmodell

Ein durchgängiges Informationsmodell

System Design und Project Management sind im selben Modell verankert: sechs Ebenen, von der Stakeholder-Sicht bis zum Work Breakdown, konsistent miteinander verknüpft statt in getrennten Werkzeugen gepflegt.

System Design Operational Layer Use Cases Stakeholder Capabilities System Requirements Layer Normative Documents Requirements <<Constraints>> Requirements <<System>> Design Layer Functions System Elements Interfaces Test & Verification
Project Management Project Requirements Layer Requirements <<Content>> Requirements <<Work Package>> Requirements <<Contract>> Management Layer Work Packages Decisions Risks SOW Layer Work Packages Deliverables Tasks Documents

Referenzmodell nachgezeichnet aus der RePoSyD-Präsentation: Operational-, System-Requirements- und Design-Layer bilden das System, Project-Requirements-, Management- und SOW-Layer das Projekt – durchgängig verknüpft über dieselbe Objektstruktur.

Architektur

Für verteilte Teams gebaut

Alle Standorte arbeiten über den Browser gegen dieselbe Datenbasis – ohne lokale Dateiablagen oder proprietäre Austauschformate.

Konzeptdarstellung Standort A Web-Client (SPA) Standort B Web-Client (SPA) Standort C Web-Client (SPA) RePoSyD Server RESTful API Single Source of Truth Report- Engine PDF / HTML

Verteilte Teams greifen per Browser (SPA) über offene REST-Schnittstellen auf dieselbe Datenbasis zu – der RePoSyD-Server läuft wahlweise on-premise oder in der Cloud; Auswertungen entstehen automatisiert über die Report-Engine.

Prozessmodell

„Yet Another Process Model" – Systems Engineering als Werkzeugkasten

RePoSyD versteht Systems Engineering nicht als starren Ablauf, sondern als Werkzeugkasten: Je nach Projekttyp ist ein anderer Einstiegspunkt sinnvoll, es gibt keinen universellen ersten Schritt. Grundlage ist die pragmatische Anwendung von IEEE 1220, deren Anforderungen selektiv je nach Projekt eingesetzt werden sollen.

Konzeptdarstellung Systemanalyse Prozesseingang Anforderungs- analyse Funktions- analyse Synthese Verifikation Anforderungs- Trade-Studies & -Bewertungen Funktions- Trade-Studies & -Bewertungen Design-Studies & -Bewertungen Steuerung Prozessausgang Anforderungen & Randbedingungen Trade-offs & Auswirkungen Dekompositions-Alternativen Zuordnungs-Trade-offs Design-Lösung & Trade-offs Design-Trade-offs & Auswirkungen

Der klassische Prozessablauf nach IEEE 1220: Anforderungsanalyse, Funktionsanalyse und Synthese durchlaufen jeweils Trade-Studies und Bewertungen im Rahmen der Systemanalyse. Die Steuerung überwacht den gesamten iterativen Ablauf vom Prozesseingang bis zum Prozessausgang.

Anforderungsanalyse

Klärt, worum es im Projekt wirklich geht – Systemgrenzen, Nutzerbedarfe und Risiken werden erfasst.

Funktionsanalyse

Definiert die Top-Level-Funktionen des Systems aus Sicht der Nutzer.

Synthese

Überführt die funktionale Architektur in eine Design-Architektur und deren Zerlegung in Systemelemente.

Systemanalyse

Bewertet Design-Alternativen mittels Trade-off-Analysen (Kosten, Risiko, Leistung) als Entscheidungsgrundlage für die anderen Prozesselemente.

Steuerung

Steuert Baselines, Änderungen und Entscheidungen über den gesamten Prozess hinweg – die Klammer um alle Prozesselemente.

Verifikation

Stellt sicher, dass alle Anforderungen bis zu Funktionen, Systemen und Komponenten rückverfolgbar sind.

Alle sechs Prozesselemente von IEEE 1220 in hochiterativer Abfolge – ohne festen Startpunkt und ohne starre Reihenfolge. Details im Original-Prozessmodell auf wiki.reposyd.de.

PLM-Backbone

RePoSyD im PLM-Backbone

Der PLM-Backbone verbindet die Systeme der Unternehmenssteuerung mit denen der Produktentwicklung. RePoSyD besetzt darin die Ebene für Requirements Engineering, Projektmanagement und Systementwurf – als durchgängige Single Source of Truth zwischen beiden Seiten.

Konzeptdarstellung UNTERNEHMENSSTEUERUNG PRODUKTENTWICKLUNG Anforderung Funktion System- Elemente Schnitt- stellen Arbeits- pakete Verifikation SINGLE SOURCE OF TRUTH RePoSyD Requirements · PM · Systementwurf PLM-BACKBONE ERP Ressourcenplanung PPM Projekt- & Portfolio CRM Kundenbeziehungen QMS Qualitätsmanagement & -sicherung CAD/ PDM Konstruktion & Daten CAE Simulation MES Fertigung Service In-Service Support

Unternehmenssteuerung

  • ERP – Enterprise Resource Planning (Finanzen, Einkauf, Ressourcen)
  • PPM – Projekt- & Portfoliomanagement (Vorhaben, Budget, Kapazität)
  • CRM – Customer Relationship Management (Kunden & Vertrieb)
  • QMS – Qualitätsmanagement & -sicherung (Prozesse, Audits, Normkonformität)

Produktentwicklung

  • CAD/PDM – Konstruktion & Produktdatenmanagement
  • CAE – Computer-Aided Engineering (Simulation & Berechnung)
  • MES – Manufacturing Execution System (Fertigungssteuerung)
  • In-Service Support – Betrieb, Wartung & Support im Feld

Hinweis: Die acht Systeme stehen exemplarisch für eine typische IT-Landschaft. Je nach Bedarf lassen sich weitere Knoten ergänzen – z. B. ALM für Embedded-Software oder SCM für die Lieferkette – ohne die Grundstruktur (Steuerung links, Entwicklung rechts, RePoSyD als Kern) zu verändern.

Funktionsumfang

Sechs Kernbereiche, ein durchgängiges Modell

Requirements Engineering, Projektmanagement und Systemdesign greifen in RePoSyD ineinander, statt in getrennten Tools gepflegt zu werden.

Requirements Engineering

  • Systemkontext- und Stakeholder-Analysen
  • Anforderungsmanagement mit Prioritäten und Reifegraden
  • Requirements Traceability
  • Testmatrix-Definition mit Akzeptanzkriterien

Projektmanagement

  • Work Breakdown Structure
  • Ressourcenallokation
  • Decision & Action Tracking
  • Verwaltung von Sitzungsprotokollen

Systemdesign

  • Systemarchitektur: funktional, strukturell, physisch
  • Grafische Modellierung (FFBD, System Context Diagram)
  • Interface Management
  • Hazard Log

Review Management

  • Statusboard für Review-Meilensteine (SRR, PDR, CDR, …)
  • Review-Fortschritt je Systemelement auf einen Blick
  • Nachvollziehbare Freigabehistorie
  • Verknüpfung von Reviews mit betroffenen Anforderungen und Elementen

Versionierung & Konfigurationsmanagement

  • Versionshistorie für Anforderungen, Modelle und Dokumente
  • Baselines und definierte Konfigurationsstände
  • Änderungsverfolgung mit Versionsvergleich
  • Rückverfolgbarkeit über den gesamten Produktlebenszyklus

Weitere Funktionen

  • Varianten- und Template-Management
  • Report-Engine (Export als PDF, HTML)
  • Rollenbasierte Zugriffskontrolle
  • Erweiterbar über Plugins zur Anbindung an Dokumentenmanagement- oder Produktdatenmanagementsysteme

In der Praxis

So arbeitet es sich in RePoSyD

Ausschnitte aus der RePoSyD-Anwendung – von der Anforderungsübernahme bis zum automatisierten Report.

RePoSyD Requirements Import
Requirements EngineeringAnforderungen werden strukturiert aus Excel/CSV importiert und automatisch den passenden Feldern zugeordnet.
RePoSyD Systemelement bearbeiten
SystemdesignSystemelemente mit Attributen und allen Verknüpfungen (Traceability) im Detail bearbeiten.
RePoSyD Work Breakdown Structure
ProjektmanagementWork Breakdown Structure mit Aufgaben, Terminen und Ressourcen je Arbeitspaket.
RePoSyD Status Board Review Management
Review ManagementStatusboard zeigt den Review-Fortschritt (SRR, PDR, CDR, …) je Systemelement auf einen Blick.
RePoSyD Report-Script-Editor
Report-GeneratorReport-Skripte werden ohne Programmierkenntnisse per Baustein-Editor erstellt.

Grundlagen

Normbasiert und wissenschaftlich evaluiert

IEEE 1220 Prozessdefinition für praktisches Systems Engineering, Basis des RePoSyD-Prozessmodells.
ISO 15288 Grundlage der Prozessbeschreibungen im RePoSyD-Workbook, gemeinsam mit IEEE 1220.
FEMMP RePoSyD wurde 2020 an der TH Ingolstadt mit dem FEMMP-Framework anhand einer Dampfmaschinen-Fallstudie evaluiert.

Praxisbeispiel

Diagramme direkt aus dem Modell

RePoSyD erzeugt technische Diagramme automatisch aus den gepflegten Modelldaten und macht die zugrunde liegenden Objekte und ihre Verknüpfungen jederzeit einsehbar – hier demonstriert am eigenen Systemkontext.

RePoSyD Service – Systemkontext

Automatisch generiertes Systemkontext-Diagramm der RePoSyD-Anwendung

Automatisch aus dem RePoSyD-Modell generiertes Systemkontext-Diagramm: Der RePoSyD Service im Zusammenspiel mit Web-Server, Mail-Server, LDAP/Active Directory, PDM/PLM-System, Ticketsystem, DMS, KI und SSO – inklusive aller Schnittstellen (HTTP, SMTP, OData, Authentifizierung). Zum Vergrößern anklicken.

RePoSyD Application – Stakeholder

Automatisch generiertes Stakeholder-Diagramm des RePoSyD-Service

Stakeholder-Sicht desselben Systemkontexts: Alle Rollen – von Systems Engineer und Requirements Manager bis Kunde, OEM und Regulatory Authority – mit ihren Datenflüssen (Anforderungen, Angebote, Vertragsdaten) zur RePoSyD-Anwendung. Zum Vergrößern anklicken.

RePoSyD – Systemstruktur

Automatisch generiertes Zerlegungsdiagramm der RePoSyD-Systemarchitektur

Vollständige Systemstruktur: RePoSyD gliedert sich in RePoSyD Application, RePoSyD-Server, RePoSyD Modules (acht Pakete wie @reposyd/service, @reposyd/core, @reposyd/blockly u. a.), RePoSyD Docker und das Support System – eingebettet in die externen Systeme Web-Server, Mail-Server, LDAP/Active Directory, PDM/PLM, Systems-Engineering-Tools, ERP, Ticketsystem und KI. Zum Vergrößern anklicken.

RePoSyD Application – Objektattribute und Verknüpfungen

Objektansicht aus dem RePoSyD-Modell: Attribute und Verknüpfungen der RePoSyD Application – hier die Beziehung „affected by" zu allen zwölf Stakeholdern, von Systems Engineer bis Regulatory Authority. Jede Verknüpfung ist benannt und in beide Richtungen navigierbar. Zum Vergrößern anklicken.

RePoSyD Service – Schnittstellen und Verknüpfungen

Objektansicht des Moduls @reposyd/service: sechs eingehende und acht ausgehende Interface-Items sind direkt als benannte Verknüpfungen im Modell abgebildet – die Grundlage für automatisch generierte Schnittstellenlisten. Zum Vergrößern anklicken.

RePoSyD – Strukturbaum und Traceability

Baumansicht der Systemstruktur mit direktem Zugriff auf Attribute und Verknüpfungen jedes Elements – hier die Anforderung „Suitability for Beginners", die das Wurzelelement RePoSyD spezifiziert. So bleibt Traceability über alle Hierarchieebenen hinweg sichtbar. Zum Vergrößern anklicken.

Herkunft

Über 20 Jahre Erfahrung, in einem Werkzeug gebündelt

RePoSyD wurde von Martin Hoppe entwickelt und baut auf über 20 Jahren praktischer Erfahrung mit MBSE Werkzeugen auf. Statt einer starren Prozessvorschrift bietet RePoSyD eine strenge Metamodell-Implementierung ohne beliebig erweiterbare „Wildcard"-Elemente – Konsistenz und Nachvollziehbarkeit stehen im Vordergrund.

Die automatische Dokumentengenerierung über die integrierte Report-Engine sowie die Auslegung auf verteilte Teams machen RePoSyD zu einem Werkzeug, das akademisch fundiert und zugleich für den praktischen Projekteinsatz konzipiert ist.

Akronym
Requirements Engineering, Project Management and System Design
Entwickler
Martin Hoppe
Lizenz
Open Source, kostenlos
Architektur
Single-Page-Application (on-premise oder Cloud), RESTful-Webservices
Wissenschaftliche Evaluation
TH Ingolstadt, Bachelorarbeit 2020 (FEMMP-Framework, Dampfmaschinen-Fallstudie)

Mehr erfahren

Ressourcen

RePoSyD Wiki & Startseite↗ RePoSyD Workbook – Prozesse & Anwendungsfälle↗ „Yet Another Process Model" – vollständiges Prozessmodell↗ Installationsanleitung (CLI)↗