VPasCode (Diagramme als Code) für SysML-Anforderungsdiagramme — Ein umfassender Leitfaden

1. Was ist ein Anforderungsdiagramm?

EinAnforderungsdiagramm ist ein SysML-Diagrammtyp, dessen einziger Zweck darin besteht,Anforderungen als gleichwertige Modellelemente zu erfassen und ihre Beziehungen explizit und nachvollziehbar zu machen. Im Gegensatz zu einem Anforderungsdokument (das lediglich eine Liste ist), ist ein Anforderungsdiagramm einGraph: Anforderungen sind Knoten, und die Beziehungen zwischen ihnen — Enthaltung, Herleitung, Erfüllung, Verifizierung und Nachverfolgbarkeit — sind Kanten.

Die Kernidee istNachverfolgbarkeit. In einem IT-System lebt eine Anforderung nicht isoliert. Ein Stakeholder-Bedarf treibt eine Systemanforderung an; diese Anforderung wird durch einen architektonischen Block erfüllt; ein Testfall verifiziert sie; und sie kann in Teilanforderungen verfeinert werden. Das Anforderungsdiagramm macht jede dieser Verbindungen sichtbar und überprüfbar. Genau das verwandelt eine flache Tabelle in ein Modell.

Warum sollte man es für IT-Systeme verwenden?

IT-Projekte sind berüchtigt fürAnforderungsdrift— Scope-Creep, unkontrollierte Änderungen und das Problem „wir haben es gebaut, aber niemand hat es verlangt”. Ein Anforderungsdiagramm hilft, weil es Ihnen ermöglicht:

• Rückwärts nachverfolgen — „Warum existiert diese Komponente?“ → Folgen SieErfüllungs-Verbindungen bis zur Anforderung undHerleitungs-Verbindungen bis zum geschäftlichen Bedarf.

• Vorwärts nachverfolgen — „Wurde diese Anforderung verifiziert?“ → Folgen SieVerifizierungs-Verbindungen zu den Testfällen.

• Änderungsauswirkungen bewerten — „Wenn sich diese Anforderung ändert, was ist sonst noch betroffen?“ → Folgen Sie jeder eingehenden und ausgehenden Kante.

• Abdeckung nachweisen — jede Anforderung sollte erfüllt werden durchetwas und verifiziert durch etwas. Waisen-Anforderungen sind sofort sichtbar.

2. Schlüsselkonzepte & Notation

2.1 Das Anforderungselement

Eine Anforderung wird als Rechteck mit einem Namen, einer eindeutigen ID (typischerweise hierarchisch, wie 1.2.3), und Anforderungstext. Das Stereotyp ist «Anforderung».

Anforderungen können Eigenschaften — formal modellierte Attribute wie Quelle, Risiko, Priorität, Status, oder Verifizierungsmethode. Diese machen eine Anforderung messbar und nicht vage.

2.2 Die Beziehungen (das Herzstück des Diagramms)

Die kritische Regel: Eine Beziehung wird niemals auf die ID-Zeichenfolge einer Anforderung gezeichnet, sondern auf das Alias des Elements. — sie wird auf das Alias des Elements gezeichnet. alias Und wenn Anforderung A Anforderung B enthält, müssen Sie nicht zusätzlich eine «ableiten»-Beziehung zwischen ihnen in irgendeiner Richtung zeichnen; Enthaltensein und Ableitung sind für dasselbe Paar gegenseitig ausschließend.

2.3 Blöcke, Testfälle und Verfeinerungsquellen

• Block («block»): das Designelement, das Anforderungen erfüllt. Im IT-Kontext ist dies Ihre Architekturkomponente — ein Dienst, Modul oder eine API.

• Testfall («testCase»): die Verifikationseinheit.

• Verfeinerungsquellen: Anwendungsfälle, Aktivitäten oder jedes Modellelement, das eine Anforderung ausführt.

