Kaizen 2 go 029 : Requirements Engineering und agile Software-Entwicklung

Inhalt der Episode

Die Rolle von Requirements-Engineering (RE) im Software-Entwicklungsprozess
Was ist das Besondere für das RE in der agilen Software-Entwicklung
Der Umgang mit Komplexität im Requirements Engineering
Die Wichtigkeit nicht-funktionaler Anforderungen
Was sollten Unternehmen beachten, wenn sie von klassischen zu agilen Methoden wechseln
Gegenüberstellung von RE-Werkzeugen
Der Faktor Mensch im Produktentstehungsprozess und speziell im Requirements Engineering

Notizen zur Episode

XING-Profil von Sebastian Adam
Website der „OSSENO Software GmbH„
Website des IESE – Fraunhofer-Institut für Experimentelles Software Engineering
Episode 027 über Scrum, agile Software-Entwicklung und Lean

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode jetzt bitte bei Apple Podcasts.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Eine KI-generierte Zusammenfassung finden Sie am Ende des Transkripts.

Episode 029 : Requirements Engineering und agile Software-Entwicklung

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Dr. Sebastian Adam bei mir. Er ist Geschäftsführer der Firma OSSENO in Kaiserslautern und ich gebe ihm einfach gleich das Wort, damit er sich selber vorstellen kann. Herzlich willkommen.

Sebastian Adam: Dankeschön für die Einladung. Ja, mein Name ist Sebastian Adam. Ich bin, wie Sie schon gesagt haben, Geschäftsführer oder einer von drei Geschäftsführern der OSSENO Software GmbH. Wir sind eine Ausgründung des Fraunhofer-Instituts für experimentelle Software-Engineering hier in Kaiserslautern. Wir haben ungefähr alle drei zehn Jahre lang hier am Institut gearbeitet im Bereich Requirements-Engineering. Und basierend auf unserer Erfahrung, die wir in den letzten Jahren gemacht haben, haben wir uns dann ungefähr, ich glaube, 2013, 2014 darum entschieden, den Weg in die Selbstständigkeit zu gehen, quasi mit einer eigenen Lösung an den Markt zu kommen. Wobei wir als Lösung verstehen wirklich ein Paket aus Dienstleistungen, aus methodischer Beratung und eben auch einem innovativen Werkzeug für die frühen Phasen von Softwareentwicklungsprojekten.

Ich selbst bin, wie gesagt, Geschäftsführer hier in dieser Organisation, bin daneben aber auch insbesondere für die Produktweiterentwicklung verantwortlich, also Innovation, neue Features ausdenken, festzustellen, was der Markt benötigt und das gemeinsam mit meinen Kollegen dann auch aufzubereiten und entsprechend dann bei uns im Haus auch in die Entwicklung zu geben.

Götz Müller: Ja, ein Stichwort haben Sie schon genannt und das ist auch unser Thema heute, Requirements Engineering. Was für eine Rolle spielt denn Requirements Engineering grundsätzlich in Softwareentwicklungsprojekten?

Sebastian Adam: Gut, also ganz generell eine sehr wichtige Rolle. Also ich möchte jetzt nicht sagen, dass es in der Softwareentwicklung einzig und allein um Requirements Engineering gehen sollte. Natürlich ist die lauffähige Software letztendlich das Entscheidende, was dabei rauskommen sollte. Aber man weiß schon sehr lange, quasi schon seit den 70er oder 80er Jahren, dass es doch sehr wichtig ist, auf diese frühen Phasen in der Software-Entwicklung, also das neudeutsche Requirements Engineering einen großen Wert zu legen, da die meisten Fehler, und das ist wirklich bewiesen und auch nachgewiesen und belegt.

Durch Studien, dass die meisten Fehler in Softwareentwicklungsprojekten immer noch dadurch entstehen, dass man nicht wirklich weiß, was eigentlich entwickelt werden soll. Okay, also Requirements Engineering ist, wenn man so in die Lehrbücher schaut, die erste logische Phase von Softwareentwicklungsprojekten. Sicherlich nicht die zentrale, aber doch eine der wichtigsten Phasen, da man durch Studien in der Vergangenheit herausgefunden hat, dass die meisten Fehler in Softwareentwicklungsprojekten immer noch dadurch entstehen, dass man eigentlich nicht weiß, was man entwickeln soll. Es gibt jede Menge Beispiele, auch außerhalb der Softwareentwicklung, die immer wieder zeigen, wie wichtig das Ganze ist. Also beispielsweise werden irgendwelche wichtigen Sachen vergessen und erst sehr spät in einem Projekt stellt man fest, dass man das auch noch hätte benötigt. Und das macht natürlich Projekte sehr kostspielig und lange. Und man weiß schon seit vielen Jahren, dass das ein sehr wichtiges Thema ist.

Und interessanterweise beschäftigt sich die Industrie, insbesondere in Deutschland, aber erst in den letzten zehn Jahren sehr intensiv mit dem Aufbau dieses Themas. Also es ist etwas, was noch sehr stark im Entstehen ist, auch wenn man schon sehr lange weiß, dass es eben eine sehr wichtige Rolle einnimmt. Erstmal herauszuarbeiten, was entwickelt werden soll, das auch zu klären, auch zu verhandeln, nicht wirklich jeden Wunsch des Kunden als gegeben anzunehmen, sondern mal herauszufinden, wollen wir das wirklich bauen, was ist uns diese ganze Sache wert und was müssen wir dazu tun? Also diese frühen Phasen sind eben sehr wichtig in der Softwareentwicklung.

