Lastenheft erstellen: Schritte, Vorlage, Fehler
· DigifyNow
Ein Lastenheft schreibt der Auftraggeber. Darin steht, was eine Lösung leisten soll und woran man das bei der Abnahme prüft, aber nicht, wie sie gebaut wird. Erstellen Sie es in dieser Reihenfolge: Ist-Ablauf aufnehmen, Ziele festlegen, Nutzerrollen benennen, Anforderungen als prüfbare Sätze mit MUSS, SOLL oder KANN formulieren, Schnittstellen und Daten auflisten und Abnahmekriterien ergänzen. Im Pflichtenheft beschreibt der Auftragnehmer dann, wie er das umsetzt.
Was ist ein Lastenheft und worin unterscheidet es sich vom Pflichtenheft?
Das Lastenheft ist das Dokument des Auftraggebers. Darin steht, welches Problem gelöst werden soll, wer mit der Lösung arbeitet und welche Anforderungen sie erfüllen muss. Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf. Er legt fest, wie er die Anforderungen technisch umsetzt, also mit welcher Architektur, welchen Systemen und in welchen Ausbaustufen. Dabei gilt eine einfache Regel: Jede Anforderung im Lastenheft braucht eine Antwort im Pflichtenheft. Fehlt sie, ist sie entweder vergessen worden oder bewusst gestrichen, und das sollten Sie wissen, bevor Sie unterschreiben.
| Merkmal | Lastenheft | Pflichtenheft |
|---|---|---|
| Wer schreibt es? | Auftraggeber, also Ihr Unternehmen | Auftragnehmer, also Entwickler oder Dienstleister |
| Welche Frage beantwortet es? | Was soll die Lösung können, und wofür? | Wie wird das umgesetzt? |
| Typischer Inhalt | Ist-Zustand, Ziele, Rollen, Anforderungen, Rahmenbedingungen | Technische Lösung, Systeme, Datenmodell, Ausbaustufen, Testkonzept |
| Wann entsteht es? | Vor der Anfrage beim Dienstleister | Nach dem Lastenheft, vor oder zu Beginn der Umsetzung |
| Wofür dient es später? | Vergleichbare Angebote und Maßstab für die Abnahme | Verbindliche Umsetzungsbeschreibung |
Lastenheft erstellen: die sieben Schritte
Diese Reihenfolge funktioniert für Software, Web-Apps, Onlineshops und Automatisierungen gleichermaßen. Jeder Schritt baut auf dem vorherigen auf. Wer mit Schritt 4 anfängt, schreibt meist eine Wunschliste ohne Bezug zum eigentlichen Engpass.
- Ist-Ablauf aufnehmen: Beschreiben Sie, wie der Vorgang heute läuft, wer beteiligt ist, welche Programme und Listen genutzt werden und wo Daten von Hand übertragen werden. Halten Sie fest, wie oft der Vorgang pro Woche vorkommt, und nehmen Sie dafür Ihre eigenen Zahlen, keine geschätzten.
- Ziele festlegen: Pro Ziel ein Satz, der sich nach dem Projekt überprüfen lässt. Zum Beispiel: „Aufträge werden nicht mehr aus E-Mails abgetippt, sondern landen direkt im System.“
- Rollen und Nutzer benennen: Wer erfasst, wer gibt frei, wer liest nur? Jede Rolle braucht eigene Rechte, und Rechte sind ein Kostentreiber.
- Anforderungen formulieren: Jede Anforderung bekommt eine Nummer, eine Priorität (MUSS, SOLL, KANN) und einen prüfbaren Satz.
- Schnittstellen und Daten auflisten: Welche Systeme müssen Daten liefern oder empfangen, etwa Warenwirtschaft, Buchhaltung oder CRM? Welche Altdaten werden übernommen, und in welchem Format liegen sie vor?
- Rahmenbedingungen festhalten: Wer betreibt das System, wer hostet es, welche Geräte werden genutzt, muss es offline funktionieren, welche internen Vorgaben gelten für den Umgang mit Daten?
- Abnahmekriterien ergänzen: Schreiben Sie zu jeder MUSS-Anforderung, wie Sie sie bei der Abnahme testen. Das kann ein Testfall mit echten Beispieldaten sein oder eine Liste von Fällen, die durchlaufen müssen.
Für Schritt 1 lohnt sich eine kurze Prozessanalyse, bevor Sie Anforderungen schreiben. Wie man Liege- und Durchlaufzeiten ermittelt, steht in unserem Artikel zur Prozessanalyse mit Vorlage und Beispiel. Was nach dem Lastenheft kommt, also Angebot, Vertrag, Umsetzung und Abnahme, beschreibt der Beitrag zum Ablauf eines Softwareprojekts.
Welche Gliederung eignet sich als Vorlage?
Eine Word-Vorlage ersetzt nicht das Nachdenken, gibt aber eine Reihenfolge vor, die Dienstleister schnell lesen können. Diese Gliederung deckt die meisten Vorhaben im Mittelstand ab:
- Einleitung: Unternehmen, Anlass, Ansprechpartner, Entscheider
- Ist-Zustand: Ablauf, beteiligte Systeme, bekannte Probleme
- Ziele: überprüfbare Sätze, nach Wichtigkeit sortiert
- Nutzer und Rollen: wer was darf
- Funktionale Anforderungen: nummeriert, mit MUSS, SOLL oder KANN
- Nicht-funktionale Anforderungen: Geräte, Browser, Verfügbarkeit, Sprachen, Barrierefreiheit, Datenhaltung
- Schnittstellen und Datenübernahme: Systeme, Richtung des Datenflusses, Formate, Datenmenge
- Betrieb und Wartung: Hosting, Updates, Support, wer im Haus zuständig ist
- Abnahmekriterien und Testfälle
- Offene Fragen: was Sie noch nicht wissen und vom Dienstleister geklärt haben wollen
Das letzte Kapitel, die offenen Fragen, fehlt in den meisten Vorlagen. Dabei hilft es, ehrlich zu sagen, was noch unklar ist. Sonst füllt der Dienstleister die Lücke mit eigenen Annahmen, und die tauchen erst bei der Abnahme wieder auf.
Wie formuliert man Anforderungen, die man prüfen kann?
Eine Anforderung ist gut, wenn zwei Personen unabhängig voneinander zum selben Ergebnis kommen, ob sie erfüllt ist. Bewährt hat sich das Muster „Das System MUSS / SOLL / KANN [wem] [was] ermöglichen“, und zwar mit genau einer Aussage pro Satz. Wörter wie schnell, intuitiv, benutzerfreundlich, flexibel, möglichst, gegebenenfalls oder „usw.“ sind nicht prüfbar. Ersetzen Sie sie durch eine konkrete Bedingung.
| Nicht prüfbar | Prüfbar |
|---|---|
| Die Kundensuche muss schnell und einfach sein. | Die Kundensuche MUSS Treffer über Firmenname, Kundennummer und Postleitzahl liefern, auch bei Teileingabe. |
| Das System soll Rechnungen erstellen usw. | Das System MUSS aus einem abgeschlossenen Auftrag eine Rechnung im Format der bestehenden Buchhaltung erzeugen. |
| Mitarbeiter sollen unterwegs arbeiten können. | Die Auftragserfassung MUSS auf dem Smartphone ohne Netz möglich sein und die Daten übertragen, sobald wieder Verbindung besteht. |
| Die Daten sollten möglichst aus dem Altsystem kommen. | Kunden- und Artikelstammdaten MÜSSEN aus dem CSV-Export des Altsystems übernommen werden, offene Aufträge KÖNNEN manuell nacherfasst werden. |
Priorisieren Sie ehrlich. Steht am Ende fast alles auf MUSS, hat die Priorisierung nichts bewirkt. Die MUSS-Liste ist der Kern, aus dem sich ein MVP schneiden lässt: die kleinste Version, die den Engpass im Alltag schon löst. Alles, was auf SOLL und KANN steht, bewerten Sie danach anhand der echten Nutzung neu, statt es vorab auf Verdacht mitzubauen.
Welche Fehler machen ein Lastenheft wertlos?
- Lösung statt Anforderung: „Wir brauchen eine Datenbank mit Tabelle X“ legt das Wie fest, bevor das Was klar ist. Beschreiben Sie das Ergebnis und überlassen Sie die Technik dem Pflichtenheft.
- Schnittstellen nur benannt: „Anbindung an die Warenwirtschaft“ reicht nicht. Es fehlen die Richtung (lesen, schreiben oder beides), die Datenfelder und die Frage, ob die Warenwirtschaft überhaupt eine Schnittstelle hat. Fehlende Schnittstellen sind ein häufiger Grund, warum Angebote weit auseinanderliegen.
- Altdaten vergessen: Wer erst nach dem Vertrag merkt, dass Stammdaten nur als PDF vorliegen, erweitert das Projekt nachträglich.
- Betrieb ausgeklammert: Hosting, Updates und Support fehlen oft im Lastenheft, laufen aber Jahre länger als die Entwicklung.
- Ein Autor, keine Nutzer: Schreibt nur die Geschäftsführung, fehlen die Ausnahmen, die die Sachbearbeitung jeden Tag erlebt.
- Zu früh zu detailliert: Bei einem Vorhaben, dessen Ablauf sich erst im Einsatz zeigt, veraltet ein sehr ausführliches Lastenheft schon in der ersten Testwoche. Dann reicht ein kurzes Lastenheft mit Zielen und MUSS-Anforderungen, den Rest klärt ein agiles Vorgehen mit Backlog.
Wann sich ein festes Lastenheft lohnt und wann iterative Zyklen besser passen, steht im Beitrag zu agiler Softwareentwicklung und ihren Grenzen. Wie Umfang, Schnittstellen und Datenübernahme den Preis bestimmen, erklärt der Artikel zu den Kostentreibern der Softwareentwicklung.
Prozesslandkarte erstellen: Hilft das vor dem Lastenheft?
Ja, wenn das Vorhaben mehrere Abteilungen berührt. Eine Prozesslandkarte zeigt auf einer Seite die Führungs-, Kern- und Unterstützungsprozesse eines Unternehmens und wie sie zusammenhängen. Fürs Lastenheft beantwortet sie eine Frage, die sonst untergeht: Welche Prozesse sind betroffen, wenn das neue System kommt? Ein Auftragssystem berührt zum Beispiel Vertrieb, Arbeitsvorbereitung, Lager und Rechnungsstellung. Jeder dieser Bereiche gehört dann ins Kapitel Ist-Zustand und als Rolle ins Lastenheft. Bauen Sie die Landkarte nach Abläufen auf, nicht nach dem Organigramm, sonst sehen Sie die Übergaben zwischen den Abteilungen nicht, und gerade dort liegen meist die Medienbrüche. Betrifft das Vorhaben nur einen einzelnen Ablauf, etwa die Urlaubsanträge, ist eine Landkarte zu viel. Dann reicht die Ablaufbeschreibung aus Schritt 1. Aufbau und ein Beispiel finden Sie im Artikel zur Prozesslandkarte.
Onlineshop im Westerwald erstellen lassen: Was gehört ins Lastenheft?
Auch wer einen Onlineshop von einem Dienstleister in der Region erstellen lässt, im Westerwald genauso wie anderswo, bekommt nur vergleichbare Angebote, wenn er dieselben Punkte festlegt. Bei Shops sind das: Anzahl der Artikel und Varianten, Herkunft der Produktdaten (Warenwirtschaft, Tabelle oder Handpflege), gewünschte Zahlarten, Versandarten und Versandregeln, Anbindung an Warenwirtschaft und Buchhaltung, Kundengruppen mit eigenen Preisen, Sprachen und Länder, und wer Produkte und Inhalte nach dem Start pflegt. Ob ein gehostetes Shopsystem reicht oder eine eigene Lösung nötig ist, hängt meist an zwei Dingen: an den Schnittstellen und an Sonderlogik wie Konfiguratoren oder Preisen pro Kunde. Die möglichen Wege und ihre Kostentreiber vergleicht der Artikel zum Webshop erstellen. DigifyNow baut Shops aus Unnau im Westerwald heraus für Kunden in der Region und deutschlandweit. Was dazugehört, steht auf der Seite zu Onlineshops.
Wann sich Unterstützung lohnt
Unterstützung von außen lohnt sich, wenn das Lastenheft mehrere Systeme mit Schnittstellen verbinden soll, wenn Altdaten übernommen werden müssen oder wenn intern niemand sagen kann, ob eine Anforderung technisch einfach oder aufwendig ist. Für einen einzelnen Ablauf mit einem Standardwerkzeug schaffen Sie das Lastenheft meist selbst. Halten Sie für ein Gespräch bereit: den beschriebenen Ist-Ablauf, Ihre Ziele, eine erste MUSS-Liste, die beteiligten Systeme und Beispieldaten. In der kostenlosen Einschätzung Ihres Vorhabens schaut sich DigifyNow diese Unterlagen an und sagt Ihnen, welche Punkte noch offen sind und ob sich eine eigene Software lohnt oder ein Standardwerkzeug reicht. Einen Überblick über alle Leistungen von App bis KI-Automatisierung finden Sie ebenfalls auf der Website.
Häufige Fragen
Wie lang sollte ein Lastenheft sein?
Die Länge richtet sich nach der Zahl der Anforderungen, nicht nach Seiten. Für eine Web-App mit einem Ablauf reichen oft wenige Seiten mit Zielen, Rollen und einer nummerierten MUSS-Liste. Mehr Umfang ist nur sinnvoll, wenn mehr Schnittstellen und Rollen dazukommen. Ein langes Lastenheft ohne Abnahmekriterien bringt weniger als ein kurzes mit Testfällen.
Wer schreibt das Pflichtenheft?
Das Pflichtenheft schreibt der Auftragnehmer, also der Entwickler oder Dienstleister. Er beantwortet darin jede Anforderung aus dem Lastenheft mit einer Umsetzung: Technik, Datenmodell, Ausbaustufen und Tests. Der Auftraggeber prüft, ob jede Anforderung darin vorkommt, und gibt das Pflichtenheft frei, bevor die Umsetzung beginnt.
Ist das Lastenheft Vertragsbestandteil?
Das kann es sein, wenn es im Vertrag ausdrücklich als Anlage genannt wird. Dann ist es der Maßstab, gegen den abgenommen wird. Wird es nur erwähnt, gilt meist das Pflichtenheft oder das Angebot. Wie verbindlich das Dokument im Einzelfall ist, richtet sich nach Ihrem Vertrag. Lassen Sie das bei Bedarf rechtlich prüfen.
Kann KI beim Lastenheft erstellen helfen?
Ja, für Gliederung, Umformulierung und als Prüfer. Ein Sprachmodell findet zum Beispiel unprüfbare Wörter wie „schnell“ oder Sätze mit zwei Anforderungen. Den Ist-Ablauf, die Ausnahmen und die Prioritäten kennt es nicht, die müssen von Ihnen kommen. Laden Sie vertrauliche Unterlagen nur in Werkzeuge hoch, die Ihre internen Regeln dafür erlauben.