Komplexität im Requirements Engineering

Nach unserer Auffassung entsteht Komplexität im Requirements Engineering nicht allein durch die Menge der Anforderungen, die Kritikalität des Systems oder die Anzahl an Stakeholdern, sondern dadurch dass sowohl das zu entwickelnde System als auch die dazu verwendete (RE-)Methode von den Beteiligten als herausfordernd empfunden wird. Hat ein RE-Experte beispielsweise „nur“ mit einer großen Anzahl von Anforderungen zu tun, aber weiß, wie man diese systematisch erschließen kann, so ist für diese Person das Requirements Engineering zwar durchaus fordernd (insbesondere was die Verwaltung und Pflege der riesigen Anforderungsmenge betrifft), aber nicht unmittelbar komplex, da er / sie die notwendigen Methoden und Werkzeuge besitzt. Anders herum kann aber für weniger RE-versierte Personen bereits das Erheben und Dokumentieren von Anforderungen an ein recht überschaubares System als herausfordernd empfunden werden, wenn ihnen die dafür notwendigen Skills und Erfahrungen fehlen.

Komplexität durch zweidimensionale KompliziertheitDie wirklich erfolgskritische Komplexität im Requirements Engineering entsteht erst dann, wenn beide Aspekte zusammenkommen: Nicht-Experten (und damit sind keine Laien oder Anfänger gemeint, sondern gemäß der Definition von Doug Norman Menschen, die nicht mindestens 5.000 Stunden praktische Erfahrung haben) sollen Requirements Engineering für große Systeme durchführen. Obwohl dies auf den ersten Blick grob fahrlässig und gar unrealistisch klingen mag, so belegen Studien wie zuletzt der RE Kompass 2014/2015, dass dies eher die Regel als die Ausnahme darstellt. Häufig führen Personen Requirements Engineering Aufgaben in Projekten durch, obwohl sie dies nie richtig gelernt haben, nur wenige Prozent ihrer Arbeitszeit darauf verwenden und auch von ihren Kollegen als  nur „mittelmäßig gut“ hierin eingeschätzt werden.

Typische Herausforderungen die einem Projektteam dadurch erwachsen gehen von einfachen Fragestellungen wie beispielsweise nach dem verständlichen und homogenen Dokumentieren über eine schrittweise Verfeinung und sinnvolle Strukturierung bis hin zu Wiederverwendung, Vollständigkeitsprüfung oder dem Finden der richtigen Detailebene. Vielbeworbene Zertifizierungslehrgänge liefern hierfür zwar erste Antworten, aber gute und vollständige Anforderungen lassen sich i.d.R. nur kontextspezifisch auf Basis von langjähriger Erfahrung verlässlich und effizient gewinnen. Der Spruch „A Fool with a Tool is still a Fool“ mag daher in diesem Zusammenhang zunächst passend erscheinen, berücksichtigt man die Möglichkeiten und Funktionalität etablierter Requirements Management Werkzeuge am Markt.

Allerdings zeigen Werkzeuge aus anderen Branchen und Anwendungsfeldern längst, dass der Spruch „A Fool with a Tool is still a Fool“ – der im Übrigen aus den frühen 1980er stammt, als erste PCs Einzug in Büros hielten – nur noch bedingt Gültigkeit besitzt. Gute Gegenbeispiele sind Programme für die Erstellung von Steuererklärungen oder Navigationssysteme im Auto. Solche Werkzeuge erlauben auch ohne Expertenwissen (z.B. zu Steuerrecht, ELSTER-Formularen, etc.) oder einer umfassenden Kenntnis über mögliche Wege, ein Ziel oder Ergebnis zumindest „gut genug“ zu erreichen. Insofern sehen wir einen Markt für neuartige und intelligente Werkzeuge auch im Requirements Engineering und Management, da der vereinfachte Ansatz „wir schulen erst mal unsere Mitarbeiter und schaffen dann ein RM Tool an“ viel zu kurz greift (denken Sie an die 5.000 Stunden Erfahrung), um komplexen Anforderungssituationen gemäß oben genannter Definition wirklich effizient zu begegnen.

Entsprechend hat uns gefreut, dass neben uns auch andere (kleinere) Hersteller von RE/RM-Werkzeugen die Notwendigkeit zunehmender Automatisierung und Assistenz erkannt haben. Während diese Anbieter jedoch oft isolierte Probleme wie die Transformation oder Qualitätssicherung von Anforderungen beleuchten, hilft unsere ReqSuite® den gesamten Prozess der systematischen Herausarbeitung von Anforderungen zu erleichtern. Hierfür konnten wir in unserem Vortrag anhand zahlreicher typischer Fragestellung überzeugende Beispiele liefern.

Der gesamte Vortrag findet sich hier.

Sebastian Adam
Sebastian Adam
Dr. Sebastian Adam ist Geschäftsführer der OSSENO Software GmbH und operativ für die Bereiche Produktinnovation und Marketing verantwortlich. Vor seiner Zeit bei OSSENO arbeitete er 10 Jahre lang als Berater, Wissenschaftler und Teamleiter für Requirements Engineering am Fraunhofer-Institut für Experimentelles Software Engineering (IESE). Dr. Adam hat bereits mehrere Duzend Unternehmen begleitet und verfügt über branchenübergreifende Best Practices bezüglich der Einführung und Durchführung von Requirements Engineering.