Hinweis zur Notation: die Beziehungspfeile haben spezifische Köpfe (der «erfüllt»-Pfeil zeigt beispielsweise auf die zu erfüllende Anforderung). Wenn Sie darüber in Fließtext schreiben, zitieren Sie immer das Stereotyp — schreiben Sie `«erfüllt»` — damit es nicht vom Markdown-Parser des Lesers verschluckt wird.

3. Diagrammbeispiele

Beispiel 1 — Eine grundlegende Anforderungshierarchie

Dieses Beispiel zeigt Enthaltung und Herleitung, das Grundgerüst, mit dem jedes Anforderungsdiagramm beginnt. Eine übergeordnete Leistungsanforderung wird in messbare Teilanforderungen zerlegt.

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType RequirementDiagram
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title Hierarchie der Fahrzeugleistungsanforderungen

$requirement("Fahrzeugleistung", ReqVehiclePerf, "1", "Das Fahrzeug muss die angegebenen Leistungsziele unter nominalen Betriebsbedingungen erfüllen.")
$requirement("Beschleunigung", ReqAccel, "1.1", "Das Fahrzeug muss von 0 auf 100 km/h in weniger als 6 Sekunden beschleunigen.")
$requirement("Höchstgeschwindigkeit", ReqTopSpeed, "1.2", "Das Fahrzeug muss eine maximale Geschwindigkeit von mindestens 220 km/h erreichen.")
$requirement("Bremsen", ReqBraking, "1.3", "Das Fahrzeug muss von 100 km/h auf trockenem Fahrbahnbelag in weniger als 38 Metern zum Stillstand kommen.")
$requirement("Kraftstoffeffizienz", ReqFuel, "1.4", "Das Fahrzeug muss im kombinierten Zyklus mindestens 15 km/l erreichen.")

$containment(ReqVehiclePerf, ReqAccel)
$containment(ReqVehiclePerf, ReqTopSpeed)
$containment(ReqVehiclePerf, ReqBraking)
$containment(ReqVehiclePerf, ReqFuel)
$deriveReqt(ReqBraking, ReqVehiclePerf)
@enduml

Lesen Sie es: Beschleunigung, Höchstgeschwindigkeit, Bremsen, und Kraftstoffeffizienz sind allesamt Teile von der übergeordneten Fahrzeugleistung Anforderung (Enthaltung). Bremsen ist auch abgeleitet aus davon, was bedeutet, dass es in ein konkretes, messbares Ziel aufgeteilt wurde.

Beispiel 2 — Erfüllung und Verifikation (Entwurf erfüllt Anforderungen)

Dies fügt die Entwurfsseite hinzu. Architekturkomponenten erfüllen Anforderungen, und Testfälle verifizieren sie. Dies ist das Diagramm, das Sie bei einer Entwurfsprüfung vorlegen.

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType Anforderungsdiagramm
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title Zahlungssystem — Erfüllung und Verifizierung

$requirement("PCI-DSS-Konformität", ReqPci, "3", "Das System darf keine Kartenverifizierungswerte speichern und muss Kundendaten im Ruhezustand verschlüsseln.")
$requirement("Zahlung verarbeiten", ReqPay, "3.1", "Das System muss eine Kundenzahlung innerhalb von 3 Sekunden autorisieren.")
$requirement("Idempotente Belastung", ReqIdem, "3.2", "Das System darf einen Kunden bei einem erneuten Versuch nicht doppelt belasten.")

$block("PaymentService", PaymentService)
$block("VaultService", VaultService)

$testCase("PCI-Audit", TAudit)
$testCase("Latenztest", TLatency)
$testCase("Idempotenztest", TIdem)

$containment(ReqPci, ReqPay)
$containment(ReqPci, ReqIdem)

$satisfy(PaymentService, ReqPay)
$satisfy(VaultService, ReqPci)

$verify(TAudit, ReqPci)
$verify(TLatency, ReqPay)
$verify(TIdem, ReqIdem)
@enduml

