Features Preise Unsere KI KI-Projektplan-Generator
Branchen Interne Projekte Anwendungsfälle Case Studies
Blog Wissensbibliothek Vergleich PM-Vorlagen Kostenlose Tools Integrationen KI-Projektmanagement API & Entwickler
Login Kostenlos starten
Lastenheft-Beispiel

Lastenheft für ein Softwareprojekt: Beispiel und Vorlage

Bei Individualsoftware ist das Lastenheft die Grundlage für Angebot, Festpreis und Abnahme. Dieses Beispiel beschreibt eine Web-Anwendung für das Reklamationsmanagement — mit Workflow, Fotodokumentation, SAP-Anbindung und prüfbaren Abnahmekriterien für jede Anforderung.

10 Kapitel 20 Anforderungen 15 MUSS-Anforderungen

Lastenheft-Vorlage mit Anleitung · Lastenheft-Generator

Lastenheft

Lastenheft für eine Web-Anwendung zum Reklamationsmanagement

Der Auftraggeber benötigt eine zentrale Web-Anwendung zur Erfassung, Bearbeitung und Auswertung von Reklamationen eines Herstellers von Haushaltsgeräten mit 450 Mitarbeitenden. Die Anwendung soll den heutigen E-Mail- und Excel-basierten Prozess zwischen Kundenservice, Qualitätssicherung und Technik durch einen nachvollziehbaren Workflow mit Fotos, Zuständigkeiten, Fristen und SAP-Anbindung ersetzen.

1. Einleitung und Zielsetzung

Der Auftraggeber bearbeitet Reklamationen derzeit über E-Mail und Excel zwischen Kundenservice, Qualitätssicherung und Technik. Die neue Web-Anwendung soll Reklamationsdaten zentral erfassen, die Bearbeitung steuern und die Ursachen systematisch auswerten.

Ziel ist eine einheitliche und nachvollziehbare Bearbeitung mit klaren Zuständigkeiten, Fristen, Statusinformationen und einer geringeren manuellen Übertragung von Kunden- und Artikeldaten.

  • Zentrale Erfassung von Reklamationen einschließlich Fotos und ergänzender Dokumente.
  • Transparente Zuordnung von Aufgaben an Kundenservice, Qualitätssicherung und Technik.
  • Automatisierte Fristenüberwachung und nachvollziehbare Bearbeitungshistorie.
  • Auswertungen nach Fehlerursachen, Produkten, Zeiträumen und Bearbeitungsstatus.
  • Zugriff für bis zu 60 berechtigte Nutzer.

2. Ist-Zustand

Reklamationen werden heute per E-Mail entgegengenommen und in Excel-Dateien weiterbearbeitet. Die beteiligten Bereiche Kundenservice, Qualitätssicherung und Technik stimmen sich dadurch teilweise manuell und medienbruchbehaftet ab.

Eine zentrale, rollenbasierte Übersicht zu Bearbeitungsstatus, Zuständigkeiten und Fristen ist nicht beschrieben. (Annahme) Fristen werden überwiegend manuell verfolgt und Rückfragen sowie Bearbeitungsschritte sind nicht durchgängig zentral dokumentiert.

SAP enthält Kunden- und Artikeldaten und soll künftig zur Vermeidung von Doppelerfassungen angebunden werden. SAP-Version, verfügbare Schnittstellen und die führenden Stammdaten sind noch festzulegen.

  • Beteiligte Fachbereiche: Kundenservice, Qualitätssicherung und Technik.
  • Bestehende Arbeitsmittel: E-Mail und Excel.
  • Bestehendes führendes System für Kunden- und Artikeldaten: SAP.
  • Bekannte Schwachstellen: Medienbrüche, uneinheitliche Bearbeitung, manuelle Fristenkontrolle und eingeschränkte Auswertbarkeit.

3. Funktionale Anforderungen

Die Anwendung muss die folgenden fachlichen Funktionen für bis zu 60 Nutzer bereitstellen. Rollen und Berechtigungen müssen so eingerichtet werden, dass Nutzer nur die für ihre Aufgabe erforderlichen Daten und Funktionen verwenden können.

F-01MUSS

Anmeldung und Rollenberechtigungen

