Requirements Engineering |
Requirements Engineering = Anforderungsfindung, -erhebung und -management oder einfach Analyse genannt
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).
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.
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.
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.
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.
Die Atlantic Systems Guild beherbergt auch das Roberson Pärchen.
GI Fachgruppe Requirements Engineering