Lesen Sie es: PaymentService erfüllt die Anforderung zur Zahlungsabwicklung, während VaultService erfüllt die umfassendere PCI-DSS-Anforderung. Jede Anforderung wird verifiziert durch einen Testfall. Beachten Sie die Pfeilrichtungen: `«satisfy»` zeigt vom Block zur Anforderung, die es erfüllt; `«verify»` zeigt vom Testfall zur Anforderung, die er nachweist.

Beispiel 3 — Vollständige IT-System-Nachverfolgungskette

Dies ist das Diagramm, das Sie verwenden würden, um einen Geschäftsbedarf bis hin zur Verifizierung nachzuverfolgen — die klassische Frage „Warum existiert dieser Code?“.

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType Anforderungsdiagramm
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title E-Commerce-System — Anforderungsnachverfolgung

$requirement("Geschäft: Warenkorbabbruch um 15% reduzieren", ReqBiz, "B1", "Das Geschäft muss den Warenkorbabbruch innerhalb von zwei Quartalen um 15% reduzieren.")
$requirement("Checkout-UX", ReqUx, "S1", "Das System muss einem Gast ermöglichen, den Checkout in weniger als 5 Schritten abzuschließen.")
$requirement("Ein-Klick-Nachbestellung", ReqReorder, "S2", "Das System muss einem wiederkehrenden Kunden ermöglichen, einen früheren Kauf in einem Schritt erneut zu bestellen.")
$requirement("Datenresidenz", ReqResidency, "S3", "Das System muss Kundendaten der EU in EU-Regionen speichern.")

$block("CheckoutUI", CheckoutUI)
$block("ReorderService", ReorderService)
$block("RegionalDatastore", RegionalDatastore)

$testCase("Checkout-Flow-Test", TCheckout)
$testCase("Nachbestellungstest", TReorder)
$testCase("Residenz-Audit", TResidency)

$containment(ReqBiz, ReqUx)
$containment(ReqBiz, ReqReorder)
$deriveReqt(ReqUx, ReqBiz)
$deriveReqt(ReqReorder, ReqBiz)

$satisfy(CheckoutUI, ReqUx)
$satisfy(ReorderService, ReqReorder)
$satisfy(RegionalDatastore, ReqResidency)

$verify(TCheckout, ReqUx)
$verify(TReorder, ReqReorder)
$verify(TResidency, ReqResidency)

$trace(ReqResidency, ReqBiz)
@enduml

Lesen Sie es: Die geschäftliche Anforderung B1 verankert alles. Die Systemanforderungen S1 und S2 sind abgeleitet aus es (das „Warum“), während S3 (Datenresidenz) ist ein rückverfolgbar Einschränkung, die nur durch `«trace»`. Jede Systemanforderung ist erfüllt durch eine Komponente und überprüft durch einen Test. Wenn B1 geändert wird, zeigt Ihnen dieses Diagramm sofort, welche Komponenten und Tests im Geltungsbereich liegen.

4. Wie man eine erstellt (praktischer Arbeitsablauf)

1. Beginnen Sie mit dem übergeordneten Bedarf. Normalerweise eine Geschäfts- oder Stakeholder-Anforderung. Geben Sie ihr einen klaren ID-Bereich (z. B. B* für Geschäftsanforderungen, S* für Systemanforderungen).

2. Zersetzen Sie sich nach unten mit Einbettung. Teilen Sie die großen Anforderungen in kleinere, messbare auf. Guter Anforderungstext enthält eine Zahl („unter 3 Sekunden“, „15 %“, „innerhalb der EU-Regionen“).

3. Fügen Sie Ableitungsverbindungen hinzu, wo ein Kind eine konkrete Wiedergabe ist, nicht nur ein Teil. Denken Sie daran: Ein Paar kann durch Einbettung oder Ableitung verbunden sein, niemals beides.

4. Entwurf an Anforderungen mit erfüllen.Jeder architektonische Block sollte mindestens eine Anforderung erfüllen. Blöcke, die nichts erfüllen, sind Kandidaten für die Löschung; Anforderungen, die von nichts erfüllt werden, sind Lücken in der Abdeckung.

5. Tests mit verifizieren.Jede Anforderung benötigt einen Verifizierungsweg. Anforderungen, die von nichts verifiziert werden, sind nicht überprüfbar – ein Warnsignal.