Die Anwendung muss eine personalisierte Anmeldung und mindestens die Rollen Kundenservice, Qualitätssicherung, Technik und Administration unterstützen. Funktionen und Datensichten müssen rollenabhängig eingeschränkt werden können.

Abnahme: Für mindestens einen Testnutzer je Rolle sind Anmeldung, rollenabhängige Anzeige und der Zugriff auf eine nicht freigegebene Funktion nachweisbar. Ein Administrator kann Nutzer aktivieren, deaktivieren und Rollen zuweisen.

F-02MUSS

Erfassung einer Reklamation

Nutzer müssen Reklamationen über ein Webformular erfassen können. Mindestens Reklamationsnummer, Eingangstermin, Kunde, Artikel, Fehlerbeschreibung, Kontaktinformationen, Priorität und aktueller Status müssen strukturiert gespeichert werden.

Abnahme: Eine Testreklamation kann vollständig angelegt werden. Bei fehlenden Pflichtfeldern verhindert das System das Speichern und zeigt verständliche Fehlermeldungen an; nach dem Speichern erhält der Vorgang eine eindeutige Reklamationsnummer.

F-03MUSS

Fotos und Dokumente

Zu einer Reklamation müssen Fotos und weitere Dokumente hochgeladen, angezeigt, heruntergeladen und gelöscht werden können, soweit hierfür eine Berechtigung besteht. Dateityp und Dateigröße müssen geprüft werden.

Abnahme: Ein berechtigter Nutzer kann mindestens ein JPG-Foto und ein PDF-Dokument anlegen und wieder abrufen. Eine nicht zulässige Datei oder eine Datei oberhalb des konfigurierten Größenlimits wird abgewiesen und entsprechend gemeldet.

F-04MUSS

Workflow und Status

Die Anwendung muss einen konfigurierbaren Workflow für die Bearbeitung abbilden. Mindestens die Status Neu, In Prüfung, Rückfrage, Maßnahme, Erledigt und Abgeschlossen sowie definierte Übergangsregeln müssen unterstützt werden.

Abnahme: Eine Testreklamation kann gemäß den konfigurierten Übergangsregeln durch alle vorgesehenen Status geführt werden. Nicht erlaubte Statuswechsel werden verhindert und dem Nutzer angezeigt.

F-05MUSS

Zuständigkeiten und Aufgaben

Reklamationen und einzelne Bearbeitungsaufgaben müssen Personen oder Teams aus Kundenservice, Qualitätssicherung und Technik zugewiesen werden können. Die aktuelle Zuständigkeit muss in der Vorgangsübersicht sichtbar sein.

Abnahme: Ein berechtigter Nutzer weist einen Vorgang einem Team und anschließend einer Person zu. Die Zuständigkeit ist nach dem Speichern in der Detailansicht und in der Liste sichtbar.

F-06MUSS

Fristen und Eskalationen

Für Reklamationen und Aufgaben müssen Fristen hinterlegt werden können. Das System muss vor Ablauf und bei Überschreitung einer Frist eine konfigurierbare Benachrichtigung an zuständige Nutzer oder Teams auslösen.

Abnahme: Für einen Testvorgang wird eine Frist in der Vergangenheit und eine Frist in der Zukunft gesetzt. Das System erzeugt bei Überschreitung beziehungsweise vor Ablauf die jeweils konfigurierte Benachrichtigung und kennzeichnet den Vorgang als überfällig.

F-07MUSS

SAP-Abfrage von Kunden- und Artikeldaten

Bei der Erfassung müssen Kunden- und Artikeldaten aus SAP gesucht und übernommen werden können. Die aus SAP übernommenen Daten müssen als Quelle erkennbar sein und dürfen nicht unkontrolliert durch Freitexte überschrieben werden.

Abnahme: Mit einem abgestimmten Test-SAP-System werden ein vorhandener Kunde und ein vorhandener Artikel gesucht und in eine Testreklamation übernommen. Bei Nichtverfügbarkeit von SAP wird eine verständliche Fehlermeldung angezeigt und es werden keine unvollständigen Stammdaten gespeichert.

F-08MUSS

Bearbeitungsverlauf und Kommunikation

Die Anwendung muss Statuswechsel, Zuständigkeitsänderungen, Friständerungen, Kommentare und wesentliche Feldänderungen mit Zeitstempel und Nutzer protokollieren. Interne Kommentare müssen von externen Kundendaten getrennt gekennzeichnet werden können.

