Anforderungen klären

Der häufigste Fehler im System Design passiert in den ersten fünf Minuten: Man beginnt zu zeichnen, bevor klar ist, was das System eigentlich leisten soll. Das Ergebnis sind Architekturen, die ein Problem lösen, das niemand hat, oder die das eigentliche Problem übersehen. Ein guter System Designer beginnt deshalb nicht mit der Frage, welche Technologie er einsetzen möchte, sondern mit beobachtbaren Anforderungen. Aussagen wie „schnell“, „skalierbar“ oder „sicher“ sind zu ungenau. Erst eine messbare Definition macht eine Entscheidung prüfbar.

1. Funktionale Anforderungen

Für eine Online-Terminbuchung eines Friseursalons könnten das sein: Kunden sehen freie Termine, buchen einen Termin mit Leistung und Mitarbeiter, erhalten eine Bestätigung per E-Mail und können bis 24 Stunden vorher stornieren. Der Salon pflegt Öffnungszeiten, Leistungen und Abwesenheiten. Die wichtigste Regel für den Entwurf lautet: Beschränken Sie sich auf die wichtigsten drei bis fünf Abläufe. Ein System Design wird unklar, wenn jede denkbare Zusatzfunktion – Gutscheine, Bewertungen, Treuepunkte, Warteliste – gleichzeitig betrachtet wird. Zusatzfunktionen werden notiert und später ergänzt, wenn der Kern steht.

2. Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen, auch Qualitätsanforderungen genannt, beschreiben, wie gut das System seine Aufgaben erfüllen muss. Sie sind für die Architektur meist entscheidender als die Funktionen selbst, denn dieselben Funktionen lassen sich mit sehr unterschiedlichen Architekturen umsetzen – je nachdem, wie schnell, verfügbar oder sicher sie sein müssen.

Wählen Sie für einen Entwurf drei bis fünf dieser Kategorien aus, die für das konkrete System am wichtigsten sind, und versehen Sie sie mit Zahlen. Wenn Sie Zahlen schätzen müssen, markieren Sie sie als Annahme. Eine markierte Annahme ist viel wertvoller als keine Zahl, weil sie überprüft und korrigiert werden kann.

3. Von vage zu messbar

Üben Sie die Unterscheidung an einigen Aussagen zur Terminbuchung:

4. Harte Grenzen, weiche Ziele und Invarianten

Nicht alle Anforderungen sind gleich streng. Ein harter Grenzwert darf nie verletzt werden: Ein Preis muss serverseitig korrekt berechnet werden, eine Abbuchung darf nicht doppelt ausgeführt werden, ein Termin darf nicht zweimal vergeben werden. Ein weiches Ziel ist ein Optimierungsziel: Eine Suchantwort darf in seltenen Fällen 600 statt 300 Millisekunden brauchen, solange der Dienst insgesamt zuverlässig bleibt. Diese Unterscheidung steuert die Architektur.

Abb. 2.1Harte und weiche Grenzen

Notieren Sie Invarianten früh. Sie bestimmen Transaktionsgrenzen, Datenmodell, Berechtigungen und Testfälle oft stärker als das Diagramm der Komponenten. In der Terminbuchung etwa folgt aus der Invariante „kein Termin doppelt vergeben“ direkt, dass die Buchung in der Datenbank mit einer eindeutigen Regel oder einer Sperre abgesichert werden muss – ein Cache oder eine Prüfung im Browser reicht dafür nicht.

5. Den Umfang begrenzen

Zum Klären der Anforderungen gehört auch das Klären der Grenzen. Welche Systeme liegen außerhalb des Entwurfs – etwa das Bezahlsystem eines Anbieters oder das bestehende Kassensystem? Welche Daten sind besonders sensibel? Welche Infrastruktur ist bereits vorhanden, und welche Kenntnisse hat das Team? Ein Entwurf, der ein Team mit Erfahrung in PostgreSQL und einem einzelnen Server plötzlich zu Kubernetes und drei verschiedenen Datenbanken zwingt, ist selten eine gute Idee, auch wenn er auf dem Papier eleganter aussieht.