6. Verwenden Sie Verfolgungnur wenn nichts anderes passt.Sie ist die Ausweichmöglichkeit für lose Assoziationen; übermäßiger Gebrauch verwässert den Wert.

7. Halten Sie es unter ~24 Elementen.Große Diagramme werden unlesbar. Teilen Sie sie nach Subsystem oder Anforderungskategorie (Sicherheit, Leistung, Funktionalität).

Die drei Abdeckungsfragen

Führen Sie diese Checkliste gegen jedes Anforderungsdiagramm durch:

• Ist jede Anforderung erfüllt?(wenn es eine Systemanforderung ist, muss etwas sie realisieren)

• Ist jede Anforderung verifiziert?(etwas muss es beweisen)

• Leitet jede Anforderung auf einen Bedarf zurück?(keine verwaisten Anforderungen, die ohne geschäftliche Begründung schweben)

Jede „Nein“-Antwort ist ein Befund.

5. Anwendung auf IT-Systeme — Muster und Fallstricke

Gute Praktiken

• Trennen Sie Anforderungen typenvisuell.Sie können Anforderungen stereotypisieren («funktional», «Leistung», «Sicherheit», «Benutzbarkeit») damit nichtfunktionale Anforderungen von funktionalen abgehoben werden.

• Halten Sie die ID-Hierarchie aussagekräftig. 2.3.4 sollte einem Leser mitteilen, dass diese Anforderung unter Modul 2, Funktion 3, Teilfunktion 4 angesiedelt ist. Konsistenz über Diagramme hinweg und in Ihrem ALM-Tool ist wichtig.

• Modellieren Sie die Quelle. Fügen Sie ein Quelle Eigenschaft (regulatorisch, Stakeholder-Name, Marktanforderungsdokument). Rückverfolgbarkeit zu Ursprung ist oft wichtiger als die Rückverfolgbarkeit zum Design.

• Ein Diagramm, eine Sorge. Ein Zufriedenheitsdiagramm (Design-Überprüfung) und ein Verifizierungsdiagramm (Test-Überprüfung) haben unterschiedliche Zielgruppen. Versuchen Sie nicht, beide sowie die gesamte Hierarchie in ein Bild zu pressen.

Häufige Fallstricke

• Verwechslung von Ableitung und Enthaltensein. Sie sehen ähnlich aus, bedeuten aber unterschiedliches. Enthaltensein ist strukturelle Zerlegung; Ableitung ist logische Entwicklung der Absicht. Das Vermischen (oder das Zeichnen beider zwischen einem Paar) macht das Modell ungültig.

• Verweis über ID statt Alias. Im Tool binden Beziehungen an Element Aliasnamen, nicht an menschenlesbare ID-Zeichenfolgen. Stellen Sie den Aliasnamen korrekt ein, sonst verweist die Beziehung stillschweigend auf nichts.

• Behandlung von Verfolgung als erfüllen. Ein Verfolgungsverknüpfungspunkt beansprucht nicht, dass das Ziel etwas erfüllt. Wenn Sie „diese Komponente implementiert diese Anforderung” meinen, verwenden Sie `«erfüllen»`.

• Anforderungen ohne Nummer. „Das System soll schnell sein” kann nicht verifiziert werden. Eine Anforderung ohne messbaren Schwellenwert ist ein Wunsch, keine Anforderung.

• Das Diagramm zur Spezifikation werden lassen. Das Diagramm zeigt Beziehungen; die Anforderung Text und Eigenschaften tragen die Details. Halten Sie den Text präzise und fügen Sie Eigenschaften (Status, Priorität, Risiko) hinzu, damit das Modell abfragbar ist.

6. Werkzeuge

Sie können diese Diagramme direkt aus dem oben gezeigten PlantUML-Quellcode mit VPasCode — fügen Sie den Code ein, und das Diagramm wird sofort gerendert. Von dort aus können Sie es auch exportieren oder verfeinern.

