Softwareentwicklung

Von der Kundenfrage zur technischen Spezifikation

„Kann die Software Angebote automatisch freigeben?“ Hinter dieser beispielhaften Kundenfrage steckt mehr als eine zusätzliche Schaltfläche. Bevor sich die Funktion sinnvoll umsetzen lässt, muss feststehen, welche Entscheidung die Anwendung übernehmen darf, welche Informationen sie dafür benötigt und was eine Freigabe anschließend bewirkt. Andernfalls entstehen diese Regeln während der Programmierung, ohne dass ihre fachlichen Folgen ausdrücklich besprochen wurden.

Wenn du Software beauftragst, musst du dafür keine technische Spezifikation mitbringen. Du kennst den bisherigen Arbeitsablauf und kannst beschreiben, was daran schwierig ist. Aus diesem Wissen entsteht schrittweise eine überprüfbare Arbeitsgrundlage. Das folgende allgemeine Beispiel einer Angebotsfreigabe zeigt diesen Weg; es beschreibt keinen konkreten Kundenfall.

Zuerst den Ablauf hinter der Frage verstehen

Eine automatische Freigabe erscheint zunächst als naheliegende Lösung für wartende Angebote. Die Wartezeit kann jedoch unterschiedliche Ursachen haben: Vielleicht werden regelmäßig dieselben Kriterien von Hand geprüft, vielleicht fehlen notwendige Angaben, oder die zuständige Person erfährt zu spät vom fertigen Entwurf. Eine Automatisierung der Entscheidung hilft nur, wenn sie die tatsächliche Ursache trifft.

Die erste Untersuchung folgt deshalb einem gewöhnlichen Angebot vom Entwurf bis zum Versand. Wer bearbeitet es, welche Informationen werden geprüft und an welcher Stelle bleibt es liegen? Anschließend lohnt sich ein schwieriger Fall, etwa ein Angebot mit individuellen Vertragsbedingungen. Der Vergleich macht sichtbar, welche Entscheidungen festen Regeln folgen und wo eine persönliche Einschätzung gebraucht wird.

Dabei sollten auch bisher unausgesprochene Kontrollen zur Sprache kommen. Wer ein Angebot öffnet, prüft möglicherweise neben dem Preis auch Lieferbarkeit oder Zahlungsbedingungen. Wird nur die sichtbare Freigabe automatisiert, können solche Nebenaufgaben versehentlich entfallen. Ein anonymisiertes Beispieldokument und die gemeinsame Betrachtung des tatsächlichen Ablaufs liefern dafür häufig eine bessere Grundlage als eine abstrakte Wunschliste.

Das Ergebnis dieser Phase ist ein konkretes Ziel. Im Beispiel sollen geeignete Standardangebote ohne manuelle Einzelentscheidung zum Versand bereitstehen. Ob dadurch relevante Wartezeit entfällt, hängt davon ab, wie häufig diese Angebote vorkommen und weshalb sie bisher aufgehalten werden. Diese Fragen gehören vor die Entscheidung über den technischen Aufbau.

Begriffe werden zu verbindlichen Regeln

„Freigegeben“ kann bedeuten, dass ein Angebot intern geprüft wurde, versendet werden darf oder bereits verschickt wurde. Für die Software sind das unterschiedliche Zustände. Im Beispiel soll die Freigabe ausschließlich die interne Erlaubnis zum Versand bezeichnen; eine E-Mail wird dadurch noch nicht ausgelöst.

Damit bekommt ein scheinbar gewöhnliches Wort konkrete Folgen. Die Oberfläche muss Freigabe und Versand unterscheiden, und nach erfolgreicher Prüfung darf kein automatischer Versand starten. Diese Abgrenzung verhindert, dass eine zusätzliche Aktion als vermeintlich selbstverständlicher Bestandteil der Funktion umgesetzt wird.

Für den weiteren Verlauf nehmen wir folgende vereinfachte Regel an: Vollständige Einzelangebote in Euro mit unveränderten Standardvertragsbedingungen dürfen automatisch freigegeben werden, wenn ihr Nettogesamtbetrag nach Rabatt größer als null und höchstens 5.000 Euro ist. Andere fachlich gültige Angebote benötigen eine manuelle Prüfung. Fehlerhafte oder unvollständige Angaben müssen zunächst korrigiert werden. Diese Festlegungen dienen nur dem Beispiel und sind keine allgemeine Empfehlung für Angebotsprozesse.

Auch diese Beschreibung braucht noch Ergänzungen. Welche Angaben sind verpflichtend, wie wird der Betrag gerundet und woran erkennt die Anwendung unveränderte Standardbedingungen? Wenn dafür bereits verbindliche Regeln existieren, müssen sie mit ihrer gültigen Fassung in die Arbeitsgrundlage eingehen. „Wie bisher“ genügt nur, wenn das bisherige Verhalten eindeutig bekannt und tatsächlich gewünscht ist.

Rückfragen nach ihren Auswirkungen ordnen

