Empirisches Requirements Engineering

Beim Requirements Engineering geht es darum, zu vollständigen, korrekten, verständlichen Anforderungen zu gelangen und diese aktuell zu halten. Mithilfe von Interview-, Moderations- und Recherchetechniken, aber auch mit Tätigkeiten wie Analyse und Synthese, Modellierung und Formulierung, Komplexitätsverwaltung, Machbarkeitsstudien, quantitative Prognosen und Managemententscheidungen, versuchen Organisation, diese Aufgabe zu lösen.

Im Requirements Engineering gibt es eine Vielzahl an empfohlenen Methoden und Techniken, und da jedes Projekt andere Rahmenbedingungen hat, passt nicht jede Methode überall gleich gut. Eine ähnliche Situation gibt es in der Medizin, wo zahlreiche Behandlungsmethoden und Medikamente miteinander konkurrieren. Jeder einzelne Arzt kann selbst nur stichprobenartige Erfahrungen sammeln. Darum schafft die evidenzbasierte Medizin systematisch und wissenschaftlich mit Hilfe von empirischer Forschung die Wissensgrundlage für Ärzte, damit diese fundiert und objektiv für jeden Fall die passende Behandlung auswählen können. Analog dazu untersucht das empirische Requirements Engineering die Wirksamkeit verschiedener Ansätze in unterschiedlichen Anwendungsbereichen.

Herausforderungen beim empirischen Requirements Engineering

Als ich vor rund 20 Jahren mit der Requirements Engineering Forschung begann, war ich erschüttert von dem niedrigen Niveau an wissenschaftlichem Anspruch in der Community. Das hatte ich während des Studiums anders gelernt. Die Informatik war um die Jahrtausendwende nicht nur in der Praxis eine Spielwiese für exploratives Ausprobieren, wo sich erst noch allgemein anerkannte Vorgehensweisen und Qualitätsstandards entwickeln mussten. Das hat erfreulich gut geklappt. Es gibt nun jede Menge Standardwerke an Büchern und vielzitierten Artikeln, die Maßstäbe für empirische Studien im Software Engineering setzen wie beispielsweise die Bücher von Robert K. Yin über Fallstudien¹, der Artikel “Preliminary Guidelines for Empirical Research in Software Engineering”² von Kitchenham et al. oder die “Reporting Guidelines for Reporting Experiments in Software Engineering” des Fraunhofer IESE³ sowie Richtlinien für systematische Literaturübersichten (Systematic Reviews).

Die Fallstudie in einem einzigen Projekt ist immer noch die häufigste empirische Forschungsmethode im Software Engineering, hat aber wissenschaftlich gesehen die geringste Aussagekraft. Es werden auch immer mehr kontrollierte Experimente durchgeführt und durch Metastudien die Forschungsergebnisse zahlreicher Studien zusammengefasst.

Unterstützt werden kann die empirische Datensammlung durch quantitative Auswertungsverfahren wie beispielsweise Hypothesentests, Korrelationsanalysen und Faktorenanalysen. Die Schwierigkeit, endgültige Aussagen zu treffen, besteht aber darin, dass man grundsätzlich nicht dasselbe Projekt mehrmals durchführen kann, um es jedes Mal mit einer anderen Methode zu unterstützen und den Unterschied zu messen. Mit demselben Team kann man nicht zweimal unvoreingenommen dasselbe Projekt bearbeiten, weil es beim zweiten Durchlauf natürlich vom Wissen des ersten Durchlaufs profitiert. Führt man “dasselbe Projekt” mit unterschiedlichen Teams zweifach durch, mit anderen Methoden, dann weiß man nicht sicher, ob Unterschiede beim Ergebnis durch die Methode verursacht wurden oder dadurch entstanden, dass jeder Mensch anders ist. Auch bei Verwendung derselben Vorgehensweisen mit demselben Ziel und denselben Vorgaben kommt am Ende ein völlig anderes Ergebnis heraus. Das kann man sehr schön in der Lehre beobachten, wo diese Situation regelmäßig vorkommt.

Mögliche Strategien zur Nutzung der Empirie

Grundsätzlich wird die empirische Forschung durchgeführt, damit Praktiker in jeder Situation wissen, welche Technik oder Praktik für ihr Projekt oder ihr Problem am besten passt. Allerdings ist es gar nicht so einfach, aus der Flut an Forschungsergebnissen die richtigen Schlussfolgerungen zu ziehen. Es gibt dafür zwei Strategien:

1. Man sucht sich eine oder mehrere Fallstudien, die der eigenen Situation ähneln, z. B. bezüglich

• Teamgröße,
• Projektgröße,
• Projektart (Neuentwicklung versus Migration versus Weiterentwicklung) und
• Kundenbeziehung (Individualentwicklung für einen bestimmten Kunden versus Entwicklung eines Produkts für den Markt, also für zahlreiche Kunden)

und viele mehr.

