Lastenheft Softwareentwicklung: Aufbau, Vorlage und Beispiel

Ein Lastenheft in der Softwareentwicklung beschreibt, welche Anforderungen eine neue Software erfüllen soll und welche Ziele ein Unternehmen mit dem Projekt verfolgt. Es schafft eine gemeinsame Grundlage für Auftraggeber und Entwicklungspartner, bevor Funktionen geplant, Angebote verglichen und technische Lösungen ausgearbeitet werden.

Besonders bei der Entwicklung individueller Software ist eine strukturierte Anforderungsbeschreibung wichtig. Unklare Ziele, fehlende Prioritäten oder unvollständig dokumentierte Geschäftsprozesse können zu Missverständnissen, zusätzlichen Abstimmungen und steigenden Entwicklungskosten führen. Ein gut vorbereitetes Lastenheft hilft dabei, funktionale und nichtfunktionale Anforderungen frühzeitig zu erfassen, den Projektumfang abzugrenzen und Erwartungen nachvollziehbar festzuhalten.

Dieser Artikel zeigt, wie Sie ein Lastenheft für ein Softwareprojekt erstellen, welche Inhalte und Bestandteile dazugehören und worin der Unterschied zum Pflichtenheft liegt. Anhand eines konkreten Beispiels mit Anforderungsmatrix und Abnahmekriterien erfahren Sie außerdem, wie sich Anforderungen verständlich formulieren und sinnvoll priorisieren lassen.

Was ist ein Lastenheft in der Softwareentwicklung?

Das Lastenheft dokumentiert die fachlichen Anforderungen des Auftraggebers an eine geplante Softwarelösung. Es macht nachvollziehbar, welches geschäftliche Problem gelöst werden soll, welche Ergebnisse erwartet werden und welche Rahmenbedingungen gelten. Damit dient es nicht nur als Anforderungsliste, sondern auch als Orientierung für die Bewertung möglicher Lösungen. Im Mittelpunkt steht die Frage, was die Software leisten soll – nicht die detaillierte technische Umsetzung.

In der Softwareentwicklung dient das Lastenheft als Grundlage für die Abstimmung zwischen Unternehmen und potenziellen Entwicklungspartnern. Es hilft, den gewünschten Funktionsumfang einzugrenzen, Anforderungen nachvollziehbar zu dokumentieren und Angebote auf einer vergleichbaren Basis einzuholen. Gleichzeitig lassen sich offene Fragen und unterschiedliche Erwartungen erkennen, bevor die eigentliche Umsetzung beginnt.

Die Verantwortung für die Inhalte liegt grundsätzlich beim Auftraggeber. In der Praxis werden Anforderungen häufig gemeinsam mit Fachabteilungen, späteren Anwendern und externen Beratern erarbeitet. Auch ein Softwareentwicklungspartner kann bei der Strukturierung und Präzisierung unterstützen. Entscheidend ist, dass die dokumentierten Anforderungen den tatsächlichen Bedarf des Unternehmens widerspiegeln.

Ein Lastenheft muss nicht jedes technische Detail vorwegnehmen. Es sollte jedoch ausreichend konkret sein, um Projektziele, Anforderungen und Grenzen des Softwareprojekts verständlich zu machen. Wie umfangreich die Dokumentation ausfällt, hängt unter anderem von der Komplexität der Software, der Anzahl beteiligter Systeme und den Abstimmungsanforderungen im Projekt ab.

Lastenheft und Pflichtenheft: Was ist der Unterschied?

Der wesentliche Unterschied zwischen Lastenheft und Pflichtenheft liegt in ihrer Perspektive: Das Lastenheft beschreibt die Anforderungen und Erwartungen des Auftraggebers, während das Pflichtenheft erläutert, wie der Auftragnehmer diese Anforderungen umsetzen will. Vereinfacht gesagt beantwortet das Lastenheft die Frage „Was soll die Software leisten?“ und das Pflichtenheft die Frage „Wie werden die Anforderungen umgesetzt?“.

Beide Dokumente können in der Softwareentwicklung aufeinander aufbauen. Das Lastenheft bildet dabei die Ausgangsbasis für die fachliche Abstimmung und die Bewertung möglicher Lösungen. Auf dieser Grundlage kann der Entwicklungspartner ein Pflichtenheft erarbeiten, das die vorgesehene Realisierung genauer beschreibt.

Die folgende Tabelle zeigt die wichtigsten Unterschiede im Überblick:

