Die Anforderung klingt einfach – was vor der ABAP-Entwicklung geklärt sein muss

„Im Lieferungsmonitor brauchen wir noch einen Button, mit dem sich die ausgewählten Lieferungen gesammelt verarbeiten lassen.“

Das klingt nach einer überschaubaren Erweiterung. Der Button bekommt einen Namen, die markierten Zeilen werden übergeben, eine Verarbeitungsroutine wird aufgerufen. Danach erscheint eine Erfolgsmeldung.

Aber was passiert, wenn eine der Lieferungen bereits bearbeitet wurde? Wenn ein anderer Benutzer gerade daran arbeitet? Oder wenn die Verarbeitung für einige Lieferungen gelingt und für andere scheitert?

An solchen Fragen entscheidet sich, wie die Funktion tatsächlich aussehen muss. Sie beeinflussen die Verarbeitung, die Rückmeldungen und den Arbeitsablauf der Menschen, die den Monitor verwenden.

Ich würde deshalb vor dem ersten Coding klären, welche fachliche Entscheidung hinter der gewünschten Funktion steckt. Ein Button beschreibt zunächst eine Bedienhandlung. Die Anforderung muss zusätzlich beschreiben, welches Ergebnis unter welchen Bedingungen entstehen soll.

Vom gewünschten Bedienelement zum fachlichen Ziel

Nehmen wir ein bewusst vereinfachtes, konstruiertes Beispiel: In einem kundeneigenen Lieferungsmonitor sollen Versandmitarbeiter eine vorhandene Prüf- und Freigabefunktion künftig für mehrere Lieferungen gemeinsam starten können. Bisher müssen sie jede Lieferung einzeln aufrufen. Die Freigabe ist in diesem Beispiel ein kundeneigener Bearbeitungsstatus.

Der eigentliche Bedarf lautet dann:

Versandmitarbeiter sollen geeignete Lieferungen gesammelt prüfen und freigeben können. Anschließend müssen sie erkennen, welche Lieferungen freigegeben wurden und wo noch etwas zu tun ist.

Damit lässt sich arbeiten. Die Formulierung benennt Nutzer, Tätigkeit und erwartetes Ergebnis. Sie lässt außerdem Raum, die passende Bedienung zu finden.

Ich würde an dieser Stelle auch fragen, warum die Einzelbearbeitung stört. Ist es die Zahl der Aufrufe? Fehlt eine Übersicht? Oder müssen Mitarbeiter dieselben Angaben immer wieder erfassen? Je nach Antwort kann eine andere Änderung den größeren Nutzen bringen.

Wörter wie „geeignet“ brauchen eine eindeutige Bedeutung

Im Beispiel steckt die wichtigste offene Frage in einem einzigen Wort: Welche Lieferungen sind für die Freigabe geeignet?

„Alle offenen Lieferungen“ reicht als Antwort noch nicht aus. Offen kann bedeuten, dass die kundeneigene Freigabe fehlt. Es könnte aber auch ein anderer Bearbeitungsstand gemeint sein. Bevor daraus eine Bedingung im Code wird, braucht der Begriff eine gemeinsame Definition.

Für unser Beispiel wären folgende Punkte zu entscheiden:

• Welche fachlichen Voraussetzungen muss eine Lieferung erfüllen?
• Welche Sperren oder fehlenden Angaben schließen die Freigabe aus?
• Gilt die Regel für die gesamte Lieferung oder für einzelne Positionen?
• Darf die Sammelverarbeitung dieselben Lieferungen bearbeiten wie die Einzelverarbeitung?

Besonders die letzte Frage ist wichtig. Wenn beide Wege dieselbe fachliche Handlung auslösen, sollten ihre Regeln zusammenpassen. Eine abweichende Regel für die Sammelverarbeitung braucht eine bewusste fachliche Entscheidung.

Für die Abstimmung würde ich einige konkrete Fälle nebeneinanderlegen: eine geeignete Lieferung, eine bereits freigegebene und eine mit fehlenden Pflichtangaben. An solchen Beispielen werden unterschiedliche Vorstellungen schneller sichtbar als an einem langen Fließtext.

Bei gemischten Ergebnissen wird aus dem Button ein Prozess

Angenommen, ein Mitarbeiter markiert zehn Lieferungen. Acht erfüllen die Voraussetzungen. Bei einer fehlen Angaben, eine weitere wird gerade von jemand anderem bearbeitet.

Jetzt muss entschieden werden: Sollen die acht geeigneten Lieferungen verarbeitet werden? Oder darf die gesamte Auswahl erst verarbeitet werden, wenn alle zehn geeignet sind?

Beides kann fachlich sinnvoll sein. Für unabhängig voneinander freizugebende Lieferungen würde ich eine getrennte Verarbeitung mit einem Ergebnis je Lieferung bevorzugen. Müssen die ausgewählten Objekte dagegen zwingend gemeinsam einen Zustand erreichen, braucht die Funktion ein anderes Konzept.

Diese Entscheidung sollte der Fachbereich vor der Umsetzung treffen. Sie bestimmt, was ein Teilfehler bedeutet und wie die technische Verarbeitung aufgebaut werden muss.

Auch die Rückmeldung gehört dazu. „Verarbeitung abgeschlossen“ hilft dem Mitarbeiter wenig, wenn zwei Lieferungen offen geblieben sind. Er braucht eine Zuordnung: Was wurde erledigt? Was wurde übersprungen? Welche Ursache kann er selbst beheben?

Eine Anzeige ist noch keine Zusage für die Verarbeitung

Zwischen dem Laden der Liste und dem Klick auf den Button kann sich der Zustand einer Lieferung ändern. Ein anderer Benutzer könnte sie bereits freigegeben haben. Eine zuvor freie Lieferung könnte inzwischen in Bearbeitung sein.