Allerdings ist die Forschung nicht so weit, dass sie angeben könnte, bei welchen dieser Parameter Ihr Projekt mit einem untersuchten Projekt übereinstimmen muss, damit das dort erfolgreich einsetzte Vorgehen auch bei Ihnen zum Erfolg führen wird. Vermutlich ist das auch gar nicht möglich, weil zu viele Faktoren gemeinsam für den Projekterfolg nötig sind, ohne ihn garantieren zu können.

2. Man betrachtet Metastudien, die eine Vielzahl von Studien zusammenfassen. Allerdings gibt es momentan keine systematische Hilfe für Praktiker, solche Studien zu lesen und die für sie passenden Schlussfolgerungen daraus zu ziehen.

Die Anwendung empirischer Methoden während des Requirements Engineerings

Als ich ChatGPT befragte, was es unter empirischem Requirements Engineering versteht, brachte es mich auf eine zusätzliche Bedeutung, die der Begriff haben könnte, auch wenn er so bisher nicht verwendet wird: Die Anwendung empirischer Methoden während des Requirements Engineerings.

ChatGPT formulierte dies so: “Dieser Ansatz betont die Sammlung und Analyse von empirischen Informationen, um sicherzustellen, dass die Anforderungen tatsächlichen Bedürfnissen und Herausforderungen gerecht werden.”

Das würde bedeuten:

• Durchführung von Benutzerbefragungen, Interviews und Workshops für die Anforderungsermittlung und Priorisierung, von Marktanalysen und Prototypentests mit derselben Sorgfalt in Vorbereitung, Durchführung und Auswertung, mit der wissenschaftliche Studien durchgeführt werden.
• Priorisierung von Anforderungen auf der Grundlage von gesammelten Daten statt Pi mal Daumen.
• Prüfen von Anforderungen anhand von empirischen Methoden wie Prototypentests, Benutzertests und Simulationen, um sicherzustellen, dass sie tatsächliche Bedürfnisse befriedigen.
• Feedbackschleifen zur regelmäßigen Evaluierung der bisherigen Ergebnisse.

Das wiederum erinnerte mich an das Buch “Lean Startup”⁴ von Eric Ries, der ebenfalls empirische Methoden für die Produktentwicklung in einem Startup empfiehlt, insbesondere das Einholen von Endnutzer-Feedback und das Messen von Kennzahlen bzw. die Nutzung von Metriken. Das Requirements Engineering ist in diesem Buch nur ein Aspekt, aber ein wichtiger.

Auch Entwicklungs-Frameworks und Prozessverbesserungsmethoden wie Lean Production, PDCA, Six Sigma, Kanban und Engpasstheorie arbeiten grundsätzlich mit quantitativen Daten, um ein faktenbasiertes Management zu gewährleisten. Im Projektmanagement verwendet man die Earned-Value-Analyse.

Die Verfälschung der Daten

Je mehr die Softwarebranche Hilfsmittel wie Kanban-Boards bzw. Taskboards, Burndown Charts und Ticketsysteme verwendet, um die tägliche Arbeit zu protokollieren, umso leichter wird es, Kenngrößen des Prozessmanagements wie

• Fertigstellungsgrad,
• Produktivität (Velocity),
• Work in Progress,
• Durchsatz und Durchlaufzeit von Aufgaben

zu ermitteln. Je detaillierter die Arbeit verwaltet wird – auf Projektebene, als dreimonatiges Arbeitspaket, als zweiwöchiger Sprint oder eintägige Aufgabe – umso detaillierter und genauer werden diese Auswertungen. Mit allen Nebenwirkungen wie Auswertungsaufwand und Datenschutz.

Es verursacht beim Mitarbeiter natürlich einen gewissen psychischen Stress, wenn seine Arbeit stundengenau protokolliert und ausgewertet wird. Diesem Stress entzieht er sich durch Frisieren seiner Daten oder Vernachlässigung derjenigen Aufgaben, die wenige Punkte zählen. Die Überwachung wird somit gleichzeitig zur Steuerung. Auch das ist ein wissenschaftliches Prinzip: Wenn man Menschen beobachtet, ändern sie ihr Verhalten. Das verfälscht die Daten.

Fazit

Zusammenfassend würde ich also sagen: Die Idee ist prima. Es wird eifrig am empirischen Requirements Engineering gearbeitet – in vielen wissenschaftlichen Communities wie Forschungsinstituten, Konferenzen, Zeitschriften und Arbeitskreisen. Allerdings fehlt noch der letzte Schritt, um die Wissenskluft zwischen Forschung und Praxis zu überwinden, nämlich einfache Auswahlhilfen zu bieten, die es Praktikern erlauben, aus dem riesigen Wissenspool für sich selbst die richtigen Schlussfolgerungen zu ziehen, um bspw. für eine bestimmte Situation die passende Requirements Engineering Technik auszuwählen.

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

[1] Robert K. Yin: Case Study Research and Applications – Design and Methods
[2] B. A. Kitchenham: Preliminary guidelines for empirical research in software engineering
[3] A. Jedlitschka, D. Pfahl: Reporting guidelines for controlled experiments in software engineering
[4] Eric Ries: The Lean Startup

Dr. Andrea Herrmann hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.