1 Einleitung

1.1 Motivation zu diesem Buch

Es ist Freitagmittag. Herr Maier denkt bereits genüsslich über seinen baldigen Feierabend nach – da steht sein Chef in der Tür: „Wir haben hier ein neues Thema auf dem Tisch. In zwei Wochen muss das Fachkonzept „Urlaub beantragen“ fertig erstellt sein. Bitte übernehmen Sie das.“ Na super, denkt sich Maier. Und das vor dem Wochenende. Keine Ahnung, was ich da genau machen soll. Jetzt bräuchte man eine Anleitung, wie das konkret funktioniert und die IT-Abteilung auch was damit anfangen kann …

Das ist eine Situation, wie sie in der Praxis sehr häufig in ganz verschiedenen Themengebieten vorkommt. Im Zuge der wachsenden Globalisierung und des enormen Wettbewerbsdrucks sind wir mit ständigen Veränderungen in immer kürzeren Zeiten konfrontiert. Es ist eine große Herausforderung für alle Beteiligten, den Anforderungen gerecht zu werden und dabei die Qualität in ausreichendem Maße sicherzustellen. Das erfahren und erleben wir täglich in unseren Projektaufträgen bei Unternehmen in unterschiedlichen Branchen.

Es ist eine ständige Gratwanderung in der Abwägung zwischen Zeit, Ressourcen und Qualität. In der Regel wird – teils bewusst, teils unbewusst – bereits auf dem kritischen Pfad geplant, ohne jeglichen Puffer. Dabei wissen wir alle aus Erfahrung, dass Projekte niemals zu 100 % von Beginn bis zum Schluss so ablaufen, wie anfangs gedacht. Es passieren immer Dinge auf dem Weg, die nicht absehbar waren, übersehen wurden oder als neue Randbedingung aus aktuellen Gegebenheiten dazu kommen.

Zusätzlich zu alldem wird ein Thema besonders stiefmütterlich behandelt – die Dokumentation. Wir hören oft „das können wir später noch machen“ – wir wissen alle: Später wird in der Regel nichts mehr dokumentiert. Leider fehlen in der Praxis häufig ganze Fachkonzepte für bestehende Programme, oder Fachkonzepte sind nicht einheitlich strukturiert und archiviert. Vorhandene Dokumentationen liegen an verschiedenen („versteckten“) Orten, in unterschiedlichen Formaten. Oft wird nur ein fachliches Grobkonzept erstellt, ein fachliches Feinkonzept – also eine Detaillierung bis auf Datenfeldebene – existiert nicht. Ein Beispiel dazu aus dem Projektalltag:

Ein Unternehmen erteilte den Auftrag, zwei Kernsysteme, die bereits seit über 30 Jahren im Einsatz waren, nachzudokumentieren. Grund dafür war, dass die einzigen beiden Mitarbeiter, die die Systeme noch umfangreich kannten und eine Masse von Informationen dazu im Kopf hatte, in sechs Monaten in Rente gehen würden. Jetzt galt es, soviel wie möglich an Dokumentation zu sichern. Aber jeder kann sich vorstellen, wie eingeschränkt diese Aufgabe zu erfüllen war. Denn die Zeit war beschränkt auf sechs Monate. Es gab nur eine uralte fachliche Dokumentationsbasis. In 30 Jahren wurden massenweise fachliche Änderungen vorgenommen. Und keiner konnte im Detail sagen, wie diese umgesetzt waren. Warum ist das in der Praxis ganz häufig so? Dafür gibt es verschiedene Gründe.

Aus unserer Erfahrung liegt es oft an mangelnder geplanter Zeit und unzureichenden methodischen Kenntnissen. Der Kostenfaktor spielt immer eine entscheidende Rolle. Es wird angenommen, dass ein Projekt Geld sparen könnte, wenn es weniger Zeit in die fachliche Konzeption steckt – ein Irrtum, wie sich in den meisten Fällen herausstellt. Häufig besteht auch ein unterschiedliches Verständnis der Aufgabenabgrenzung zwischen Fachbereich und IT – sprich: Was ist fachliche Beschreibung und was ist IT-Umsetzung?

Der vermeintliche Gedanke, dass alle doch wüssten, worum es geht, beweist sich in der Praxis als absoluter Trugschluss. Aber kaum jemand traut sich zu fragen – denn niemand möchte als unwissend dastehen. Dabei ist die Dokumentation entscheidend wichtig, um im Detail zu klären, was getan werden soll. Niemand kann alles wissen und hat sämtliche relevante Sichtweisen im Fokus. Es braucht die Köpfe und das Know-how aller Beteiligten. Geschieht das nicht, ist ganz viel Raum für Interpretation und genau das wird zum großen Problem.