Schnellreferenz: Element- und Beziehungs-Makros

$requirement("Name", Alias, "id", "Anforderungstext")
$block("BlockName", Alias)
$testCase("TestfallName", Alias)

$containment(ElternAlias, KindAlias)
$deriveReqt(KindAlias, ElternAlias)
$satisfy(BlockAlias, AnforderungsAlias)
$verify(TestfallAlias, AnforderungsAlias)
$refine(ModelAlias, AnforderungsAlias)
$trace(VonAlias, ZuAlias)
$copy(VonAlias, ZuAlias)

Zusammenfassung

Ein Anforderungsdiagramm ist das Rückgrat der Rückverfolgbarkeit eines Modells. Für IT-Systeme beantwortet es die drei Fragen, die jede Prüfung, Designüberprüfung und Änderungsanfrage stellt: Warum existiert dies? Was implementiert es? Was beweist es? Gut eingesetzt — mit messbarem Anforderungstext, korrekten Beziehungssemantiken und disziplinierten Abdeckungsprüfungen — verwandelt es Anforderungen von einem statischen Dokument in ein lebendiges, abfragbares Modell, das Design, Code und Test mit der Geschäftsabsicht in Einklang hält.

Referenz

1. VPasCode: KI-gestütztes Diagramm-as-Code mit PlantUML, Mermaid und Graphviz: Offizieller Leitfaden zur KI-gestützten Diagrammerstellung, Änderungsworkflows und Multi-DSL-Unterstützung einschließlich PlantUML, Mermaid und Graphviz.
2. Visual Paradigm VPasCode: Umfassender Leitfaden: Detaillierte Übersicht über die Funktionen von VPasCode, Zielgruppen (Entwickler, Architekten, Analysten) und seine Rolle in agilen Dokumentationsworkflows.
3. Willkommen bei Visual Paradigm VPasCode: Der Wechsel zu Diagramm als Code (DaC): Einführung in die einheitliche Plattform, Erläuterung der Vorteile von Text-zu-Diagramm-Workflows und automatisierter Layout-Engineering.
4. 60-Sekunden-Schnellstartanleitung | VPasCode-Leitfaden: Text zu Diagramm: Schritt-für-Schritt-Anleitung zum Erstellen, Anpassen und Exportieren von Diagrammen mit dem browserbasierten Editor mit Live-Vorschau.
5. Neu in VPasCode: KI-gestützter UML-Profil-Diagramm-Generator: Produktupdate mit der Einführung einer KI-gestützten Generierung von UML-Profil-Diagrammen mittels einfacher englischer Eingabeaufforderungen, mit Beispiel für die Einhaltung von Datenschutzbestimmungen im Gesundheitswesen.
6. Native KI-Diagrammerstellung in Visual Paradigm VPasCode: Ankündigung integrierter KI-Funktionen zum Erstellen, Ändern und Korrigieren von Diagrammen über natürliche Sprachbefehle direkt im Editor.
7. KI-gestützter Diagramm-Generator & Produktivitätstools | VPasCode: Überblick über die Integrationen von VPasCode mit KI-Chatbots, Visual Paradigm Desktop und OpenDocs für optimierte Dokumentationspipelines.
8. Beste PlantUML-Alternativen & kostenlose Diagramm-als-Code-Editoren: Vergleichsmatrix von PlantUML-Alternativen, die die Unterstützung mehrerer DSLs, KI-Funktionen und den browserbasierten Ansatz ohne Einrichtung von VPasCode hervorhebt.
9. Diagramm-als-Code-Editor: Text sofort in Diagramm umwandeln: Funktionsübersicht mit automatischer Formaterkennung, Echtzeit-Rendering und Exportoptionen für mehrere Formate (SVG, PNG, PDF).
10. Leitfaden zum Visual Paradigm-Ökosystem: Erläutert, wann VPasCode gegenüber VP Desktop zu verwenden ist, mit Hinweisen zur versionierten Diagramm-Wartung und Integration in lebendige Dokumentation.

Der Artikel ist auch in English, فارسی and English verfügbar.