Ein Beispiel verdeutlicht die Abgrenzung: Im Lastenheft kann festgelegt werden, dass Mitarbeitende den Bearbeitungsstatus eines Kundenauftrags einsehen und aktualisieren können müssen. Das Pflichtenheft beschreibt dagegen, wie diese Funktion innerhalb der geplanten Software realisiert wird, etwa durch ein Rollen- und Berechtigungskonzept, definierte Statusübergänge und eine entsprechende Benutzeroberfläche.

Nicht jedes Softwareprojekt benötigt zwei umfangreiche, getrennte Dokumente. Je nach Projektgröße, Vertragsmodell und Entwicklungsmethode können Anforderungen auch in einer gemeinsamen Spezifikation oder in einem strukturierten Product Backlog dokumentiert werden. Entscheidend ist, dass fachliche Erwartungen und geplante Umsetzung ausreichend klar abgestimmt sind.

Lastenheft Aufbau: Welche Inhalte gehören hinein?

Der Aufbau eines Lastenhefts sollte die Anforderungen an ein Softwareprojekt so strukturieren, dass sowohl fachliche Ansprechpartner als auch potenzielle Entwicklungspartner den geplanten Leistungsumfang nachvollziehen können. Eine einheitliche Gliederung erleichtert es, fehlende Informationen zu erkennen, Anforderungen zu vergleichen und offene Fragen frühzeitig zu klären.

Welche Inhalte ein Lastenheft im Detail benötigt, hängt vom Projekt ab. Für die Entwicklung individueller Software haben sich jedoch mehrere zentrale Bestandteile bewährt: die Beschreibung der Ausgangssituation und Projektziele, funktionale und nichtfunktionale Anforderungen, Angaben zu Daten und Schnittstellen sowie Prioritäten, Rahmenbedingungen und Abnahmekriterien.

Ausgangssituation, Ist-Zustand und Projektziele

Am Anfang steht die Beschreibung der aktuellen Situation. Welche Geschäftsprozesse sollen verbessert werden? Welche Probleme bestehen mit vorhandenen Anwendungen oder manuellen Abläufen? Und welche Ergebnisse erwartet das Unternehmen von der neuen Software?

Die Darstellung des Ist-Zustands und der Projektziele schafft den fachlichen Kontext für die späteren Anforderungen. Dabei sollten nicht nur bestehende Schwierigkeiten, sondern auch die betroffenen Abteilungen, eingesetzten Systeme und gewünschten Verbesserungen erfasst werden.

Projektziele sollten möglichst konkret formuliert sein. Statt lediglich eine effizientere Auftragsbearbeitung anzustreben, kann beispielsweise festgelegt werden, dass Auftragsdaten künftig zentral erfasst werden und berechtigte Mitarbeitende den aktuellen Bearbeitungsstatus ohne zusätzliche Rückfragen einsehen können.

Ebenso wichtig ist die Abgrenzung des Projektumfangs. Das Lastenheft sollte erkennen lassen, welche Prozesse und Funktionen Bestandteil des Vorhabens sind und welche ausdrücklich nicht umgesetzt werden sollen.

Zielgruppen, Benutzerrollen und funktionale Anforderungen

Ein weiterer Bestandteil sind die Personen und Benutzergruppen, die später mit der Software arbeiten. Unterschiedliche Rollen können unterschiedliche Aufgaben, Informationsbedürfnisse und Zugriffsrechte haben. Deshalb sollten die vorgesehenen Benutzergruppen bereits bei der Anforderungserfassung berücksichtigt werden.

Die funktionalen Anforderungen beschreiben, welche Aufgaben und Abläufe die Software unterstützen muss. Dazu gehören beispielsweise das Erfassen und Bearbeiten von Datensätzen, Such- und Filterfunktionen, Freigabeprozesse, Benachrichtigungen oder die Erstellung von Auswertungen.

Eine Anforderung sollte dabei möglichst eindeutig und aus Sicht des fachlichen Bedarfs formuliert werden. Bei einer individuellen Auftragsverwaltung könnte sie beispielsweise lauten: „Berechtigte Mitarbeitende müssen Kundenaufträge anhand der Auftragsnummer suchen und den aktuellen Bearbeitungsstatus einsehen können.“

Hilfreich ist es, Anforderungen mit konkreten Anwendungsfällen zu verbinden. So wird deutlich, wer eine Funktion benötigt, welche Aufgabe damit erledigt werden soll und welches Ergebnis erwartet wird. Die technische Gestaltung der Benutzeroberfläche muss dafür noch nicht abschließend feststehen.

Nichtfunktionale Anforderungen und Qualitätsziele

