NextGenSysML Teil 9 - Anforderungen Anforderungen

Blog offline

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

In diesem Blogbeitrag werden die Anforderungen für die Modellierung von Anforderungen mit der SysMLv2 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.

Anforderungen sind ein wesentlicher Bestandteil des Systems Engineering, und insbesondere SysML v1 hat sie in der Systemmodellierungswelt populär gemacht. Schauen wir uns also an, was für die nächste Generation von SysML für Anforderungen geplant ist.

Natürlich wird SysML v2 ein Modellelement zur Definition einer Anforderung bereitstellen. Die Anforderung verfügt über eine eindeutige Kennung mit einem benutzerdefinierten Schema, einem textuellen Anforderungstext und zusätzlichen optionalen Attributen wie Status, Priorität, Risiko, Autor und Eigentümer. Viele Quellen schlagen unterschiedliche Mengen wichtiger Anforderungsattribute vor. Die Attribute für die SysML v2-Anforderung stammen aus dem INCOSE-Handbuch und ReqIF. Natürlich ist es möglich, eigene spezifische Attribute hinzuzufügen.

Auch wenn Anforderungen Teil des Modells sind, werden sie in den meisten Fällen immer noch durch Text definiert. SysML v2 bietet zusätzliche, formalere Möglichkeiten zum Definieren von Anforderungen. Sie können einen Anforderungstext mit vordefinierten Schlüsselwörtern und Satzstrukturen verwenden. Das ist besser als nur purer Text, aber immer noch textbasiert. Eine weitere Option ist eine formale Anforderung, die Ausdrücke enthalten kann, um Bedingungen anzugeben, die eine akzeptable Lösung erfüllen muss. Dies ermöglicht reale modellbasierte Anforderungen. Der Ausdruck kann ein Teil des Modells sein.

Es wird möglich sein, an Anforderungen und Anforderungsgruppen zusätzliche beliebige Informationen zu speichern, beispielsweise, um die Motivation der Anforderung näher zu erläutern.

Anforderungen kommen niemals allein und Sie benötigen Möglichkeiten, um die Vielzahl an Anforderungen zu organisieren. Neben einem allgemeinen Container für Modellelemente (siehe NextGenSysML 4) bietet SysML v2 ein Anforderungsgruppenelement. Zwischen der Gruppe und ihren Mitgliedern besteht eine Beziehung, die die Semantik der Mitgliedschaft angibt. Die Anforderungen in der Gruppe können eine Ordnung haben. Neben den Anforderungen kann eine Gruppe auch andere Gruppen als Mitglieder haben.

SysML v2 trennt die Definition und die Verwendung von Anforderungen, wie Sie es beispielsweise auch von Blöcken und Teilen (Blockdefinition und internes Blockdiagramm) kennen. Eine Anforderung kann lokal unterschiedlich genutzt werden, um beispielsweise unterschiedliche Systemkonfigurationen mit lokalisierten Werten als Teil der Anforderung zu modellieren.

Eine weitere Möglichkeit, Anforderungen zu variieren, ist die Anforderungsspezialisierung, d.h., eine Generalisierungsbeziehung von einer Anforderung zu einer anderen Anforderung. In der SysML v1 ist das nicht zulässig.

Apropos Beziehungen: SysML v2 bietet einige spezielle Anforderungsbeziehungen:

Satisfy: Beziehung zwischen einer Anforderung und einem Modellelement, das sie erfüllt.
Verify: Beziehung zwischen einem Testfall und der entsprechenden Anforderung.
Derive: Beziehung zwischen einer Anforderung und einer anderen Anforderung, von der sie abgeleitet wurde (beispielsweise durch eine Architekturentscheidung)

Eine optionale Anforderung für SysML v2 Anforderungen fordert logische Operationen zwischen Anforderungsbeziehungen. Wenn Sie beispielsweise modellieren, dass zwei Architekturelemente eine Anforderung erfüllen, ist zunächst unklar, ob beide Elemente gemeinsam die Anforderung erfüllen oder jedes für sich. Das kann mit den logischen Operationen angegeben werden. Mit der SysML v1 ist das nicht möglich, aber SYSMOD schließt diese Lücke mit einigen speziellen Stereotypen (z.B. weightedSatisfy).

SysML v2 enthält die neuen Konzepte Kriterium und Ziel, die nicht Teil von SysML v1 sind. Ein Kriterium liefert die Grundlage für eine Bewertung einer Anforderung, beispielsweise dass die Masse eines Bauteils unter einem bestimmten Wert liegen darf. Anforderungen, die auf diesen Kriterien basieren, legen den konkreten Wert fest. Die Ziele (goal) sind ähnlich und geben eine Richtung wie "Minimieren der Masse" vor. Strategischere Ziele (objective) beschreiben einen gewünschten Endzustand, wie das leichteste System seiner Art.

Der nächste Blog-Beitrag behandelt die Anforderungen an die Fähigkeit von SysML v2, die Verifikation von Systemen zu modellieren.

Frühere Blogbeiträge dieser Reihe:

Geplante zukünftige Blogbeiträge:

NextGenSysML Teil 10 - Verifikationsanforderungen
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/06/14/nextgensysml-part-9-requirements-requirements/)