Falle 2: Faule Kompromisse und Falle 3: Designfehler bei Geschäftsmodellen (Gutes Anforderungsmanagement, Teil 2)

Im 2. Artikel meiner Reihe stelle ich Falle 2: Faule Kompromisse sowie Falle 3: Designfehler bei Geschäftsmodellen vor. Thematisch passt der Aspekt der „Mehrdeutigkeiten in Anforderungsdokumenten“ gut den Kontext der beiden „Fallen“, sodass ich auch dieses Thema in diesem Artikel aufgreife.

Falle 2: Faule Kompromisse

Bei der Anforderungserhebung ist es unerlässlich die Wünsche der Stakeholder zu ermitteln und genau zu kennen. In einigen Fällen unterscheiden sich die Anforderungen der unterschiedlichen Stakeholder. Wenn dies der Fall ist, darf sich der Requirements Engineer (RE) auf keine „faulen“ Kompromisse einlassen. Um die Bedeutung eines „faulen“ Kompromisses zu veranschaulichen, stelle ich Ihnen folgendes vereinfachtes Beispiel vor:

Stakeholder A:

  • Bei einem Fehler muss das System anhalten.

Stakeholder B

  • Bei einem Fehler muss das System neustarten.

Requirements Engineer einigt sich mit A und B auf

  • Im Fehlerfall wird eine Ausnahmeroutine veranlasst.

Spätestens der Entwickler wird sich bei der Umsetzung fragen, was genau bei dieser sog. Ausnahmeroutine veranlasst werden soll. Schlimmstenfalls implementiert der Entwickler die Ausnahmeroutine, wie er sich diese vorstellt.

Mehrdeutigkeit in einem Anforderungsdokument

Nach de Marco steht eine Mehrdeutigkeit im Anforderungsdokument oft für einen Konflikt bei den Stakeholdern.

Eine Anforderung ist dann mehrdeutig, wenn sie innerhalb eines Kontextes mehrere Interpretationsmöglichkeiten aufweist. Es gibt unterschiedliche Mehrdeutigkeiten, die für ein Anforderungsdokument von Bedeutung sind:

Vagheit/Verallgemeinerung 

Eine Anforderung ist so unpräzise formuliert, dass verschiedene Interpretationen möglich sind. Innerhalb der Mehrdeutigkeit „Vagheit“ gibt es einige „Unterformen“ wie z.B.

  • Unzulässige Universalquantoren (Generalisierungsworte, Verallgemeinerungsformulierungen; Beispiel: Der Benutzer soll…(jeder Benutzer?), die Daten (welche Daten, alle?)
  • Unvollständig spezifizierte Bedingungen (Beispiel: Das System soll performanter sein als das Altsystem – Was bedeutet perfromanter?)
  • Nominalisierte Prozesse (abstrakte Prozesse, die unkonkret sind; Beispiel: Es sollen Datenverluste erkannt werden – Welche genau? Wie stellt man diese fest?)
  • Funktionsverbgefüge (Beispiel: Das System muss die Berechnung der Statistiken innerhalb einer Stunde zu Ende bringen – Was passiert, wenn dies nicht erfüllt ist?)

Solche Doppeldeutigkeiten lassen sich i.d.R. durch Stellen der sog. W-Fragen identifizieren: Wer, Was, Welche, Wie (viel), Wann, Weshalb?

Lexikalische Mehrdeutigkeit
Ein Satz hat verschiedene, in Beziehung stehende Bedeutungen. Beispiel: Ich kann die Mutter nicht finden.

Syntaktische Mehrdeutigkeit
Der Satzbau führt zu verschiedenen Interpretationen. Beispiel: Die Milch trinkt die Katze.

Semantische Mehrdeutigkeit
Das Auto kann verschiedene Farben haben (s. auch Falle 3).

Wie wir sehen, können verschiedenste Arten von Mehrdeutigkeiten in einem Anforderungsdokument auftauchen. Der RE kann Mehrdeutigkeiten aus dem Anforderungsdokument „verbannen“ – dafür gibt es unterschiedliche Hilfen, die in Falle 5 und 6 näher dargestellt werden.

Falle 3: Designfehler bei Geschäftsobjekten

Wie bereits beschrieben (siehe Falle 2), ist es für den RE unerlässlich die Anforderungen aller Stakeholder zu kennen und diese „richtig“ zu verstehen. Wozu unterschiedliche Auffassungen das Satzes „das Auto kann verschiedene Farben haben“ führen können, zeigt das Beispiel:

Designfehler bei Geschaeftsobjekten


In unserem Beispiel verstand der RE: Ein Auto soll verschiedene Farben haben. Der Kunde wollte aber, dass ein Auto verschiedene Farben haben kann.
Diese Art von Fehlern hat einen durchaus ernsten Hintergrund. Im ersten Fall hat das Objekt Auto ein Attribut „Farbe“, im zweiten Fall gibt es eine 1:n-Beziehung zu Farbe.

UML-Diagramm


Es geht um die Kardinalität zwischen Geschäftsobjekten. Solche Fehler ziehen sich durch alle Schichten der Software:

  • Von der Datenbank über
  • die Service-Schicht bis hin
  • zur Benutzeroberfläche.

Es geht hierbei darum, Geschäftsobjekte und deren Beziehungen untereinander zu identifizieren. Das ist Thema des sog. Domaine Driven Designs und sollte Bestandteil des REs sein, denn Fehler, die hierbei gemacht werden, erfordern entweder hohe Korrekturkosten oder es geht auf Kosten der Software-Qualität.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.