Lastenheft für Software, mit Vorlage

Im V-Modell XT Bund (externe Website) ist das Lastenheft die Grundlage für Ausschreibung und Vertrag und damit die wichtigste Vorgabe für die Angebote. Das Pflichtenheft übernimmt die Anforderungen daraus, bereitet sie auf und ist das zentrale Ausgangsdokument der Entwicklung.

Auf die erste Seite gehören der Name des Vorhabens, Version, Datum und Ansprechperson. So sprechen alle Beteiligten über dieselbe Fassung.

Die Gliederung lehnt sich an das Lastenheft im V-Modell XT Bund an und ist für kleine und mittlere Vorhaben gekürzt. Eine Vorlage hilft, nichts zu vergessen, hat aber Tücken. Der Lehrplan des International Requirements Engineering Board (externe Website) (IREB) nennt zwei davon. Oft gilt die Aufmerksamkeit mehr dem Ausfüllen der Vorlage als dem Inhalt. Außerdem fällt eher weg, was die Vorlage nicht vorsieht. Fragen Sie sich deshalb zum Schluss, was Ihr Vorhaben braucht, wofür die Gliederung keinen Abschnitt hat.

Schreiben Sie auf, wie der Ablauf heute läuft, mit welchen Werkzeugen und wo es hakt. Excel-Listen, Formulare und Bildschirmfotos der heutigen Lösung legen Sie als Anlage bei. Das V-Modell XT Bund sieht an dieser Stelle auch eine Begründung vor, warum vorhandene Systeme das Problem nicht lösen.

Ob eine Standardsoftware Ihren Ablauf schon abdeckt, prüfen Sie deshalb früh. Eine erste grobe Marktsichtung lässt das V-Modell schon vor der endgültigen Fassung des Lastenhefts zu. Wie Sie dabei vorgehen, zeigt unser Vergleich Individualsoftware oder Standardsoftware? Planen Sie ein Produkt, das Sie selbst verkaufen wollen, erklärt unser Leitfaden zu SaaS, was ein solches Produkt außerdem braucht.

Beispiel: „Unsere sechs Beschäftigten im Außendienst schreiben Arbeitszeit und Material auf Papier. Das Büro tippt die Zettel einmal pro Woche ab und schreibt danach die Rechnungen. Ziel: Jede Rechnung geht spätestens zwei Arbeitstage nach dem Einsatz hinaus.“

Typischer Fehler: Das Lastenheft beschreibt eine Lösung, etwa „Wir brauchen eine App mit Datenbank“, und das Problem dahinter fehlt. Damit ist die Lösung festgelegt, bevor jemand geprüft hat, was Ihren Ablauf am besten unterstützt. In einer internationalen Befragung von 228 Unternehmen zählte jedes vierte zu seinen fünf kritischsten Problemen, dass Beteiligte Anforderungen schwer von bekannten Lösungen trennen.

Quelle: Méndez Fernández u. a., Empirical Software Engineering (externe Website), 27.11.2016 · Befragung 2014/15 in 10 Ländern

Erledigt, wenn eine Person, die Ihren Betrieb nicht kennt, nach dem Lesen sagen kann, welches Problem die Software löst und woran Sie den Erfolg messen.

Bei funktionalen Anforderungen fragt das V-Modell XT Bund immer nach vier Aspekten: Was wird gemacht? Wer ist beteiligt? Welche Daten werden genutzt? Mit welchen anderen Systemen arbeitet die Software dabei zusammen? Halten Sie außerdem fest, wer was sehen und ändern darf. Daraus entstehen später die Rollen und Rechte.

Die Sonderfälle kennen die Menschen aus dem Tagesgeschäft: den Auftrag mit zwei Lieferadressen, die stornierte Rechnung, die Bestellung ohne Auftragsnummer. Das Forschungsprojekt NaPiRE (Naming the Pain in Requirements Engineering) hat Unternehmen nach Problemen mit Anforderungen gefragt. Am häufigsten nannten sie unvollständige oder versteckte Anforderungen: 48 % der 228 Unternehmen zählten sie zu ihren fünf kritischsten Problemen.

Quelle: Méndez Fernández u. a., Empirical Software Engineering (externe Website), 27.11.2016 · Befragung 2014/15 in 10 Ländern

