4.3. Ergebnis des Anforderungs-Erfassungs-Prozesses

Fast alle Ergebnisse des Anforderungs-Erfassungs-Prozesses sind dokumentarisch. Das einzige Diagramm ist das Anwendungsfalldiagramm, das die Beziehungen zwischen den Anwendungsfällen und den Akteuren darstellt.

4.3.1. Visions-Dokument

Typische Kapitel dieses Dokumentes könnten die folgenden sein.

  • Zusammenfassung. Eine Aussage zum Umfeld, zum Problem und zu den Zielen der Lösung.

  • Ziele. Was wir erreichen wollen (und wie wir es erreichen wollen).

  • Marktumfeld oder vertragliche Vereinbarungen. Bei einer Entwicklung zur Marktführerschaft, sollte es die Zielmärkte, die Alleinstellungsmerkmale, die zwingenden Ereignisse und so weiter aufzeigen. Bei einer vertraglich vereinbarten Entwicklung sollte es die Hauptelemente der vertraglichen Vereinbarung erläutern.

  • Nutzer. Die Nutzer (im weitesten Sinne) des Systems. Viele davon werden als Akteure, oder Steuer-Equipment das in Akteure umgewandelt wird, abgebildet.

  • Haupteigenschaften. Auf einer sehr hohen Abstraktionsebene: Was sind die hauptsächlichen Aspekte des Problems/der gewünschten Lösung. Es ist hilfreich, hier bereits zu priorisieren.

  • Randbedingungen. Eine Sicht auf die nicht-funktionalen Parameter des Systems auf einer sehr hohen Abstraktionsebene. Diese werden in der ergänzenden Anforderungsspezifikation detailliert ausgearbeitet.

  • Anhang. Eine Liste der Akteure und Anwendungsfälle die zur Erfüllung der Vision notwendig sind. Es ist hilfreich, diese mit den vorher beschriebenen Abschnitten zu verlinken um eine in sich geschlossene Darstellung sicherzustellen.

4.3.2. Anwendungsfalldiagramm

Das Visions-Dokument identifizierte die Anwendungsfälle und Akteure. Das Anwendungsfalldiagramm stellt dar, wie sie interagieren. In unserem ATM (Geldautomat) Beispiel haben wir „Kunde nutzt den Automaten“, „Wartung des Automaten“ und „Revision“ als die drei Hauptanwendungsfälle identifiziert. Als Akteure haben wir „Kunde“, „Wartungsingenieur“, „lokaler Zweigstellenbeamter “ und „Zentralcomputer“ identifiziert.

Abbildung 4.1, „ Grundlegendes Anwendungsfalldiagramm für einen Geldautomaten zeigt, wie das in einem Anwendungsfalldiagramm dargestellt werden kann. Die Anwendungsfälle werden als Ovale dargestellt, die Akteure als Strichmännchen (auch wenn es Maschinen sind), mit Linien (als Assoziationen bekannt), die die Anwendungsfälle mit den damit involvierten Akteuren verbinden. Ein Rahmen um die Anwendungsfälle stellt die Abgrenzung zwischen dem System (durch die Anwendungsfälle definiert) und den Akteuren dar, die extern sind.

[Anmerkung]Anmerkung

Nicht alle Analytiker möchten einen Rahmen um die Anwendungsfälle verwenden. Dies ist ein Fall persönlicher Vorlieben.

Abbildung 4.1. Grundlegendes Anwendungsfalldiagramm für einen Geldautomaten

Grundlegendes Anwendungsfalldiagramm für einen Geldautomaten

Die folgenden Abschnitte zeigen, wie das grundlegene Anwendungsfalldiagramm erweitert werden kann, um zusätzliche Informationen über das zu designende System darzustellen.

4.3.2.1. Aktive und passive Akteure

Aktive Akteure initiieren eine Interaktion mit dem System. Dies kann durch einen Pfeil in der Assoziation vom Akteur zum Anwendungsfall dargestellt werden. Im Geldautomaten-Beispiel ist der Kunde ein aktiver Akteur.

Die Interaktion mit passiven Akteuren wird durch das System initiiert. Dies kann durch einen Pfeil in der Assoziation vom Anwendungsfall zum Akteur dargestellt werden. Im Geldautomaten-Beispiel ist der Zentralcomputer ein passiver Akteur.

