In diesem Blogbeitrag werden die Anforderungen für die Modellierung der Verifikation mit der SysML v2 vorgestellt. Er ist Teil einer Blogpostserie über den kommenden neuen Standard SysML v2 und SysML API & Services. Die Blogbeiträge stellen die Anforderungen an den Standard vor, die in der von der OMG veröffentlichten Ausschreibung (Request for Proposal, RFP) spezifiziert sind. Am Ende dieses Beitrags finden Sie eine Liste aller Beiträge dieser Serie, einschließlich eines Links zum ersten Beitrag der Serie, der eine allgemeine Einführung bietet.
Verifikation ist ein wichtiger, aber oft vernachlässigter Teil des Systems Engineerings. Sie zeigt, ob das System den Anforderungen entspricht. Alle SysML v2-Elemente für die Modellierung der Verifikation umfassen auch die Modellierung der Validierung, die aus Sicht der Modellierung ähnlich ist.
SysML v2 bietet die Möglichkeit, das System, das für die Verifizierung verwendet wird, sowie den Kontext zu modellieren, der das System zur Verifizierung, die zugehörige Umgebung umfasst.
SysML v2 bietet das Modellelement VerificationCase, um zu bewerten, ob eine Komponente die gestellten Anforderungen erfüllt. Es ist eine Spezialisierung des allgemeinen Konzepts eines Falls (siehe NextGenSysML- Teil 8). In SysML v1 heißt es TestCase. Eine Beziehung verknüpft den VerificationCase mit den zu überprüfenden Modellelementen.
Der VerificationCase umfasst
- Ziele, modelliert durch eine Beziehung zwischen dem Fall und den Zielen
- Erfolgskriterien, anhand derer bewertet wird, ob die Ziele erfüllt und die Anforderungen verifiziert sind
- Methoden zur Überprüfung der Anforderungen. Die Methoden wie Inspektion, Test oder Demonstration sind in einer Modellbibliothek enthalten.
Der nächste Blog-Beitrag behandelt die Anforderungen an die SysML v2, Analysen zu modellieren.
Frühere Blogbeiträge dieser Reihe:
- NextGenSysML Teil 0 – Next Generation Modeling: SysML v2 und SysML API & Services – Einführung
- NextGenSysML Teil 1 – Überblick SysML V2 und SysML API & Services RFPs
- NextGenSysML Teil 2 – Die allgemeinen OMG-Anforderungen
- NextGenSysML Teil 3 – Anforderungen an die Architektur der SysML v2
- NextGenSysML Teil 4 – Querschnittsanforderungen
- NextGenSysML Teil 5 – Anforderungen an Eigenschaften, Werte und Ausdrücke
- NextGenSysML Teil 6 – Strukturanforderungen
- NextGenSysML Teil 7 – Schnittstellenanforderungen
- NextGenSysML Teil 8 – Verhaltensanforderungen
- NextGenSysML Teil 9 – Anforderungen Anforderungen
Geplante zukünftige Blogbeiträge:
- NextGenSysML Teil 11 – Analyseanforderungen
- NextGenSysML Teil 12 – Beispielmodell und Konformitätsanforderungen
- NextGenSysML Teil 13 – SysML API & Services Übersicht
- NextGenSysML Teil 14 – API & Services: Architekturanforderungen
- NextGenSysML Teil 15 – API & Services: Konformitätsanforderungen
- NextGenSysML Teil 16 – API & Services: Serviceanforderungen
(Übersetzung des Original-Blogposts: https://mbse4u.com/2019/07/17/nextgensysml-part-10-verification-requirements/)
Hallo Tim,
ich komme eher von der NAF v2+, UAF Schiene und muss mich daher in die Denkweise von INCOSE, SysMod hineindenken. Mir ist aktuell absolut unklar, weshalb ich einen VerificationCase benötige.
Wenn ich die Definition des Begriffs Verification aus dem V-Modell nehme, dann ist Verifikation der Prozess zu prüfen, ob eine Detailierung zu ihrer Spezifikation passt. zum Beispiel ob das Pflichtenheft zum Lastenheft passt. Verifikation umfasst sowohl Vollständigkeit als auch Kohärenz. Vollständigkeit weist nach, dass alle Punkte, um beim Beispiel zu bleiben des Lasteheftes im Pflichtenheft behandelt sind. Kohärenz ist schwieriger nachzuweisen. Ich nutze hier, falls es formal wird in aller Regel das Liskov’sche Substitutionsprinzip als mathematische Basis, ansonsten ein Review.
Im formalen Fall (LSP) ist kein VerificationCase notwendig. Im informellen oder semi-formalen Fall (Review) sind Prüfkriterien (criteria) gefragt. Die Prüfkriterien dürfen jedoch nicht vom Architekten kommen, da sonst das 4-Augen-Prinzip verletzt wäre. Somit auch kein VerificationCase.
Am Schluss noch ein großes Lob. Der Artikel impliziert NICHT, dass Verifikation Korrektheit nachweist. Verifikation kann ausschließlich Vollständigkeit und Kohärenz nachweisen.
/Carsten
Hallo Carsten,
Es gibt scheinbar unterschiedliche Definitionen des Begriffs „Verifikation“. In den Anforderungen an die SysML v2 wird der Begriff sehr allgemein verwendet und bezeichnet den Vorgang zu prüfen, dass etwas korrekt ist.
Auf welche konkrete Definition des Begriffs „Verification“ im V-Modell beziehst Du Dich? Der ISTQ definiert „Verification“ als „Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled.“. Das trifft die Verwendung in der SysML v2 recht gut.
Beste Grüße,
Tim
Hallo Tim,
ich hatte die Definition aus dem klassischen V-Modell (AU250 bis V-Modell ’97) verwendet. Daher auch die Begriffe Lasten- und Pflichenheft. Im aktuellen V-Modell XT sind die Begriffe Validierung und Verifikation anders definiert.
Die Definition aus dem klassischen V-Modell spiegelt sich, wenn auch leider nicht mehr in Reinform im SEBook
(https://www.sebokwiki.org/wiki/System_Validation) wieder.
Oder auch in ASpice V3.x
4.5.2. SUP.2 Verification
Process ID SUP.2
Process name Verification
Process purpose
The purpose of the Verification Process is to confirm that each work product of a process or project properly reflects the specified requirements.
/Carsten