Abnahme: Bei einem Testvorgang werden mindestens eine Statusänderung, eine Zuständigkeitsänderung und ein Kommentar durchgeführt. Alle drei Aktionen erscheinen anschließend mit Nutzer und Zeitstempel im Verlauf und können nicht durch normale Nutzer gelöscht werden.

F-09MUSS

Fehlerursachen und Maßnahmen

Reklamationen müssen Fehlerkategorien, Fehlerursachen, betroffene Komponenten oder Artikelmerkmale sowie getroffene Maßnahmen zugeordnet werden können. Die Auswahllisten müssen administrativ gepflegt werden können.

Abnahme: Ein Administrator legt eine neue Fehlerursache an. Ein berechtigter Bearbeiter ordnet sie einer Testreklamation zu und kann zusätzlich eine Maßnahme erfassen; die Angaben erscheinen anschließend im Vorgang und in der Auswertung.

F-10MUSS

Suche und Filterung

Nutzer müssen Reklamationen mindestens nach Reklamationsnummer, Kunde, Artikel, Status, Zuständigkeit, Zeitraum, Fehlerursache und Priorität suchen und filtern können.

Abnahme: Mit einem Testbestand von mindestens 20 Reklamationen liefern mindestens drei kombinierte Filter nur die jeweils passenden Vorgänge. Eine Suche nach Reklamationsnummer findet den zugehörigen Vorgang eindeutig.

F-11MUSS

Auswertungen und Kennzahlen

Die Anwendung muss Auswertungen zu Anzahl und Status von Reklamationen, Bearbeitungszeiten, Fehlerursachen, Artikeln und Zeiträumen bereitstellen. Ergebnisse müssen nach mindestens Zeitraum, Produkt und Organisationseinheit filterbar sein.

Abnahme: Für einen definierten Testbestand werden die Anzahl der Reklamationen je Status und Fehlerursache sowie die durchschnittliche Bearbeitungszeit angezeigt. Die Ergebnisse ändern sich nachvollziehbar bei Änderung eines Filters.

F-12SOLL

Benachrichtigungen

Das System muss bei neu zugewiesenen Vorgängen, Statusänderungen, Kommentaren und Fristüberschreitungen Benachrichtigungen erzeugen können. Die Empfänger und auslösenden Ereignisse müssen konfigurierbar sein.

Abnahme: Bei der Zuweisung eines Testvorgangs erhält der konfigurierte Empfänger eine Benachrichtigung mit Reklamationsnummer, Ereignis und direktem Link zum Vorgang.

F-13SOLL

Datenexport

Berechtigte Nutzer müssen gefilterte Reklamationslisten und Auswertungsergebnisse in einem weiterverarbeitbaren Format, mindestens CSV oder XLSX, exportieren können.

Abnahme: Ein berechtigter Nutzer exportiert eine gefilterte Liste. Die Exportdatei enthält ausschließlich die gefilterten Datensätze und die angezeigten relevanten Felder; ein nicht berechtigter Nutzer kann den Export nicht ausführen.

4. Nicht-funktionale Anforderungen

Die Anwendung soll als browserbasierte Web-Anwendung ohne lokale Fachanwendungsinstallation betrieben werden. Die folgenden Qualitätsanforderungen gelten für die produktive Nutzung mit bis zu 60 berechtigten Nutzern.

N-01MUSS

Performance

Standardseiten, Suchabfragen und das Öffnen einer Reklamation müssen bei bis zu 60 gleichzeitig aktiven Nutzern (Annahme) in mindestens 95 Prozent der Fälle innerhalb von 2 Sekunden antworten. Auswertungen dürfen bei einem definierten Referenzbestand innerhalb von 5 Sekunden angezeigt werden.

Abnahme: Ein dokumentierter Lasttest mit einem abgestimmten Referenzbestand bestätigt die genannten Antwortzeiten für die vereinbarten Standardoperationen und Auswertungen.

N-02SOLL

Verfügbarkeit

Die produktive Anwendung muss eine monatliche Verfügbarkeit von mindestens 99,5 Prozent innerhalb der vereinbarten Betriebszeiten erreichen. Geplante Wartungen müssen angekündigt und außerhalb der Kernarbeitszeit durchgeführt werden.