Dies ist ein gutes Beispiel, wo die Pfeile helfen, da es uns erlaubt, ein ereignisgetriebenes System (der Geldautomat initiiert die Interaktion mit dem Zentralcomputer) von einem zyklisch abfragenden System (der Zentralcomputer fragt den Geldautomaten von Zeit zu Zeit ab) zu unterscheiden.

Dort wo ein Akteur entweder aktiv oder passiv sein kann, je nach den Umständen, kann der Pfeil weggelassen werden. Im Geldautomaten-Beispiel fällt der Bankingenieur in diese Kategorie. Normalerweise ist er aktiv, indem er regelmässig auftaucht um die Maschine zu warten. Wenn jedoch der Geldautomat einen Fehler entdeckt, kann er den Ingenieur auffordern diesen zu beheben.

Die Verwendung von Pfeilen bei Assoziationen wird als Navigation der Assoziation bezeichnet. Wir sollten dies später in der UML im Einsatz sehen. Die Wahl der OMG eine bidirektionale Assoziation durch keine anstelle von zwei Pfeilspitzen darzustellen ist unvorteilhaft. Mit dieser Konvention können Sie nicht zwischen einer Assoziation unterscheiden, deren Navigation noch zu bestimmen ist und einer die bidirektional ist.

Abbildung 4.2, „ Anwendungsfalldiagramm für einen Geldautomaten mit Navigation. zeigt das Geldautomaten-Anwendungsfalldiagramm mit dargestellter Navigation.

Abbildung 4.2. Anwendungsfalldiagramm für einen Geldautomaten mit Navigation.

Anwendungsfalldiagramm für einen Geldautomaten mit Navigation.

4.3.2.2. Kardinalität

Es kann sehr nützlich sein, die Multiplizität von Assoziationen zwischen Akteuren und Anwendungsfällen darzustellen. Damit meinen wir, wie viele Ausprägungen eines Akteurs mit wie vielen Ausprägungen eines Anwendungsfalles interagieren.

Standardmäßig nehmen wir an, dass eine Ausprägung eines Akteurs mit einer Ausprägung eines Anwendungsfalles interagiert. In den anderen Fällen können wird die Multiplizität an einem Ende der Assoziation kennzeichnen. Entweder mit einer Nummer, um darzustellen, wie viele Ausprägungen involviert sind, oder mit einem durch zwei Punkten separierten Bereich (.. ). Ein Stern (*) wird verwendet, um eine beliebige Zahl darzustellen.

Im Geldautomaten-Beispiel gibt es nur einen Zentralcomputer, aber es können beliebig viele Nutzungen des Geldautomaten aufgezeichnet werden. Daher plazieren wir das Kennzeichen 0..* am Ende des Anwendungsfalles. Es gibt keine Notwendigkeit für eine Kennzeichnung am anderen Ende, da der Standard 1 ist.

Eine lokale Bank kann bis zu drei Beamte haben, die autorisiert sind, die Geldautomaten zu leeren und zu befüllen. Daher plazieren wir bei der Beziehung zwischen dem Akteur und dem Anwendungsfall Wartung Geldautomat am Ende zum Akteur die Kennzeichnung 1..3. Sie können sich mit beliebig vielen Geldautomaten befassen, so dass wir auf dem anderen Ende das Kennzeichen 0..* plazieren.

Es gibt beliebig viele Kunden und beliebig viele Geldautomaten die diese nutzen dürfen. Daher plazieren wir an jedem Ende der Assoziation das Kennzeichen 0..*.

Abbildung 4.3, „ Anwendungsfalldiagramm für einen Geldautomaten und dargestellter Kardinalität. zeigt das Geldautomaten-Anwendungsfalldiagramm mit dargestellter Kardinalität.

Abbildung 4.3. Anwendungsfalldiagramm für einen Geldautomaten und dargestellter Kardinalität.

Anwendungsfalldiagramm für einen Geldautomaten und dargestellter Kardinalität.

Die Multiplizität kann ein Diagramm überladen und wird oft nicht angezeigt, ausser wo es für das Verständnis kritisch ist. Im Beispiel Geldautomat würde wir nur 1..3 zum lokalen Bankbeamten darstellen, da alle anderen aus dem Kontext heraus offensichtlich sind.

4.3.2.3. Hierarchien von Anwendungsfällen

