Strukturierte natürliche Sprache zur Beschreibung von Anforderungen

Veröffentlicht auf 17. Mai 2017

Strukturierte Sprache sollte der erste Schritt sein hin zu einer verständlichen Notation von Anforderungen. Viele Werkzeuge unterstützen zudem die Nutzung von Tabellen um mehr Übersicht zu gewinnen.

Die Probleme mit der natürlichen Sprache kommen aus der Mehrdeutigkeit, bei verschachtelten Sätzen, bei Wörtern, durch verschiedene Ausdrucksweisen und der resultierenden Unstrukturiertheit. Die große Flexibilität wird zum Nachteil.

Welche Alternativen gibt es?
* Strukturierte natürliche Sprache (Structured natural language)
Standard Strukturen und Vorlagen unterstützen die fachliche Beschreibung von Anforderungen.
* Design Beschreibungssprachen (Design description languages)
Mittels Programmiersprachen ähnlicher Syntax wird ein oft technisches Model des Systems beschrieben.
* Grafische Notationen
Grafisch lässt sich vieles schneller ausdrücken, Details werden immer noch textuell festgehalten. Beispiele sind UML, Use Case Diagramme, Sequenzdiagramme, Aktivitätsdiagramme usw.
* Mathematische Notationen
Keine Sorge, sie müssen hier keine Gleichungen lösen. Gemeint sind endliche Automaten (Finite state machine), um die Zustände und ihre Übergänge zu visualisieren.

Beispieldarstellung von Anforderungen:
* Wenn -> Dann -> Ansonsten (If -> Then -> Else)
- Jedes Wenn, Dann, Ansonst wird in einer Tabelle als eigene Zeile, als eigene Anforderungsnummer erfasst
- Jede Alternative wird in der Tabelle durch einrücken strukturiert sichtbar gemacht
* Eingeschränkte Terminologie
- Verwendung von MUSS / SOLL / DARF, Verbot von Kann / Könnte / sollte / wenn machbar etc.
- Verbot von Generalisierung: Alle, jede, wenige, viele, schnell, langsam, leicht, schwer, normal usw.
- Verbot von UND / ODER zur Verknüpfung / Schachtelung von Anforderungen, jede bekommt eine eigene Anforderungsnummer!
- Verbot von zu vielen Abkürzungen und Fachbegriffen (einfach, lesbar)
- Nur in einem einheitlichen Glossar definierte Begriffe (benutzerdefiniert, performant etc.) werden verwendet.
* Immer vollständige Beschreibung der Funktion / Entität
* Höher priorisierte Anforderungen werden zuerst genannt.
* Inputs immer mit Quelle beschreiben
* Outputs immer mit Ziel beschreiben
* Abhängigkeiten mit Verweisen lösen
* Vor- und Nachbedingungen nicht vergessen
* Grafische Modelle unterstützen komplexe Sachverhalte

Vergleichen Sie:
* Das Bauteil soll exponieren, wenn das Signal kommt oder wenn ein akustisches Signal kommt, soll es auf eine Bestätigung warten. Ansonsten soll es in den Stromsparmodus gehen.

Wenn das Bauteil ESX betriebsbereit ist,
-	Wenn ein digitales Signal über den Busport kommt,
	-	dann soll das Bauteil ESX in den Ausgangszustand A gehen.
-	Wenn ein Sprachbefehl "Aufwachen" über das Mikrofon wahrgenommen wird,
	-	dann soll es das Startprotokoll an den Betriebsserver über die Ethernet-Schnittstelle senden
		-	und auf Antwort warten,
		-	bevor es in den Ausgangszustand B geht.
-	Ansonsten soll das Bauteil ESX im Stromsparmodus sein.
Ansonsten sollen Signale ignoriert werden.

Bedenken Sie dabei immer die Grundregeln
* "Smaller is better"
* was nicht wie
* nur so detailliert wie notwendig, nicht mehr
* Anforderungen können sich ändern

Welche Form können Sie eindeutiger umsetzen oder schneller ändern?