Neben den Funktionen muss ein Lastenheft auch beschreiben, welche qualitativen Eigenschaften die Software erfüllen soll. Diese nichtfunktionalen Anforderungen betreffen unter anderem Leistung, Verfügbarkeit, Sicherheit, Datenschutz, Bedienbarkeit und Wartbarkeit.

Solche Anforderungen sind besonders wichtig, wenn viele Mitarbeitende gleichzeitig mit der Anwendung arbeiten, sensible Unternehmensdaten verarbeitet werden oder die Software geschäftskritische Prozesse unterstützt.

Allgemeine Aussagen wie „Die Software muss schnell und sicher sein“ reichen als Anforderungsbeschreibung meist nicht aus. Sinnvoller sind überprüfbare Vorgaben, etwa zu erwarteten Benutzerzahlen, zulässigen Antwortzeiten unter definierten Bedingungen, benötigten Zugriffsrechten oder Anforderungen an die Wiederherstellung von Daten.

Welche Qualitätsziele erforderlich sind, sollte sich aus den tatsächlichen Geschäftsprozessen und Risiken ergeben. Nicht jedes Softwareprojekt benötigt dieselben Leistungs- oder Verfügbarkeitsanforderungen.

Daten, Schnittstellen und Datenmigration

In vielen Unternehmen arbeitet eine neue Software nicht isoliert. Sie muss Daten aus bestehenden Anwendungen übernehmen, Informationen mit anderen Systemen austauschen oder vorhandene Datenbestände weiterverwenden. Deshalb gehören auch Datenanforderungen, Schnittstellen und eine mögliche Datenmigration zum Lastenheft.

Zu dokumentieren ist beispielsweise, welche Daten benötigt werden, aus welchen Systemen sie stammen, welche Anwendungen angebunden werden sollen und welche fachlichen Abläufe vom Datenaustausch abhängen. Bei einer Auftragsverwaltung könnte dies die Übernahme von Kundenstammdaten aus einem ERP-System oder die Weitergabe freigegebener Aufträge an eine bestehende Warenwirtschaft betreffen.

Bei einer geplanten Datenmigration sollten außerdem der Umfang der zu übernehmenden Daten, bekannte Qualitätsprobleme und fachliche Anforderungen an die Vollständigkeit berücksichtigt werden.

Das Lastenheft beschreibt dabei zunächst den geschäftlichen Integrationsbedarf. Die detaillierte technische Spezifikation einer ERP-Anbindung ist ein nachgelagerter Schritt. Welche Informationen und Abnahmekriterien dafür wichtig sind, erläutert der Beitrag ERP-Schnittstellen spezifizieren: Anforderungen und Abnahmekriterien.

Prioritäten, Rahmenbedingungen und Abnahmekriterien

Nicht jede Anforderung ist für den Projekterfolg gleich wichtig. Deshalb sollte das Lastenheft erkennen lassen, welche Funktionen zwingend benötigt werden und welche erst in einer späteren Ausbaustufe umgesetzt werden können. Eine mögliche Einteilung ist die Unterscheidung zwischen Muss-, Soll- und Kann-Anforderungen.

Die Einstufung sollte gemeinsam mit den fachlich verantwortlichen Personen abgestimmt werden. Eine Muss-Anforderung ist für den vereinbarten Mindestumfang erforderlich, während Soll- und Kann-Anforderungen je nach Nutzen, Budget und Projektphase unterschiedlich berücksichtigt werden können.

Zusätzlich sind relevante Rahmenbedingungen festzuhalten. Dazu können Budgetvorgaben, gewünschte Termine, organisatorische Abhängigkeiten, bestehende IT-Vorgaben oder regulatorische Anforderungen gehören. Sie beeinflussen, welche Lösungen im Projekt realistisch sind, ohne bereits eine bestimmte technische Umsetzung vorzuschreiben.

Ebenso wichtig sind nachvollziehbare Abnahmekriterien. Sie beschreiben, woran sich später erkennen lässt, ob eine Anforderung erfüllt wurde. Für eine Suchfunktion könnte beispielsweise festgelegt werden, dass ein berechtigter Benutzer einen vorhandenen Auftrag über seine eindeutige Auftragsnummer finden und dessen gespeicherten Bearbeitungsstatus anzeigen lassen kann.

Eine klare Priorisierung und überprüfbare Anforderungen erleichtern die weitere Projektplanung. Sie helfen dabei, den notwendigen Leistungsumfang einzugrenzen und spätere Entscheidungen über Erweiterungen oder Änderungen auf einer dokumentierten Grundlage zu treffen.

