Dies ist der zweite Teil der Miniserie “Requirements Modeling”. In diesem Artikel schaffen wir ein gemeinsames Verständnis dafür, was Modellierung im Allgemeinen und ein Anforderungsmodell im Besonderen ist.
Modelle im Allgemeinen
Modelle werden überall im Leben eingesetzt, nicht nur für Systeme und Anforderungen. Sie werden allgemein als “kleine Kopie von etwas, das einige Merkmale des Originals aufweist” betrachtet. Da kommen einem physische Objekte wie Schiffsmodelle in den Sinn.
Es gibt auch formellere Definitionen eines Modells (Was ist ein Modell? von Thomas Kühne). Doch widmen wir uns zunächst einem wichtigeren Aspekt: Bereits mit der obigen einfachen Definition stellen alle Anforderungen ein Modell des zu bauenden Produkts dar.
Anforderungen werden immer modelliert
Anforderungen sind eine pragmatische Beschreibung des zu bauenden Systems. Sie sollten sich auf das Problem konzentrieren, das dieses System löst (und nicht auf die spezifische Implementierung) und sind daher nur eine Teilbeschreibung. Aber per Definition ist dies ein Modell, auch wenn es nur ein paar Zeilen einfachem Text sind.
Ein Modell hat üblicherweise eine Modellierungssprache, die textuell oder grafisch sein kann. Und wieder, mit ein paar Zeilen einfachem Text, ist die Modellierungssprache... Englisch.
Im Kontext des Requirements-Engineerings stellt sich also nicht die Frage, ob modelliert wird oder nicht: Wir modellieren immer. Stattdessen stellen sich die Fragen:
- Auf welcher Ebene die Modellierungssprache das Modell strukturiert.
- Welche Modellierungssprache verwenden wir?
- Wie förmlich soll das Modell sein?
An diesem Punkt sind wir bereit für eine einfache Definition:
Ein Anforderungsmodell ist eine strukturierte Darstellung von Anforderungen, die eine spezifische Modellierungssprache verwendet.
Schauen wir uns die drei Fragen einzeln an.
Modellierungsgrad
Modellierung kann auf breiter Ebene auf drei Ebenen formeller angewendet werden:
Spezifikationsstufe: Die Struktur der Spezifikation als Ganzes kann formalisiert werden. Ein triviales, aber nützliches Beispiel hierfür ist die Kapitelstruktur. Diese wurde sogar standardisiert: IEEE 29148-2011 (formal nach IEEE 830-1998) liefert mögliche Gliederungsstrukturen für Systemanforderungsspezifikationen (SRS).
Anforderungsstufe: Die einzelnen Anforderungen können als Ganzes Teil eines Anforderungsmodells werden, indem sie mit Metadaten angereichert werden. Beispielsweise könnte eine Anforderung als funktional oder nicht funktional klassifiziert werden. Ein ausgefeilteres Klassifikationsschema wurde vorgeschlagen von Cimatti oder Gunter.
Anforderungstext-Ebene: Die tatsächlichen Anforderungen Text kann auch modelliert werden, beispielsweise durch die Verwendung von Textvorlagen. Einige der bekannteren werden von der Sophist Group bereitgestellt (Master-Schablonen, Deutsch), aber es gibt noch viele andere zur Auswahl.
Modellierungssprachen
Wenn das Thema Anforderungsmodellierung oder Systemmodellierung angesprochen wird, denken die Leute meist an grafische Sprachen wie UML oder SysML. Und tatsächlich können diese auch verwendet werden.
Grafische Sprachen nutzen die Tatsache aus, dass Menschen unglaublich gut darin sind, visualisierte Informationen zu erfassen. Es ist jedoch wichtig zu beachten, dass die Modelle typischerweise viele Informationen enthalten, die nicht auf den Bildern dargestellt sind. Die Bilder dienen als Orientierungskarte, die hilft, zusätzliche Informationen zu finden. Diese Informationen finden sich normalerweise in den Tabellen, die die Bilder begleiten.
Formalitätsgrade
Unabhängig davon, ob eine textuelle oder grafische Darstellung verwendet wird, können die Anforderungen recht informell oder extrem formalisiert sein.
Umgangssprache (oder jede andere natürliche Sprache) ist informell, kann aber durch Textvorlagen formeller gestaltet werden. Je nach Raffinesse der Werkzeuge können recht viele Informationen automatisch aus dem Text extrahiert werden (z. B. automatische Glossarverwaltung).
Die Extreme sind spezifikationssprachen, die textuell sind, aber eher Programmiersprachen ähneln als Text. Beispiele für diese Kategorie sind Event-B oder Z. Diese Sprachen haben ein so hohes Maß an Formalität, dass bestimmte Eigenschaften der Beschreibung mathematisch bewiesen werden können.
Ähnliches gilt für grafische Sprachen. Auf dem informellen Spektrum befinden sich “Kästchen und Linien”, die ad hoc gezeichnet werden. Aber auch diese können großartige Kommunikationswerkzeuge sein. Als nächstes folgt UML, das “nur als Zeichnung” verwendet wird, d. h. nicht Teil eines größeren Modells.
Die Modellierung des Gesamtsystems ist formaler als der bisherige Ansatz und erlaubt die Überprüfung der Modellintegrität. Und natürlich gibt es Modellierungssprachen, die formeller sind als UML und SysML, wie Petri-Netze oder der Scade-Dialekt der Lustre-Sprache.
Fazit
Auch textuelle Anforderungen stellen ein Anforderungsmodell dar. Die Fragen, die man sich also stellen muss, sind:
- Sollte ich zu einer grafischen Darstellung meiner Anforderungen wechseln?
- Sollte ich meine textlichen Anforderungen formeller gestalten?
- Sollte ich die Modellierung auf der Ebene der Spezifikation, der Anforderungen oder des Anforderungstextes anwenden?
Bevor diese Fragen in Teil vier dieser Reihe beantwortet werden, werden wir uns im nächsten Artikel mit den Vor- und Nachteilen einer formelleren Anforderungsmodellierung befassen.