In unserem Geldautomatenbeispiel haben wir jetzt drei Anwendungsfälle, um das Verhalten des Systems zu beschreiben. Auch wenn Anwendungsfälle immer einen signifikanten Teil des Systemverhaltens beschreiben sollten, wenn diese zu generell sind, können sie schwer zu beschreiben sein.

Wir könnten zum Beispiel das Verhalten des Anwendungsfalles „Geldautomat nutzen“ durch das Verhalten von drei einfacheren Anwendungsfällen, wie „Bargeld lagern“, „Bargeld ausgeben“ und „Konto abfragen“ ausdrücken. Der Hauptanwendungsfall könnte durch einbinden (include) des Verhaltens der benötigten Unteranwendungsfälle spezifiziert werden.

Der Anwendungsfall „Geldautomat warten“ könnte ebenfalls durch zwei Anwendungsfälle „Equipment warten “ und „Geldautomat neu starten“ definiert werden. In diesem Fall sind die zwei im Hauptanwendungsfall involvierten Akteure natürlich nur in einem oder dem anderen der beiden Unteranwendungsfälle involviert. Dies wird im nachfolgenden Diagramm dargestellt.

Die Aufteilung eines Anwendungsfalles in einfacherere Unteranwendungsfälle wird in UML durch eine include Beziehung, einem gestrichelten Pfeil vom Hauptanwendungsfall zum Unteranwendungsfall mit der Kennzeichnung «include» bezeichnet.

Abbildung 4.4. Anwendungsfalldiagramm für einen Geldautomaten mit include-Beziehungen.

Anwendungsfalldiagramm für einen Geldautomaten mit include-Beziehungen.

Include-Beziehungen sind ideal für das Herunterbrechen des Anwendungsfallverhaltens in Hierarchien. Wir wollen jedoch auch einen Anwendungsfall, der eine Erweiterung (extension) eines existierenden Anwendungsfalles darstellt, in bestimmten Umständen darstellen.

Im Geldautomatenbeispiel haben wir einen Anwendungsfall „ Equipment warten“, der die Routinewartung des Geldautomaten beinhaltet. Wir wollen aber auch den Spezialfall einer ungeplanten Reparatur abdecken, die durch den vom Geldautomaten erkannten internen Fehlers ausgelöst wurde.

Dies wird in UML durch die extend-Beziehung dargestellt. Im Hauptanwendungsfall spezifizieren wir einen Namen für einen Ort in der Beschreibung, an den die Erweiterung des Verhaltens hinzugefügt werden kann. Der Name und der Ort werden in einem separaten Abschnitt innerhalb des Anwendungsfall- Ovales dargestellt. Die Darstellung der extend-Beziehung entspricht der include-Beziehung, aber mit dem Kennzeichen «extend». An der extend- Beziehung spezifizieren wird die Bedingung, unter der das Verhalten hinzugefügt wird.

Abbildung 4.5, „ Anwendungsfalldiagramm für einen Geldautomaten. Zeigt eine extend-Beziehung. zeigt das Geldautomaten-Anwendungsfalldiagramm mit einer extend- Beziehung auf einen Anwendungsfall für ungeplante Reparaturen. Das Diagramm ist jetzt sehr komplex so dass wir es in zwei aufteilen sollten. Eines für die hauptsächlichen Dinge, das andere für den Kundennutzen und Revision.

Der Anwendungsfall „Equipment warten“ definiert den Namen „Unshed“ am Anfang seiner Beschreibung. Der erweiterte Anwendungsfall „ungeplante Reparatur“ wird herangezogen, wenn der Geldautomat einen internen Fehler entdeckt.

Abbildung 4.5. Anwendungsfalldiagramm für einen Geldautomaten. Zeigt eine extend-Beziehung.

Anwendungsfalldiagramm für einen Geldautomaten. Zeigt eine extend-Beziehung.

Anwendungsfälle können auch auf andere Art und Weise miteinander verknüpft sein. Ein Anwendungsfall kann eine Generalisierung eines Sub-Anwendungsfalles (oder alternativ: Der Sub-Anwendungsfall ist eine Spezialisierung des Hauptanwendungsfalles). Das ist der extend-Beziehung sehr ähnlich, aber ohne die Bedingung des spezifischen Erweiterungspunktes, unter welcher der Haupt-Anwendungsfall erweitert wird und ohne Bedingung unter welcher der Sub-Anwendungsfall verwendet wird.