Lastenheft erstellen: Schritt-für-Schritt-Anleitung

Wer ein Lastenheft erstellen möchte, sollte nicht direkt mit einer Liste gewünschter Softwarefunktionen beginnen. Zunächst müssen die geschäftlichen Ziele, beteiligten Personen und bestehenden Arbeitsabläufe geklärt werden. Erst daraus lassen sich Anforderungen ableiten, die den tatsächlichen Bedarf des Unternehmens widerspiegeln.

Die folgenden sieben Schritte zeigen, wie sich ein Lastenheft für die Softwareentwicklung systematisch vorbereiten, ausarbeiten und abstimmen lässt.

1. Stakeholder und Ansprechpartner identifizieren

   Zu Beginn wird festgelegt, welche Personen und Abteilungen Anforderungen an die neue Software stellen. Dazu gehören beispielsweise Fachabteilungen, spätere Anwender, IT-Verantwortliche und die Projektleitung. Durch Interviews oder gemeinsame Workshops lassen sich unterschiedliche Erwartungen erfassen und frühzeitig abstimmen. Wichtig ist außerdem, eine verantwortliche Person zu benennen, die offene Fragen koordiniert und Entscheidungen herbeiführt.

2. Ist-Zustand und bestehende Probleme analysieren

   Im nächsten Schritt werden die betroffenen Geschäftsprozesse und vorhandenen Anwendungen untersucht. Welche Aufgaben erfolgen manuell? Wo entstehen Medienbrüche, doppelte Dateneingaben oder unnötige Abstimmungen? Welche bestehenden Abläufe sollen erhalten bleiben? Die Ergebnisse helfen, konkrete Probleme von bloßen Funktionswünschen zu unterscheiden.

3. Projektziele und Leistungsumfang festlegen

   Auf Grundlage der Bestandsaufnahme werden die gewünschten Ergebnisse formuliert. Dabei sollte deutlich werden, welchen geschäftlichen Nutzen die Software erzielen soll und welche Prozesse zum Projekt gehören. Ebenso wichtig ist die Abgrenzung: Funktionen, Systeme oder Aufgaben, die nicht Bestandteil der geplanten Umsetzung sind, sollten ausdrücklich benannt werden. So lassen sich unterschiedliche Erwartungen an den Projektumfang reduzieren.

4. Anforderungen sammeln und eindeutig formulieren

   Anschließend werden die fachlichen und qualitativen Anforderungen dokumentiert. Jede Anforderung sollte möglichst eine klar erkennbare Aussage enthalten und bei Bedarf eine eindeutige Kennung erhalten. Formulierungen wie „Die Software soll benutzerfreundlich sein“ sind zu ungenau. Besser ist es, konkrete Nutzungssituationen, erforderliche Funktionen und nachvollziehbare Qualitätskriterien zu beschreiben. Offene Fragen und Annahmen sollten dabei sichtbar bleiben, statt sie als bereits geklärte Anforderungen darzustellen.

5. Anforderungen priorisieren und Rahmenbedingungen prüfen

   Da nicht alle Funktionen denselben Stellenwert haben, werden Anforderungen nach ihrer geschäftlichen Bedeutung geordnet. Eine Einteilung in Muss-, Soll- und Kann-Anforderungen kann dabei helfen, den notwendigen Funktionsumfang von optionalen Erweiterungen zu trennen. Gleichzeitig sollten Budgetrahmen, Terminvorstellungen, organisatorische Abhängigkeiten und technische Vorgaben berücksichtigt werden. Diese Informationen bilden eine wichtige Grundlage für die spätere Kalkulation der Individualsoftware-Kosten, ersetzen jedoch keine belastbare Aufwandsschätzung durch den Entwicklungspartner.

6. Anforderungen prüfbar machen und abstimmen

   Vor der Freigabe wird kontrolliert, ob die dokumentierten Anforderungen verständlich, widerspruchsfrei und ausreichend konkret sind. Für wesentliche Funktionen sollten Abnahmekriterien festgelegt werden, anhand derer sich die Erfüllung später überprüfen lässt. Anschließend stimmen die zuständigen Fachbereiche und Entscheidungsträger die Inhalte ab. Unklare Punkte sollten geklärt oder als offene Entscheidungen dokumentiert werden.

