Die einfachste Form, Anforderungen an ein System zu dokumentieren, ist die natürliche Sprache. Lies weiter, um zu erfahren, wie Du Produktanforderungen narrensicher dokumentierst.

Der Transformationsprozess

Im letzten Newsletter hatte ich dir den Transformationsprozess vorgestellt: Von der Realität, dem zu entwickelnden Produkt, hin zum sprachlichen Ausdruck, der Anforderungsspezifikation.

Der sprachliche Ausdruck

Stell Dir vor, Du hast in Deinem Projekt die Aufgabe, die Anforderungen an unseren bekannten Kaffeevollautomaten in natürlicher Sprache zu dokumentieren. Mit natürlicher Sprache meine ich die Sprache, mit der wir im Alltag kommunizieren. Du denkst Dir vielleicht, das kann doch nicht so schwer sein, natürliche Sprache kann ich, da bin ich Experte.

Zum Beispiel dokumentierst Du eine Anforderung so:

„Der Kaffeevollautomat soll Kaffee brühen.“

Damit ist die Aufgabe doch erledigt, oder?

Leider nein, die Aufgabe ist nicht erledigt. Die Anforderung ist nicht eindeutig beschrieben. Es fehlen wichtige Angaben:

  • Wann soll der Kaffee gebrüht werden? Sofort?
  • Wer oder was löst den Brühvorgang aus?
  • Gibt es nur eine Sorte Kaffee?
  • In welches Gefäß wird der Kaffee gefüllt?
  • Wann ist der Brühvorgang fertig?
  • Wieviel Kaffee soll gebrüht werden?

Es gibt dabei einige Regeln zu beachten, die ich nachfolgend beschreiben werde.

Was ist bei der Anwendung eines natürlichsprachlichen Arbeitsproduktes zu beachten?

Die natürliche gesprochene und auch geschriebene Sprache dient uns bereits seit jeher als entscheidendes Mittel zur Kommunikation von Anforderungen an Systeme.

Die Nutzung der natürlichen Sprache beim Formulieren von RE-Arbeitsprodukten hat zahlreiche Vorteile. Als besonders ausdrucksstarkes und flexibles Kommunikationsmittel, kann die natürliche Sprache fast jede denkbare Anforderung in allen ihren Aspekten ausdrücken. Als weiterer Vorteil gilt, dass wir die natürliche Sprache von klein auf im Alltag verwenden und in der Schule vermittelt bekommen, sodass bei Verwendung der natürlichen Sprache für das Lesen und Verstehen von Anforderungen keine spezielle Ausbildung erforderlich ist.

Doch wie wir alle wissen – so ist das Leben – alles hat zwei Seiten. So bringt die Nutzung der natürlichen Sprache auch Probleme mit sich. Als Schwächen können gesehen werden, dass Anforderungsdokumentationen in natürlicher Sprache:

  • Nicht (immer) eindeutig
  • Bei komplexen Sachverhalten nicht ausreichend

sind.

Das Ziel einer Anforderungsdokumentation sollte sein, die Anforderungen so zusammenzustellen, dass sie unabhängig vom Ersteller (und vom Umsetzer) verständlich sind. Häufig treten jedoch Missverständnisse durch die sprachlichen Defekte auf.

Wie Du Produktanforderungen narrensicher dokumentierst

Was sind sprachliche Defekte?

Wenn wir in natürlicher Sprache kommunizieren, können wir den Effekt der sprachlichen Defekte beobachten. Einen (systematischen) Ansatz hierzu bietet das NLP (Neurolinguistische Programmieren), welches Modelle menschlicher Kommunikation und Ausdrucksweise erstellt und verfeinert. Maßgeblich daran

beteiligt waren der Psychologe und Linguistikprofessor John Grinder und der Informatiker

und Gestalttherapeut Richard Bandler. Ein Ergebnis war das Metamodell der natürlichen Sprache.

Menschen kommunizieren miteinander unter Einsatz von Sprache. Unser Bild von der Welt drücken wir mit natürlicher Sprache aus. Die dabei entstehenden Effekte werden in der Grundlagenarbeit von Bandler und Grinder erklärt. Sie identifizierten drei universelle Gestaltungsprozesse:

  • Tilgung (engl. Deletion):
    Tilgung ist ein Prozess, durch den wir unsere Aufmerksamkeit selektiv bestimmten Dimensionen unserer Erfahrung zuwenden und andere ausschließen. Tilgung reduziert die Welt auf Ausmaße, mit denen wir umgehen können.
  • Generalisierung (engl. Generalization):
    Generalisierung ist der Prozess, durch den Elemente oder Teile eines persönlichen Modells von der ursprünglichen Erfahrung abgelöst werden, um dann die gesamte Kategorie, von der diese Erfahrung ein Beispiel darstellt, zu verkörpern.
  • Verzerrung (engl. Distortion):
    Verzerrung ist der Prozess, der es uns ermöglicht, in unserer Erfahrung sensorischer Einzelheiten eine Umgestaltung vorzunehmen.