Götz Müller: Ja, manchmal auch den Kunden zu fragen, was er denn will, aber andererseits auch ein Stück weit zu wissen oder damit zu rechnen, dass er es nicht wirklich weiß, was er denn braucht. Da zitiere ich immer ganz gern den Henry Ford, der immer gesagt hat, wenn ich meine Kunden gefragt hätte, was sie denn haben wollen, hätten sie schnellere Pferde gesagt.

Sebastian Adam: Diesen Spruch zitieren wir auch sehr oft, wenn wir Schulungen halten, weil oftmals wirklich die Annahme ist, man kann zum Kunden oder auch zum Nutzer gehen und zu fragen, was hättest du denn gerne? Und es ist wirklich ein Problem herauszufinden, was Leute tatsächlich brauchen und nicht nur, was Leute wollen. Also wenn Sie mich beispielsweise fragen, was ich für ein Auto fahren möchte, dann würde ich Ihnen natürlich ein ganz anderes Auto nennen als das, was ich jetzt tatsächlich fahre oder auch, was ich auch tatsächlich brauche. Also das wäre wahrscheinlich irgendein schöner Sportwagen oder sowas, der jede Menge Geld kostet, der viele PS hat. Aber ist das was, was man tatsächlich braucht für das, was man tagtäglich tut? Und das ist ein bisschen das Problem wirklich auch in der Softwareentwicklung herauszufinden.

Ist das jetzt ein Wunsch, der hier geäußert wird oder ist es wirklich ein Bedarf, der erfüllt sein muss, damit gewisse, ja, letztendlich auch organisatorische, wirtschaftliche Ziele damit erreicht werden können? Diese Abgrenzung zu machen, das ist oftmals wirklich eine Herausforderung und führt dazu, dass entweder alles aufgeschrieben wird, alles wird irgendwie als Anforderung aufgenommen. Man traut sich nicht zu verhandeln, das ist eine große Herausforderung. Das andere, was wir aber auch oft erleben, ist, dass man von vornherein Leute erst gar nicht befragt, weil man Angst hat, dass man dann eben solche Wünsche bekommt. Was natürlich aber auch nicht die Lösung sein kann, weil oftmals dann auch wichtige Sachen vergessen werden.

Götz Müller: Ja, also das kann ich aus meinem eigenen, ich sage mal früheren Leben auch als Softwareentwickler absolut bestätigen. Jetzt haben sich ja seit ein paar Jahren oder ja schon fast ein Jahrzehnt oder etwas mehr, haben sich ja so Themen wie agile Softwareentwicklung als, ich möchte nicht sagen eine Alternative, aber eben einen Weg zu klassischen Entwicklungsmethoden herausgestellt, so wie V-Modell oder gar noch davor das Wasserfallmodell. Was würden Sie denn sagen, was ist das Besondere bezüglich Anforderungsmanagement bei solchen agilen Methoden?

Sebastian Adam: Gut, also was das Zentrale meiner Meinung nach ist, das ist zum einen, dass man ja quasi mit wenig anfängt.

Das heißt also wirklich mal die wichtigsten Anforderungen klärt und dann auch schon direkt mit der Entwicklung startet. Also das heißt, man schreibt nicht erst über Wochen oder Monate ein Lastenheft, verhandelt das dann irgendwann, macht ein Pflichtenheft raus und begann dann zu entwickeln, Sondern man beginnt wirklich mit dem ersten Satz von Anforderungen relativ früh schon mit der Entwicklung, mit der Qualitätssicherung, mit der ersten Lieferung von gewissen Inkrementen. Das ist sicherlich etwas, was sehr unterschiedlich ist, ganz anders ist als in klassischen Entwicklungsmethoden. Und ein zweiter Punkt, der ein wenig damit einhergeht, ist, dass man auch deutlich weniger dokumentiert. Also es gibt ja in diesem Agile Manifest die Aussage, also mehr reden, weniger dokumentieren. Um es mal ein bisschen vereinfacht auszudrücken. Und man schreibt eben nicht wirklich alles auf, sondern versucht sich auf das zu fokussieren, was relevant ist eben für die Entwicklung.

Und das sind meines Erachtens die zwei wesentlichen Änderungen. Was ich aber auch oft erlebe, ist, dass es jede Menge Missverständnisse gibt durch die agile Entwicklung, dass man meint, man bräuchte überhaupt kein Requirements Engineering mehr, dass man, ja, wir schreiben jetzt einfach mal eine User Story auf eine Karte, kleben die bei uns an die Wand im Entwicklungsraum und damit können wir dann arbeiten. Das kann es in der Regel aber auch nicht sein. Also das heißt, meiner Meinung nach braucht man Requirements Engineering als Methode nach wie vor. Was sich unterscheidet, ist, wie stark das als Prozess wirklich in der Organisation dann verankert wird. Das ist sicherlich ein deutlicher Unterschied zu traditionellen Entwicklungsmethoden.

Götz Müller: Das mit dem vielen Aufschreiben hat, glaube ich, auch was mit Komplexität zu tun, die ja so das Charakteristikum ist. Und wenn man die Dinge nicht weiter zergliedern kann, im Sinne von aufschreiben, dann haben wir ein Problem mit der Komplexität.

Sebastian Adam: Also die Komplexität heutzutage kommt ja quasi nicht aus dem Requirements Engineering, sondern sie kommt ja meistens daher, was eigentlich entwickelt werden soll. Das heißt also, Systeme werden komplexer, die Welt wird generell komplexer, Anforderungen an solche Systeme werden entsprechend komplexer. Sie brauchen jetzt nur an Industrie 4.0 beispielsweise zu denken. Also wenn wirklich Maschinen anfangen, mit Informationssystemen zu reden, Daten auszutauschen, die Produktion zu automatisieren, Da entstehen ganz neue Herausforderungen an die Komplexität, an das, was gebaut werden soll. Und Komplexität hat aber auch eine Komponente dadurch, wie man Projekte bearbeitet. Das heißt, eine gewisse Komplexität kommt auch dadurch ins Spiel, dass das Vorgehen selbst oftmals als sehr komplex erachtet wird. Also Requirements Engineering ist nichts Einfaches. Das heißt, man braucht da schon gewisse Skills für, man braucht gewisse Erfahrungen für. Nicht jeder kann wirklich Anforderungsdokumente schreiben.

