Zu viel ist zu viel!

Der Klassiker: ein Entwicklungsunternehmen hat von den Vorzügen des modernen Requirements Engineerings erfahren und möchte davon profitieren. Das Management ist vor allem von der verlockenden Aussicht, durch einen zukünftigen RE-Standard mittelfristig Kosten zu sparen, angetan. Zu diesem RE-Standard gehören ein definierter RE-Prozess, RE-Methoden und eine RE-Toolumgebung. Die Tool-Evaluierung ist ein zeitlich klar begrenzter Vorgang. Welche der bereits definierten Methoden zu verwenden sind, ergibt sich zum Teil im Projektalltag. Der RE-Prozess für ein konkretes Unternehmen muss jedoch erst entwickelt werden. Und hier liegt die Gefahr! Der RE-Prozess kann beliebig komplex werden und sich zur Spielwiese der RE-Beauftragten entwickeln. Unübersichtliche Informationsmodelle, ein aufgeblähtes Änderungsmanagement oder eine kaum handhabbare Menge an Attributen sind Beispiele dieser Problematik. Vor allem den letzten Punkt möchte ich näher erläutern.

Zunächst erscheinen die Fähigkeiten eines RE-Managementwerkzeuges mit seinen schier endlosen Attributierungsmöglichkeiten verlockend. Kontextinformationen werden von Requirements getrennt, funktionale und nicht-funktionale Requirements werden gekennzeichnet. Einzelne Anforderungen können verschiedenen Architekturelementen, aber auch Abstraktionsstufen zugeordnet werden. Test-Level können direkt an der Anforderung gesetzt werden, genauso wie konkrete Testkriterien. Manche Anforderungen erfüllen Normen, manche Anforderungen spiegeln Kundenlasten wider. Sie sehen: Die Menge an Attributen kann gerade zu Beginn rasant anwachsen!

Doch hier beginnen auch die Probleme. Was zunächst sinnvoll erschien, kann im Alltag das gesamte Requirements Engineering lähmen. Es bestehen zwei Möglichkeiten – entweder dauert die Erstellung der Requirements enorm lang, weil viel zu viele Attribute verpflichtend zu befüllen sind oder aber der Requirements Engineer entscheidet nach eigenem Ermessen, welche Attribute er für sinnvoll erachtet und welche nicht. In letzterem Fall kann die mangelhafte Befüllung der Attribute aber zur Folge haben, dass die Arbeit des Requirements Engineerings innerhalb von Metriken, welche unbedingt alle Attribute benötigen, verfälscht wird. Während der Requirements-Autor sich also auf das Wesentliche beschränkt und seine Arbeit vermeintlich erledigt hat, sieht dies aus Managementsicht unter Umständen ganz anders aus!

Nicht zu unterschätzen ist auch das Problem, dass jedes Attribut nach seinen eigenen Regeln zu befüllen ist – und je mehr Attribute der Requirements-Autor befüllen muss, desto komplexer und damit unübersichtlicher wird diese Aufgabe. Nicht selten herrscht dann Uneinigkeit darüber, wie welches Attribut bei einer konkreten Anforderung zu setzen ist – und wenn hier Interpretationsspielraum besteht, hat das Attribut seinen Zweck verfehlt. Ich empfehle also gerade am Beispiel der Attributierung den Mut zur Lücke, denn: weniger ist manchmal mehr!

Zudem ist es enorm wichtig, dass Mitarbeiter mit langjähriger praktischer RE-Erfahrung an der Erstellung des Prozesses arbeiten. Nur diese Erfahrung kann gewährleisten, dass das neue Vorgehen auch effizient auf konkrete Projekte angewandt werden kann. Es ist ein Unterschied, Requirements Engineering in seiner Theorie zu beherrschen, oder bereits an zahlreichen echten Projekten mitgewirkt zu haben.

Abschließend sei noch gesagt, welche wichtige Rolle ein gut geplanter Rollout des neuen RE-Standards spielt. Solange dieser nicht in beherrschbaren, kleinen Schritten erfolgt, werden die Entwicklungsbeteiligten mit hoher Wahrscheinlichkeit direkt zu Beginn eine Abneigung gegen das eigentlich Vorteile bringende neue Vorgehen entwickeln.

Es ist also unerlässlich, dass sich auch das Management eingehend mit dem Thema Requirements Engineering beschäftigt, um nicht nur den theoretischen Kostenvorteil, sondern auch die praktische Anwendbarkeit des neuen RE-Konzepts vor Augen zu haben.

Marcel Klein

Kontaktieren Sie Marcel Klein

Marcel Klein arbeitet bei der HOOD GmbH als Consultant und als Trainer im Bereich Requirements Engineering. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, die Prozessverbesserung sowie die Erstellung von objektorientierten Modellen. Als Trainer hat er sich vor allem auf die gute Formulierung textueller Anforderungen und die nachhaltige Etablierung von Requirements Engineering in einem Unternehmen spezialisiert. Er veröffentlicht regelmäßig zu beiden Themen Artikel und Blogs.