Abnahme: Der Auftragnehmer legt ein Monitoring- und Verfügbarkeitsprotokoll vor. Für einen Abrechnungsmonat nach Produktionsstart wird die vereinbarte Verfügbarkeit nachgewiesen.

N-03MUSS

Sicherheit und Zugriffsschutz

Die Übertragung muss verschlüsselt erfolgen. Die Anwendung muss rollenbasierte Zugriffe, sichere Passwortrichtlinien und eine Sperrung oder Deaktivierung nicht mehr berechtigter Konten unterstützen.

Abnahme: Ein Sicherheitstest bestätigt ausschließlich verschlüsselte Zugriffe. Ein Nutzer ohne erforderliche Rolle kann geschützte Vorgänge und Funktionen nicht aufrufen; ein deaktiviertes Konto kann sich nicht anmelden.

N-04SOLL

Bedienbarkeit

Die Benutzeroberfläche muss in deutscher Sprache verfügbar, konsistent bedienbar und für aktuelle Standardbrowser geeignet sein. Ein geübter Nutzer soll eine neue Reklamation einschließlich Kunden- und Artikelauswahl in höchstens 5 Minuten erfassen können. (Annahme)

Abnahme: Mindestens fünf Vertreter der beteiligten Fachbereiche führen einen definierten Erfassungstest durch. Mindestens vier von fünf Personen schließen den Vorgang ohne Hilfe innerhalb von 5 Minuten ab.

N-05MUSS

Datensicherung und Wiederherstellung

Produktive Daten und Anhänge müssen regelmäßig gesichert werden. (Annahme) Es gelten ein Recovery Point Objective von höchstens 24 Stunden und ein Recovery Time Objective von höchstens 8 Stunden.

Abnahme: Der Auftragnehmer weist anhand eines Wiederherstellungstests nach, dass Daten und Anhänge innerhalb des vereinbarten RPO und RTO wiederhergestellt werden können.

N-06SOLL

Kompatibilität und Barrierearmut

Die Anwendung muss mit den jeweils aktuellen Versionen von Microsoft Edge, Google Chrome und Mozilla Firefox funktionieren. Formulare, Tabellen und Statusinformationen müssen mit Tastatur bedienbar und mit ausreichenden Beschriftungen versehen sein.

Abnahme: Ein Abnahmetest in den drei genannten Browsern bestätigt die Kernfunktionen. Die definierten Kernprozesse können vollständig mit der Tastatur durchgeführt werden.

N-07MUSS

Betrieb, Protokollierung und Wartbarkeit

Betriebs- und Sicherheitsereignisse müssen nachvollziehbar protokolliert werden, ohne unnötige personenbezogene Daten zu speichern. Für Anwendung, Schnittstellen, Konfiguration und Wiederanlauf müssen technische Betriebsdokumentationen vorliegen.

Abnahme: Der Auftragnehmer übergibt die vereinbarten Betriebsdokumente und zeigt anhand eines Testereignisses die Protokollierung von Anmeldung, fehlgeschlagenem Zugriff und SAP-Kommunikationsfehler.

5. Schnittstellen und Datenmigration

Die zentrale Schnittstelle ist die Anbindung an SAP zur Suche und Übernahme von Kunden- und Artikeldaten. (Annahme) Die Anwendung greift zunächst lesend auf SAP zu; Änderungen an SAP-Stammdaten sind nicht Bestandteil des Vorhabens.

Die technische Umsetzung der SAP-Anbindung ist nach Klärung der SAP-Version, der verfügbaren APIs oder Webservices, der Authentifizierung und der Netzfreigaben festzulegen. Schnittstellenfehler müssen protokolliert und den Nutzern verständlich angezeigt werden.

Als mögliche Migrationsquellen stehen bestehende Excel-Dateien zur Verfügung. (Annahme) E-Mail-Inhalte werden nicht automatisiert migriert, sofern sie nicht zuvor in einem abgestimmten strukturierten Format bereitgestellt werden.

