Projektmanagement

Wie Sie ein Lastenheft für ein Software- oder Webprojekt schreiben

Von Codevista InnovationsVeröffentlicht am 12. Oktober 20268 Min. Lesezeit

Ein gutes Lastenheft beschreibt den Bedarf, nicht die Lösung: wer die Nutzer sind, was sie tun können müssen, wann eine Funktion als fertig gilt und unter welchen Rahmenbedingungen (Sicherheit, Hosting, Sprachen, Budget, Termine). Es lässt sich in acht Kapitel gliedern, von den Geschäftszielen bis zum Eigentum am Quellcode und zur Wartung. Sorgfältig geschrieben, dient es Auftraggeber und Dienstleister als gemeinsame Referenz und geht während des Projekts in ein agiles Backlog über.

Wozu dient ein Lastenheft bei einem Webprojekt?

Das Lastenheft übersetzt einen fachlichen Bedarf in Anforderungen, die ein Entwicklungsteam versteht. Für die Geschäftsführung oder die IT-Leitung ist es das Werkzeug, um Angebote zu vergleichen, ein realistisches Budget zu schätzen und das Projekt ohne Missverständnisse zu steuern.

Es schützt den Auftraggeber: Ohne Referenzdokument lässt sich kaum belegen, dass eine Funktion fehlt oder eine Lieferung nicht vertragsgemäß ist. Es schützt aber auch den Dienstleister: Ein schriftlich festgelegter Umfang begrenzt Zusatzwünsche, die nie kalkuliert wurden.

Liegt das Dokument vor, erklärt unser Leitfaden zur Auswahl einer Entwicklungsagentur in Casablanca, welche Fragen Sie den Kandidaten stellen sollten.

Welcher Aufbau eignet sich für ein Software-Lastenheft?

Hier eine Mustergliederung, die Sie an die Größe des Projekts anpassen. Das Warum kommt vor dem Was, das Was vor dem Wie.

1. Ausgangslage und Ziele: die aktuelle Situation, das zu lösende Problem und die fachlichen Kennzahlen, an denen das Unternehmen selbst das Ergebnis messen wird (Bearbeitungszeit eines Vorgangs, Eingabefehler, Aufgaben, die noch von Hand erledigt werden).
2. Nutzer und Personas: wer das Werkzeug verwenden wird (Kunden, Vertrieb, Backoffice, Führungskräfte), auf welchem Gerät und in welcher Sprache.
3. Funktionaler Umfang: der Bedarf, formuliert als User Stories, jede mit Akzeptanzkriterien und Priorität.
4. Nicht-funktionale Anforderungen: Performance, Sicherheit, Barrierefreiheit, Hosting, Sprachen.
5. Schnittstellen: ERP, CRM, E-Mail, Online-Zahlungsanbieter, Single Sign-on (SSO), APIs von Partnern.
6. Daten und Migration: zu übernehmende Bestandsdaten, deren Qualität, Aufbewahrungsfristen und die betroffenen personenbezogenen Daten.
7. Rahmenbedingungen, Budget und Zeitplan: ein Budgetrahmen, ein verbindlicher oder gewünschter Termin, regulatorische oder interne Vorgaben.
8. Liefergegenstände, Eigentum und Wartung: was übergeben wird, wem Quellcode und geistiges Eigentum gehören, wie die Software gewartet wird.

Einige gut gegliederte Seiten sind mehr wert als ein dickes Dokument, das niemand liest. Legen Sie Entwürfe (Mock-ups) und Screenshots des Bestandssystems als Anhang bei.

Funktionen beschreiben: User Stories und Akzeptanzkriterien

Die wirksamste Form ist die User Story: „Als [Nutzer] möchte ich [Aktion], damit [Nutzen].“ Sie zwingt dazu, festzuhalten, wer den Bedarf hat und warum.

Zu jeder Story gehören Akzeptanzkriterien: überprüfbare Bedingungen, anhand derer sich ohne Diskussion sagen lässt, ob die Funktion fertig ist. Ein Beispiel für einen Urlaubsantrag:

• die Mitarbeiterin oder der Mitarbeiter sieht den Resturlaub, bevor der Antrag abgeschickt wird;
• die Führungskraft erhält eine Benachrichtigung und kann mit Kommentar genehmigen oder ablehnen;
• ein Antrag, der sich mit einem bereits genehmigten Zeitraum überschneidet, wird mit einer klaren Meldung blockiert.