Und das jetzt wirklich gepaart, diese methodische Komplexität des Requirements Engineering mit der inhaltlichen Komplexität des Projektgeschäftes, das verlangt wirklich, sage ich jetzt mal, neuartige Lösungen, wie man mit diesem Thema umgehen kann.

Götz Müller: Wenn wir jetzt nochmal zu den agilen Methoden kurz kommen und Requirements Engineering, angenommen ein Unternehmen kommt aus klassischen Entwicklungsmethoden her und hat Requirements Engineering, was müssen Sie tun, wenn Sie jetzt zu agilen Methoden wechseln?

Sebastian Adam: Also ganz gezielt im Hinblick auf das Requirements Engineering ist unsere Empfehlung, nicht alles über den Haufen zu werfen, was man bis dato gemacht hat. Also wir kennen das von einigen unserer Kunden, die sind so ungefähr 2010 auf die agile Entwicklung, auf Scrum und ähnliches umgeschwenkt. Die haben wirklich das versucht, lehrbuchartig zu leben. Die haben wirklich alles weggeworfen, um es mal so zu nennen, was sie vorher gemacht haben. Also es wurden keine Anforderungen mehr klassisch dokumentiert. Es wurde eigentlich, ja, der Product Owner hat sich was ausgedacht oder hat irgendwas aus den Gesprächen mit den Kunden mitgenommen und hat das dann auf Karten geschrieben und seinem Entwicklungsteam zur Verfügung gestellt.

Wir haben relativ schnell gemerkt, dass das auch nicht das Wahre sein kann. Also was unsere Empfehlung ist, wenn Sie wirklich von einer traditionellen Entwicklung zu einer agilen Entwicklung wandern, dass Sie bewährte Techniken, bewährte Praktiken, die Sie in der Vergangenheit eingesetzt haben, kritisch hinterfragen und versuchen, diese anzupassen. Aber nicht jetzt zu meinen agilen Entwicklungen, wie es jetzt irgendwie in vereinfachten Lehrbüchern dargestellt wird, eins zu eins umzusetzen. Also konkret im Requirements Engineering, Sie brauchen immer noch gewisse Erhebungstechniken. Sie müssen wissen, wie Sie mit Ihren Leuten, mit Ihren Stakeholder, mit Ihren Kunden reden können. Sie müssen wissen, wie Sie das auch kurz und prägnant aufschreiben können, wie Sie das auch vorhalten für spätere Änderungen beispielsweise. Das gesamte System, wir hatten eben von Komplexität gesprochen, wird immer komplexer.

Das heißt, man muss auch eine gewisse Dokumentation aufrechterhalten, auch wenn das gewissermaßen gegen agile Prinzipien verstößt, einfach um auch langfristig zu wissen, was haben wir damals eigentlich entwickelt und wie können wir das auch nochmal anpassen.

Also kurz zusammengefasst, die Empfehlung ist, nicht alles wegzuwerfen, sondern kritisch zu hinterfragen, was passt zu dieser agilen Entwicklung und das möglichst dann auch mitzunehmen, wenn Sie es in der Vergangenheit bewährt haben.

Götz Müller: Gut, da haben Sie jetzt schon viele der Probleme genannt, die eben im Requirements Engineering im Zusammenspiel mit agilen Entwicklungsprozessen auftreten. Was gibt es denn noch für Themen und wie kann man die vermeiden?

Sebastian Adam: Also zwei klassische Themen, das haben wir in der Vergangenheit auch oft zu Fraunhofer-Zeiten gemerkt, wir hatten dann auch bei Fraunhofer ein entsprechendes Forschungsprojekt beantragt, das nennt sich PQ for Agile, Product Qualität in agiler Entwicklung. Was man oft feststellt, ist, dass zu wenig in agiler Entwicklung, insbesondere in den ersten Sprints, auf nicht funktionale Anforderungen, Qualitätsanforderungen gelegt wird. Und es ist oftmals der Irrglaube da, dass man diese Anforderungen irgendwie, so wie funktionale Anforderungen jederzeit in einem Release nochmal mit reinbringen kann. Also man kann durchaus irgendwann mal nochmal eine Funktion nachreichen. Man kann eine neue Suchfunktion beispielsweise einbauen, neue Backup-Funktionalität. Das lässt sich vielleicht in ein, zwei Sprints realisieren. Aber nicht funktionale Anforderungen, also diese Qualitätseigenschaften, die betreffen oftmals ein System als Ganzes.

Und das hat eben zur Folge, dass Sie nicht spät in einem Projekt erst sagen können, so jetzt müssen wir, was ist die Verfügbarkeit, die Performance, die Sicherheit, wie auch immer für unsere Lösung, mal noch ein bisschen verbessern und können das in ein, zwei Sprints machen, sondern oftmals müssen sie dadurch wirklich die komplette Architektur umbauen und das dauert relativ lange und deckt sich dann auch nicht mit dem, was eigentlich die agile Entwicklung besagt, dass man nämlich immer neuen Wert generieren soll. Im Endeffekt haben sie dann sehr viele Sprints für Refactoring von dem Ganzen, ohne dass sie neuen Wert generieren. Und das ist natürlich nicht die Idee und nicht Ziel des Ganzen Und deshalb ist es wichtig, dass man eben auch sehr früh auf diese Qualitätsanforderungen, auf diese nicht-funktionalen Anforderungen eingeht, was, so wie wir das sehen, leider oftmals vergessen wird.