Für die Migration sind Datenfelder, Dublettenregeln, Anhänge, historische Zeiträume, Bereinigungsregeln und die fachliche Freigabe der migrierten Daten festzulegen.

  • SAP: Kunden- und Artikelsuche sowie Übernahme ausgewählter Stammdaten.
  • E-Mail: künftig primär Benachrichtigungskanal; eine automatische E-Mail-Archivierung ist nicht vorausgesetzt. (Annahme)
  • Excel: mögliche Quelle für die initiale Migration historischer Reklamationen.
  • Export: mindestens CSV oder XLSX für berechtigte Nutzer.
  • Für alle Schnittstellen sind Test-, Fehler- und Berechtigungskonzepte zu dokumentieren.

6. Rahmenbedingungen

Die Verarbeitung personenbezogener Daten muss den Anforderungen der DSGVO und des Bundesdatenschutzgesetzes entsprechen. Dazu gehören insbesondere Zweckbindung, Datenminimierung, Rollen- und Berechtigungskonzept, Lösch- und Aufbewahrungsregeln, Auskunftsfähigkeit sowie ein Verzeichnis der Verarbeitungstätigkeiten durch den Auftraggeber.

Soweit der Auftragnehmer personenbezogene Daten im Auftrag verarbeitet, ist vor Produktivbetrieb ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO abzuschließen. Unterauftragnehmer, Verarbeitungsorte und gegebenenfalls Drittlandübermittlungen sind offenzulegen und freizugeben.

Anmeldungen, Änderungen, Zuständigkeiten und Zeitstempel können Rückschlüsse auf das Verhalten oder die Leistung einzelner Beschäftigter ermöglichen. Vor Einführung ist deshalb zu prüfen, ob die Anwendung der Mitbestimmung des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG unterliegt. Falls das System zur Leistungs- oder Verhaltenskontrolle geeignet ist, sind Betriebsrat und Datenschutzbeauftragter einzubeziehen.

Der Auftragnehmer muss ein Schutzkonzept für Zugriffsschutz, Verschlüsselung, Schwachstellenmanagement, Protokollierung, Datensicherung und Sicherheitsvorfälle vorlegen. Sicherheitsvorfälle mit personenbezogenen Daten sind dem Auftraggeber unverzüglich nach einem zu vereinbarenden Verfahren zu melden.

Das Hosting muss innerhalb der Europäischen Union erfolgen. (Annahme) Bevorzugt wird ein Betrieb in Deutschland oder in einer vom Auftraggeber freigegebenen Unternehmens- beziehungsweise Cloud-Infrastruktur.

  • Keine Nutzung personenbezogener Reklamationsdaten für eigene Zwecke des Auftragnehmers.
  • Zugriff auf Produktivdaten nur für ausdrücklich autorisierte Personen und Supportfälle.
  • Löschung oder Rückgabe der Daten nach Vertragsende gemäß vereinbartem Verfahren.
  • Betriebsrat und Datenschutzbeauftragter werden vor Festlegung von Monitoring-, Protokollierungs- und Auswertungsfunktionen beteiligt.
  • Hostingmodell, Aufbewahrungsfristen, Datenschutz-Folgenabschätzung und Berechtigungskonzept sind vor Umsetzung verbindlich zu bestätigen.

7. Mengengerüst

Der Auftraggeber beschäftigt 450 Mitarbeitende. Für die Anwendung sind bis zu 60 Nutzer aus Kundenservice, Qualitätssicherung, Technik und Administration vorgesehen.

Die erwartete Reklamationsmenge und das Datenvolumen sind nicht angegeben. (Annahme) Für die Erstplanung wird von bis zu 10.000 Reklamationen pro Jahr, durchschnittlich fünf Anhängen je Reklamation und einer durchschnittlichen Anhangsgröße von 5 MB ausgegangen.

Standorte und die Verteilung der Nutzer auf Standorte sind noch nicht beschrieben. (Annahme) Die Anwendung wird zunächst für mindestens einen zentralen Unternehmensstandort und den Zugriff über das Unternehmensnetz oder einen abgesicherten Fernzugang ausgelegt.

  • Mitarbeitende insgesamt: 450.
  • Vorgesehene Nutzer: bis zu 60.
  • Fachbereiche: Kundenservice, Qualitätssicherung und Technik.
  • Planungsgröße Reklamationen: bis zu 10.000 pro Jahr. (Annahme)
  • Planungsgröße Anhänge: durchschnittlich fünf je Reklamation mit durchschnittlich 5 MB. (Annahme)
  • Historische Daten: Umfang, Zeitraum und Qualität noch festzulegen.

