Requirements Engineering

Requirements Engineering = Anforderungsfindung, -erhebung und -management oder einfach Analyse genannt

Anforderungsfindung

In der Anforderungsfindung gehen wir nicht davon aus, dass wir bereits wissen was wir wollen. Wer glaubt alles zu wissen, weiß nicht, wie wenig er überhaupt weiß. In diesem Zusammenhang möchte ich auf den sehr unterhaltsamen Artikel "Phillip G. Armour, The Five Orders of Ignorance - Viewing software development as knowledge acquisition and ignorance reduction, Communications of the ACM, October 2000/Vol. 43, No. 10" hinweisen. Und es stimmt: Softwareentwicklung ist Wissensakquisition. Ungünstigerweise sind wir erst wirklicher Experte auf dem jeweiligen Gebiet, wenn die Software fertig ist. Wir müssen diesen Sachverhalt in unserem Vorgehen berücksichtigen (z.B. durch kleine Iterationszyklen oder Prototyping).

Anforderungserhebung

Die Anforderungen sollen dem Softwareentwickler sagen, was er zu tun hat. Sie sind damit ein Kommunikationsmedium zwischen Menschen. In der Kommunikationstheorie spricht man auch von einem Sender und Empfänger. Während der Kommunikation wird das gesprochene Wort sowohl vom Sender als auch vom Empfänger interpretiert.

Woher weiß ich als Sender, dass der Empfänger meine gesendeten Daten "richtig" empfangen und interpretiert hat? Gar nicht! Ich kann mich nur durch weiteres Senden und Empfangen vergewissern. Sie können z.B. einen geschilderten Sachverhalt von Ihrem Gegenüber wiederholen lassen.

Ein guter Analyseprozess erleichtert dem Sender das Senden und dem Empfänger das Empfangen. Außerdem sind Störungen und Fehler im Kommunikationsprozess zu vermeiden.

Welche Art der Kommunikation ist für einen Analyseprozess optimal? Dies hängt von den beteiligten Personen, deren Anzahl, Hintergrundwissen und Erfahrungen ab. Auch die zu kommunizierenden Sachverhalte selbst haben großen Einfluss.

Es gibt ein ganzes Sortiment von verschiedenen Sprachen, die Sie einsetzen können. Da ist zum einen die natürliche Sprache wie z.B. Deutsch. Im Gegensatz dazu gibt es die formalen Sprachen. Wenn sie einen Sachverhalt in dieser Sprache schildern, erstellen Sie ein formales Modell. Zu den formalen Sprachen zählt auch die Unified Modeling Language der OMG.

Natürliche Sprache

Das Problem bei Verwendung natürlicher Sprache ist die mangelnde Genauigkeit. Es gibt prinzipiell zwei Ansätze, dieses Problem zu lindern. Zum einen kann durch Regeln die natürliche Sprache etwas formalisieren. Die Grenzen zwischen natürlicher und formaler Sprache sind fließend. Zu viele Regeln machen die Sprache unnatürlich. Sprachschablonen, Definitionen aller Fachbegriffe und Prozesswort-Listen helfen, gute Anforderungen zu bestimmen.

Die andere Möglichkeit ist eine systematische Verwendung von Beispielen. Das Beispiel hilft nicht nur dem Empfänger, sondern auch dem Sender, eine Anforderung zu verifizieren und zu verstehen.

Formale Sprachen

In diesem Zusammenhang spricht man auch von Anforderungsmodellierung. Eine formale Sprache besteht aus einer Menge von erlaubten Elementen, die sich nach bestimmten Regeln kombinieren lassen. In diesem Bereich findet man, neben dem traditionellen SA/SD, die verschiedenen Diagramtypen der UML wie Klassendiagramme, Zustandsdiagramme und Aktivitätsdiagramme. Die ereignisgesteuerten Prozessketten des ARIS Toolsets sind, wie die UML Aktivitätsdiagramme, Varianten der Petri-Netze. Diese Modell-Typen verwendet man auch für die Geschäftsprozessmodellierung.

Die Verwendung von Modellen in der Analyse ist schon in Ordnung. Stellen Sie nur sicher, dass diese Sprache auch jedem geläufig ist. Wenn Sie Ihrem Anforderungssteller ein Klassendiagramm zeigen und fragen: "Ist das in Ordnung so?", dann mag er von Ihren Modellierungsfähigkeiten beeindruckt sein. Der eigentlichen Sache ist es aber nur dienlich, wenn der Anforderungssteller das Analysemodell verstehen und verantworten kann. Sonst hätten Sie genauso gut alles in Japanisch schreiben können, das ist sogar noch hübscher als ein Klassendiagramm.

Egal was für einen Modell-Typen Sie verwenden: Achten Sie auf eine gute Dokumentation der Modelle und auf die Strukturierung. Die Strukturierung ist das Skelett Ihrer Anforderungsmenge. Sie bestimmt, wie gut Sie sich in der Anforderungsmenge bewegen können. Über die Struktur finden Anfänger den Einstieg.

Literatur

Für die Anforderungsmodellierung gibt es genügend Literatur. Bei den natürlichsprachlichen Dingen sieht es dagegen dünn aus. Die Suchbegriffe "natural language requirements" liefern bei Google einige interessante Abhandlungen zu diesem Thema.

Suzanne Robertson, James Robertson: Mastering the Requirements Process, Addison Wesley

Chris Rupp: Requirements-Engineering und -Management, Hanser

Diese beiden Bücher kann ich Ihnen weiterempfehlen. Das Werk von Robertson ist etwas theoretischer. Theorie ist wichtig, aber leider kommt in beiden Werken die Praxis etwas zu kurz. Keins der Bücher enthält ein vollständiges kleines Beispiel. Hinter beiden Werken stehen Consulting Dienstleistungen und Produkte. Man ist daran interessiert, eine Aura des Geheimnisvollen zu schaffen. Dabei ist gutes Requirements Engineering wirklich einfach.

Links

Die Atlantic Systems Guild beherbergt auch das Roberson Pärchen.

GI Fachgruppe Requirements Engineering

[Zurück]