Der Generalisierung wird in einem Anwendungsfalldiagramm durch einen Pfeil mit durchgehender Linie und einer weissen Pfeilspitze vom Sub-Anwendungsfall zum Hauptanwendungsfall dargestellt. Das kann hilfreich sein, wenn ein Sub-Anwendungsfall das Verhalten des Hauptanwendungsfalles in einer Vielzahl von Positionen und in einem weiten Bereich von Sachverhalten spezialisiert. Das Fehlen jeglicher Einschränkungen macht es sehr schwierig, die Generalisierung genau zu beschreiben. Im Normalfall verwenden Sie besser eine extend-Beziehung.

4.3.3. Die Anwendungsfall-Spezifikation

Jeder Anwendungsfall muss dokumentiert sein, um das das spezifizierte Verhalten im Detail zu erläutern. ArgoUML unterstützt Sie in diesem Bereich durch das Generieren graphischer Dateien, die in diese Dokumentation eingebunden werden kann. Dieses Dokument ist unter verschieden Namen in verschiedenen Prozessen bekannt: Anwendungsfall-Spezifikation, Anwendungsfall-Szenario oder auch (verwirrend) nur Anwendungsfall.

Eine typische Anwendungsfall-Spezifikation wird folgende Kapitel enthalten.

  • Name. Der Name des Anwendungsfalles.

  • Ziel. Eine ein oder zweizeilige Zusammenfassung darüber, was dieser Anwendungsfall für seine Akteure ausführt.

  • Akteure. Die in diesen Anwendungsfall involvierten Akteure und jeden Umstand bezüglich Ihrer Einbindung.

    [Anmerkung]Anmerkung

    Dies sollte keine Beschreibung des Akteurs sein. Diese sollte mit dem Akteur im Anwendungsfalldiagramm verknüpft sein.

  • Vorbedingung. Diese würden besser als „Voraussetzungen“ bezeichnet, aber der überall verwendete Begriff ist Vorbedingungen. Dies ist eine Beschreibung jeder vereinfachenden Voraussetzung, die wir zum Start des Anwendungsfalles machen können.

    Im Geldautomatenbeispiel könnten wir beim Anwendungsfall „Equipment warten“ die Voraussetzung haben, das immer ein Ingenieur verfügbar ist und wir uns nicht vor dem Fall fürchten müssen, in dem ein Routinewartungs-Besuch ausgelassen wurde.

    [Achtung]Achtung

    Vermeiden Sie Vorbedingungen wo immer das möglich ist. Sie müssen sich absolut sicher sein, dass die Vorbedingung unter allen möglichen Umständen eingehalten wird. Wenn nicht, ist ihr System zu wenig spezifiziert und wird daher fehlschlagen, wenn die Vorbedingung nicht wahr ist. Wenn Sie nicht sicher sein können, dass die Vorbedingung immer wahr ist, müssen Sie einen zweiten Anwendungsfall spezifizieren, der den Fall handhabt, wenn die Vorbedingung falsch ist. Im ersten Fall sind die Vorbedingungen die Ursache der Probleme, im zweiten Fall die Ursache für mehr Arbeit.

  • Standardablauf. Die aufeinander folgenden Schritte, die das Verhalten des Anwendungsfalles im „Normalfall“ beschreiben. Wo ein Anwendungsfall mehrere normale Szenarien aufweist, wird einer davon willkürlich ausgewählt. Die Spezifizierung des Standardablaufes wird nachfolgend detaillierter beschrieben Abschnitt 4.3.3.1, „“.

  • Alternative Abläufe. Eine Reihe von linearen Sequenzen beschreiben jede der alternativen, gegenüber dem Standardablauf abweichenden Verhaltensweisen. Die Spezifizierung alternativer Abläufe ist detaillierter in Abschnitt 4.3.3.2, „“ beschrieben.

  • Nachbedingungen. Dies ist der Zustand jeder Nachbedingung, den wir am Ende des Anwendungsfalles feststellen können. Sehr hilfreich, wo der Anwendungsfall einer von einer Serie von in den Hauptanwendungsfall eingebundenen Unteranwendungsfällen ist, wo sie die Vorbedingung für den nächsten einzubindenden Anwendungsfall bilden.

    [Achtung]Achtung

    Nachbedingungen sind wie Vorbedingungen am Besten zu vermeiden. Sie bilden eine Belastung für die Spezifikation des Anwendungsfallablaufes, das sichergestellt sein muss, dass die Nachbedingung immer eingehalten wird. Daher sind sie auch eine Ursache von Problemen und zusätzlicher Arbeit.

  • Anforderungen. In einer idealen Welt würden das Visionsdokument, die Anwendungsfalldiagramme, die Anwendungsfallbeschreibungen und die Spezifikation der zusätzlichen Anforderungen die Anforderungen für ein Projekt bilden.

    Bei den meisten Marktführer-Entwicklungen, ist es gewöhnlich der Fall, dass sich die Eigentumsrechte der Anforderungen im gleichen Business befinden, wie das Team, das die Entwicklung durchführen wird. Die Marketingabteilung kann das Erfassen und die Analyse der Anwendungsfallanforderungen erlernen, um ihre kundenspezifischen Aktivitäten damit zu verbinden.

    Bei externen Vertragsentwicklungen jedoch, kann der Kunde auf einer traditionellen „Liste von Features“ als Basis des Vertrages bestehen. Wo dies der Fall ist, sollte dieser Abschnitt der Anwendungsfallspezifikation mit den vertraglich festgelegten Features übereinstimmen, die durch den Anwendungsfall abgedeckt werden.

    Das wird oft mit Hilfe eines Third-Party-Werkzeuges ausgeführt, das Dokumente verknüpfen kann und eine automatische Prüfung des Geltungsbereiches enthält. In diesem Fall wird dieser Abschnitt nicht benötigt oder kann automatisch generiert werden.