Wie Sie einen Ablauf so aufnehmen, wie er wirklich läuft, und welchen Sie zuerst angehen, steht in unserem Ratgeber Prozesse digitalisieren.

Beispiel: „Ablauf Einsatz abrechnen: 1. Der Außendienst erfasst vor Ort Arbeitszeit und Material. 2. Die Bauleitung prüft den Einsatz und gibt ihn frei. 3. Das Büro erstellt aus freigegebenen Einsätzen die Rechnung. Sonderfall: Ein Einsatz dauert mehrere Tage.“

Typischer Fehler: Die Geschäftsführung schreibt das Lastenheft allein. Dann beschreibt es die Abläufe so, wie sie gedacht sind, und die Sonderfälle aus dem Alltag fehlen.

Erledigt, wenn jede Nutzergruppe mit Anzahl und Aufgaben aufgeführt ist und jemand aus dem Tagesgeschäft jeden Ablauf gelesen und bestätigt hat.

Der Lehrplan des IREB empfiehlt für jede einzelne Anforderung sechs Qualitätskriterien: adäquat, notwendig, eindeutig, vollständig, verständlich und prüfbar. Adäquat heißt: Sie beschreibt, was die Beteiligten wirklich brauchen und miteinander abgestimmt haben. Adäquatheit und Verständlichkeit nennt der Lehrplan die wichtigsten der sechs Kriterien.

Quelle: IREB, Lehrplan Foundation Level 3.3.0, 01.04.2026

Wörter, die sich nicht prüfen lassen, listet das Systems Engineering Handbook der NASA (externe Website) auf, darunter „flexibel“, „einfach“, „ausreichend“, „benutzerfreundlich“, „schnell“ und „robust“. Dieselbe Prüfliste fragt, ob jeder Satz nur eine Anforderung enthält. Verbindet ein „und“ zwei Fähigkeiten, sind es zwei Anforderungen.

Beim Satzbau hilft eine Schablone. Verbreitet ist das Muster EARS (Easy Approach to Requirements Syntax) (externe Website), entwickelt bei Rolls-Royce und 2009 erstmals veröffentlicht. Für Ereignisse lautet es sinngemäß: „Wenn [Auslöser], [Reaktion der Software].“ Ein Beispiel: „Wenn die Bauleitung einen Einsatz freigibt, erscheint er in der Rechnungsliste des Büros.“ Schreiben Sie in der Sprache Ihres Betriebs und erklären Sie Begriffe, die Außenstehende nicht kennen, im Glossar. Das Glossar ist laut V-Modell für alle Beteiligten verbindlich und beugt Missverständnissen vor.

Für die Priorität eignet sich die Einteilung MoSCoW: muss, soll, kann und diesmal nicht. Fragen Sie bei jeder Muss-Anforderung, was passiert, wenn sie fehlt. Lohnt sich der Start ohne sie nicht, ist sie ein Muss. Sobald ein Anbieter den Aufwand je Anforderung schätzt, prüfen Sie den Anteil der Muss-Anforderungen. Das Agile Business Consortium (externe Website) empfiehlt in der Regel höchstens 60 % des Aufwands. Die Kann-Anforderungen bilden die Reserve, falls Zeit oder Budget knapp werden. Wann ein Festpreis passt und wann die Abrechnung nach Aufwand, vergleicht unser Beitrag Festpreis oder Aufwand.

Quelle: Agile Business Consortium, 28.05.2026

Typischer Fehler: Jede Anforderung bekommt die Priorität Muss. Dann gibt es keine Reserve, und wenn es knapp wird, lässt sich nicht entscheiden, was warten kann.

Erledigt, wenn jede Anforderung eine Nummer, eine Priorität und nur eine Aussage hat und kein unprüfbares Wort ohne Zahl oder Bedingung darin steht.

Bei einer Ablösung sieht das V-Modell XT Bund eine Altsystemanalyse vor, die das Datenmodell des alten Systems ermittelt und die Datenqualität einschätzt. Erleichtern Sie das: Legen Sie eine Beispieldatei bei, aus der Sie Namen und Kontaktdaten entfernt haben, und schreiben Sie dazu, wo Sie doppelte oder lückenhafte Einträge kennen. Wie Datenübernahme und Parallelbetrieb bei einer Ablösung von Excel oder Access aussehen können, beschreibt unsere Seite Verwaltungssoftware entwickeln lassen.