Götz Müller: Ja, und Dinge mehrfach zu machen, das ist jetzt das, wo dann wieder mein Lean-Herz mitschlägt. Das ist ja die maximale Verschwendung. Was haben denn die Themen Requirements Engineering im agilen Umfeld dann für Auswirkungen auf die Management-Werkzeuge, auf die Requirement-Management-Werkzeuge?

Sebastian Adam: Gut, da gibt es ganz verschiedene Punkte. Also zum einen muss man überlegen, wenn man so ein Requirements Management Werkzeug benutzt, wozu möchte man das eigentlich einsetzen? Also das ist noch relativ unabhängig, ob man jetzt traditionell oder agil entwickeln möchte. Man muss sich klar werden, brauchen wir so ein Werkzeug und wenn ja, wofür brauchen wir denn so ein Werkzeug?

Die Werkzeuge, die es am Markt gibt in diesem Bereich, die sind hauptsächlich dafür gedacht, wirklich sehr große Anforderungsmengen vorrätig zu halten, zu verwalten.

Den Status zu kontrollieren, wo befinden sich die ganzen Sachen in der Entwicklung, können wir Sachen wiederverwenden, wie steht das alles miteinander, Beziehung. Also wirklich sehr, sehr schwergewichtige Werkzeuge oftmals, was sich von der Grundidee erstmal gar nicht deckt mit einer agilen Entwicklung. Beziehungsweise es deckt sich auch noch nicht mal mit, sage ich jetzt mal, Organisationen, die vielleicht traditionell entwickeln, aber doch eher begrenzte Ressourcen haben. Das heißt, die Herausforderung, die es bei solchen Werkzeugen, insbesondere im Hinblick auf die agile Entwicklung gibt, ist, dass sie oftmals überfrachtet sind, zu schwierig sind und sich auch zu wenig anpassen lassen an den agilen Gedanken. Also quasi, dass man wirklich sehr gezwungen ist, sehr viel zu verwalten, sehr viel vorzuhalten, sehr viel zu versionieren, zu attributieren, freizugeben.

Alles das, was man in der agilen Entwicklung eher sehr leichtgewichtig macht, durch beispielsweise Gespräche, durch Daily-Stand-Up-Sessions beispielsweise, indem man einfach mal festkommt, wo stehen wir denn, da wird eine Karte umgehängt, entweder jetzt wirklich in so einem Backlog-Tool, die sehr leichtgewichtig sind, oder eben als wirklich physikalische Karte an der Wand. Und das jetzt wirklich mit einem klassischen RM-Werkzeug nachzubilden, ist oftmals, man sagt so schön, mit Kanonen auf Spatzen geschossen. Also da braucht man doch eher leichtgewichtige Sachen. Und das ist auch der Grund, warum sich diese Werkzeuge eigentlich generell in der Praxis nur begrenzt etabliert haben und auch insbesondere im agilen Umweltfeld eigentlich gar keine Anwendung finden. Weil es doch einen gewissen organisatorischen Overhead mitbringt.

Götz Müller: Solche Werkzeuge zu benutzen. Wie unterscheidet sich jetzt Ihr Werkzeug von den klassischen Werkzeugen wie DOORS oder Rhapsody oder was es noch alles gibt?

Sebastian Adam: Also bis vor kurzer Zeit haben wir gesagt, der große Unterschied ist, dass wir kein Requirements-Management-Werkzeug im klassischen Sinne sind. Also das mit im klassischen Sinne würde ich nach wie vor unterstreichen. Inzwischen sind wir auch ein Requirements-Management-Werkzeug, weil wir die entsprechende Funktionalität vorhalten. Aber historisch betrachtet kommen wir eigentlich aus einer ganz anderen Ecke. Wir haben gesagt, wir wollen ein Werkzeug schaffen, das die Leute wirklich in der Herausarbeitung von Anforderungen unterstützt. Also nicht darum, wir haben jetzt irgendwie 10.000 Anforderungen erhoben und die müssen wir irgendwie verwalten, um jetzt irgendwie ein fünf Jahre langes Projekt damit bedienen zu können, sondern es geht eher darum, wie komme ich überhaupt zu diesen Anforderungen? Woher weiß ich, dass die Anforderungen gut sind? Woher weiß ich, dass die Anforderungen vollständig sind? Dass ich nichts Wichtiges vergessen habe?

Und was wir gemacht haben, ist eigentlich quasi basiert auf unserer langjährigen Industrieerfahrung, aber auch Forschungsexpertise bei Fraunhofer, dass wir versucht haben, Expertenwissen algorithmisch abzubilden. Das heißt also, wie würden Experte ein komplexes Thema zerlegen? Diese Vorgehensweise haben wir algorithmisch beschrieben und im Werkzeug abgebildet. Und der Charme davon ist, dass man das vollständig konfigurieren kann für den konkreten Projektbedarf. Wenn Sie jetzt beispielsweise, ich sage jetzt mal, Anforderungsspezifikation schreiben für irgendein Gebäude, dann würden Sie eben, sage ich jetzt mal, die Eigenschaften oder die Elemente von einem Gebäude dort hinterlegen und das Werkzeug könnte zur Laufzeit eben nachfragen, was da gemacht werden soll. Also beispielsweise, wie sollen denn die Fenster im ersten Stock aussehen oder wie viel Stahl muss eigentlich in der Bodenplatte verarbeitet werden?

