Anforderungsmanagement als Brückenbauer zwischen Geisteswissenschaft und IT

2. Wie bringen Sie die verschiedenen Anforderungen aus den Entwicklungsbereichen der verteilt arbeitenden Teams auf einen gemeinsamen Nenner?

Anforderungsmanagement ist im Wesentlichen eine vermittelnde und ausgleichende Aufgabe. Wie in Malgorzata Aschs Blogartikel am Beispiel des Fluges zur „Insel der Erwartungen“ veranschaulicht wurde, ist der Weg zum Ziel kein gerader, sondern muss Schritt für Schritt neu bestimmt werden.

Betrachtet man die Anforderungen an ein System als eine gemeinsame Menge, so soll diese einerseits vollständig sein: Ein System auf der Basis korrekter, aber nicht umfassender Anforderungen wird nicht die Erwartungen der Nutzer:innen erfüllen. Andererseits darf zwischen den einzelnen Anforderungen kein Widerspruch existieren. Da sie jedoch aus potentiell unterschiedlichen Quellen kommen, ist es keineswegs außergewöhnlich, dass sie initial eben nicht zueinander passen. Zum Anforderungsmanagement gehört daher nicht zuletzt die Identifikation dieser Widersprüche, die Priorisierung der Sachverhalte und die Suche nach möglichst widerspruchsfreien Kompromissen.

Ein Projekt kann nur dann mit Erfolg enden, wenn die Anforderungen ein konsistentes Bild des zu entwickelnden Systems liefern. Zu diesem Bild gehört nicht zuletzt seine Überprüfbarkeit bzw. Testbarkeit. Grundlage hierfür sind definierte Akzeptanzkriterien. Ein Anforderungsmanagement kann nur dann wirksam werden, wenn verifizierbar ist, ob eine bestimmte Anforderung tatsächlich fachgerecht umgesetzt wurde. Hier schließt sich der Kreis. Die Realität sieht – zumindest im Cartoon – oft anders aus:

3. Wie würden Sie Ihre Rolle im Projektzusammenhang beschreiben? Wofür genau sind Sie verantwortlich?

Im Sinne der oben skizzierten Definition verstehe ich mich und meine Aufgabe als Schnittstelle zwischen Fachseite und IT. Dabei liegt mein inhaltlicher Schwerpunkt als Mitarbeiterin der Berliner IT im Bereich von Backend und Nachweis. Zusammen mit dem Product Owner plane und spezifiziere ich die Aufgaben für jeden Sprint und teste die Entwicklungsergebnisse. Konkret bin ich u.a. an der Definition der Importformate, der Benutzeroberfläche des Erfassungsmoduls sowie der fachlichen Modellierung der Daten beteiligt. Außerdem entwickle ich Konzepte für so diverse Themen wie Normdaten, Rollen und Rechte oder die Strukturierung der Beschreibungsdokumente. Gleichgültig, an welcher Stelle der Entwicklung Anforderungen formuliert und Entscheidungen getroffen werden, sie haben potentiell Implikationen auf andere Bereiche, auch wenn diese auf den ersten Blick voneinander entkoppelt scheinen. Daher muss ich kontinuierlich auch Querschnittsanforderungen an das Gesamtsystem identifizieren und im Blick behalten.

4. Wie wurden und werden die Anforderungen an das Erfassungsmodul erhoben?

Die erste Grundlage für die Anforderungsanalyse bietet der von der Deutschen Forschungsgemeinschaft (DFG) genehmigte Antrag. Bereits bei der Vorbereitung des Projekts wurden viele Anforderungen identifiziert und die wichtigsten Grundsteine für das Portal gelegt. Allerdings werden für die Steuerung der eigentlichen Systementwicklung Anforderungen mit feinerer Granularität benötigt.

Eine wichtige Perspektive des Handschriftenportals ist es, die bereits existierenden Systeme Manuscripta Mediaevalia und HiDA (MXML) abzulösen. Daher liefert die Analyse dieser Systeme eine wertvolle Quelle der Anforderungen. Im Mittelpunkt steht dabei natürlich die Frage, was fehlt bzw. verbessert werden kann. Interessant sind aber auch Informationen darüber, was bislang als gut empfunden wurde und im neuen System nicht fehlen darf. Um dieser Analyse eine Basis in der konkreten Erschließungsarbeit zu geben, habe ich – natürlich noch vor Corona – Vor-Ort-Interviews mit Mitarbeiter:innen der Handschriftenzentren durchgeführt und sie bei der Arbeit beobachtet. Im Anschluss hieran haben wir am 21. Januar 2020 einen Benutzerworkshop in Berlin veranstaltet, um zusätzliche Anforderungen weiterer Nutzer:innenkreise außerhalb der Handschriftenzentren zu erheben.

