Der Verein IREB e. V. hat dazu im vergangenen Jahr die neue Zertifizierung zum „Digital Design Professional“ (DDP) lanciert. Sie vermittelt die Grundlagen zur systematischen Integration des „Digital Designs“ in den Entwicklungsprozess digitaler Lösungen. Ein Training zum DDP richtet sich faktisch an alle Mitarbeiterinnen und Mitarbeiter von Digitalisierungsprojekten, die erste Vorkenntnisse in der agilen Produktentwicklung haben. Es geht um das Verständnis und die Fähigkeiten für den Entwurf digitaler Lösungen, um das richtige Prüfen und Integrieren der notwendigen Technologien, um das effiziente Verbinden und Abstimmen interdisziplinärer Gestaltungsherausforderungen sowie um das Managen über den gesamten Entwicklungsprozess.
Vor diesem Hintergrund und angesichts der Allianz mit dem ISTQB sprachen wir mit den beiden Geschäftsführern der operativen Gesellschaft des Vereins, der IREB GmbH. Stefan Sturm ist dort in der Geschäftsführung für alle Aktivitäten verantwortlich, die sich aus dem wachsenden weltweiten Erfolg des CPRE-Zertifikats – kurz für „Certified Professional for Requirements Engineering“ – ergeben. Stan Bühne verantwortet das neue Geschäftsfeld „Digital Design“.
Im Interview machen die beiden deutlich, dass die Kombination von Requirements Engineering und „Digital Design“ – richtig in die Projektpraxis umgesetzt – nachhaltige Vorteile auch für das Testing bringt.
Herr Sturm, Herr Bühne, warum sollten sich Software-Tester mit Requirements Engineering (RE) befassen? Oder umgekehrt gefragt: Wie kann ein gutes Requirements Engineering den Software-Testern die Arbeit erleichtern?
Stefan Sturm: Einfach gesagt: Ohne gute Anforderungsspezifikation kein erfolgreicher Test.
Testerinnen und Tester kennen das Problem. Ist eine Anwendung fertiggestellt, oder heute im agilen Umfeld ein Inkrement, dann kann das Ergebnis getestet werden. Es stellt sich aber leider allzu häufig heraus: Die Anforderungen fehlen komplett, sie sind unvollständig, mehrdeutig, fehlerhaft oder veraltet. Sinnvolles Testen ist dann nicht möglich.
Stan Bühne: Beim Requirements Engineering geht es darum, die funktionalen und qualitätsorientierten Anforderungen eindeutig festzulegen und eine gemeinsame Sicht auf diese Anforderungen zu schaffen, damit alle Mitglieder des Projektteams ganz genau wissen, was gemeint ist. Dann sind später beim Testen der Entwicklungsergebnisse Überraschungen ausgeschlossen, die auf Missverständnissen bei der Interpretation der Spezifikation zurückzuführen sind. Es geht also auch darum, die Kritikalität von Anforderungen deutlich zu machen: Welche Anforderungen sind besonders wichtig? Worauf gilt es besonders zu achten?
„Mit der CPRE-Zertifizierung schalten wir eines der größten Probleme im Requirements Engineering aus: die Missverständnisse in der Kommunikation.“ Stefan Sturm
Was macht IREB?
Welche Fortschritte hat IREB – das International Requirements Engineering Board – auf diesem Gebiet in den letzten zehn Jahren erreicht?
Stefan Sturm: Wir haben verschiedene Zertifizierungen dafür auf den Markt gebracht, zum Beispiel den CPRE in verschiedenen Stufen. Damit sind wir in 80 Ländern der Welt mit mehr als 75.000 zertifizierten Personen unterwegs.
CPRE schaltet eines der größten Probleme im Requirements Engineering aus: die Missverständnisse in der Kommunikation. Jemand definiert etwas – und wer es implementieren soll, versteht etwas anderes darunter als das Gemeinte. Wenn man eine gemeinsame Basis hat – also gemeinsame Begriffe, gemeinsame Methoden und gemeinsame Techniken –, hilft das unglaublich dabei, in der Zusammenarbeit der Teams in Business-Analyse, Requirements Engineering und Software-Testing eigentlich unnötige Fehler zu vermeiden.
Stan Bühne: Hier hilft die internationale Ausrichtung des IREB sowohl großen Firmen als auch angesichts der zunehmenden internationalen Vernetzung verteilten Teams, an den verschiedenen Standorten rund um den Globus eine gemeinsame Sprache zu sprechen. Ein gemeinsames Verständnis der Aufgabe ist ja das A und O für den Projekterfolg. Hier gilt es auch, ein konsequentes Erwartungsmanagement zu betreiben, sowohl im Team selbst als auch bei den Stakeholdern, also den späteren Nutzern und den Auftraggebern, als auch bei den künftigen Betreibern der Software.
Gerade im internationalen Kontext ist es ganz entscheidend, ein gemeinsames Verständnis herzustellen. Wenn beispielsweise die Programmierung in Ägypten erfolgt, das Testing in Indien und Teile der Konzepte in Deutschland erstellt werden, ist ein gemeinsames Verständnis der Aufgabe und eine gemeinsame Sicht auf die konkreten Anforderungen absolut entscheidend. Natürlich gibt es darüber hinaus auch kulturelle Unterschiede, beispielsweise verschiedene Arten zu arbeiten. Das sind aber keine Themen, die das CPRE explizit adressiert.
Stefan Sturm: Wir haben eines geschafft: Es steht in den Projekten fest, was wann wie gemacht wird. Darauf sind wir stolz. Gerade kulturelle Unterschiede lassen sich dank gemeinsam gelebter einheitlicher Prozesse durchaus unter einen Hut bringen. Beispiel Fehlerkultur: In vielen Kulturen wird unterschiedlich mit Fehlern umgegangen. Dürfen Fehler überhaupt gemacht werden? Darf man einen Fehler zugeben? Kann man Fehler offen kommunizieren? Diese Unterschiede machen den Job des Testers nicht einfacher. Hier hilft in internationalen Teams eine wirklich gelebte, einheitliche und allgemein verbindliche Methode. Und das nicht nur bei CPRE, sondern generell in allen Bereichen.
„Wir haben deshalb seit langer Zeit eine enge Kooperation mit dem ISTQB vereinbart. In einem ersten Schritt wurden unsere Glossare synchronisiert.“ Stefan Sturm
Welche Verbesserungen Ihres praxisbewährten CPRE-Zertifizierungsmodells streben Sie an – und wie gehen Sie bei der Weiterentwicklung konkret vor?
Stan Bühne: Im vergangenen Jahr hat die Vorgehensweise durch das Update des Kernmoduls auf CPRE Foundation Level 3.0 eine deutliche Weiterentwicklung erfahren. Damit haben wir ein Ausrufezeichen gesetzt, indem wir klar machen: Wir unterstützen sowohl die altbewährten planbasierten Vorgehensweisen als auch die derzeit angesagten agilen Methoden. Der Grund ist einfach: Beides wird in der Praxis gebraucht. Einerseits werden vorhandene, zum Beispiel nach dem Wasserfallmodell entwickelte, Softwaresysteme modernisiert und erweitert, andererseits werden neue Systeme agil, das heißt in kleineren Inkrementen und kürzeren Intervallen, gebaut.
Stefan Sturm: Diese Unterschiede haben natürlich Konsequenzen für das Requirements Engineering, denn das muss sich an diese Methoden anpassen. Genau das beschreiben wir im CPRE Foundation Level 3.0.
Diese neue Anpassungsfähigkeit des Requirements Engineerings bezieht sich aber nicht nur auf die im Projekt eingesetzten Softwareentwicklungsmethoden, sondern auch auf die Domäne des Projekts. In Branchen wie Medizintechnik, Handel oder Telekommunikation haben Anforderungen an Zuverlässigkeit, Sicherheit, Performance oder Ease of Use eine völlig unterschiedliche Wichtigkeit. Genauso ist es mit Blick auf die Priorität der Anforderungen ein Riesenunterschied, ob ein Batch-Job, eine interne Online-Anwendung oder eine Web-App für Kunden beziehungsweise Lieferanten entwickelt wird. Abhängig von der Domäne können die RE-Prozesse völlig unterschiedlich aussehen.
„Zwar fordert der Markt oft sehr schnell neue Produkte, doch an dieser Stelle kann sich die Entdeckung der Langsamkeit durchaus als Vorteil entpuppen. Wir können nicht jedes Jahr die Kurse fundamental verändern, denn das könnten weder Trainingsanbieter so schnell umsetzen noch die Schulungsteilnehmer verinnerlichen.“ Stefan Sturm
Was sind die größten Vorteile dieser inkrementellen Weiterentwicklung der Zertifizierungen?
Stan Bühne: Sie ist sehr praxisorientiert. Wir sehen, wie die Unternehmen aktuell in der Softwareentwicklung arbeiten und wie die Kursteilnehmer auf das Training reagieren. Daran erkennen wir, wenn es Veränderungsbedarf gibt.
Stefan Sturm: Dazu kommt unsere interne Expertise, sowohl aus dem praktischen als auch aus dem akademischen Umfeld. Diese Expertise stellt sicher, dass unsere Standards immer „state of the art“ sind. Mit dem zusätzlichen Feedback von außen entstehen so marktgerechte Produkte. Zwar fordert der Markt oft sehr schnell neue Produkte, doch an dieser Stelle kann sich die Entdeckung der Langsamkeit durchaus als Vorteil entpuppen. Wir können nicht jedes Jahr die Kurse fundamental verändern, denn das könnten weder Trainingsanbieter so schnell umsetzen noch die Schulungsteilnehmer verinnerlichen.
Stan Bühne: Es kommt ja vor allem auf die gelungene Kommunikation und das gemeinsame Verständnis im Projekt an. Da wäre die rasche Änderung der Schulungsinhalte kontraproduktiv. Für die Teilnehmer wäre es auch frustrierend, wenn das Erlernte schon nach ein zwei Jahren wieder obsolet wäre.
Stefan Sturm: Mit unserer Art zu arbeiten schaffen wir es, die Trends zu erkennen, und wenn sie bleiben, in unseren Standard aufzunehmen. Gleichzeitig gehen kurzfristige Hypes aber an uns vorbei, weil sie schon wieder abklingen, bevor wir solche Modetrends in unsere Zertifikate und Schulungsinhalte übernommen haben.
„Tester müssen wissen, welche Arten von Anforderungen es gibt – und welche Priorität und Kritikalität diese Anforderungen haben.“ Stan Bühne
Am Ende der Prozesskette „Entwicklung“ steht der Tester, der validieren muss, ob das Ergebnis den Anforderungen des Kunden entspricht …
Stan Bühne: Genau. Und dafür hat er natürlich bewährte Tools und Testmethoden. Er muss aber auch genau wissen, was die Anforderungen des Kunden sind. Deshalb sollten die Tester auch möglichst früh in den Entwicklungsprozess involviert werden – und nicht erst ganz am Ende mit den Ergebnissen konfrontiert werden.
Tester müssen wissen, welche Arten von Anforderungen es gibt – und welche Priorität diese Anforderungen haben. Worauf ist bei Qualitätsanforderungen besonders zu achten, worauf bei funktionalen Anforderungen? Wie sind Modelle aufgebaut – und wie sind Aktivitäts- oder Sequenzdiagramme zu interpretieren? Wie interagiert das System mit dem Benutzer, wie mit anderen Systemen? Versteht man die Zusammenhänge, kann man bessere Testszenarien aufbauen und in Ende-zu-Ende-Betrachtungen sogar in sehr großen Systemlandschaften überprüfen, ob die Anforderungen erfüllt werden – ob also der Auftraggeber wirklich das erhält, was er bestellt hat. Das Software-Design in Verbindung mit der Anforderungsspezifikation bildet dafür eine gute Grundlage.
Stefan Sturm: Ganz wichtig ist auch die Kommunikation auf Augenhöhe. Der Tester darf nicht als Überbringer schlechter Botschaften und Termingefährder diskreditiert werden, sondern muss vielmehr als jemand wertgeschätzt werden, der die Qualität der Arbeit des gesamten Teams verbessert.
Seit Mitte vergangenen Jahres bietet IREB eine Zertifizierung zum „Digital Design Professional“. Was genau macht ein solcher DDP?
Stan Bühne: Den Begriff des Digital Designs hat der Branchenverband Bitkom vor drei, vier Jahren geprägt. Die Idee: Im Zuge der digitalen Transformation brauchen wir Menschen, die die Gestaltung digitaler Lösungen anders verstehen und begleiten als die klassischen Rollenbilder Business-Analyst, Requirements Engineer, Entwickler oder Tester. Heute schaffen diese klassischen Jobprofile und Rollenbilder oft künstliche Grenzen im Verantwortungsbereich; dann sagt der Requirements Engineer: Ich habe alle Anforderungen spezifiziert – I am out of business! Und am Ende des Prozesses kommt der Tester und muss im schlimmsten Fall die Scherben zusammenkehren.
Das soll der Digital Design Professional grundlegend ändern, indem er das große Ganze bedenkt, von der Idee der Anwendung über Konzeption und Realisierung bis hin zu Evaluierung, Implementierung und Betrieb. Ein DDP ist also wie ein Architekt im Bauwesen: Er setzt die Idee des Auftraggebers in einen konkreten Plan um und stellt dessen terminund kostengerechte Umsetzung sicher. Dazu hat der DDP wie ein Architekt das nötige Grundverständnis von den einzelnen Gewerken, zieht aber natürlich bei Detailfragen Experten wie Requirements Engineers, Softwarearchitekten, UXler und Tester zurate.
„Der Digital Design Professional bedenkt das große Ganze, von der Idee der Anwendung über Konzeption und Realisierung bis hin zu Test, Implementierung und Betrieb.“ Stan Bühne
Warum werden DDPs immer wichtiger? Eigentlich könnte man den Requirements Engineer doch auch als „Digital Designer“ begreifen ...
Stefan Sturm: Viele Requirements Engineers werden Ihnen genau das auch bestätigen. Demgegenüber steht das klassische Berufsbild eines Requirements Engineers, der sich eher als „Durchlauferhitzer“ versteht. Er sammelt und ermittelt zwar alle Anforderungen und bringt sie in eine entsprechende Dokumentationsform, die weiterverarbeitet werden kann, aber er ist dabei nicht kreativ. Er ist also kein Gestalter, sondern nimmt die Anforderungen als gegeben hin. Hier stößt er angesichts der digitalen Transformation an Grenzen, denn dabei geht es auch um neue Geschäftsmodelle. Und dafür gibt es noch keine Experten, die der Requirements Engineer fragen könnte. Deshalb ist hier mehr gefragt als nur das akribische Aufspüren von Anforderungen – vor allem Fantasie und Kreativität.
Anfangs gilt es, viele unterschiedliche Lösungsideen zu entwickeln und diese dann auf ihre Tragfähigkeit hin abzuklopfen. So etwas macht ein DDP. Erst wenn er eine Lösungsidee hat, kommt der Requirements Engineer ins Spiel und erstellt die Anforderungsspezifikation. Das Denken in Lösungsräumen war früher für den Requirements Engineer sogar unerwünscht – er hatte nur die Anforderungen zu spezifizieren, die er ermittelt hat. Das ist ein Paradigmenwechsel.
Welche Vorteile bringt es für das Testing, wenn die zu testende Software von DDPs gestaltet wurde?
Stan Bühne: Vor allem werden die Tester früher in den Entwicklungsprozess einbezogen. Gerade bei der explorativen Arbeit des DDP, beispielsweise mit frühen Prototypen, kann der Input aus dem Testing sehr relevant sein. Hier kann zum Beispiel in einer sehr frühen Projektphase validiert werden, ob das geplante Zusammenspiel von Software und Hardware, beispielsweise Tablet oder Smartwatch, auch tatsächlich funktioniert. Das wird Tester und DDP in Zukunft vermutlich sehr eng zusammenbringen. Für seine Arbeit braucht der DDP aber auch all die anderen Experten, etwa für die Gestaltung von Usability oder Schnittstellen oder für die stabile, sichere und performante Implementierung einer digitalen Lösung.
Meine Herren, vielen Dank für das Gespräch!
