Die Schildbürger als Requirements-Engineers?

Requirements-Engineering ist eine vergleichsweise junge Disziplin. 1968 war der ein oder andere SOPHIST noch nicht einmal in den Kinderschuhen, als auf der Nato Software Konferenz in Garmisch der Begriff „Software Engineering“ geprägt wurde. Die eigentliche Geburtsstunde des Requirements-Engineerings [1].

Das Jahr 1968 ist leider etwas spät für die Schildbürger [2],  den Bewohnern des dummheitenumwobenen Dorfes Schilda. Zwar hätten die Schildbürger ganz dringend eine Schulung zum Certified Professional for Requirements Engineer besuchen sollen [3], doch im Mittelalter war ihnen dies leider nicht vergönnt. So steckten sie sehr viel Eifer und Ideenreichtum in Projekte, wie es sie sicherlich auch noch heutzutage hin und wieder gibt. Nämlich Projekte, in denen man sich hin und wieder fragt, was ist denn eigentlich hier los? Diese Frage nehmen wir zum Anlass für eine kleine Blogserie zum Schmunzeln. Thema: Die Schildbürger und warum ihnen Requirements-Engineering gut getan hätte.

Als Weisheit zu Dummheit wurde

Die Schildbürger waren einst berühmt für ihre Weisheit. Doch das kann sehr anstrengend sein. Jeder will was von einem und man muss jedem tagein tagaus mit Rat und Tat zur Seite stehen. Da dachten sich die Schildbürger – nein. Und so wurden sie berühmt für ihre Dummheit (die aus Klugheit resultierte). Folgende Begebenheit im Dörfchen Schilda ist ein Beispiel dafür: Flughäfen bauen ist schwierig. Rathäuser bauen aber auch. Die Schildbürger wollen ein dreieckiges Rathaus bauen – wenn der schiefe Turm von Pisa den Pisa… hmm, den Einwohnern von Pisa zur Berühmtheit verholfen hat, so kann das ja wohl auch das dreieckige Rathaus von Schilda. Los ging die Arbeit. Und schon bald konnte das dreieckige Rathaus eröffnet werden. Eine flammende Eröffnungsrede war leider nicht Teil der Eröffnungsfeier, denn im dreieckigen Rathaus was es stockduster. Aber die Schildbürger wären ja nicht die Schildbürger, wenn sie nicht auch für dieses Problem eine Lösung hätten. Rein mit dem Licht ins Rathaus und zwar in Eimern, Säcken und Gießkannen (falls es damals schon Gießkannen gab). Zur Verwunderung der Schildbürger brachte diese Hauruckaktion leider nichts. Im Rathaus war es nach wie vor stockduster. Zum Glück lag Schilda auf dem Weg eines Landstreichers. Der analysierte die Situation geistesgegenwertig und kostengünstig in Echtzeit: Das Rathausdach muss weg. Kaum war es abgedeckt, war es hell im Rathaus. Und zwar bis zum nächsten Regen. Im Nassen sitzen ist ungemütlich, kalt und – ganz klar – nass. Es war also wieder nichts mit dem Licht im Rathaus. Das Dach musste wieder drauf, denn im Dunkeln ist zumindest gut munkeln. Jetzt aber! Der Schuster der Schildbürger sah einen Lichtstrahl, der durch das Gemäuer der Rathauswände schien. Das war es also! Die Schildbürger hatten die Fenster vergessen!

Keine Geschichte ohne Moral

Und die Moral von der Geschicht? Mit Requirements-Engineering gibt’s Licht. Genauer: Einzelne Anforderungen sind für Kunden unterschiedlich wichtig. Ein Hilfsmittel, das bei der Einteilung von Anforderungen, die für die Kundenzufriedenheit sehr wichtig und eher unwichtig ist, ist das Kano Modell [4]. Eigentlich in der Marktforschung angesiedelt, hat es sich über die Jahre im Requirements-Engineering etabliert. Das Kano-Modell stellt drei Kategorien zur Verfügung, in die die Features eines Produkts eingeteilt werden können. Wird der Erfüllungsgrad der Anforderungen in Relation zur Kundenzufriedenheit gesetzt, ergibt sich ein Überblick darüber, was den Kunden wirklich glücklich macht:

• Basisfaktoren sind als selbstverständlich vorausgesetzte Features.
• Leistungsfaktoren sind die bewusst verlangte Sonderausstattung.
• Begeisterungsfaktoren sind die Features eines Produkts, die der Kunde nicht kennt und erst während der Benutzung als angenehme Überraschung entdeckt.

Was heißt das für die Schildbürger? Beim Bau des Rathauses haben die Schildbürger sich nicht um die Basisfaktoren ihres dreieckigen Rathauses gekümmert. Die ausgefallene Form Dreieck hat sie in helle Begeisterung versetzt. Der Basisfaktor Fenster wurde vollkommen vergessen. Bei der Eröffnung konnte die Schildbürger der Begeisterungsfaktor dreieckige Form nicht über den fehlenden Basisfaktor Fenster hinwegtrösten.

Auf Begeisterung folgt Leistung folgt Basis

Ein Feature (so auch die Rathausfenster der Schildbürger) durchlebt eine zeitliche Veränderung. Nichts ist auf ewig neu, toll und modern und macht den Kunden zufrieden. Der Kunde ist ein Gewohnheitstier und so sind Begeisterungsfaktoren nicht für die Ewigkeit gemacht. So würdest wohl auch du, lieber Leser, zustimmen: Fenster in einem Gebäude sind schön und gut. Die setze ich jedoch voraus und bin alles andere als sehr zufrieden, wenn ein neues Rathaus Fenster hat. Voraussetzung bzw. impliziert annehmen birgt die Gefahr des Vergessens. Thematisieren Sie daher in Ihren Projekten Anforderungen auf allen drei Ebenen. Vielleicht erscheint Ihnen eine Anforderung der Art „Das Rathaus muss Fenster haben.“ auf den ersten Blick banal. Beim genaueren Hinsehen merken Sie aber, „gut, dass wir das thematisiert und dokumentiert haben“, denn dieses „banale“ hat einen entscheidenden Einfluss auf die Kundenzufriedenheit.

Damit sind wir entschieden am Ende des ersten Blogeintrags und Sie haben hoffentlich das eingangs erwähnte Schmunzeln auf den Lippen. Weiterschmunzeln können Sie in ein paar Wochen beim Lesen des zweiten Teils dieser Blogserie.

[1] Randell, Brian: The 1968/69 NATO. Software Engineering Reports. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/. Zuletzt am 17.07.2015.
[2] U.a. Wunderlich, Wener (Hrsg.): Das Lalebuch. In Abbildung des Drucks von 1597. Göppingen 1982: Litterae. Göppinger Beiträge zur Textgeschichte. Bd. 87.Preußler, Ottfried: Bei uns in Schilda – die wahre Geschichte der Schildbürger nach den Aufzeichnungen des Stadtschreibers Jeremias Punktum. 18., Auflage. Thienemann: Stuttgart 1988.
[3] Bei welcher Firma können Sie sich an dieser Stelle sicherlich denken. Und falls aus irgendwelchen Gründen doch nicht: www.sophist.de
[4] Rupp, Chris und SOPHISTen, die: Requirements- Engineering und -Management – Aus der Praxis von klassisch bis agil. Hanser: München 2014. 6., aktualisierte und erweiterte Auflage. Kapitel 6.