Das ist vielleicht erstmal schwer verständlich. Deshalb hier die Anforderungen an einen Geldautomaten

Ein Beispiel für eine Tilgung:

„Die Auszahlungsmöglichkeit soll überprüft und die Auszahlung verbucht werden“

Wir könnten uns fragen:

  • Überprüfen: Wer überprüft? Was wird überprüft? Nach welchen Regeln wird überprüft? Wann wird überprüft? Wie?
  • Verbuchen: Wer verbucht? Was wird verbucht? Wann wird es verbucht? Wie?

Ein Beispiel für eine Generalisierung:

„Jede Auszahlung soll für die Rückverfolgbarkeit zusätzlich mit einem Zeitstempel etikettiert werden“.

Wir können uns fragen: „Wirklich für jede Auszahlung?“

Und noch ein Beispiel für eine Verzerrung:

„Der Nutzer muss zunächst sein Login und dann sein Passwort eingeben“.

Wir könnten uns fragen:

  • Was führt zur Annahme, dass diese Reihenfolgen notwendig sind?
  • Was würde sich bei einer anderen Reihenfolge oder Verlassen einer Einschränkung ändern?

Die gute Nachricht ist, für diese Herausforderungen beim Schreiben von Anforderungen gibt es Regeln, die es uns ermöglichen, diese Probleme bis zu einem gewissen Grad zu verringern und bekannte Hürden zu umgehen.

Requirements Engineers können viele potenzielle Missverständnisse vermeiden, durch Befolgung einfacher Regeln:

  • Schreibe kurze und gut strukturierte Sätze.
  • Definiere einheitliche Terminologien und verwende diese konsequent.
  • Vermeide ungenaue oder mehrdeutige Begriffe und Phrasen.
  • Kenne und vermeide Fallstricke wie:
  • unvollständige Beschreibungen (z.B. „testen“, Wer? Was? Wie? Wo? Wann?),
  • unspezifische Substantive (z.B. „Daten sollen dem Nutzer auf dem Terminal angezeigt werden“, Welche Daten? Welchem Nutzer? Auf welchem Terminal?),
  • unvollständige Bedingungen (z.B. „Daten müssen eingegeben werden“, Wer? Was? Wie? Wann? Nach welchen Regeln?),
  • unvollständige Vergleiche (z.B. „wenn…dann“, „falls“, „im Falle von“, „abhängig von“, …).
  • Vermeide folgende Fallstricke (Siehe Metamodell der Sprache):
  • passive Formulierung (Verzicht auf aussagefähiges Subjektiv),
  • Universalquantoren (wie „alle“ oder „nie“)
  • Nominalisierungen (d.h. von einem Verb abgeleitete Substantive, z.B. „Authentifizierung“)

Ausblick

Im nächsten Newsletter stelle ich eine Satzschablone vor. Mit Hilfe dieser Satzschablone bekommst Du ein ideales Hilfsmittel zur Erstellung von natürlichsprachlichen Anforderungen.

Zusammenfassung

Die Verwendung von natürlicher Sprache zur Festlegung von Arbeitsanforderungen ist eine einfache Möglichkeit, Anforderungen zu dokumentieren, nur bringt dieses nicht nur Vorteile, sondern auch Nachteile mit sich. Um die Nachteile so gering wie möglich zu halten, sollten einfache Regeln beachtet werden. So können die Schwächen der natürlichsprachlichen Arbeitsprodukte überwunden werden.

Zertifizierung als Certified Professional for Requirements Engineering CPRE

Informationen und Voraussetzungen zur Zertifizierungsprüfung findest Du auf der Seite des IREB hier.

Warum bekomme ich diesen Newsletter?

Wir hatten in der Vergangenheit Kontakt und Du hattest Interesse an weiteren Informationen der Projektstart GmbH. Falls Du keine weiteren Informationen wünschst, kannst Du Dich gerne vom Newsletter abmelden, aber das wäre sehr schade.

Viele erfolgreiche Projekte wünscht

Projektstart GmbH

Gerhard Wirnsberger

https://www.projektstart.com

schreibe mir eine email:

gerhard@projektstart.com

Literaturtipp:

Bei den folgenden Links handelt es sich um Provisions-Links (Affiliate-Links). Erfolgt über einen solchen Link eine Bestellung, erhält die Projektstart GmbH eine Provision. Für den Käufer entstehen dadurch keine Mehrkosten. Alle Preise inkl. MwSt. und ggf. zuzüglich Versandkosten. Details zu den Angeboten finden Sie auf der jeweiligen Webseite. Durch Klicken auf die Affiliate-Links wirst du zu Amazon weitergeleitet.

Buchempfehlungen
Requirements Engineering und Management

Basiswissen Requirements Engineering
Klaus Pohl/ Chris Rupp