8. Lieferumfang

Der Lieferumfang umfasst eine produktionsfähige Web-Anwendung einschließlich Konfiguration der Rollen, Workflows, Fristen, Fehlerursachen und Auswertungen. Die SAP-Anbindung, soweit technisch freigegeben, sowie die vereinbarte Datenmigration sind Bestandteil der Einführung.

Der Auftragnehmer muss die Einführung in abgestimmten Phasen durchführen: Konzeption, Umsetzung, Integrationstest, Fachtest, Pilotbetrieb, Schulung, Produktivsetzung und Übergabe in den Betrieb.

  • Fachliche und technische Konzeption einschließlich Daten- und Berechtigungskonzept.
  • Web-Anwendung mit den MUSS-Anforderungen und vereinbarten SOLL-Anforderungen.
  • SAP-Schnittstelle sowie technische Schnittstellendokumentation.
  • Migration der freigegebenen historischen Reklamationsdaten einschließlich Prüfprotokoll.
  • Testkonzept, Testfälle, Fehlerlisten und Nachweis der Fehlerbehebung.
  • Administrations-, Benutzer-, Betriebs- und Wiederherstellungsdokumentation.
  • Schulung für Administratoren sowie für Nutzer aus Kundenservice, Qualitätssicherung und Technik.
  • Übergabe in den Betrieb einschließlich Supportprozess, Ansprechpartnern und Eskalationsweg.
  • Nach Produktivsetzung gilt zunächst ein Supportmodell zu Geschäftszeiten. (Annahme)

9. Zeitrahmen und Budgetrahmen

Ein verbindlicher Starttermin ist noch nicht festgelegt. (Annahme) Für Konzeption, Umsetzung, SAP-Integration, Migration, Tests, Schulungen und Produktivsetzung wird ein Gesamtzeitraum von etwa 6 Monaten ab Beauftragung vorgesehen.

Als vorläufiger Budgetrahmen werden 180.000 bis 300.000 Euro netto angenommen. Der Rahmen umfasst Softwareentwicklung, SAP-Schnittstelle, Einführung, Migration, Schulung und Dokumentation, nicht jedoch bislang unbekannte SAP-Lizenz-, Infrastruktur- oder Zusatzkosten.

Der Auftragnehmer soll ein verbindliches Angebot mit Projektplan, Meilensteinen, Annahmen, Leistungen, Tagessätzen, laufenden Betriebskosten und optionalen Leistungen vorlegen.

  • Meilenstein 1: abgestimmtes Fach- und Technikkonzept.
  • Meilenstein 2: funktionsfähige Anwendung mit Test-SAP-Anbindung.
  • Meilenstein 3: Fachtest und Migrationstest.
  • Meilenstein 4: Pilotbetrieb mit ausgewählten Nutzern.
  • Meilenstein 5: Produktivsetzung und Betriebsübergabe.
  • Planungszeitraum: etwa 6 Monate. (Annahme)
  • Planungsbudget: 180.000 bis 300.000 Euro netto. (Annahme)

10. Abnahme

Die Abnahme erfolgt nach erfolgreichem Abschluss des vereinbarten Fachtests, der Schnittstellen- und Migrationstests sowie eines Pilotbetriebs mit Vertretern aus Kundenservice, Qualitätssicherung und Technik.

Abnahmevoraussetzung ist, dass alle MUSS-Anforderungen nachgewiesen sind, keine Fehler der Kategorien kritisch oder hoch offen sind und die vereinbarten Dokumentationen, Schulungen und Betriebsübergaben vollständig erfolgt sind.

Die Abnahme wird durch ein gemeinsames Abnahmeprotokoll dokumentiert. Festgestellte Restmängel werden mit Priorität, Verantwortlichem und Termin zur Nachbesserung festgehalten.

Der Auftraggeber behält sich vor, die Abnahme zu verweigern, wenn die SAP-Anbindung, die Berechtigungstrennung, die Datensicherheit oder die Wiederherstellung der produktiven Daten die vereinbarten Kriterien nicht erfüllt.

  • Abnahmetest anhand abgestimmter fachlicher und technischer Testfälle.
  • Nachweis der Anforderungen F-01 bis F-11 sowie der vereinbarten SOLL-Anforderungen.
  • Nachweis der nicht-funktionalen Anforderungen durch Messung, Test oder Dokumentation.
  • Prüfung der Rollen, Fristen, Anhänge, SAP-Daten, Auswertungen und Protokollierung.
  • Übergabe eines Abnahmeprotokolls mit offenen Restpunkten und Fristen.