Zu jeder Schnittstelle gehören das andere System, die Daten, die Richtung, die Häufigkeit und eine Ansprechperson für das andere System.

Qualitätsanforderungen beschreiben, wie gut die Software ihre Funktionen erfüllt. Das V-Modell empfiehlt, sie messbar, prüfbar und entscheidbar zu formulieren. Als Prüfliste eignet sich das Qualitätsmodell der Norm ISO/IEC 25010:2023 (Product quality model) (externe Website), das ausdrücklich auch für Anforderungen gedacht ist. Für ein kleines Vorhaben klären Sie mindestens diese Punkte:

• Datenschutz: Welche Daten über Personen verarbeitet die Software, wer darf sie sehen, und wann werden sie gelöscht?
• Verfügbarkeit und Datensicherung: Zu welchen Zeiten muss die Software laufen, wie lange darf ein Ausfall dauern, und wie oft wird gesichert?
• Antwortzeiten: Wie lange darf das Laden einer Liste oder das Speichern höchstens dauern, bei welcher Datenmenge?
• Geräte und Browser: Auf welchen Geräten und in welchen Browsern muss die Software laufen?
• Barrierefreiheit: Arbeiten Menschen mit Einschränkungen mit der Software, etwa mit Bildschirmlupe oder Screenreader?

Typischer Fehler: Mengen fehlen, etwa wie viele Menschen gleichzeitig arbeiten oder wie viele Datensätze in drei Jahren zusammenkommen. Auch die Prüfliste der NASA fragt nach Leistungsangaben wie Antwortzeit, Durchsatz und Speichergröße. Ohne solche Angaben kann ein Anbieter die passende Bauweise nur erraten.

Erledigt, wenn jede Datenart mit Menge und Herkunft aufgeführt ist, jede Schnittstelle Richtung und Häufigkeit hat und jede Qualitätsanforderung eine Zahl oder eine prüfbare Bedingung enthält.

Vor der Beauftragung genügt eine allgemeine Form. Das V-Modell sieht vor, dass der Auftragnehmer die Kriterien im Pflichtenheft konkretisiert; das erwartete Ergebnis jeder Muss-Anforderung sollte aber schon im Lastenheft stehen. Dieselbe Dreiteilung steckt in der Form „Angenommen … Wenn … Dann …“. Mit diesen Schlüsselwörtern beschreibt die Sprache Gherkin (externe Website) Testfälle, die sich auch automatisch ausführen lassen; die Schlüsselwörter gibt es auch auf Deutsch. Für die Anforderung „Wenn die Bauleitung einen Einsatz freigibt, erscheint er in der Rechnungsliste des Büros“ sähe ein Kriterium so aus:

• Angenommen: Ein Einsatz mit 3,5 Stunden Arbeitszeit und zwei Materialpositionen ist erfasst.
• Wenn: Die Bauleitung gibt ihn frei.
• Dann: Er steht innerhalb einer Minute in der Rechnungsliste, mit denselben Stunden und Positionen.

Bei Zahlen wie Antwortzeiten gehört das Messverfahren zum Kriterium: auf welchem Gerät, mit welcher Datenmenge und in wie vielen Läufen gemessen wird. Messwerte streuen. Die Dokumentation des Prüfwerkzeugs Lighthouse zur Streuung der Messwerte (externe Website) empfiehlt deshalb, Grenzwerte auf zusammengefasste Werte wie den Median mehrerer Läufe zu beziehen.

Ein Abnahmekriterium muss am Tag der Abnahme prüfbar sein. Ein Ziel wie „Jede Rechnung geht spätestens zwei Arbeitstage nach dem Einsatz hinaus“ zeigt sich erst im Betrieb. Halten Sie es als Ziel fest und messen Sie es nach dem Start; bei der Abnahme prüfen Sie die Funktionen, die es möglich machen. Legen Sie außerdem fest, wer auf Ihrer Seite prüft und wer die Abnahme erklärt. Welche rechtlichen Folgen die Abnahme hat, klären Sie mit Ihrer Rechtsberatung.