7. Lastenheft freigeben und Änderungen dokumentieren

   Nach der fachlichen Abstimmung wird eine nachvollziehbare Version des Lastenhefts freigegeben. Diese dient als gemeinsame Ausgangsbasis für weitere Gespräche, Angebote und die Projektplanung. Ändern sich Anforderungen später, sollten die Anpassungen mit Begründung, Verantwortlichkeit und möglichen Auswirkungen auf Umfang, Termine und Kosten dokumentiert werden. So bleibt erkennbar, welche Anforderungen ursprünglich vereinbart und welche nachträglich angepasst wurden.

Wichtig: Ein Lastenheft muss nicht bereits jede fachliche Frage abschließend beantworten. Es sollte jedoch klar zwischen abgestimmten Anforderungen, Annahmen und offenen Punkten unterscheiden. Dadurch entsteht eine belastbare Grundlage für die weitere Planung, ohne notwendige Entscheidungen vorzutäuschen.

Lastenheft Beispiel: Individuelle Software für die Auftragsverwaltung

Wie ein Lastenheft für ein Softwareprojekt in der Praxis aussehen kann, zeigt das folgende vereinfachte Beispiel. Ein mittelständisches Handelsunternehmen möchte seine bisher teilweise manuelle Auftragsverwaltung durch eine individuelle Softwarelösung ersetzen. Das Beispiel ist fiktiv und verdeutlicht, wie sich Geschäftsziele, funktionale Anforderungen, Prioritäten und Abnahmekriterien miteinander verbinden lassen.

Ausgangslage und Ziel des Beispielprojekts

Im Unternehmen werden Kundenaufträge bisher über E-Mail, Tabellen und ein bestehendes ERP-System bearbeitet. Informationen zum Bearbeitungsstand liegen an unterschiedlichen Stellen vor. Mitarbeitende müssen mehrfach nachfragen, um den aktuellen Status eines Auftrags zu ermitteln. Zudem werden einzelne Angaben manuell zwischen Anwendungen übertragen.

Geplant ist eine individuelle Software zur zentralen Auftragsverwaltung, mit der berechtigte Mitarbeitende Kundenaufträge erfassen, bearbeiten und nachverfolgen können. Die Anwendung soll vorhandene Kundenstammdaten aus dem ERP-System nutzen und die Bearbeitungsschritte transparent dokumentieren.

Für das Lastenheft werden folgende Projektziele und Grenzen festgelegt:

• Zentrale Auftragsübersicht: Berechtigte Mitarbeitende sollen Kundenaufträge mit ihrem aktuellen Bearbeitungsstatus an einer Stelle einsehen können.

• Nachvollziehbare Bearbeitung: Statusänderungen sollen mit Zeitpunkt und verantwortlichem Benutzer dokumentiert werden.

• Weniger manuelle Datenpflege: Vorhandene Kundenstammdaten sollen aus dem ERP-System übernommen werden, statt sie erneut eingeben zu müssen.

• Klare Benutzerrechte: Mitarbeitende sollen nur die Funktionen und Informationen nutzen können, für die sie berechtigt sind.

• Projektabgrenzung: Die neue Anwendung soll weder die Buchhaltung noch die Lagerverwaltung des bestehenden ERP-Systems ersetzen.

Diese Ziele beschreiben den fachlichen Bedarf, ohne bereits eine bestimmte Technologie oder technische Architektur vorzugeben. Sie bilden die Grundlage für die konkreten Anforderungen.

Beispiel einer Anforderungsmatrix mit Prioritäten

Eine Anforderungsmatrix im Lastenheft hilft dabei, einzelne Anforderungen eindeutig zu dokumentieren und nach ihrer Bedeutung für das Projekt zu ordnen. Im folgenden Beispiel werden Muss-, Soll- und Kann-Anforderungen unterschieden. Zusätzlich wird festgehalten, wie sich die jeweilige Anforderung später überprüfen lässt.

Die Matrix enthält sowohl funktionale Anforderungen (F) als auch eine beispielhafte nichtfunktionale Anforderung (NF). Die angegebenen Benutzerzahlen und Antwortzeiten sind fiktive Projektvorgaben und müssen bei einem realen Softwareprojekt anhand der tatsächlichen Nutzung und technischen Rahmenbedingungen festgelegt werden.

Die Priorisierung macht sichtbar, welche Anforderungen für den geplanten ersten Funktionsumfang unverzichtbar sind. Gleichzeitig schaffen eindeutige Kennungen eine Grundlage, um Anforderungen in Besprechungen, Angeboten und späteren Tests gezielt zu referenzieren.

Abnahmekriterien konkret formulieren

Eine Anforderung ist besonders hilfreich, wenn sich eindeutig feststellen lässt, ob sie erfüllt wurde. Deshalb sollten wichtige Funktionen durch konkrete und überprüfbare Abnahmekriterien ergänzt werden.