Aus einer kurzen Kundenfrage kann eine umfangreiche Konzeptphase entstehen. Die Zahl beantworteter Fragen sagt allerdings wenig darüber aus, ob der nächste Umsetzungsschritt ausreichend geklärt ist. Eine Entscheidung über die Gültigkeit einer Freigabe nach Preisänderungen beeinflusst den Kern der Funktion; die genaue Anordnung einer Statusanzeige lässt sich meist später festlegen.

Für die Angebotsfreigabe verdienen insbesondere folgende Fragen frühe Aufmerksamkeit:

  • Wer darf eine Prüfung auslösen, und wer darf eine manuelle Freigabe erteilen?
  • Welche Änderungen am Angebot heben eine bestehende Freigabe auf?
  • Was geschieht, wenn während der Prüfung jemand dasselbe Angebot bearbeitet?
  • Wie unterscheiden sich fehlende Angaben, fachliche Ausnahmen und technische Fehler?
  • Welche Informationen müssen eine Entscheidung später nachvollziehbar machen?

Jede Antwort braucht einen erkennbaren Stellenwert. Eine bestätigte Anforderung ist etwas anderes als eine vorläufige Annahme oder ein technischer Vorschlag. Zu offenen Fragen gehören eine zuständige Person und die Angabe, welche Arbeit von der Antwort abhängt. So bleibt sichtbar, ob bereits sinnvoll umgesetzt werden kann oder zunächst eine Voraussetzung geklärt werden muss.

Manche Fragen lassen sich nur durch eine Untersuchung beantworten. Ist unbekannt, ob das vorhandene System Freigaben für einzelne Angebotsversionen speichern kann, hilft eine weitere Diskussionsrunde wenig. Dann braucht es einen begrenzten Analyseauftrag mit einem klaren Ergebnis: vorhandene Möglichkeiten feststellen, Einschränkungen benennen und notwendige Änderungen abschätzen. Auch hunderte Rückfragen ersetzen diesen Befund nicht.

Eine Spezifikation hält den geltenden Stand fest

Gesprächsnotizen enthalten häufig verworfene Ideen und spätere Korrekturen. Eine konsolidierte Spezifikation führt die gültigen Entscheidungen zusammen und kennzeichnet verbleibende Unsicherheit. Wichtige Begründungen bleiben erhalten, damit eine später plausibel wirkende Alternative nicht erneut vorgeschlagen wird, obwohl sie bereits aus einem fachlichen Grund ausgeschlossen wurde.

Markdown eignet sich dafür als einfaches, versionierbares Textformat. Eine Dokumentversion und stabile Kennzeichnungen für Anforderungen erleichtern die Verbindung mit Umsetzungsaufgaben und späteren Prüfungen. Der folgende Ausschnitt zeigt, wie aus dem Gespräch ein überschaubarer Auftrag werden kann; er ersetzt keine vollständige Spezifikation.

Bestandteil Beispielhafte Festlegung
Auslöser Eine berechtigte Person reicht einen gespeicherten Entwurf zur Prüfung ein.
Automatische Freigabe Vollständiges Einzelangebot in Euro mit Standardbedingungen und Nettogesamtbetrag nach Rabatt über null bis einschließlich 5.000 Euro.
Fachliche Ausnahme Das Angebot benötigt eine manuelle Prüfung; der Grund wird angezeigt.
Ungültige Angaben Keine Freigabe; der Entwurf bleibt zur Korrektur bearbeitbar.
Änderung nach Freigabe Änderungen an Positionen, Preisen, Rabatten, Empfänger oder Vertragsbedingungen heben die Freigabe auf.
Nicht enthalten Automatischer Versand und automatische Bewertung individueller Vertragsbedingungen.

Akzeptanzkriterien ergänzen diese Regeln um beobachtbare Ergebnisse. Ein ansonsten geeignetes Angebot über genau 5.000 Euro muss die automatische Prüfung bestehen, eines über 5.000,01 Euro benötigt eine manuelle Entscheidung. Ein fehlender Betrag darf nicht als null interpretiert werden. Nach einer Preisänderung darf die neue Angebotsfassung nicht weiterhin als freigegeben erscheinen.

Diese Beispiele helfen bei der gemeinsamen Durchsicht. Du kannst beurteilen, ob das beschriebene Ergebnis zu deinem Arbeitsalltag passt, ohne Datenbankstrukturen oder Programmierschnittstellen kennen zu müssen. Zugleich erhält die spätere Prüfung einen Maßstab, der vor der Implementierung entstanden ist.

Technische Entscheidungen brauchen Kenntnis des vorhandenen Systems

Die fachliche Spezifikation beschreibt das gewünschte Verhalten. Die technische Spezifikation ergänzt, wie dieses Verhalten innerhalb der bestehenden Anwendung erreicht werden soll. Dafür müssen Datenmodell, Berechtigungen und vorhandene Schreibwege untersucht werden. Eine bereits vorhandene Freigabelogik kann den Aufwand verringern; unterschiedliche Betragsberechnungen an mehreren Stellen können dagegen zusätzliche Klärung verlangen.