Also so Fragen kann das System dann automatisch generieren, quasi den Nutzer in einen Dialog bringen, Informationen vom Nutzer dann auch erfragen, basierend eben auf einem Algorithmus, der eigentlich agiert, wie jemand im Interview agieren würde. Und das sind Funktionalitäten, die es eben in allen anderen am Markt befindlichen Requirements Management Werkzeugen eben nicht gibt.

Und das hat eben den Charme, dass Leute, die damit arbeiten, sehr effizient, sehr einfach angeleitet werden. Sie bekommen immer nur Unterstützung zu wissen, was muss ich denn überhaupt erheben, was muss ich denn überhaupt aufschreiben. Die muss ich diese Anforderungen idealerweise aufschreiben, dass sie auch gut verständlich sind. Und es wird auch sehr viel automatisiert. Also das, was sie in der partitionellen Requirements Engineering machen müssen, beispielsweise Attributwerte setzen, Verlinkungen miteinander ziehen, also zum Beispiel sagen, diese Anforderung ist eine Verfeinerung einer anderen Anforderung, das erkennt das Werkzeug automatisch und kann es zum sehr hohen Grad automatisieren. Hat eben den Charme, dass der gesamte Prozess deutlich optimiert werden kann.

Götz Müller: Da kam mir sofort der Gedanke künstliche Intelligenz in den Sinn, da ich ja mal in Kaiserslautern schon vor Jahrzehnten studiert habe und damals das Institut dort gegründet wurde. Haben Sie da irgendwelche Querbeziehungen?

Sebastian Adam: Also künstliche Intelligenz ist ein weitreichender Begriff, was wir haben. Wir arbeiten sehr stark modellbasiert. Im Bereich der künstlichen Intelligenz würde man das vielleicht Frontologie nennen. Das heißt, man kann sehr gut beschreiben mit unserem Werkzeug, um was für Anforderung Typen es eigentlich geht. Also beispielsweise, ist das jetzt eine Schnittstellenanforderung? Ist das jetzt eine funktionale Anforderung? Ist das eine Qualitätsanforderung? Sind irgendwelche Datensätze beispielsweise beschrieben? Das lässt sich in einer semiformalen Sprache hinterlegen und das kann eben das Werkzeug zur Laufzeit interpretieren und weiß dann eben, okay, hier gibt es eine Schnittstelle zu einem externen System. Entsprechend weiß dann das Werkzeug auch, hier müssen irgendwie Daten drüber transferiert werden, Welche Daten sind denn das? Und wenn dann eben vergessen wird, diese Daten zu spezifizieren, dann erkennt das das Werkzeug zur Laufzeit auch und kann entsprechend dann auch entsprechende Hinweise generieren.

Also es ist gewissermaßen eine Intelligenz drin, ob das sich jetzt mit, sag ich jetzt mal, klassischen Ansätzen, klassischen Verfahren der künstlichen Intelligenzforschung deckt, ich glaube nicht ein bisschen überfragt, aber es ist auf jeden Fall eine intelligente Unterstützung, ja.

Götz Müller: Was haben über das hinaus, was wir schon diskutiert haben, was für Grenzen haben denn die klassischen Requirement-Werkzeuge im agilen Requirement-Engineering?

Sebastian Adam: Gut, was halt Grenzen sind. Also ich hatte schon gesagt, es ist halt sehr schwergewichtig. Es ist sehr viel administrativer Aufwand, von dem man ja bewusst in der agilen Entwicklung absehen möchte. Ist es oftmals auch, je nachdem, was man für ein Werkzeug einsetzt, schwer zu konfigurieren für den konkreten Bedarf. Also diese traditionelle oder diese klassische Denke, traditionell ist der falsche Begriff, die klassische Denke in der agilen Entwicklung ist ja quasi, dass man Epics hat, dass man User-Stories hat, dass man daraus Tasks ableitet. Und das setzt ja auch ein gewisses, sage ich mal, Denkmodell voraus, dass diese Tools auch unterstützen müssen.

Und da hängt es sehr stark von den Werkzeugen ab, ob die diese Unterteilung auch anbieten können oder ob man dann eben eher, ja, sage ich mal, spezialisierte Werkzeuge für die Agile-Entwicklung benötigt oder eben hoch anpassbare Werkzeuge, wie beispielsweise Unsass, in denen man eben auch solche Konzepte abbilden kann.

Götz Müller: Nochmal zusammengefasst, welche Vorteile, welchen Nutzen ziehen also die Beteiligten? Und da meine ich jetzt mal beide Seiten, sowohl die Kunden, die Anwender als auch die Entwickler aus Ihrem Werkzeug?

Sebastian Adam: Aus unserem Werkzeug, also für die Entwickler zum einen, werden die Anforderungen standardisierter und von einer höheren Qualität, weil quasi der Freiheitsgrad, was und wie man aufschreiben kann, gewissermaßen eingeschränkt wird. Das klingt jetzt im ersten Moment relativ negativ, hat aber wirklich den Charme, dass es oftmals auch für diejenigen, die die Kunden sind oder zumindest nur die Anforderungen beitragen müssen, die empfinden das gar nicht so restriktiv. Die sind eigentlich eher dankbar dafür, dass sie beispielsweise Schablonen, Vorlagen, Anweisungen zur Verfügung gestellt bekommen, damit sie überhaupt mal wissen, was sie aufschreiben müssen. Weil eine große Herausforderung in der Industrie heutzutage ist, dass Kunden oder generell Leute, die für die Anforderungen in Projekten verantwortlich sind, überhaupt keine Expertise in diesen Bereichen mitbringen. Das sind meistens Leute, die in der fachlichen Expertise des Systems, das gebaut werden soll, sehr gut sind, aber wenig methodische Expertise mitbringen.