Die Anforderung sollte deshalb festhalten, dass die maßgeblichen Voraussetzungen bei der Ausführung erneut geprüft werden müssen. Welche technischen Sperr- und Transaktionsmechanismen dafür geeignet sind, gehört anschließend in das Umsetzungskonzept.

Außerdem braucht die Funktion eine Antwort auf einen alltäglichen Fall: Der Mitarbeiter ist unsicher, ob der erste Klick erfolgreich war, und startet die Verarbeitung erneut.

Für unser Beispiel würde ich festlegen, dass bereits freigegebene Lieferungen unverändert bleiben und eine verständliche Rückmeldung erhalten. Löst eine Funktion zusätzliche Folgeaktionen aus, muss auch deren Verhalten bei einer Wiederholung geklärt werden.

Solche Fragen sind Teil des normalen Arbeitsablaufs. Sie gehören in die Anforderung, bevor sie als überraschender Fehler im Test auftauchen.

Verantwortlichkeiten gehören ins Ticket

Eine fachlich richtige Verarbeitung kann trotzdem am Bedarf vorbeigehen, wenn die falschen Benutzer sie ausführen dürfen oder niemand für offene Fälle zuständig ist.

Ich würde deshalb mit dem Fachbereich klären, wer die neue Sammelfunktion nutzen soll und ob dafür derselbe Berechtigungsumfang wie für die Einzelbearbeitung gilt. Eine sichtbare Schaltfläche allein beschreibt noch keine ausreichende Berechtigungsprüfung.

Ebenso wichtig ist der Umgang mit Fehlern: Korrigiert der Versandmitarbeiter fehlende Angaben selbst? Geht der Fall an einen anderen Bereich? Muss der Support später nachvollziehen können, wer welche Lieferung verarbeitet hat?

Aus den Antworten ergibt sich, welche Meldungen und welcher Nachweis benötigt werden. Der Umfang sollte zum Prozess passen. Eine kurzzeitige Rückmeldung kann für den Anwender genügen, während der Support für die Fehleranalyse einen länger verfügbaren Verarbeitungsnachweis benötigt.

Abnahmekriterien machen offene Entscheidungen sichtbar

Für das konstruierte Beispiel nehmen wir an, dass geeignete Lieferungen unabhängig voneinander verarbeitet werden dürfen. Daraus lässt sich eine kleine Abnahmematrix formulieren:

Ausgangssituation	Erwartetes Verhalten
Alle ausgewählten Lieferungen erfüllen die Voraussetzungen.	Alle werden freigegeben; das Ergebnis wird je Lieferung angezeigt.
Eine Lieferung enthält nicht alle erforderlichen Angaben.	Sie bleibt unverändert und erhält eine konkrete Meldung. Die übrigen geeigneten Lieferungen werden verarbeitet.
Eine Lieferung wurde zwischenzeitlich bereits freigegeben.	Sie bleibt unverändert; die Rückmeldung nennt den aktuellen Zustand.
Eine Lieferung ist durch eine andere Bearbeitung gesperrt.	Sie wird übersprungen und als derzeit nicht verarbeitbar ausgewiesen.
Dem Benutzer fehlt die erforderliche Berechtigung.	Die betroffene Freigabe wird abgelehnt; es erfolgt keine unberechtigte Änderung.
Die gleiche Auswahl wird erneut gestartet.	Bereits freigegebene Lieferungen werden nicht erneut geändert. Noch offene Fälle werden anhand ihres aktuellen Zustands geprüft.

Die Tabelle ist kein vollständiges Testkonzept. Sie macht aber die wesentlichen Entscheidungen prüfbar. Für den Test kommen konkrete Testdaten und die vereinbarten Voraussetzungen hinzu.

Auch die erwartete Menge gehört in die Abstimmung. Eine Funktion für wenige ausgewählte Lieferungen kann andere Anforderungen an Laufzeit, Rückmeldung und Verarbeitung haben als ein regelmäßig gestarteter Massenlauf. Eine belastbare Grenze lässt sich erst vereinbaren, wenn Datenmengen und technische Rahmenbedingungen bekannt sind.

Wie viel Klärung ist vor dem Start nötig?

Nicht jede kleine Erweiterung braucht ein umfangreiches Fachkonzept. Für das Beispiel können ein klarer Zielsatz, die fachlichen Regeln und eine abgestimmte Abnahmematrix bereits eine gute Grundlage sein.

Vor der Umsetzung sollten jedoch die Entscheidungen feststehen, die das Verhalten bestimmen: Welche Objekte dürfen verarbeitet werden? Was passiert bei Teilfehlern? Wer darf die Funktion nutzen? Und welches Ergebnis wird abgenommen?

Technische Unsicherheiten können eine begrenzte Voranalyse erfordern. Wenn beispielsweise unklar ist, ob sich die vorhandene Einzelverarbeitung für mehrere Lieferungen verwenden lässt, würde ich genau diese Frage untersuchen und die Konsequenzen zurückmelden. Fachlich ungeklärte Regeln würde ich dabei als offene Entscheidungen festhalten.

Mein Fazit

Eine brauchbare Anforderung muss nicht lang sein. Sie muss an den Stellen eindeutig sein, an denen unterschiedliche Auslegungen zu unterschiedlichem Verhalten führen.

Bevor ich eine ABAP-Erweiterung umsetzen würde, möchte ich an wenigen konkreten Fällen erklären können, was sie tun soll, wann sie eine Verarbeitung ablehnt und wie der Anwender anschließend weiterarbeitet.

Wenn sich diese Fälle mit dem Fachbereich abstimmen lassen, entsteht eine belastbare Grundlage für Entwicklung und Abnahme. Der Button ist dann nur noch ein Teil einer verstandenen Aufgabe.