Vor der Verwendung klären

Diese Punkte und Annahmen sind im Beispiel offen — in deinem Vorhaben musst du sie festlegen.

  • Welche SAP-Version, Module, APIs oder Webservices sowie Authentifizierungs- und Netzwerkanforderungen stehen für die Anbindung zur Verfügung?
  • Welche Standorte nutzen die Anwendung, wie viele Nutzer entfallen auf die einzelnen Fachbereiche und wie viele gleichzeitige Nutzer sind zu erwarten?
  • Welche konkreten Workflow-Status, Fristen, Eskalationsstufen, Rollen und Freigaberegeln gelten fachlich?
  • Wie viele Reklamationen und Anhänge liegen historisch vor, aus welchen Excel-Dateien stammen sie und welcher Zeitraum soll migriert werden?
  • Welche Datenschutz-, Aufbewahrungs- und Löschfristen gelten für Reklamations- und Kundendaten, und ist eine Datenschutz-Folgenabschätzung erforderlich?
  • Soll das System Leistungs- oder Verhaltensdaten einzelner Beschäftigter auswerten können, und welche Beteiligung des Betriebsrats ist erforderlich?
  • Welche Hostingform, Betriebszeiten, Service-Level, Supportzeiten sowie Recovery-Ziele werden verbindlich vorgegeben?
  • Welcher verbindliche Projektstart, Endtermin und Budgetrahmen stehen zur Verfügung?

Nächster Schritt: der Projektplan: Projektplan Softwareentwicklung

Aus dem Lastenheft wird ein Vorhaben mit Phasen, Zeitplan, Budget und Risiken.

Wie dieses Beispiel entstanden ist
Erstellt mit dem PathHub Lastenheft-Generator aus dieser Beschreibung: „Entwicklung einer Web-Anwendung für das Reklamationsmanagement eines Herstellers von Haushaltsgeräten mit 450 Mitarbeitenden. Heute laufen Reklamationen per E-Mail und Excel zwischen Kundenservice, Qualitätssicherung und Technik. Gewünscht: Erfassung mit Fotos, Workflow mit Zuständigkeiten und Fristen, Anbindung an SAP für Kunden- und Artikeldaten, Auswertungen nach Fehlerursachen, Zugriff für 60 Nutzer.“ — ohne Unternehmenskontext. Für dein Vorhaben: Beschreibung anpassen und ein eigenes Dokument erstellen.

Häufig gestellte Fragen

Was gehört in ein Lastenheft für ein Softwareprojekt?
Im Beispiel: Einleitung und Zielsetzung, Ist-Zustand, Funktionale Anforderungen, Nicht-funktionale Anforderungen, Schnittstellen und Datenmigration, Rahmenbedingungen, Mengengerüst, Lieferumfang, Zeitrahmen und Budgetrahmen, Abnahme. Den Kern bilden 20 nummerierte Anforderungen, davon 15 MUSS-Anforderungen, jeweils mit prüfbarem Abnahmekriterium.
Welche Anforderungen sind bei ein Softwareprojekt besonders wichtig?
Im Beispiel als MUSS eingestuft: Anmeldung und Rollenberechtigungen; Erfassung einer Reklamation; Fotos und Dokumente; Workflow und Status; Zuständigkeiten und Aufgaben.
Kann ich das Beispiel als Vorlage verwenden?
Ja. Lade es als Word-Datei herunter und passe Zahlen, Systeme und Prioritäten an dein Vorhaben an — oder erstelle mit dem Generator in etwa einer Minute ein Lastenheft aus deiner eigenen Beschreibung.
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Das Lastenheft schreibt der Auftraggeber: was gebraucht wird und warum. Das Pflichtenheft schreibt der Auftragnehmer: wie die Anforderungen umgesetzt und getestet werden.

Weitere Beispiele

Dein eigenes Lastenheft in einer Minute

Beschreib dein Vorhaben — PathHub erstellt das Dokument mit nummerierten Anforderungen und Word-Export. Kostenlos, ohne Anmeldung.

Lastenheft erstellen →