Das heißt, die wissen nicht, wie man eine gute Anforderung schreibt, die wissen nicht, in welches Kapitel oder an welche Stelle man im Dokument, im Anforderungsdokument, idealerweise diese Anforderung schreiben sollte.

Und das sind alles Sachen, bei denen unser Werkzeug eine Unterstützung bietet, das möglichst einfach zu machen. Also wir ziehen da gern auch immer den Vergleich zu einer Steuererklärungssoftware, die Sie vielleicht kennen, von Ihrer privaten Steuererklärung. Das heißt, man wird da sukzessive durchgeleitet, man bekommt Fragen gestellt, die Angaben werden plausibilisiert, stimmt das Ganze, kann das so sein, fehlt hier noch etwas. Das heißt, mit so einer Funktionalität kann man Anforderungen viel effizienter, viel einfacher zusammentragen und kann insbesondere auch Leute einbeziehen, die sich vielleicht in einer klassischen Anforderungsergebung nie beteiligen würden oder beteiligen könnten, weil die ihnen einfach dafür die Skills fehlen. Und wie gesagt, für die Entwickler fallen letztendlich dann Dokumente raus oder Anforderungen raus, also wenn wir jetzt im agilen Kontext bleiben eben, man kann einen Backlog befüllen, der dann wirklich die wichtigen Sachen auch beinhaltet.

Und das auch in einer Qualität beschreibt, die eben angemessen ist für die weitere Entwicklung.

Götz Müller: Das Stichwort weglassen fand ich auch interessant. Das kenne ich durchaus auch von früher. Ich halte es da immer mit dem Antoine, das ist natürlich Exupery, der mal gesagt hat, Vollständigkeit entsteht nicht dann, wenn man nichts mehr hinzufügen kann, sondern wenn man nichts mehr weglassen kann. Okay, wenn jetzt sich ein Unternehmen entscheiden sollte, ihr Werkzeug einzusetzen, wie sieht denn da der Einstieg oder auch eben der Umstieg, wenn man schon was vorher hatte? Vorhin hat man es vom Wegschmeißen nicht alles wegschmeißen gehabt. Was muss man beachten?

Sebastian Adam: Gut, das kommt darauf an, wie Sie gerade gesagt haben, was man eigentlich aktuell jetzt im Haus hat. Also wir haben auch zu Fraunhofer Zeiten eine Umfrage gemacht, was werden eigentlich für Werkzeuge eingesetzt für das Requirements Engineering? Das war vor ungefähr zwei Jahren. Und da kam raus, noch mehr als 80 Prozent aller Firmen setzen eigentlich die klassischen Office-Werkzeuge ein, um Anforderungen aufzuschreiben. Und wenn das der Fall ist, ist eigentlich der Umstieg sehr einfach, weil unser Werkzeug zurzeit als Frontend-seitig, also kleinseitig, als Erweiterung von Microsoft Word mitkommt. Das heißt also, im Backend steht zwar ein sehr mächtiger Datenbank-Server, aber zum Frontend hin ist es wirklich ein Add-in für Microsoft Word und das erleichtert zum einen von der Bedienphilosophie, aber auch von der Datenübernahme sehr leicht den Umstieg.

Das heißt, man kann Informationen, die man beispielsweise in Word-Dokumenten schon mal geschrieben hat, kann man markieren, kann die dann in die Datenbank auch übernehmen und damit ist eigentlich der Übergang relativ einfach. Komplizierter wird es ein bisschen, wenn man schon wirklich gut gefüllte Requirements-Management-Werkzeuge im Einsatz hat, also große Doors-Datenbanken, in denen jede Menge Sachen drinstehen. Da bietet man natürlich auch Schnittstellen an, um diese Daten zu übernehmen, aber das ist oftmals organisatorisch ein bisschen größer. Also wenn eine Firma noch kein explizites Werkzeug hat, ist der Umstieg sehr leicht. Also das lässt sich in wenigen Tagen bewerkstelligen.

Da wirklich die Systeme aufzubauen, zu schulen, zu konfigurieren, zu integrieren, das ist da gar kein Problem. Bei eben größeren Systemen, die jetzt, sag ich mal, von Mitbewerbern kommen, da jetzt einen Umstieg zu machen, das verlangt natürlich dann schon ein bisschen höheren Aufwand, das zu tun.

Götz Müller: Wie sieht es grundsätzlich mit den Menschen aus? Also da entsinne ich mich eben an Situationen, so in der klassischen Entwicklung damals Produktmanagement im Telekom-Umfeld, die eben die Produkte definiert haben. Da war dann die Herausforderung für die Entwickler immer, die hatten Requirements-Management, nur mussten sie die Anforderungen da selber reinklopfen. Und der ideale Gedanke wäre ja gewesen, dass schon das Produktmanagement da mitarbeitet. Wie sieht es da bei Ihnen aus? Wird das eher unterstützt? Weil da hatte ich immer so erlebt, Man kann mit einem Word, kann man umgehen, ja, vielleicht noch mit Excel-Tabellen, aber wenn es dann in irgendwelche komplexeren Werkzeuge reingeht, war die Zurückhaltung für mich da immer sehr groß.

Sebastian Adam: Das stimmt, ja. Also generell zum Vorgehen, was wir bei vielen Kunden vorfinden, insbesondere sage ich jetzt auch mal an Banken und Versicherungen, wo die Fachbereiche eigentlich dafür verantwortlich sind, Anforderungen zu spezifizieren an die Weiterentwicklung der IT-Systeme. Da passiert es häufig, dass die Kollegen sich wirklich zusammensetzen, Sachen aufschreiben, Dokumente befüllen. Das Ganze geht dann zur IT-Abteilung oder zum externen Zulieferer und dann wird sich erstmal über Wochen zusammengesetzt und rausgepflückt, was da eigentlich drin steht. Und da wäre natürlich auch der Wunsch beispielsweise von den Zulieferern oder von den IT-Dienstleistern, seien es intern oder externe, dass die Fachbereiche oder die Kunden oder jemand wirklich, der von außen kommt, der die Anforderungen stellt, wirklich selbst daran beiträgt. Und da haben Sie vollkommen recht, es ist schwierig, da komplexe Werkzeuge hinzustellen.