Das Grobe in der Software funktioniert oft, aber der Teufel steckt im Detail und das bringt häufig hohe zusätzliche Kosten, enorme Zeitverschiebungen, gravierende Mängel in der Qualität, Unzufriedenheit bei den Beteiligten, Akzeptanzprobleme bei den Anwendern und vieles mehr. Jeder von uns kennt das. Um trotz aller dieser Gegebenheiten ein bestmögliches Ergebnis zu erreichen, gibt es praxistaugliche, strukturierte Vorgehensweisen, die durch verschiedene Methoden unterstützt werden. Wir möchten aus unserer Erfahrung einen möglichen Weg aufzeigen, der funktioniert. Das ist Anlass und Motivation zu diesem Buch.

Zum Thema Requirements Engineering und Management gibt es zahlreiche Literatur auf dem Markt, die ausführlich nach verschiedenen Schwerpunkten das Thema analysiert und darstellt. Beispielhaft sei hier genannt das Werk von Chris Rupp u. die SOPHISTen1, das wir, soweit relevant für unser Buch, referenzieren.

Definierte Standards, wie das Vorgehen nach dem International Requirements Engineering Board (IREB), unterstützen zudem eine Vereinheitlichung des Sprachgebrauchs und sorgen für gemeinsames Verständnis in den Begrifflichkeiten. Das ist in jedem Fall hilfreich, wenn wir bedenken, wie viele unterschiedliche Beteiligte es im Rahmen des gesamten Softwareentwicklungsprozesses geben kann, mit ganz unterschiedlichen Kenntnissen, Sichtweisen, Zielsetzungen, Interpretationen der Geschehnisse und so weiter.

„IREB, das International Requirements Engineering Board, ist eine Non-Profit-Organisation und der Entwickler des CPRE(Certified Professional for Requirements Engineering)-Zertifizierungskonzepts. Die Boardmitglieder sind unabhängige und international anerkannte Experten aus Industrie, Beratung, Forschung und Lehre. Das Board wurde 2006 gegründet. Seine Mitglieder haben sich mit der Vision zusammengeschlossen, Requirements Engineering auf ein professionelles Fundament zu stellen, um dieser Disziplin den Stellenwert und die Ausprägung zu geben, die ihrem Mehrwert für die Industrie entspricht. IREB ist heute zum weltweit anerkannten Expertengremium für die Personenzertifizierung von Fachkräften im Requirements Engineering geworden“2.

Unser Buch konzentriert sich speziell auf ein konkretes operatives Vorgehen – eine Handlungsanleitung zum modellbasierten Requirements Engineering. Inhaltlicher Schwerpunkt ist das methodische Vorgehen, basierend auf den praktischen Erfahrungen der Autoren. Es gibt keinen besonderen Branchenbezug.

1.2 Zielgruppen des Buchs

Alle Leser sind herzlich eingeladen, die sich für unser Buch interessieren!

Besonders spannend ist es für alle Beteiligten, die das Fachkonzept erstellen bzw. es als Basis für die weiterführenden Aufgaben im Rahmen der Softwareentwicklung verwenden. Das betrifft Fachabteilungen, IT-Bereiche, Testverantwortliche, aber auch Projektmanager und organisatorische Bereiche, die aus dem Umfang der Fachkonzeption die entsprechenden Zeit-, Budget- und Ressourcenplanungen ableiten und umsetzen.

Die namentliche Definition der einzelnen Konzepte, Rollen und Aufgaben sind nach unserer Erfahrung in den Unternehmen sehr unterschiedlich. Am Ende ist aber nicht entscheidend, ob es „Fachliche Beschreibung“, „Fachliches Feinkonzept“ oder anders heißt. Egal, ob die Rolle Anforderungsmanager, Koordinator oder anders heißt, es kommt auf das sinnvolle methodische Vorgehen im Rahmen des gesamten Softwareentwicklungsprozesses und die Richtigkeit und Vollständigkeit der Inhalte an, um am Ende das Ergebnis zu erzielen, das vom Auftraggeber angefordert ist – in Qualität, Zeit und Budget.

1.3 Gliederung des Buchs

Der „rote Faden“ dieses Buchs zeigt einen praktischen Weg von der Idee zur fachlichen Beschreibung mit Hilfe der Methoden im Requirements Engineering – differenziert betrachtet nach klassischem und agilem Vorgehen. Es wird erläutert, wie durch das modellbasierte Requirements Engineering mit Hilfe von UML eine strukturierte Dokumentation erarbeitet wird, die Anforderungen nachvollziehbar macht und die Basis zur gezielten Umsetzung liefert.