An der gleichzeitigen Bearbeitung wird diese Übersetzung besonders deutlich. Fachlich gilt, dass eine Freigabe ausschließlich zum geprüften Angebotsstand gehört. Eine mögliche technische Absicherung ist eine Versionskennung: Die Entscheidung darf nur gespeichert werden, wenn das Angebot noch die geprüfte Version besitzt. Versionsvergleich und Zustandsänderung müssen dabei atomar erfolgen, also als unteilbarer Vorgang. Eine getrennte Vorabprüfung lässt eine Lücke für zwischenzeitliche Änderungen.

Bei einem Konflikt wird die Freigabe für den veralteten Stand nicht übernommen. Die Oberfläche muss verständlich erklären, weshalb eine erneute Prüfung erforderlich ist. Diese Regel muss auch für andere Schreibwege gelten, beispielsweise Importe oder Hintergrundprozesse. Sonst kann die normale Bearbeitungsmaske korrekt arbeiten, während eine Änderung an anderer Stelle eine überholte Freigabe bestehen lässt.

Ebenso braucht der bestehende Versand eine zuverlässige Zuordnung zur freigegebenen Fassung. Dass automatischer Versand außerhalb des Auftrags liegt, beseitigt diese Abhängigkeit nicht. Falls der bisherige Versand ungeprüfte Änderungen übernehmen würde, muss die notwendige Anpassung ausdrücklich in den Umfang aufgenommen werden.

Zur technischen Beschreibung gehören außerdem Schnittstellen, Fehlerantworten und erforderliche Entscheidungsdaten. Bei einem Verbindungsabbruch kann eine Freigabe bereits gespeichert sein, obwohl ihre Bestätigung fehlt. Die Anwendung braucht deshalb einen Weg, den tatsächlichen Zustand festzustellen. Auch Anforderungen wie „schnell“ werden erst durch vereinbarte Datenmengen, Lastbedingungen und messbare Antwortzeiten überprüfbar.

Die Übergabe muss Annahmen und Entscheidungen auseinanderhalten

Vor der Umsetzung werden fachliche Erwartungen und technische Befunde zusammengeführt. Dabei kann sich zeigen, dass eine zunächst einfache Anforderung größere Änderungen verlangt. Solche Erkenntnisse gehören zurück in die Abstimmung, besonders wenn sie Aufwand, Termin oder zugesagtes Verhalten verändern. Eine technisch bequemere Variante darf eine vereinbarte Fachregel nicht stillschweigend ersetzen.

KI kann beim Ordnen von Notizen, beim Entwickeln weiterer Fragen und bei der Suche nach Widersprüchen helfen. Eine erzeugte Zusammenfassung braucht jedoch einen Abgleich mit den tatsächlichen Entscheidungen. Aus „Standardbedingungen sind vermutlich erkennbar“ darf beim Umschreiben keine bestätigte Voraussetzung werden. Gerade sprachlich glatte Dokumente können verdecken, dass eine wesentliche Frage noch offen ist.

Für die Übergabe zählt deshalb ein nachvollziehbarer Stand mit klaren Grenzen. Eine Aufgabe verweist auf die gültige Anforderung und ihre Akzeptanzkriterien; blockierende Fragen bleiben ausdrücklich sichtbar. Nicht jede spätere Erweiterung muss bereits beschrieben sein. Der nächste abgegrenzte Umsetzungsschritt braucht jedoch ausreichend geklärte Voraussetzungen, damit während der Programmierung keine grundlegenden Geschäftsregeln erraten werden müssen.

Neue Erkenntnisse verändern die Arbeitsgrundlage

Eine Spezifikation bleibt auch während der Entwicklung bearbeitbar. Taucht eine übersehene Ausnahme auf, müssen die betroffene Regel, ihre Begründung und die zugehörigen Akzeptanzkriterien gemeinsam angepasst werden. Bereits laufende Aufgaben brauchen einen Abgleich mit dem neuen Stand, denn eine Änderung im Dokument erreicht ihre Umsetzung nicht automatisch.

Der erforderliche Aufwand richtet sich nach den Folgen einer falschen Entscheidung. Eine neue Beschriftung benötigt weniger Vorbereitung als eine automatische Angebotsfreigabe mit geschäftlicher Wirkung. Ausführlichkeit ist deshalb kein Selbstzweck: Die Beschreibung soll die Entscheidungen nachvollziehbar machen, von denen das gewünschte Verhalten tatsächlich abhängt.

Am Ende musst du an der Spezifikation erkennen können, welche Angebote automatisch weiterkommen, wann eine persönliche Entscheidung erforderlich bleibt und was bei Änderungen geschieht. Die technische Planung ergänzt dazu konkrete Mechanismen für Daten, Zugriffe und Konflikte. Wenn später eine neue Frage auftaucht, lässt sich auf dieser Grundlage gezielt weiterarbeiten, statt den ursprünglichen Kundenwunsch erneut aus verstreuten Gesprächsnotizen rekonstruieren zu müssen.