Eine ungenaue Formulierung wäre beispielsweise: „Die Auftragssuche muss schnell und zuverlässig funktionieren.“ Daraus geht weder hervor, welches Suchverhalten erwartet wird, noch unter welchen Bedingungen die Funktion als erfüllt gilt.

Für die Anforderung F-02 könnten stattdessen folgende Abnahmekriterien vereinbart werden:

• Ein berechtigter Benutzer kann eine vollständige Auftragsnummer in das Suchfeld eingeben.

• Existiert ein Auftrag mit dieser Nummer, wird der zugehörige Datensatz mit Auftragsnummer, Kunde und aktuellem Bearbeitungsstatus angezeigt.

• Existiert kein entsprechender Auftrag, erhält der Benutzer eine eindeutige Meldung, dass kein Treffer gefunden wurde.

• Ein Benutzer ohne Leseberechtigung erhält über die Suche keinen Zugriff auf geschützte Auftragsdaten.

Diese Kriterien lassen sich anhand definierter Testfälle überprüfen. Leistungsanforderungen wie die maximale Antwortzeit sollten zusätzlich mit konkreten Datenmengen, Benutzerzahlen und Testbedingungen beschrieben werden.

Das Beispiel zeigt: Ein gutes Lastenheft besteht nicht nur aus einer Sammlung gewünschter Funktionen. Es verbindet Geschäftsziele, nachvollziehbare Anforderungen, Prioritäten und Abnahmekriterien zu einer gemeinsamen Grundlage für die weitere Softwareplanung. Bei umfangreicheren Projekten kommen weitere Angaben hinzu, beispielsweise zu Datenmigration, organisatorischen Rahmenbedingungen und zusätzlichen Qualitätsanforderungen.

Lastenheft Vorlage: Wie lässt sich ein Muster verwenden?

Eine Lastenheft Vorlage für Softwareprojekte bietet eine vorgegebene Struktur, mit der sich Projektziele, Anforderungen und Rahmenbedingungen systematisch dokumentieren lassen. Besonders Unternehmen, die erstmals eine individuelle Software entwickeln lassen, profitieren von einem solchen Muster: Es erleichtert den Einstieg und hilft dabei, wichtige Themen bei der Anforderungserfassung nicht zu übersehen.

Eine Vorlage sollte jedoch nicht unverändert übernommen werden. Je nach Softwareprojekt unterscheiden sich Geschäftsprozesse, Benutzerrollen, Schnittstellen und Qualitätsanforderungen erheblich. Deshalb müssen die einzelnen Abschnitte an den tatsächlichen Bedarf angepasst, nicht relevante Punkte entfernt und projektspezifische Anforderungen ergänzt werden.

📄

Lastenheft Vorlage für Softwareprojekte

Nutzen Sie eine strukturierte Vorlage als Ausgangspunkt, um Projektziele, Anforderungen und Rahmenbedingungen für Ihr Softwareprojekt zu dokumentieren.

Zur Lastenheft Vorlage

Häufige Fehler beim Erstellen eines Lastenhefts

Auch ein umfangreiches Lastenheft bietet keine verlässliche Planungsgrundlage, wenn Anforderungen unklar, widersprüchlich oder unvollständig beschrieben sind. Viele Probleme entstehen nicht durch fehlende technische Details, sondern durch unterschiedliche Erwartungen an den Funktionsumfang und die Ziele des Softwareprojekts. Die folgenden Fehler sollten Unternehmen deshalb bereits bei der Erstellung des Lastenhefts vermeiden.

• Zu allgemeine oder mehrdeutige Anforderungen: Formulierungen wie „Die Software soll einfach zu bedienen sein“ oder „Alle Prozesse müssen automatisiert werden“ lassen viel Interpretationsspielraum. Ohne konkrete Nutzungssituationen und nachvollziehbare Kriterien können Auftraggeber und Entwicklungspartner unterschiedliche Vorstellungen von derselben Anforderung entwickeln.

• Fehlende Abgrenzung des Projektumfangs: Wenn nicht festgelegt wird, welche Funktionen und Geschäftsprozesse zum Projekt gehören, können während der Umsetzung zusätzliche Erwartungen entstehen. Eine ausdrückliche Beschreibung der nicht enthaltenen Leistungen hilft, Missverständnisse und ungeplante Erweiterungen zu reduzieren.

