Wir dürfen dabei aber nicht nur die monetären Kosten im Auge haben, sondern auch den möglichen Imageschaden, der durch zu spät erkannte Fehler entstehen kann. Man denke nur an große Rückrufaktionen in der Automobilbranche, bei denen manchmal mehrere 100 000 Fahrzeuge aufgrund von Fehlern zurückgerufen werden. Wer kauft schon ein Fahrzeug von einem Hersteller, der in der Presse über fehlerhafte Bremspedale zu einer unschönen Berühmtheit gelangt ist? Solche immensen Schäden sind Extrembeispiele, die aber leider recht häufig vorkommen. Ganz nach dem Motto „Kleinvieh macht auch Mist“ dürfen wir aber auch geringere Imageschäden nicht außer Acht lassen. Bei der Frage, ob mit einem Unternehmen in zukünftigen Projekten zusammengearbeitet werden soll, kann ein schlecht gelaufenes Projekt aus der Vergangenheit entscheidend sein.
Herr Unterhändler: „Sie meinen also, mit der Neuorganisation und Verstärkung unserer Design- und Implementierungsabteilung allein ist es nicht getan?“
Herr Sündenbock: „Mitnichten. Erst wenn wir es schaffen, die Anforderungen an die zu programmierende Software exakt und strukturiert aufzunehmen und uns darüber abzustimmen, können wir die Software auch vernünftig realisieren. Bevor wir überhaupt eine Codezeile beginnen, möchten wir wissen, was wir machen sollen. Im Moment raten wir das eher, als das wir es wissen.“
Herr Unterhändler: „Das heißt, wir sollten mehr Augenmerk auf die Analyse als auf Design und Implementierung legen?“
Herr Sündenbock: „Ja. Zwar möchte ich nicht behaupten, dass wir vollkommen schuldlos an dem Debakel sind, aber immer nur uns die Schuld in die Schuhe zu schieben, ist zu einfach. Selbst die am besten organisierten Spitzenprogrammierer sind machtlos, wenn ihnen niemand sagen kann, was eigentlich gewollt ist. Also plädiere ich dafür, an dieser Stelle zu arbeiten.“
Das eigentliche Problem wird erkannt
Vollkommen richtig erkannt, man kann einfach nicht erwarten, dass die Realisierung immer genau weiß, wie denn die Anforderungen lauten, die sie umsetzen müssen. Denn das ist stark von der Qualität der Basis, auf der die Realsierung aufsetzen kann, abhängig. Und die Basis ist nun einmal das Ergebnis aus der Analyse. Und genau dort gilt es herauszufinden, was eigentlich gewünscht wird. Denn „Wer nicht weiß was er will, braucht sich nicht über das zu wundern, was er bekommt.“ Ja gut, aber sind wir mal ehrlich, eine Analyse wird wohl immer durchgeführt werden. Mal mit größerem und mit geringerem Aufwand. Warum tauchen trotzdem solche Probleme auf?
Ein paar Tage später sitzt Hr. Unterhändler mit Herrn Dr. Hohestier zusammen und bespricht die nächsten Schritte. Herr Unterhändler hat dafür eine Präsentation vorbereitet, die er gerade vorstellt.
„... ich möchte an dieser Stelle nochmal betonen, dass eine gut strukturierte und wohl überlegt durchgeführte Analyse eine erhebliche Kostenersparnis in unseren Projekten bewirken kann.“ (Genau, Preisargumente sind beim Chef immer gut) „Mit den richtigen Analysetechniken und sauberen Analyseergebnissen reduzieren wir die Anzahl der Analysefehler, die, wenn sie unentdeckt bleiben, sehr teuer werden können. Auch reduzieren wir die Anzahl der Fehlentwicklungen, die durch Missverständnisse zwischen den Projektbeteiligten entstehen.“
Dr. Hohestier: „Aber wir haben doch bereits eine Analysephase, bevor es in die Realisierung geht.“
Hr. Unterhändler: „Richtig, allerdings nur sehr rudimentär und mehr dem Prinzip ‚machen wir mal was’ folgend als wirklich durchdacht an die Aufgaben heranzugehen. Folglich leiden die Analyseergebnisse an Anforderungen in nur mäßiger Qualität, zum Teil unnötigen Anforderungen und – dem Hauptproblem – sich ständig ändernde Anforderungen.“
Genau, eine schlecht oder nur unzureichend durchgeführte Analyse hat mit vielen Problemen zu kämpfen. Dabei können sechs Hauptprobleme identifiziert werden:
Dr. Hohestier: „Verstehe, unser Ziel muss es sein, nicht nur zu analysieren, sondern eine professionelle Anforderungsanalyse mit erprobten und den Gegebenheiten angepassten Techniken durchzuführen.“
Herr Unterhändler: „Korrekt. Wir benötigen die richtigen Techniken, um Anforderungen zu ermitteln, zu dokumentieren, zu prüfen und zu verwalten. Zusammengefasst spricht man dabei vom Requirements Engineering.“
Zusammengefasst beinhaltet das Requirements Engineering (RE) alle durchzuführenden Tätigkeiten, um die relevanten Anforderungen zu erhalten (Abb. 3). All die Tätigkeiten können in vier Haupttätigkeiten zusammengefasst werden, die in Abbildung 4 dargestellt werden.
Requirements Engineering ist also mehr, als nur einfach so einen Prosatext zu schreiben. Professionelles Requirements Engineering sorgt dafür, dass alle relevanten Anforderungen aufgedeckt werden und verständlich dokumentiert werden. Dafür werden verschiedenste Mittel eingesetzt, z. B. eine Satzschablone, mit deren Hilfe Anforderungen einfach, schnell und in guter Qualität erzeugt werden können. Außerdem bedient sich das Requirements Engineering Hilfsmitteln, von denen man eigentlich meinen würde, sie werden nur in der Architektur oder dem Design verwendet. Die Rede ist hier von Modellen (z. B. UML-Modellen) [3], [4] als Dokumentationsmittel. Im Requirements Engineering werden natürliche Sprache und Modelle intelligent gemischt, sodass die Anforderungen exakter und besser vor Fehlinterpretationen geschützt sind. Idealerweise erlaubt dies, die Analyseergebnisse nahtlos in ein sauberes Design zu überführen.
Dr. Hohestier: „Sehr schön. Dann lassen Sie uns unverzüglich an das Problem herangehen und unser Requirements Engineering professioneller aufsetzen. Denn Sie haben mich jetzt überzeugt, dass dies ein Meilenstein zum Erfolg unserer Projekte ist. Ach ja und die Neuorganisation der Design- und Entwicklungsabteilung setzen wir erst einmal aus. Damit haben wir schon zu viele Ängste vor Entlassungen geschürt, die wie sich jetzt herausgestellt hat, unbegründet sind.“
Fazit
Natürlich sind Herr Dr. Hohestier, Herr Unterhändler und Herr Sündenbock von uns frei erfundene Charaktere, und Ähnlichkeiten mit lebenden Personen sind gewollt. Falls Ihnen die Situation und die Gespräche bekannt vorkommen, dann leben Sie in unserer realen IT-Welt. Holperige oder schleppend verlaufende Projekte aufgrund mangelhafter Analyse sind keine Seltenheit. In vielen Entwicklungsprojekten wird dem Requirements Engineering, dem professionellen Umgang mit Anforderungen, zu wenig Aufmerksamkeit gewidmet. Welche Auswirkungen das haben kann, haben wir in diesem Artikel gezeigt. Machen Sie sich über das Requirements Engineering in Ihren Projekten Gedanken, denn schließlich kann dies über Erfolg oder Nichterfolg entscheidend sein. Im privaten Umfeld handeln Sie genauso. Bevor Sie sich bei Ihrem Lieblingsitaliener eine Pizza bestellen, überlegen Sie sich doch auch, was ihnen schmecken würde, worauf Sie allergisch reagieren und für welche Zutaten Sie Ihre Frau kritisierend anblicken wird und belassen Ihre Bestellung nicht bei „eine Pizza bitte“. Sobald eine Vorstellung existiert, die enttäuscht werden könnte, macht es Sinn, sie zu artikulieren. Sie wollen schließlich keine negativen Überraschungen erleben. Wenn Sie ein Haus bauen wollen, dann werden Sie auch das Haus von einem Architekten planen lassen, bevor überhaupt das Loch für das Fundament gegraben wird.
Geben Sie also dem Requirements Engineering genügend Spielraum in Ihren Projekten, damit solche extrem negativen Projekterfahrungen bei Ihnen keine Chance haben. Wenn Sie mehr zum Thema Requirements Engineering wissen wollen, besuchen Sie uns auf unserer Webseite unter www.sophist.de. Zusätzlich können Sie zwei Probekapitel aus dem Buch „Requirements-Engineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis.“ erhalten. Senden Sie dafür einfach eine kurze Mail an heureka[at]sophist.de.
Chris Rupp (www.sophist.de/chris.rupp) liefert durch Ihre Publikationen und Vorträge immer wieder wichtige Impulse für die Bereiche Requirements Engineering und Objektorientierung. Erfindungen von Ihr und den SOPHISTen legten die Basis des modernen Requirements Engineering. Chris ist Geschäftsführerin der SOPHIST GmbH.
Carsten Pflug (www.sophist.de/carsten.pflug) ist seit 2002 für die SOPHIST GmbH als Berater und Trainer unterwegs. Thematisch ist er dabei sehr vielseitig einsetzbar. Sei es die Erhebung, Analyse und Dokumentation natürlichsprachiger Anforderungen, die Entwicklung einer Systemarchitektur, die Etablierung und Verbesserung von Requirements-Management-Methoden, den Einsatz der Objektorientierung oder das umfangreiche Gebiet der Modellierungstechniken.
Links & Literatur
- Schwaber, K.; Beedle, M.: „Agile Software Development with Scrum“, Prentice Hall, 2002
- Rupp, C.; Pohl, K.: „Basiswissen Requirements Engineering“, dPunkt Verlag, 2009
- Rupp, C.; Queins, S.; Zengler, B.: „UML 2 glasklar. Praxiswissen für die UML-Modellierung“, Hanser Verlag, 2007
- Object Management Group: www.uml.org.
- Rupp, C. und die SOPHISTen: „Requirements Engineering und Management“, 5. Auflage, Hanser Verlag, 2009