Und der Charme von unserem Werkzeug, und das wird auch bestätigt von unseren Kunden, ist eben, dass es sehr einfach ist, dass es wirklich die Leute dort abholt, wo sie aktuell stehen von ihrer Wissenslage, auch keine neuen Werkzeuge erfordert, sondern die können einfach Word aufmachen, bekommen dann eben diese adaptive Arbeitsunterstützung, wissen, was sie eintragen sollen. Und so kann man viel besser ja quasi diesen Medienbruch oder auch personellen Bruch umgehen, dass irgendwie jemand im Auftrag von anderen erstmal die Anforderungen eintragen muss, sondern man kann wirklich den Endkunden, den Endnutzer, auch Leute ohne die entsprechende Erfahrung aktiv mit einbeziehen in diese Prozesse.

Götz Müller: Und da schließt sich ja dann der Kreis wieder eben, dass man ganz am Anfang anfangen muss, dass man die Nutzer befragen muss, letztendlich aus denen rauskitzeln, was sie denn brauchen, was sie denn machen müssen. Prima. Was wäre denn so Ihr abschließendes Fazit, was sich über die Zeit hinweg verändert hat im Requirements Management, im Requirements Engineering in Richtung agiler Softwareentwicklung?

Sebastian Adam: Gut, also was sich verändert hat sicherlich ist erstmal, dass dieses Thema vor einigen Jahren aufkam. Und da muss man sagen, da gab es sehr verschiedene Strömungen. Also im akademischen Umfeld wurde das mit dem Agile am Anfang etwas, ja nicht belächelt, aber doch etwas unterschätzt, sage ich jetzt mal, dass man gedacht hat, okay, das hat eigentlich keine so großen Auswirkungen auf das Requirements Engineering. Und man hat dann aber sehr schnell festgestellt, weil man in der akademischen Welt dieses Thema vernachlässigt hat, dass Firmen sich abgewandt haben von traditioneller Entwicklung, auch von traditionellen Requirements Engineering, dann sehr stark auf diese extremst vereinfachten, sage ich jetzt mal, Vorgehensweisen umgeschränkt sind. Also wir wissen, was wir wollen, der Product Owner erzählt uns das, wir schreiben das auf und dann wissen wir schon, was gemeint ist oder wir reden darüber, was gemeint ist.

Und wie ich eingangs auch schon erzählt habe, irgendwann kam dann die Ernüchterung und hat gemerkt, okay, wir brauchen trotzdem Requirements Engine. Also wir müssen, bevor wir wirklich anfangen zu entwickeln, vor dem ersten Sprint im Endeffekt, brauchen wir dann schon ein halbwegs gut gefülltes Backlog, damit wir überhaupt mal eine Orientierung haben, wo es eigentlich hingehen soll. Und da hat man relativ schnell dann auch festgestellt, okay, wir brauchen doch Requirements Engineering. Das sieht anders aus wie das Traditionelle, aber wir können nicht gänzlich darauf verzichten. Und das ist, denke ich, auch mal ein Ansatz, mit dem man sehr gut fährt, mit dem man auch die nächsten Jahre noch sehr gut fahren wird. Wer weiß, was dann vielleicht mal irgendwann Neues kommt nach Agile Entwicklung.

Es ist auf jeden Fall wichtig, die Best Practices des Requirements Engineering beizubehalten, aber eben diesen starren Prozessgedanken, den man aus der traditionellen Entwicklung kennt, ein bisschen wegzulassen, da eher zu überlegen, Wie kann ich die Methoden, die Best Practices sehr leichtgewichtig, aber dann auch zielführend in unseren Projekten einsetzen? Ich denke, das ist die große Kunst und immer mehr Firmen verstehen das, immer mehr Firmen bauen da auch Expertise auf. Aber es ist sicherlich noch ein paar Jahre ein Weg, bis das wirklich in der breiten Mast dann auch angekommen ist.

Götz Müller: Prima, das war jetzt ein schönes Schlusswort. Dann danke ich Ihnen für die interessanten Inhalte, für das Gespräch. Vielen Dank.

Sebastian Adam: Danke auch.

Götz Müller: Das war die heutige Episode im Gespräch mit Sebastian Adam zum Thema Requirements Engineering und agile Softwareentwicklung.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei Apple Podcasts. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.

KI-generierte Zusammenfassung

In dieser Episode spricht Götz Müller mit Sebastian Adam über die Rolle des Requirements Engineering in der klassischen und agilen Softwareentwicklung sowie über die Herausforderungen und Lösungsansätze im praktischen Einsatz.

Sebastian Adam ist Geschäftsführer der OSSENO Software GmbH in Kaiserslautern, einer Ausgründung des Fraunhofer-Instituts für Experimentelles Software Engineering. Gemeinsam mit seinen Mitgründern verfügt er über langjährige Erfahrung im Requirements Engineering aus Forschung und Industrie. Das Unternehmen bietet ein Paket aus methodischer Beratung, Dienstleistungen und einem eigenen Werkzeug für die frühen Phasen von Softwareentwicklungsprojekten an. Sebastian Adam verantwortet unter anderem die Weiterentwicklung des Produkts und die strategische Ausrichtung am Marktbedarf.