• Keine Priorisierung der Anforderungen: Werden alle Funktionen als gleich wichtig behandelt, ist schwer erkennbar, welche Leistungen für den ersten nutzbaren Softwarestand tatsächlich erforderlich sind. Eine nachvollziehbare Einteilung in Muss-, Soll- und Kann-Anforderungen erleichtert Entscheidungen, wenn Budget, Zeit oder Ressourcen begrenzt sind.

• Unvollständige Angaben zu Daten und Schnittstellen: Bestehende Systeme, benötigte Datenbestände und notwendige Integrationen werden bei der Projektvorbereitung teilweise unterschätzt. Werden diese Abhängigkeiten erst spät erkannt, kann dies erhebliche Auswirkungen auf Aufwand und Projektplanung haben. Auch Anforderungen an die Datenqualität und eine mögliche Migration sollten frühzeitig berücksichtigt werden.

• Vernachlässigte Sicherheits- und Qualitätsanforderungen: Der Fokus liegt häufig auf sichtbaren Funktionen, während Zugriffsrechte, Datenschutz, Verfügbarkeit oder Leistungsanforderungen zu wenig Beachtung finden. Gerade bei geschäftskritischen Anwendungen müssen solche Eigenschaften rechtzeitig beschrieben und anhand geeigneter Kriterien überprüfbar gemacht werden.

• Fehlende Abnahmekriterien und unkontrollierte Änderungen: Ohne klare Kriterien bleibt bei der Abnahme unklar, wann eine Anforderung als erfüllt gilt. Werden Anforderungen nach der Abstimmung zusätzlich ohne dokumentierte Bewertung geändert, können unterschiedliche Erwartungen an Leistungsumfang, Kosten und Termine entstehen. Deshalb sollten wesentliche Änderungen nachvollziehbar festgehalten und ihre Auswirkungen gemeinsam bewertet werden.

Ein gutes Lastenheft zeichnet sich daher nicht durch möglichst viele Seiten aus, sondern durch eindeutige, priorisierte und überprüfbare Anforderungen. Offene Fragen sollten sichtbar dokumentiert und rechtzeitig geklärt werden. So lassen sich Missverständnisse reduzieren und die Voraussetzungen für eine realistische Projektplanung verbessern.

Lastenheft in der agilen Softwareentwicklung: Ist es noch sinnvoll?

Auch in der agilen Softwareentwicklung ist es wichtig, Projektziele, geschäftliche Anforderungen und Rahmenbedingungen frühzeitig zu klären. Ein klassisches, bis ins Detail ausgearbeitetes Lastenheft ist dafür jedoch nicht zwingend erforderlich. Stattdessen kann eine kompakte Anforderungsbeschreibung als gemeinsame Ausgangsbasis dienen, während einzelne Funktionen im Projektverlauf schrittweise konkretisiert werden.

In agilen Projekten werden detaillierte Anforderungen häufig in einem Product Backlog verwaltet und beispielsweise durch User Stories, Akzeptanzkriterien und fachliche Abstimmungen ergänzt. Das Backlog beschreibt und priorisiert die anstehenden Arbeiten und wird regelmäßig angepasst. Ein Lastenheft kann dagegen den übergeordneten Bedarf dokumentieren: Welches Problem soll gelöst werden, welche Ziele verfolgt das Unternehmen und welche wesentlichen Anforderungen oder Einschränkungen sind bereits bekannt?

Besonders bei der Entwicklung eines Minimum Viable Product (MVP) kann diese Trennung hilfreich sein. Das Unternehmen legt zunächst fest, welchen geschäftlichen Nutzen die erste nutzbare Version bieten soll. Welche Funktionen dafür notwendig sind und wie sie im Detail ausgestaltet werden, kann anschließend gemeinsam mit dem Entwicklungsteam priorisiert und weiterentwickelt werden.

Agiles Vorgehen bedeutet allerdings nicht, dass Anforderungen beliebig geändert werden können. Auch hier müssen Auswirkungen auf Budget, Zeitplan, technische Abhängigkeiten und vereinbarte Leistungen berücksichtigt werden. Insbesondere bei extern vergebenen Softwareprojekten sollte klar geregelt sein, wie neue oder veränderte Anforderungen bewertet und abgestimmt werden.

Fazit für agile Projekte: Ein Lastenheft kann sinnvoll sein, wenn es als Orientierung für Projektziele, Leistungsgrenzen und wesentliche Anforderungen dient. Es sollte jedoch nicht mit einer unveränderlichen Detailplanung verwechselt werden. Entscheidend ist, dass die Dokumentation zum gewählten Vorgehensmodell passt und ausreichend Raum für neue Erkenntnisse lässt.