Versehen Sie jede Story mit einer Priorität, etwa nach der MoSCoW-Methode (Must, Should, Could, Won't: unverzichtbar, wichtig, wünschenswert, in dieser Version ausgeschlossen). Sie ist die Grundlage, um bei knapperem Budget abzuwägen und eine erste, tatsächlich nutzbare Version abzugrenzen.

Nicht-funktionale Anforderungen: Sicherheit, Performance, Sprachen und Hosting

Diese Anforderungen werden oft vergessen, und das Nachholen ist teuer. Beschreiben Sie das erwartete Niveau, nicht eine Technologie.

• Performance: erwartete gleichzeitige Nutzer, akzeptable Antwortzeit auf den kritischen Bildschirmen, Nutzung im Mobilfunknetz.
• Sicherheit: Rollen und Rechte, Authentifizierung, Protokollierung sensibler Aktionen, Datensicherung und Wiederherstellung. Fragen Sie den Dienstleister auch, wie er Ihre Daten auf seiner Seite schützt; eine Zertifizierung nach ISO/IEC 27001 ist ein Indiz dafür, wie unser Artikel zur Datensicherheit bei einem Dienstleister erläutert.
• Personenbezogene Daten: In Marokko regelt das Gesetz 09-08 (loi 09-08, das marokkanische Datenschutzgesetz) ihre Verarbeitung. Die Formalitäten bei der CNDP, der nationalen Datenschutzbehörde, obliegen dem Verantwortlichen, in der Regel also dem Kundenunternehmen; legen Sie fest, was der Dienstleister zu deren Vorbereitung liefern muss (Zwecke, Datenkategorien, Sicherheitsmaßnahmen).
• Barrierefreiheit: Kontraste, Tastaturbedienung, Kompatibilität mit Screenreadern; die WCAG-Richtlinien des W3C bieten ein gemeinsames Vokabular, um das erwartete Niveau festzulegen.
• Hosting: Cloud oder eigene Server, Speicherort der Daten, falls vorgeschrieben (auch die Übermittlung personenbezogener Daten ins Ausland regelt das Gesetz 09-08), Test- und Produktivumgebungen.
• Sprachen: Französisch, Arabisch, Englisch, eventuell Amazigh. Arabisch verlangt eine Oberfläche von rechts nach links (RTL): gespiegeltes Layout, passende Typografie, Felder mit gemischtem arabischem Text und Ziffern. Von Anfang an eingeplant, ist das eine Designentscheidung; am Projektende nachgerüstet, wird es zur Baustelle.

Schnittstellen, Daten und Migration: der unterschätzte Teil

Eine Fachanwendung steht selten für sich allein. Geben Sie für jedes anzubindende System an, was in welche Richtung und wie häufig ausgetauscht werden muss, wer der technische Ansprechpartner ist und ob es eine API-Dokumentation und eine Testumgebung gibt. Eine Schnittstelle, deren Anbieter nicht reagiert, kann ein ganzes Projekt blockieren: Das sollten Sie vor der Unterschrift wissen.

Die Datenübernahme verdient dieselbe Aufmerksamkeit. Listen Sie die Quellen auf (Excel-Dateien, Altanwendung, bestehende Datenbank), schätzen Sie deren Qualität ehrlich ein (Dubletten, leere Felder, uneinheitliche Formate) und legen Sie fest, wer die Bereinigung übernimmt. Planen Sie mindestens eine Probemigration auf der Testumgebung vor der eigentlichen Umstellung ein, dazu einen Rückfallplan, falls sie scheitert.

Budget, Termine, Liefergegenstände und Eigentum am Quellcode

Viele Unternehmen scheuen sich, ein Budget zu nennen. Dabei ermöglicht ein Budgetrahmen den Dienstleistern, eine passende Lösung vorzuschlagen, statt Angebote abzugeben, die sich nicht vergleichen lassen. Unterscheiden Sie außerdem zwischen verbindlichem Termin und Wunschtermin.

Das Kapitel zu den Liefergegenständen muss jede Unklarheit ausräumen:

• Übergabe des Quellcodes in einem Repository, auf das das Unternehmen selbst Zugriff hat;
• geistiges Eigentum am für Sie entwickelten Code sowie Nutzungsbedingungen für wiederverwendete oder Open-Source-Komponenten; gehen Sie nicht davon aus, dass Sie mit der Bezahlung der Entwicklung automatisch Eigentümer werden, sondern lassen Sie die Rechteübertragung schriftlich festhalten;
• technische Dokumentation, Zugänge zu Hosting-Konten und Domainnamen auf den Namen des Unternehmens;
• Bedingungen der Wartung: Fehlerbehebungen, Weiterentwicklungen, Reaktionszeiten, Reversibilität bei einem Dienstleisterwechsel.

Diese Klauseln gehören in den Vertrag: Lassen Sie sie von einer Juristin oder einem Juristen prüfen, statt sich auf eine allgemeine Vorlage zu verlassen.

Festes Lastenheft oder agiles Backlog: wie Sie beides verbinden

Ein Lastenheft für einen Festpreisauftrag, das den gesamten Umfang festschreibt, beruhigt den Einkauf, setzt aber voraus, dass alle Anforderungen im Voraus bekannt sind, was selten der Fall ist. Umgekehrt lässt ein Backlog ohne schriftlichen Rahmen den Auftraggeber ohne Budgetschutz. Die Kombination, die funktioniert:

1. im Dokument festschreiben, was sich nicht ändern soll: Ziele, Nutzer, nicht-funktionale Anforderungen, Budget, Termine, Liefergegenstände und Eigentum;
2. den funktionalen Umfang als priorisierte User Stories formulieren, die zum ersten Backlog werden;
3. eine Discovery-Phase vorsehen, um die vorrangigen Stories zu verfeinern;
4. in jeder Iteration auf einer Testumgebung abnehmen und jede neue Anforderung abwägen, indem sie eine Story mit geringerer Priorität ersetzt.

So arbeitet Codevista Innovations bei seinen Entwicklungsprojekten: eine Discovery- und Designphase (UX/UI), danach Sprints von zwei Wochen mit regelmäßigen Lieferungen auf eine Staging-Umgebung zur Abnahme. Wenn Sie unsicher sind, wie Sie dieses Backlog lebendig halten, hilft unser Vergleich Scrum oder Kanban bei der Wahl.

Auf Kundenseite muss die Person, die das Projekt steuert, Umfang, Risiken und Stakeholder im Griff haben: genau diese Bereiche deckt die PMP®-Schulung ab, die auf die Zertifizierung des PMI vorbereitet.

Häufige Fehler im Lastenheft für eine Anwendung

• Eine Lösung statt eines Bedarfs beschreiben: „ein Excel-Button oben rechts“ statt „die Personalabteilung muss die Historie in ihren eigenen Werkzeugen auswerten können“. Der Dienstleister kann dann nichts Besseres mehr vorschlagen.
• Nicht priorisieren: Wenn alles unverzichtbar ist, ist es nichts, und die erste Budgetentscheidung wird zum Konflikt.
• Akzeptanzkriterien vergessen: Die Abnahme wird zur Auslegungsdebatte.
• Allein schreiben: Ein Dokument, das die IT-Abteilung ohne die Fachbereiche verfasst, oder umgekehrt, übersieht einen Teil der Rahmenbedingungen.
• Beim Go-live aufhören: Sind Hosting, Wartung und Reversibilität nicht schwarz auf weiß geregelt, wird die gelieferte Software schnell zu einer ungewollten Abhängigkeit.

Sie wünschen einen Blick von außen auf Ihr Lastenheft oder möchten ein künftiges maßgeschneidertes SaaS-Projekt vorbereiten? Das Team von Codevista Innovations in Casablanca bespricht es gern mit Ihnen: Nehmen Sie Kontakt auf.

Häufige Fragen

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft (im Französischen „cahier des charges fonctionnel“) beschreibt, was die Software ermöglichen soll, für welche Nutzer und mit welchen Abnahmekriterien. Das Pflichtenheft („cahier des charges technique“) beschreibt, wie sie umgesetzt wird: Architektur, Technologien, Datenmodell, Hosting. Der Auftraggeber verfasst das Lastenheft; das Pflichtenheft erstellt in der Regel der Dienstleister, abgestimmt mit der IT-Leitung.

Wie viele Seiten sollte ein Lastenheft für eine Webanwendung haben?

Eine ideale Länge gibt es nicht: Ein einfaches internes Werkzeug kommt mit wenigen Seiten aus, eine Plattform mit vielen Schnittstellen braucht mehr. Entscheidend ist die Überprüfbarkeit: Jede erwartete Funktion muss identifizierbar, priorisiert und mit Akzeptanzkriterien versehen sein. Kurz und von den Fachbereichen gegengelesen ist besser als lang und ignoriert.

Sollte das Budget im Lastenheft stehen?

Ja, zumindest als Rahmen. Ohne Angabe kalkulieren die Dienstleister ihre Angebote sehr unterschiedlich, und die Vorschläge lassen sich nicht mehr vergleichen. Ein Budgetrahmen erlaubt es jedem, Realistisches anzubieten und eine Aufteilung in aufeinanderfolgende Versionen vorzuschlagen. Geben Sie auch an, ob das Budget Wartung und Hosting nach dem Go-live abdeckt.

Ist ein Lastenheft mit Scrum vereinbar?

Ja, sofern nicht alles festgeschrieben wird. Das Dokument legt Ziele, Nutzer, nicht-funktionale Anforderungen, Budget, Liefergegenstände und das Eigentum am Code fest. Der funktionale Umfang, formuliert als priorisierte User Stories, wird zum ersten Product Backlog, das der Product Owner ordnet und das Team Sprint für Sprint verfeinert. Jede neue Anforderung wird gegen die bestehenden Stories abgewogen, was das Budget unter Kontrolle hält.