Die abschliessende Grösse der Anwendungsfallspezifikation hängt von der Komplexität der Anwendungsfälle ab. Als Faustregel gilt, dass die meisten Anwendungsfälle ca. 10-15 Seiten für die Spezifikation benötigen, das meiste davon für die alternativen Abläufe. Wenn sie sehr viel grösser sind, sollten Sie die Anwendungsfälle aufteilen. Wenn sie sehr viel kleiner sind, betrachten Sie, ob der Anwendungsfall einen zu kleinen Bereich des Verhaltens beschreibt.

4.3.3.1.

Alle Abläufe in einer Anwendungsfallspezifikation sind linear - d.h. es gibt keine bedingte Verzweigung. Jede Auswahl im Ablauf wird durch einen anderen, nach dem Auswahlpunkt kommenden alternativen Ablauf behandelt. Es ist wichtig, sich daran zu erinnern, dass wir hier das Verhalten und nicht die Programmierung spezifizieren.

Ein Ablauf wird durch eine Reihe von numerierten Schritten spezifiziert. Jeder Schritt muss einige Interaktionen mit einem Akteur oder mindestens eine Änderung generieren, die durch einen Akteur extern überwacht wird. Das Anforderungen erfassen sollte nicht das versteckte interne Verhalten eines Systems spezifizieren.

In unserem Geldautomatenbeispiel könnten wir im Anwendungsfall „Bargeld ausgeben“ die folgende Sequenz von Schritten im Standardablauf haben:

  1. Der Kunde gibt an, dass eine Quittung erforderlich ist.

  2. Der Kunde gibt die gewünschte Bargeldmenge ein.

  3. Der Geldautomat überprüft mit dem Zentralcomputer, dass der Kunde diese Auszahlung durchführen kann.

  4. Der Geldautomat gibt das Bargeld an den Kunden.

  5. Der Geldautomat gibt die Quittung an den Kunden aus.

Zur Erinnerung: Dies ist ein Sub-Anwendungsfall der im Haupt- Anwendungsfall „Geldautomat benutzen“ enthalten ist, der voraussichtlich das Prüfen von Karten und PINs handhaben wird, bevor dieser eingebundene Anwendungsfall aufgerufen wird.

[Anmerkung]Anmerkung

Der erste Schritt ist keine Bedingung. Wir nehmen als unseren Standardablauf den Fall, wo der Kunden eine Quittung haben möchte. Der Fall, wo der Kunde keine Quittung haben will, wird ein alternativer Ablauf sein.

4.3.3.2.