Zum praktischen Verständnis verwenden wir das durchgängige Beispiel „Urlaubsantrag“. Darauf kommen wir immer wieder zurück und verdeutlichen das methodische Vorgehen.

Im ersten Teil beschäftigen wir uns mit dem gedanklichen Weg von der Idee hin zu weiter detaillierten Anforderungen – mit methodischer Unterstützung. Es wird das klassische Requirements Engineering kurz vorgestellt und einer der wichtigsten Ergebnistypen, das Fachkonzept, detailliert erläutert. Das konkrete Vorgehen ist in den einzelnen Kapiteln mit Schritten versehen. Am Ende jedes Schritts ist das Ergebnis formuliert, die in der Zusammenfassung nochmals im Sinne einer Checkliste aufgeführt sind. Daran anschließend wird das Requirements Engineering in agilen Projektkontexten betrachtet.

Der zweite Teil beschreibt eine Methodik, wie das Requirements Engineering durch modellbasierte Ansätze unterstützt und professionalisiert werden kann. Dabei wird unter anderem die Modellierungssprache UML verwendet. Gezeigt werden auch die vielfältigen Einsatzmöglichkeiten von Modellierungswerkzeugen für ein modellbasiertes Requirements Engineering.

In diesem zweiten Teil kommen verstärkt Programmierbeispiele zum Einsatz. Der Leser, der mit dem Thema Programmierung nicht vertraut ist, kann diese Programmierabschnitte bedenkenlos überspringen. Leser, die sich mit der Programmiersprache C# gut auskennen, mögen die teilweise naive Implementierung entschuldigen, aber bei dem Beispielcode geht es darum, die Ideen zu verdeutlichen und die dargestellte Programmierung sollte eher als Pseudocode verstanden werden, denn als perfekte C#-Implementierung.

Abgeleitet daraus erfolgt in einem dritten Teil die Betrachtung des Nutzens für den Test bzw. das Test Engineering. Es werden die grundlegenden Testbegriffe und Teststufen erläutert und diese mit dem modellbasierten Requirements Engineering verbunden. Daraus ergeben sich dann elegante Möglichkeiten, aus fachlichen Modellen Testfälle automatisiert zu generieren.

Ein weiteres wichtiges Kapitel beschäftigt sich mit dem Aufbau der Projektstruktur, dem Teamaufbau und den notwendigen Rollen, die beim modellbasierten Requirements Engineering erforderlich sind. In diesem Zusammenhang wird auch betrachtet, welche Rahmenbedingungen für dieses Vorgehen geschaffen werden müssen, beispielsweise die Unterstützung durch das Management oder die ausreichende Vermittlung von entsprechenden methodischen Kenntnissen für die Beteiligten.

Modellbasiertes Requirements Engineering ist ein spannendes Thema, dass die Herausforderungen unserer heutigen Zeit in der Softwareentwicklung aufgreift und einen konstruktiven Weg zeigt, damit effizient umzugehen und gleichermaßen das Ziel einer hohen Qualität und Zufriedenheit bei den Beteiligten zu verfolgen. Lassen Sie sich ein auf neue Wege – es lohnt sich, das können wir aus eigener Erfahrung berichten.

1.4 Danksagungen

Die Autoren sprechen allen Mitwirkenden an diesem Buch ihren herzlichen Dank aus.

Insbesondere bedanke ich, Alexander Ritter, mich sehr bei meiner Frau Yvette für die Unterstützung und die Verbesserungsvorschläge, während ich an meinen Texten schrieb. Nicht zuletzt wurde während dieser Zeit unser erstes Kind geboren – wofür ich ihr ebenfalls sehr zu Dank verpflichtet bin.

Dank gilt insbesondere unseren vier Reviewern, ohne deren Hinweise dieses Buch nicht diese Kohärenz erhalten hätte, die bei drei Autoren zwangsläufig schnell verloren geht: Birgit Bruchmüller, Sven Dockter, Stefan Petersen und Heinz Scheeres.3

Dank auch an die Unterstützung durch den entwickler.press-Verlag, hier namentlich erwähnt, als Stellvertreterin für ihre Kollegen und Kolleginnen: Martina Raschke. Ohne ihren Einsatz wären wir gar nicht auf die Idee gekommen, dieses Buch zu publizieren.

Die Autoren erreichen Sie unter der E-Mail Adresse: mReqEng@gmx.de.

---