Im Gespräch wird deutlich, dass Requirements Engineering eine zentrale, wenn auch nicht allein entscheidende Rolle in Softwareprojekten spielt. Ziel ist es zwar, funktionierende Software bereitzustellen, doch zahlreiche Studien zeigen seit Jahrzehnten, dass viele Fehler in Projekten darauf zurückzuführen sind, dass zu Beginn unklar ist, was eigentlich entwickelt werden soll. Unklare oder unvollständige Anforderungen führen häufig zu teuren Nacharbeiten und Verzögerungen. Gerade in Deutschland habe sich das Bewusstsein für die Bedeutung dieser frühen Phase erst in den letzten zehn Jahren deutlich verstärkt.

Ein wesentlicher Aspekt ist die Unterscheidung zwischen Wünschen und tatsächlichen Bedarfen. Kunden können oft formulieren, was sie gerne hätten, nicht jedoch zwingend, was sie wirklich benötigen, um ihre Ziele zu erreichen. Requirements Engineering bedeutet daher auch, Anforderungen zu hinterfragen, zu priorisieren und zu verhandeln. Es geht nicht darum, jeden geäußerten Wunsch ungefiltert zu dokumentieren, sondern gemeinsam mit den Stakeholdern herauszuarbeiten, was wirklich wertstiftend ist.

Im Kontext agiler Methoden verändert sich die Ausprägung des Requirements Engineering, nicht jedoch dessen Notwendigkeit. Sebastian Adam betont, dass agile Vorgehensmodelle früher mit der Entwicklung beginnen und sich zunächst auf die wichtigsten Anforderungen konzentrieren. Statt umfangreicher Lasten- und Pflichtenhefte entstehen inkrementell nutzbare Softwarebestandteile. Zudem wird weniger dokumentiert und stärker auf direkte Kommunikation gesetzt.

Missverständlich sei jedoch die Annahme, dass agile Entwicklung ganz ohne strukturiertes Requirements Engineering auskomme. User Stories allein ersetzen keine fundierte Anforderungserhebung. Vielmehr müsse das Requirements Engineering an die agilen Prinzipien angepasst werden. Unternehmen, die von klassischen Modellen wie dem Wasserfall- oder V-Modell auf agile Methoden umstellen, sollten bewährte Praktiken nicht vollständig verwerfen. Stattdessen empfiehlt Sebastian Adam, bestehende Techniken kritisch zu prüfen und sinnvoll weiterzuentwickeln.

Ein besonderes Risiko in agilen Projekten sieht er bei nicht funktionalen Anforderungen wie Performance, Sicherheit oder Verfügbarkeit. Diese Qualitätsmerkmale betreffen häufig die gesamte Systemarchitektur und lassen sich nicht beliebig spät ergänzen. Werden sie zu Beginn vernachlässigt, drohen aufwendige Refactorings ohne unmittelbaren Kundennutzen. Daher sollten auch in agilen Projekten frühzeitig Qualitätsanforderungen berücksichtigt werden.

Im Hinblick auf Werkzeuge kritisiert Sebastian Adam, dass viele klassische Requirements-Management-Systeme sehr schwergewichtig sind. Sie eignen sich für große Anforderungsmengen, umfangreiche Versionierungen und komplexe Freigabeprozesse, stehen jedoch häufig im Widerspruch zum leichtgewichtigen Charakter agiler Methoden. Der organisatorische Overhead führe dazu, dass solche Werkzeuge im agilen Umfeld selten akzeptiert werden.

Das von OSSENO entwickelte Werkzeug verfolgt einen anderen Ansatz. Es unterstützt nicht primär die Verwaltung großer Anforderungskataloge, sondern die strukturierte Erhebung und Qualitätssicherung von Anforderungen. Auf Basis langjähriger Erfahrung wurde Expertenwissen algorithmisch abgebildet. Das System führt Anwender dialogbasiert durch die Anforderungserhebung, stellt gezielte Fragen und überprüft die Konsistenz der Eingaben. Dadurch können auch Personen ohne methodische Ausbildung qualitativ hochwertige Anforderungen formulieren.

Technisch basiert das Werkzeug auf einem modellbasierten Ansatz, bei dem unterschiedliche Anforderungstypen definiert und zur Laufzeit interpretiert werden. Das System erkennt beispielsweise, wenn bei einer Schnittstellenanforderung relevante Datenangaben fehlen, und weist aktiv darauf hin. Für Anwender erscheint das Werkzeug als Erweiterung von Microsoft Word, was den Einstieg erleichtert und bestehende Arbeitsgewohnheiten berücksichtigt. Bestehende Dokumente können übernommen und schrittweise strukturiert werden.

Ein zentraler Nutzen liegt darin, Fachbereiche stärker einzubinden. Statt Anforderungen lediglich in Dokumenten zu formulieren, die später von IT-Abteilungen interpretiert werden müssen, können Fachanwender direkt im System arbeiten. Die geführte Struktur reduziert Unsicherheiten und verbessert die Qualität der Spezifikationen. Entwickler profitieren von klareren, konsistenteren und standardisierten Anforderungen, während Kunden durch die dialogische Unterstützung sicherer in der Formulierung werden.

Abschließend stellt Sebastian Adam fest, dass sich das Requirements Engineering durch agile Methoden nicht erledigt hat, sondern neu gedacht werden musste. Nach einer Phase der Vereinfachung und teilweise Übertreibung sei heute ein ausgewogener Ansatz erkennbar. Erfolgreiche Organisationen kombinieren bewährte Methoden mit einem flexibleren Prozessverständnis. Die Kunst bestehe darin, Best Practices beizubehalten und sie zugleich schlank und praxisnah in agilen Projekten einzusetzen.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...