Dies erfasst die alternativen Szenarien, wie lineare Abläufe, die durch den Standardablauf referenziert werden. Zu Beginn erzeugen wir eine Liste der alternativen Abläufe.

    1. Der Kunde benötigt keine Quittung.

    2. Das Kundenkonto unterstützt keine Auszahlung.

    3. Die Kommunikation mit dem Zentralcomputer ist unterbrochen.

    4. Der Kunde unterbricht die Transaktion.

    5. Der Kunde macht beim Annehmen des Bargeldes Fehler.

Nachfolgend arbeiten wir jeden alternativen Ablauf als Referenz zum Standardablauf aus. Der erste alternative Ablauf könnte zum Beispiel wie folgt aussehen:

    1. Der Kunde benötigt keine Quittung.

      1. In Schritt 1 des Standardablaufes sagen die Kunden, dass Sie keine Quittung benötigen.

      2. Der Standardablauf geht von Schritt 2 in Schritt 4, Schritt 5 wird nicht benötigt.

Die Konvention ist, dass die verschiedenen alternativen Abläufe numeriert werden, wie A.1, A.2, A.3, usw. Die Schritte innerhalb eines alternativen Ablaufes werden darauf aufbauend numeriert. So dass die Schritte der ersten Alternative wie folgt lauten würden: A.1.1, A.1.2, A.1.3, usw.

4.3.3.3. Iterative Entwicklung der Anwendungsfallspezifikationen

Die Iterative Entwicklung wird die die Anwendungsfälle priorisieren und die erste Iteration wird die wichtigsten adressieren.

Frühe Iterationen werden den Standardablauf der wichtigsten Anwendungsfälle nur mit den grundlegenden Details erfassen und die Überschriften der hauptsächlichen alternativen Abläufe auflisten.

Spätere Iterationen werden die verbleibenden Anwendungsfälle adressieren, die Schritte der individuellen alternativen Abläufe ausformulieren und wahrscheinlich mehr Details über die individuellen Schritte enthalten.

4.3.4. Ergänzende Anforderungsspezifikation

Dies erfasst die nicht-funktionalen Anforderungen oder Randbedingungen, die für das System gelten. Da Anwendungsfälle von Natur aus inhärent funktional sind, können sie diese Art von Information nicht aufnehmen.

[Anmerkung]Anmerkung

Einige Analytiker plazieren nicht-funktionale Anforderungen in einem Abschnitt am Ende einer jeden Anwendungsfallspezifikation, der die nicht-funktionalen, anwendungsfallbezogenen Anforderungen enthält.

Dies kann einige Probleme verursachen. Der erste Punkt ist, dass nicht-funktionale Anforderungen (zum Beispiel über die Performance) in vielen Anwendungsfällen erscheinen muß und es ist eine schlechte Praxis, Informationen zu replizieren. Zweitens gibt es einige invariable systemweite nicht-funktionale Anforderungen, die ein systemweites Dokument erfordern. Daher meine Präferenz für eine einzige ergänzende Anforderungsdokumentation.

Es sollte ein Abschnitt für jeden Hauptbereich der nicht-funktionalen Anforderungen geben. Die Checkliste von Ian Sommerville in seinem Buch Software Engineering (Third Edition, Addison-Wesley, 1989) ist eine hilfreiche Anleitung.

  • Geschwindigkeit. Prozessorleistung, Anwender-/Ereignis-Antwortzeiten, Bildauffrischungszeiten.

  • Grösse. Hauptspeicher (und mögliche Zwischenspeicher), Plattenkapazität.

  • Leichte Anwendbarkeit. Ausbildungszeit, Stil und Details des Hilfesystems.

  • Zuverlässigkeit. Durchschnittliche Fehlerauftrittszeit, die Nichtverfügbarkeitswahrscheinlichkeit, die Fehlerrate, die Verfügbarkeit.

  • Widerstandsfähigkeit. Wiederanlaufzeit nach einem Fehler, Prozentsatz der Ereignisse, die Fehler verursachen, die Wahrscheinlichkeit von Datenverlust bei einem Fehler.

  • Portabilität. Prozentsatz von zielabhängigem Code/Klassen, Anzahl der Zielsysteme.

Dazu sollten wir Abschnitte über die Umgebung (Temperatur, Feuchtigkeit, Blitzschutz) und Übereinstimmung mit Standards hinzufügen.