Häufige Fragen zum Lastenheft in der Softwareentwicklung

Wer erstellt das Lastenheft bei einem Softwareprojekt?

Für die Erstellung des Lastenhefts ist grundsätzlich der Auftraggeber verantwortlich, da er die geschäftlichen Ziele und Anforderungen an die geplante Software definiert. In der Praxis arbeiten häufig Fachabteilungen, IT-Verantwortliche, Projektleitung und spätere Anwender daran mit. Ein externer Softwareentwicklungspartner kann die Anforderungserfassung durch Workshops, Beratung und fachliche Strukturierung unterstützen.

Ist ein Lastenheft für Softwareentwicklung Pflicht?

Ein Lastenheft ist nicht grundsätzlich gesetzlich vorgeschrieben. Ob ein formales Lastenheft benötigt wird, kann sich jedoch aus vertraglichen Vereinbarungen, Ausschreibungsbedingungen oder projektspezifischen Vorgaben ergeben. Auch ohne formales Dokument sollten Ziele, Anforderungen, Leistungsumfang und Verantwortlichkeiten nachvollziehbar festgehalten werden, insbesondere wenn ein externer Dienstleister mit der Softwareentwicklung beauftragt wird.

Wie detailliert muss ein Lastenheft sein?

Der notwendige Detaillierungsgrad hängt von der Komplexität und dem Umfang des Softwareprojekts ab. Bei einer kleineren Anwendung kann eine kompakte Anforderungsbeschreibung ausreichen. Umfangreiche Projekte mit mehreren Benutzergruppen, Systemintegrationen oder besonderen Sicherheitsanforderungen benötigen meist eine detailliertere Dokumentation. Entscheidend ist, dass wesentliche Anforderungen, Prioritäten und Rahmenbedingungen verständlich beschrieben sind und keine kritischen Fragen ungeklärt bleiben.

Kann man ein Lastenheft mit Word oder Excel erstellen?

Ja. Ein Lastenheft lässt sich mit Word oder Excel erstellen. Word eignet sich besonders für die Beschreibung von Projektzielen, Geschäftsprozessen und Rahmenbedingungen. Excel kann ergänzend verwendet werden, um Anforderungen mit eindeutigen Kennungen, Prioritäten und Abnahmekriterien tabellarisch zu verwalten. Bei größeren Projekten können spezialisierte Werkzeuge für das Anforderungsmanagement sinnvoll sein. Eine einheitliche Dokumentstruktur erleichtert den Einstieg unabhängig vom verwendeten Werkzeug.

Was passiert, wenn sich Anforderungen später ändern?

Änderungen an Anforderungen sind auch nach der Erstellung des Lastenhefts möglich. Wichtig ist, dass sie nachvollziehbar dokumentiert und hinsichtlich ihrer Auswirkungen bewertet werden. Neue oder geänderte Anforderungen können den Entwicklungsaufwand, die Kosten und den Zeitplan beeinflussen. Deshalb sollten Auftraggeber und Entwicklungspartner vereinbaren, wie Änderungen beantragt, geprüft und freigegeben werden. In agilen Projekten kann die laufende Anpassung über das Product Backlog erfolgen, wobei vertragliche Vereinbarungen weiterhin zu beachten sind.

Fazit: Mit klaren Anforderungen Softwareprojekte besser planen

Ein gut vorbereitetes Lastenheft für die Softwareentwicklung schafft Klarheit über Projektziele, Funktionsumfang und wesentliche Rahmenbedingungen. Es hilft Unternehmen, ihre Anforderungen nachvollziehbar zu dokumentieren, Prioritäten festzulegen und unterschiedliche Erwartungen frühzeitig abzustimmen. Entscheidend ist dabei nicht der Umfang des Dokuments, sondern die Qualität und Prüfbarkeit der beschriebenen Anforderungen.

Ob klassisches oder agiles Vorgehen: Eine strukturierte Anforderungsbeschreibung bildet eine wichtige Grundlage für die Planung individueller Software. Sie erleichtert die Zusammenarbeit zwischen Fachabteilungen und Entwicklungspartnern und hilft, den vorgesehenen Leistungsumfang realistisch einzuschätzen. Anforderungen sollten dabei ausreichend konkret sein, ohne notwendige Entscheidungen über die technische Umsetzung vorwegzunehmen.

Wenn Sie eine Individualsoftware entwickeln lassen möchten, unterstützt Maexware Sie dabei, geschäftliche Anforderungen zu strukturieren, technische Möglichkeiten zu bewerten und eine passende Softwarelösung zu planen und umzusetzen.