In der Praxis bewährt sich ein kurzes Anforderungsdokument auf ein bis zwei Seiten: die drei bis fünf Kernabläufe, die drei bis fünf wichtigsten Qualitätsziele mit Zahlen, die Invarianten, die bekannten Grenzen und die ausdrücklich ausgeschlossenen Funktionen. Dieses Dokument ist die Grundlage jeder weiteren Entscheidung und der Maßstab, an dem der fertige Entwurf gemessen wird. In einem Vorstellungsgespräch übernehmen Sie diese Arbeit in den ersten zehn Minuten mündlich, indem Sie gezielt nachfragen. In echten Projekten lohnt es sich, dafür eine eigene Sitzung mit den Beteiligten einzuplanen – sie spart später Wochen.

Ein letzter Tipp: Stellen Sie bei jeder Anforderung die Frage „Was passiert, wenn das nicht erfüllt ist?“. Wenn die Antwort lautet „Dann ist ein Kunde kurz verärgert“, handelt es sich um ein weiches Ziel. Lautet sie „Dann verlieren wir Geld, Daten oder Vertrauen“, ist es eine harte Grenze. Diese einfache Frage sortiert Anforderungen erstaunlich zuverlässig und zeigt, wo die Architektur besonders sorgfältig sein muss.

6. Ein vollständiges Beispiel

Wie das in der Praxis aussieht, zeigt ein kurzes Anforderungsdokument für die Terminbuchung. Kernabläufe: freie Termine anzeigen, Termin buchen, Bestätigung erhalten, Termin stornieren, Öffnungszeiten pflegen. Qualitätsziele: 95 Prozent der Anfragen unter 300 Millisekunden; 99,5 Prozent Verfügbarkeit pro Monat, weil nachts kaum gebucht wird; höchstens fünf Minuten Datenverlust bei einem Ausfall; Speicherung personenbezogener Daten nur so lange wie nötig. Invarianten: kein Termin doppelt vergeben, keine Buchung außerhalb der Öffnungszeiten, jeder Kunde sieht nur eigene Buchungen. Grenzen: Bezahlung erfolgt vor Ort, E-Mails verschickt ein externer Dienst, keine App im ersten Schritt.

Aus diesen wenigen Zeilen lässt sich bereits viel ableiten. Die geringe Last erlaubt eine einfache Architektur mit einer Anwendung und einer relationalen Datenbank. Die Invariante gegen Doppelbuchungen verlangt eine Absicherung in der Datenbank, etwa eine eindeutige Regel auf Mitarbeiter und Zeitfenster. Der externe E-Mail-Dienst sollte über eine Warteschlange angebunden werden, damit ein Ausfall des Dienstes keine Buchung verhindert. Und das Datenschutzziel erfordert eine Löschroutine für alte Buchungen. Das alles ergibt sich aus den Anforderungen – ohne dass bis hierhin eine einzige Technologie ausgewählt wurde.

Diese Arbeitsweise lässt sich auf jedes Projekt übertragen, vom kleinen Buchungssystem bis zur großen Plattform. Der Aufwand ist gering, der Nutzen groß: Alle Beteiligten sprechen über dieselben Ziele, Missverständnisse fallen früh auf, und spätere Architekturentscheidungen lassen sich an einem klaren Maßstab messen. Wer einmal erlebt hat, wie viel Zeit ein gutes Anforderungsdokument spart, möchte nie wieder ohne beginnen. Legen Sie sich deshalb eine einfache Vorlage an, die Sie bei jedem neuen Projekt wiederverwenden: Kernabläufe, Qualitätsziele mit Zahlen, Invarianten, Grenzen, offene Fragen. Nach wenigen Projekten füllen Sie diese Vorlage fast wie von selbst aus – und stellen die richtigen Fragen, bevor jemand zu zeichnen beginnt.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.