Beginnen Sie mit dem Problem, den betroffenen Rollen und dem gewünschten Ergebnis. Eine Liste von 80 Funktionen ohne Priorität macht die Auswahl nicht automatisch besser. Ein Anbieter muss erkennen können, welches Problem wesentlich ist und was nur eine wünschenswerte Ergänzung darstellt.
Ein Lastenheft beschreibt den Bedarf des Auftraggebers
Ein gutes Lastenheft erklärt, welches Problem gelöst werden soll, für wen die Lösung gedacht ist und welche Bedingungen erfüllt sein müssen. Es ist keine unkommentierte Wunschliste und muss nicht vorschnell technische Details des Auftragnehmers festlegen. Für kleine Vorhaben reicht ein kompakter Anforderungskatalog. Bei mehreren Rollen, Datenquellen und Schnittstellen braucht die Beschreibung entsprechend mehr Tiefe. Entscheidend ist die Prüfbarkeit, nicht die Seitenzahl.
Ziel, Ausgangslage und Nicht-Ziele zuerst aufschreiben
Beginnen Sie mit der heutigen Arbeit und der gewünschten Veränderung. Beschreiben Sie, wie der Erfolg beobachtet werden könnte, ohne einen unbelegten Zielwert zu erfinden. Benennen Sie angrenzende Systeme und Dinge, die ausdrücklich nicht verändert werden. Dadurch vermeiden Sie, dass ein scheinbar kleiner Auftrag unbemerkt einen vollständigen Systemwechsel oder eine Datenbereinigung einschließt. Die Nicht-Ziele sind ebenso wichtig wie die gewünschte Funktion.
Anforderungen nach Nutzeraufgaben strukturieren
Eine Anforderung sollte erklären, welche Rolle unter welchen Bedingungen welches Ergebnis benötigt. Zu allgemeine Begriffe wie „intuitiv“, „schnell“ oder „sicher“ brauchen konkrete Prüfbedingungen. Diese können durch Beobachtung einer Aufgabe, definierte Lastbedingungen oder nachvollziehbare Rechteprüfungen entstehen. Nicht jede Anforderung muss schon eine technische Lösung enthalten. Ein vorgeschriebenes vorhandenes System kann hingegen eine echte technische Rahmenbedingung sein.
| Zu unbestimmt | Besser prüfbar |
|---|---|
| Kunden sollen alles sehen | Kunden sehen ausschließlich die Vorgänge ihrer eigenen Organisation. |
| Dateiupload soll funktionieren | Freigegebene Dateitypen werden einem ausgewählten eigenen Vorgang zugeordnet; ein Fehler zeigt keinen falschen Erfolg. |
| Die Anwendung muss schnell sein | Ein konkreter Vorgang wird unter vereinbarten Geräten, Datenmengen und Netzwerkbedingungen gemessen. |
| Es muss eine Schnittstelle geben | Übertragene Felder, Richtung, Auslöser, Fehlerweg und Verantwortlicher sind beschrieben. |
Daten und Rechte gehören in die fachliche Beschreibung
Legen Sie fest, welche Daten führend sind, wer sie ändern darf und wie ein Konflikt behandelt wird. Bei mehreren Organisationen ist zu prüfen, wie die Trennung von Informationen gewährleistet werden soll. Ein Kundenportal darf keine fremden Vorgänge offenlegen, nur weil ein Nutzer einen Link kennt. Die fachliche Anforderung beschreibt dieses erwartete Verhalten. Die konkrete technische Absicherung und Prüfung muss der Umsetzungspartner passend entwerfen.
Ausnahmen verhindern eine zu glatte Spezifikation
Ergänzen Sie je kritischer Funktion wenigstens einen schwierigen Fall: unvollständige Eingabe, Dublette, abgelaufene Sitzung, fehlgeschlagene Übertragung, Storno oder nicht berechtigte Person. Beschreiben Sie, ob die Anwendung ablehnen, pausieren, nachfragen oder eine manuelle Bearbeitung ermöglichen soll. Eine Fehlermeldung allein reicht nicht, wenn unklar bleibt, ob eine Aktion bereits ausgeführt wurde. Genau diese Fälle werden später häufig zu teuren ungeplanten Änderungen.
Akzeptanzkriterien mit Anforderungs-IDs verbinden
Geben Sie jeder wichtigen Anforderung eine stabile Kennung. Der Testfall verweist auf diese Kennung und nennt Ausgangslage, Handlung, erwartetes Ergebnis und Prüfer. Der Nachweis muss nachvollziehbar sein: ein ausgeführter Test, ein Fachreview oder eine Messung unter definierten Bedingungen. Ein allgemeiner Status „getestet“ lässt nicht erkennen, ob die kritische Rolle oder der Fehlerfall überhaupt betrachtet wurde.
Muss, Soll und offene Frage unterscheiden
Ein Muss-Kriterium schließt eine Lösung bei Nichterfüllung aus. Verwenden Sie diese Kategorie deshalb nur für tatsächlich unverzichtbare Anforderungen. Soll-Kriterien werden priorisiert oder gewichtet. Offene Fragen erhalten einen Bearbeiter und dürfen nicht als bereits entschiedene Anforderung in die Kalkulation eingehen. Eine begrenzte erste Lieferetappe kann sinnvoll sein, solange ihre Nutzbarkeit und ihre klaren Grenzen beschrieben sind. Ein Etikett wie „Vollversion“ ersetzt keinen nachvollziehbaren Umfang.
Die Übergabe an einen Anbieter vorbereiten
Zum Katalog gehören Version, Ansprechpartner, Freigabestand und ein Verfahren für Rückfragen. Anbieter sollten Annahmen und Abweichungen ausdrücklich markieren. Lassen Sie sich nicht nur ein Gesamtangebot nennen, sondern auch Voraussetzungen, Ausschlüsse und den geplanten Nachweis der Erfüllung. Vertrauliche Informationen werden nur in einem geeigneten, freigegebenen Rahmen geteilt. Passwörter gehören weder ins Lastenheft noch in einen frei weitergegebenen KI-Prompt.
Weitere Formate
Die Textfassung bleibt für technische Workflows und KI-Arbeitsaufträge verfügbar.
Änderungen nach der Freigabe kontrolliert behandeln
Neue Erkenntnisse sind normal. Sie müssen aber erkennbar bleiben. Eine Änderungsanfrage beschreibt den neuen Wunsch, seinen Grund, die betroffenen Anforderungen und die Auswirkung auf Termin, Kosten und Tests. Erst danach wird entschieden, ob er in den aktuellen Auftrag oder eine spätere Etappe gehört. Ein gepflegter Katalog ist eine gemeinsame Arbeitsgrundlage; eine Datei, deren letzte Freigabe niemand kennt, ist es nicht.