Typischer Fehler: Das Kriterium wiederholt nur die Anforderung, etwa „Die Rechnungsliste funktioniert“. Dann fehlt das erwartete Ergebnis, an dem beide Seiten die Prüfung messen können.

Erledigt, wenn jede Muss-Anforderung ein Abnahmekriterium mit festgelegtem erwartetem Ergebnis hat und feststeht, mit welchen Daten geprüft wird.

Die Abgrenzung zeigt jedem Anbieter, was er nicht einplanen muss, etwa eine App für Ihre Kundschaft oder die Anbindung des Lagers in der ersten Ausbaustufe. Zum Rahmen gehören Budgetrahmen, Termine, vorhandene Systeme, die bleiben, und der Betrieb nach dem Start: Wer betreibt, wartet und erweitert die Software? Das V-Modell XT Bund fragt dafür nach dem ganzen Lebenszyklus, von Nutzung und Betrieb über geplante Ausbaustufen bis zur Stilllegung. Was Wartung nach dem Start kostet, erklärt unser Kostenratgeber Was kostet Software-Wartung?

Beantworten Sie Rückfragen der Anbieter schriftlich und an alle, damit jedes Angebot auf demselben Stand beruht. Wie Sie Angebote vergleichen und welche Preisspannen Anbieter veröffentlichen, steht in unserem Kostenratgeber Was kostet es, Software entwickeln zu lassen?

Das Pflichtenheft übernimmt laut V-Modell die Anforderungen aus dem Lastenheft und verfolgt jede bis dorthin zurück. Prüfen Sie deshalb, ob jede Nummer Ihres Lastenhefts im Pflichtenheft vorkommt, und fragen Sie nach, wo eine fehlt. Ändert sich später eine Anforderung, halten Sie das schriftlich fest, mit neuer Version, Datum und den Folgen für Preis und Termin. Wie ein Softwareprojekt bei uns abläuft, vom Erstgespräch bis zur Abnahme nach schriftlich vereinbarten Kriterien, steht auf unserer Seite Software entwickeln lassen.

Typischer Fehler: Ein Anbieter bekommt das Lastenheft, ein zweiter nur eine Beschreibung am Telefon. Dann vergleichen Sie Angebote für zwei verschiedene Vorhaben.

Erledigt, wenn Abgrenzung, Rahmen und offene Fragen aufgeschrieben sind und jeder Anbieter dieselbe Fassung erhalten hat.

Diese Abstufung empfiehlt auch der Lehrplan des IREB: Nicht jede Anforderung muss alle Qualitätskriterien vollständig erfüllen, aber je höher ihr Wert, desto wichtiger werden sie. Eine Anforderung, an der Ihr Ablauf hängt, beschreiben Sie also genauer als die Farbe einer Schaltfläche.

Wird agil entwickelt, können Ziel, Nutzer, Rahmen und Abgrenzung im Lastenheft stehen und die Anforderungen in einer geordneten Liste, dem Product Backlog. Der Scrum Guide (externe Website) beschreibt diese Liste als „emergent“: Ihre Einträge werden laufend zerlegt und genauer gefasst. Abnahmekriterien bekommt dann jeder einzelne Eintrag; so definiert es für die agile Entwicklung auch das Glossar des IREB (externe Website).

• Englische Begriffe: Das Glossar des IREB übersetzt Lastenheft mit „customer requirements specification“ und Pflichtenheft mit „software requirements specification“, kurz SRS. Arbeiten Sie mit einem Team im Ausland, klären Sie zu Beginn, welches Dokument gemeint ist.
• Richtlinie und Norm: VDI 2519 Blatt 1 (externe Website) (Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften) stammt aus der Materialfluss- und Fördertechnik. ISO/IEC/IEEE 29148 (Requirements engineering) (externe Website) gilt in der Ausgabe von 2018; eine Neufassung ist in Arbeit.
• Vorgaben aus Gesetzen und Verträgen: Das V-Modell XT Bund berücksichtigt bei den Anforderungen ausdrücklich Vorgaben zu Informationssicherheit und Datenschutz. Welche Pflichten für Ihr Vorhaben gelten, klären Sie mit Ihrer Rechts- und Steuerberatung, bevor das Lastenheft an Anbieter geht.