Eine zuverlässige Quelle der fachlichen Anforderungen sind aber natürlich die Projektmitarbeiter:innen selbst. Ein großes Glück und gleichzeitig ein Erfolgsfaktor des Projekts ist, dass im Projekt-Team bereits langjährige Erfahrungen und umfangreiches Know-how vorhanden sind. Somit können Anforderungen kontinuierlich identifiziert und priorisiert sowie Widersprüche durch schnelle fachliche Entscheidungen aufgelöst werden.

Unser Projekt läuft über mehrere Jahre und die Welt dreht sich in dieser Zeit weiter. Jenseits der engeren Anforderungslogik gibt es in diesem Projekt aber glücklicherweise auch Platz für ‘visionäre’ Ideen. Diese werden dokumentiert, priorisiert und im Realisierungsfall konzeptionell ausgearbeitet. Wenn sie aktuell nicht umgesetzt werden können, kommen sie in den ‘Inspirationsspeicher’ für eine mögliche zweite Projektphase.

5. Sie arbeiten an der Schnittstelle zwischen Fachseite und IT – ein Spagat zwischen der Definition fachlicher Anforderungen und der Umsetzung in konkrete Entwicklungsaufgaben. Wie stellen Sie eine gute und funktionierende Kommunikation sicher?

Wir entwickeln über mehrere Jahre hinweg ein komplexes System in einem über mehrere Standorte verteilten Team. Es ist natürlich eine enorme kommunikative Herausforderung, Anforderungen zu erheben, diese in konkrete Aufgaben, Konzepte und Entscheidungen zu übersetzen und gleichzeitig ihre Transparenz und Rückverfolgbarkeit – und damit ihre Glaubwürdigkeit und Stabilität – zu gewährleisten. Eine Hilfe liefert hier der Leitgedanke der von uns betriebenen agilen Entwicklung: Wir gehen von den jeweils einfachen Fällen aus und erarbeiten zuerst einen gemeinsamen Nenner für Ausnahmen und Sonderfälle. Anschließend erweitern wir iterativ die Regeln, um diese Sonderfälle gruppieren und in die Anforderungslogik einbauen zu können.

Die Projektmitarbeiter:innen haben jeweils unterschiedliche fachliche Hintergründe und Kompetenzen. Um bei der enormen Menge aller Einzelaufgaben immer fokussiert arbeiten zu können, werden je nach anstehenden Fragen und Entscheidungen unterschiedliche Arbeitsgruppen mit konkreten Aufgaben gebildet. Ein gutes Beispiel hierfür ist die sogenannte ‘ODD-Runde’, die ein TEI-Meta-Modell der Beschreibungen im HSP definiert. An dieser Arbeitsgruppe sind – ein so typisches wie notwendiges Charakteristikum – sowohl Vertreter:innen der Fachseite als auch der Entwickler:innen-Runde beteiligt.

Eine wichtige Rolle spielt die Dokumentation all dieser Schritte. Sie macht die Projektkommunikation transparent und hat sich mit der Zeit zu einer Art ‘Gruppengedächtnis’ entwickelt. Bei ihr geht es eben nicht nur um die Dokumentation der eigentlichen Entwicklungsergebnisse, sondern auch um eine solche des Projektes selbst. Ideen, Konzepte, Ergebnisse diverser Treffen und die aus ihnen folgenden Festlegungen werden aufgeschrieben. Dabei wird festgehalten, wann und mit wem sie abgestimmt wurden. Unser Projekt-Wiki hat mittlerweile über 550 Wiki-Seiten unterschiedlicher Länge.

6. Was waren die bisher größten Herausforderungen?

Ich glaube, dass die größte Herausforderung die Domäne ist, für die wir das Portal entwickeln. Handschriften sind von Natur aus einzigartig und sträuben sich bei näherem Hinsehen oftmals gegen scheinbar passende ‘Lösungen’. Entsprechend sind die Stakeholder im Projekt Geisteswissenschaftler:innen, deren Denkweise arbeitsbedingt auf die Analyse von Einzelfällen fokussiert ist. Um IT-Systeme zu entwickeln, braucht man jedoch wiederholbare und beherrschbare Regeln, die mithilfe einer Programmiersprache implementiert werden können. Die Vermittlung zwischen der Sphäre der materiellen Unikalität und der geisteswissenschaftlichen Herangehensweise einerseits und der deterministischen, regelbasierten Welt der Informatik andererseits ist eine tägliche Notwendigkeit und stellt für mich zweifellos die größte Herausforderung dar.

7. Ein Blick in die nahe Zukunft: Stehen morgen konkrete Aufgaben im Projektkontext an? Welche sind das?

In den letzten Wochen haben wir die Entscheidung für die Entwicklungstechnologie des Beschreibungseditors getroffen. Anhand einer prototypischen Implementierung wurde eine Evaluierung durchgeführt. Diese Entscheidung setzt den Rahmen, innerhalb dessen nun sinnvolle Arbeitspakete für die Entwicklung des endgültigen Erfassungssystems definiert werden können. Ich werde mich ab morgen dieser Aufgabe widmen.