Lastenheft für Software schreiben: Aufbau und Beispiele
Ein Lastenheft beschreibt, was eine Software leisten soll, aus Sicht des Betriebs und ohne Technik. Für kleine Vorhaben genügen wenige Seiten mit acht Kapiteln: Ausgangslage, Ziele, Nutzer, Abläufe, Anforderungen, Daten, Rahmen und Abnahme. Wie jedes Kapitel aussieht und wie gute Anforderungen formuliert sind, zeigen die Beispiele unten.
Kurz gesagt
- Das Lastenheft sagt, was gebraucht wird und warum. Wie es gebaut wird, beantwortet der Entwickler im Pflichtenheft oder im Angebot.
- Gute Anforderungen sind prüfbar: Wer macht was, mit welchen Daten, und woran ist zu erkennen, dass es funktioniert?
- Abläufe beschreiben ist wichtiger als Funktionen aufzählen. Ein erzählter Vorgang hilft mehr als eine lange Wunschliste.
- Prioritäten gehören dazu. Ohne Muss, Soll und Kann wird jedes Angebot zum Vollausbau.
Was ein Lastenheft ist und wofür es gebraucht wird
Das Lastenheft schreibt der Auftraggeber. Es hält fest, welches Problem gelöst werden soll, wer mit der Software arbeitet und was sie können muss. Technik kommt darin nicht vor. Das Gegenstück ist das Pflichtenheft: Darin beschreibt der Entwickler, wie er die Anforderungen umsetzt.
Der Nutzen zeigt sich an drei Stellen. Angebote werden vergleichbar, weil alle Anbieter dieselbe Grundlage haben. Missverständnisse fallen vor der Entwicklung auf und nicht danach. Und bei der Abnahme gibt es einen Maßstab, an dem sich das Ergebnis messen lässt.
Für einen kleinen Betrieb muss daraus kein Buch werden. Ein Dokument, das an zwei Nachmittagen entsteht und die richtigen Fragen beantwortet, ist mehr wert als ein Formular mit fünfzig Seiten.
Der Aufbau in acht Kapiteln
- Ausgangslage. Was macht der Betrieb, wie wird heute gearbeitet, welche Programme und Tabellen sind im Einsatz?
- Ziele. Was soll nach der Einführung besser sein? Möglichst messbar: weniger Rückfragen, keine doppelte Eingabe, Rechnungen am selben Tag.
- Nutzer und Rollen. Wer arbeitet mit der Software, wie viele Personen je Gruppe, und wer darf was sehen und ändern?
- Abläufe. Die wichtigsten Vorgänge von Anfang bis Ende, Schritt für Schritt, mit den Ausnahmen, die im Alltag vorkommen.
- Anforderungen. Was die Software in jedem Schritt können muss, sortiert nach Muss, Soll und Kann.
- Daten und Schnittstellen. Welche Daten werden erfasst, welche Bestände ziehen um, und mit welchen Programmen soll die Software Daten austauschen?
- Rahmen. Geräte, Zahl der Standorte, Wunschtermin, Vorgaben zu Datenschutz und Betrieb, Ansprechpartner mit Entscheidungsbefugnis.
- Abnahme. Woran wird geprüft, ob die Software fertig ist? Am besten anhand echter Vorgänge aus dem Betrieb.
Abläufe erzählen statt Funktionen aufzählen
Der häufigste Fehler ist die Wunschliste: Kalender, Export, Suche, Statistik. Sie sagt nichts darüber, wozu eine Funktion gebraucht wird, und führt zu Software, die alles hat und trotzdem nicht passt. Besser ist es, den Vorgang zu erzählen.
Ein Beispiel aus einem Betrieb für Heizung und Sanitär: „Ein Kunde meldet telefonisch eine Störung. Das Büro legt einen Einsatz an, wählt den Kunden aus dem Bestand und sieht dabei die Anlage und die letzten Einsätze. Der Einsatz wird einem Monteur zugeteilt, der ihn auf dem Handy sieht. Nach der Arbeit trägt er Zeit und Material ein, der Kunde unterschreibt, und das Büro erstellt daraus die Rechnung.“
Aus diesen wenigen Sätzen ergibt sich fast alles: drei Rollen, die Daten je Kunde, der Zugriff vom Handy, die Unterschrift, die Übergabe an die Rechnung. Ein Entwickler kann gezielt nachfragen, wo etwas fehlt.
Anforderungen so formulieren, dass sie prüfbar sind
Eine Anforderung ist gut, wenn zwei Menschen sie gleich verstehen und am Ende jemand sagen kann: erfüllt oder nicht erfüllt. Bewährt hat sich der Satzbau „Als Rolle möchte ich etwas tun, damit ein Nutzen entsteht“.
| Zu ungenau | Prüfbar formuliert |
|---|---|
| Die Software soll benutzerfreundlich sein. | Ein Monteur schließt einen Einsatz auf dem Handy mit höchstens fünf Eingaben ab. |
| Es soll eine Kundenverwaltung geben. | Als Büro möchte ich zu jedem Kunden Anlagen, Ansprechpartner und alle bisherigen Einsätze auf einer Seite sehen. |
| Rechnungen sollen automatisch erstellt werden. | Aus einem abgeschlossenen Einsatz entsteht ein Rechnungsentwurf mit Zeit und Material, den das Büro prüft und freigibt. |
| Das System soll schnell sein. | Die Liste der offenen Einsätze erscheint auch bei mehreren Tausend Einträgen ohne spürbare Wartezeit. |
| Anbindung an die Buchhaltung. | Freigegebene Rechnungen werden einmal täglich als Datei im Format der Buchhaltungssoftware bereitgestellt. |
Muss, Soll und Kann: Prioritäten setzen
Nicht alles ist gleich wichtig, und ein Lastenheft ohne Prioritäten führt zu Angeboten für den Vollausbau. Drei Stufen genügen:
- Muss: Ohne diese Anforderung lässt sich nicht arbeiten. Sie gehört in die erste Fassung.
- Soll: Wichtig, aber für den Start gibt es einen Behelf. Kommt in der zweiten Stufe.
- Kann: Wäre schön. Wird notiert und erst entschieden, wenn die Software im Einsatz ist.
Die Sortierung hilft auch beim Budget. Ein Entwickler kann so ein Angebot für den Kern machen und die weiteren Stufen getrennt ausweisen.
Steht mehr als die Hälfte der Anforderungen auf „Muss“, lohnt eine zweite Runde. In der Praxis kommt ein Betrieb für den Start mit weniger aus, als die erste Liste vermuten lässt.
Was nicht ins Lastenheft gehört
- Technische Vorgaben ohne Grund. Programmiersprache oder Datenbank wählt der Entwickler. Anders ist es bei echten Vorgaben, etwa einem vorhandenen Server.
- Fertige Bildschirmentwürfe. Eine Skizze hilft beim Erklären. Die Gestaltung der Oberfläche entsteht besser gemeinsam im Entwurf.
- Lösungen statt Probleme. „Ein Knopf für den Export“ verdeckt das eigentliche Anliegen. „Die Steuerkanzlei braucht monatlich alle Rechnungen“ lässt bessere Wege zu.
- Alles, was vielleicht irgendwann kommt. Ferne Ideen gehören in einen kurzen Ausblick, damit die Technik sie nicht verbaut, aber nicht in die Anforderungen.
Vom Lastenheft zum Angebot
Mit dem fertigen Dokument lassen sich Angebote einholen. Gute Anbieter antworten mit Rückfragen, denn kein Lastenheft ist beim ersten Mal vollständig. Wer ohne eine einzige Frage eine Summe nennt, hat entweder viel Puffer eingerechnet oder nicht genau gelesen.
Ein Lastenheft muss auch nicht fertig sein, bevor das erste Gespräch stattfindet. Bei unseren Projekten für individuelle Software reicht oft ein Entwurf mit Ausgangslage, Zielen und den wichtigsten Abläufen. Den Rest erarbeiten wir gemeinsam, bei einem Portal oder einer Web-App meist anhand eines klickbaren Entwurfs.
Welche Angaben aus dem Lastenheft den Aufwand am stärksten bestimmen, steht auf der Seite Kosten.
