Pflichtenheft und Lastenheft für Software: Vorlage und Anleitung

Lastenheft vs. Pflichtenheft

Das Lastenheft beschreibt aus Sicht des Auftraggebers, was eine Software leisten soll und warum: Ziele, Nutzer, Prozesse, Anforderungen und Rahmenbedingungen. Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers, wie diese Anforderungen umgesetzt werden: Architektur, Technologien, Schnittstellen, Datenmodell, Abnahmekriterien. Vereinfacht gesagt ist das Lastenheft die Frage und das Pflichtenheft die Antwort. Beide Begriffe sind im deutschsprachigen Raum etabliert und unter anderem in der Norm DIN 69901-5 beschrieben.

Wann Sie welches brauchen

Ein Lastenheft brauchen Sie fast immer, sobald Sie Software von einem externen Anbieter entwickeln lassen. Es zwingt Sie, Ziele und Prioritäten zu klären, bevor Geld fliesst, und es macht Offerten vergleichbar. Ohne Lastenheft schätzt jeder Anbieter ein anderes Projekt.

Ein Pflichtenheft brauchen Sie, wenn ein Fixpreis vereinbart wird, wenn mehrere Lieferanten zusammenarbeiten, wenn die Software in einem regulierten Umfeld eingesetzt wird (etwa als Medizinprodukt) oder wenn eine öffentliche Ausschreibung es verlangt.

Für kleine Projekte, etwa ein internes Tool mit wenigen Funktionen, genügt oft ein kurzes Lastenheft von wenigen Seiten plus ein gemeinsamer Workshop. Das Pflichtenheft entsteht dann schlank als Ergebnis dieses Workshops. Wichtig ist nicht das Format, sondern dass beide Seiten dasselbe unter dem Projekt verstehen und das schriftlich festgehalten ist.

Und bei agiler Entwicklung?

Agile Entwicklung bedeutet nicht, ohne Plan zu arbeiten. Sie bedeutet, dass sich Details während des Projekts ändern dürfen, weil man unterwegs lernt. Das Lastenheft bleibt deshalb sinnvoll: Ziele, Nutzergruppen, Rahmenbedingungen und eine priorisierte Liste von Anforderungen sind die beste Grundlage für ein agiles Projekt.

Das klassische Pflichtenheft wird in agilen Projekten ersetzt durch:

• ein Backlog mit User Stories und Akzeptanzkriterien, das laufend gepflegt wird,
• eine schlanke Architekturdokumentation, die die wichtigsten technischen Entscheidungen festhält,
• eine Definition of Done, die für jede Anforderung gilt.

So arbeiten auch wir: Eine kurze Konzeptphase schafft ein gemeinsames Verständnis, danach wird in kurzen Zyklen entwickelt. Mehr dazu unter unserem Prozess.

Lastenheft-Vorlage

Die folgende Gliederung können Sie kopieren und als Grundlage für Ihr eigenes Lastenheft verwenden. Die Leitfragen unter jedem Kapitel helfen Ihnen, die richtigen Inhalte zu finden. Nicht jedes Kapitel ist für jedes Projekt gleich wichtig; streichen Sie, was nicht passt.

# Lastenheft: [Projektname]
Version, Datum, Verfasser, Ansprechperson

## 1. Ausgangslage
- Wer sind wir? (Unternehmen, Branche, Grösse)
- Wie läuft der Prozess heute ab?
- Welches Problem wollen wir lösen? Was kostet uns das Problem heute?

## 2. Ziele
- Was soll nach der Einführung besser sein?
- Woran messen wir den Erfolg? (Kennzahlen, z. B. Bearbeitungszeit, Fehlerquote, Nutzerzahl)
- Was ist ausdrücklich NICHT Ziel dieses Projekts?

## 3. Nutzergruppen
- Wer nutzt die Software? (Rollen, Anzahl, technische Kenntnisse)
- Auf welchen Geräten? (Desktop, Smartphone, Tablet, unterwegs, offline)
- Welche Rechte hat welche Rolle?

## 4. Prozesse und Anwendungsfälle
- Welche Abläufe soll die Software abbilden? (Schritt für Schritt)
- Welche Sonderfälle und Ausnahmen gibt es?
- Wo entstehen heute Medienbrüche oder Doppelerfassungen?

## 5. Funktionale Anforderungen
- Liste der Anforderungen, jeweils mit ID und Priorität (Muss / Soll / Kann)
- Pro Anforderung: Beschreibung, Begründung, Abnahmekriterium

## 6. Nicht-funktionale Anforderungen
- Performance: Wie schnell muss es sein? Wie viele gleichzeitige Nutzer?
- Verfügbarkeit: Welche Ausfallzeit ist akzeptabel?
- Sicherheit: Anmeldung, Berechtigungen, Protokollierung
- Bedienbarkeit und Barrierefreiheit
- Sprachen

## 7. Daten und Schnittstellen
- Welche Daten werden verarbeitet? Gibt es besonders schützenswerte Personendaten?
- Welche bestehenden Systeme müssen angebunden werden? (ERP, CRM, Buchhaltung, SSO)
- Welche Daten müssen aus Altsystemen übernommen werden? In welcher Qualität liegen sie vor?

## 8. Rahmenbedingungen
- Datenschutz (nDSG, allenfalls DSGVO), Datenhaltung in der Schweiz?
- Regulatorische Vorgaben (z. B. Medizinprodukte, Finanzmarkt)
- Vorgaben der internen IT (Hosting, Technologien, Sicherheitsrichtlinien)
- Corporate Design

## 9. Projektorganisation
- Wer entscheidet auf Auftraggeberseite?
- Wer testet und nimmt ab?
- Wie viel Zeit können interne Fachpersonen einbringen?

## 10. Budget und Termine
- Budgetrahmen (Spanne genügt)
- Gewünschter Starttermin, fixe Termine (z. B. Messe, Saisonstart)
- Gewünschte Etappen

## 11. Betrieb und Weiterentwicklung
- Wer betreibt die Software nach der Einführung?
- Welche Wartung und welcher Support werden erwartet?
- Wem gehören Quellcode und Rechte?

## 12. Anhang
- Prozessskizzen, Screenshots des Ist-Zustands, Beispieldaten, Mockups

Die Kapitel 2, 4 und 5 sind der Kern. Wenn Sie wenig Zeit haben, investieren Sie sie dort.

Pflichtenheft-Vorlage

Das Pflichtenheft baut auf dem Lastenheft auf und wird vom Auftragnehmer erstellt, idealerweise in einer gemeinsamen Konzeptphase. Diese Gliederung zeigt, was ein vollständiges Pflichtenheft für ein Softwareprojekt enthält:

# Pflichtenheft: [Projektname]
Version, Datum, Bezug zum Lastenheft (Version)

## 1. Zusammenfassung
- Ziel des Projekts und gewählter Lösungsansatz in wenigen Sätzen

## 2. Systemübersicht
- Komponenten (z. B. Web-App, Mobile App, Backend, Admin-Oberfläche)
- Architekturdiagramm
- Technologien und Begründung

## 3. Umsetzung der funktionalen Anforderungen
- Pro Anforderung aus dem Lastenheft (gleiche ID): Lösungsbeschreibung
- Benutzeroberfläche: Wireframes oder Designs der wichtigsten Screens
- Abgrenzung: Was wird nicht umgesetzt oder später?

## 4. Umsetzung der nicht-funktionalen Anforderungen
- Performance-, Sicherheits- und Verfügbarkeitskonzept
- Berechtigungskonzept

## 5. Datenmodell
- Wichtigste Entitäten und Beziehungen
- Datenhaltung, Aufbewahrung, Löschung

## 6. Schnittstellen
- Pro Schnittstelle: Partner-System, Richtung, Datenformat, Häufigkeit, Fehlerbehandlung

## 7. Datenmigration
- Quellen, Mapping, Bereinigung, Probeläufe

## 8. Betrieb
- Hosting, Umgebungen (Test, Staging, Produktion), Monitoring, Backups

## 9. Qualitätssicherung und Abnahme
- Teststrategie (automatisierte Tests, manuelle Tests, Nutzertests)
- Abnahmekriterien und Abnahmeverfahren

## 10. Projektplan
- Etappen, Meilensteine, Abhängigkeiten, Mitwirkungspflichten des Auftraggebers

## 11. Risiken und Annahmen
- Bekannte Risiken und Gegenmassnahmen
- Getroffene Annahmen

## 12. Glossar

Achten Sie darauf, dass jede Anforderung aus dem Lastenheft im Pflichtenheft wieder auftaucht, mit derselben ID. So bleibt nachvollziehbar, was umgesetzt wird und was nicht.

Beispiel-Anforderung richtig formuliert

Die Qualität eines Lastenhefts steht und fällt mit der Formulierung der einzelnen Anforderungen. Eine gute Anforderung ist eindeutig, prüfbar und priorisiert. Verwenden Sie dafür drei Stufen:

• Muss: Ohne diese Anforderung ist die Software nicht einsetzbar.
• Soll: Wichtig, aber für einen ersten Einsatz verzichtbar.
• Kann: Wünschenswert, wenn Budget und Zeit es zulassen.

Schlecht formuliert

«Die Suche soll schnell und benutzerfreundlich sein.»

Was heisst schnell? Was heisst benutzerfreundlich? Zwei Anbieter werden darunter zwei völlig unterschiedliche Lösungen verstehen und entsprechend unterschiedlich offerieren.

Gut formuliert

A-12 (Muss): Innendienst-Mitarbeitende können Kunden über Name, Kundennummer oder Ort suchen. Die Trefferliste erscheint bei bis zu 50'000 Kunden in unter einer Sekunde. Tippfehler mit einem falschen Buchstaben liefern trotzdem den richtigen Kunden.

A-13 (Soll): Die letzten zehn aufgerufenen Kunden werden ohne Suche als Liste angezeigt.

A-14 (Kann): Die Suche berücksichtigt auch Ansprechpersonen beim Kunden.

Jede dieser Anforderungen hat eine ID, eine Priorität, eine klare Rolle, ein messbares Kriterium und lässt sich bei der Abnahme eindeutig prüfen.

Was Agenturen aus einem Lastenheft lesen

Wenn wir ein Lastenheft erhalten, suchen wir vor allem nach Hinweisen auf Aufwand und Risiken. Diese Punkte beeinflussen eine Offerte am stärksten:

• Anzahl Rollen und Prozesse: Der beste Indikator für den Grundaufwand.
• Schnittstellen: Jedes angebundene System ist ein Risiko, besonders ältere Systeme ohne dokumentierte API.
• Datenmigration: Wie viele Daten, aus wie vielen Quellen, in welcher Qualität?
• Nicht-funktionale Anforderungen: Hohe Verfügbarkeit, strenge Performance-Vorgaben oder Datenhaltung in der Schweiz verändern Architektur und Betriebskosten.
• Regulatorik: Medizinprodukte oder Finanzmarkt bedeuten zusätzliche Dokumentation und Tests.
• Mitwirkung: Wer entscheidet, und wie schnell? Unklare Zuständigkeiten sind eines der grössten Projektrisiken.
• Was fehlt: Fehlende Ziele oder Priorisierungen deuten darauf hin, dass sich der Umfang während des Projekts noch stark bewegen wird.

Ein gutes Lastenheft führt deshalb nicht nur zu einer genaueren, sondern oft auch zu einer tieferen Offerte, weil weniger Risiko eingepreist werden muss. Welche Grössenordnungen realistisch sind, zeigen unsere Artikel zu den Kosten von Individualsoftware und den Kosten einer App-Entwicklung.

Typische Fehler

• Lösungen statt Anforderungen: «Wir brauchen ein Dropdown mit allen Filialen» ist eine Lösung. «Mitarbeitende müssen Aufträge einer Filiale zuordnen können» ist die Anforderung. Lassen Sie dem Anbieter Raum für bessere Ideen.
• Keine Priorisierung: Wenn alles «Muss» ist, ist nichts priorisiert. Rechnen Sie damit, dass ein Drittel Ihrer Wünsche in die zweite Etappe gehört.
• Unmessbare Begriffe: «Schnell», «modern», «intuitiv» ohne Kriterium sind nicht prüfbar.
• Ziele fehlen: Ohne Ziele kann niemand beurteilen, ob eine Anforderung wichtig ist.
• Sonderfälle vergessen: Stornos, Teillieferungen, Vertretungen, Jahresabschluss. Hier steckt oft die Hälfte des Aufwands.
• Betrieb ignoriert: Wer betreibt, wartet und entwickelt die Software nach dem Launch weiter?
• Zu früh zu detailliert: 100 Seiten Detailspezifikation, bevor die Grundidee validiert ist, bremsen mehr, als sie helfen.

Vorlage als Datei erhalten

Sie möchten die Lastenheft-Vorlage und die Pflichtenheft-Vorlage als bearbeitbares Dokument? Schreiben Sie uns eine kurze E-Mail an info@softverse.ch mit dem Betreff «Vorlage Lastenheft». Wir senden Ihnen beide Vorlagen zu.

Wenn Sie lieber gemeinsam starten, gehen wir Ihr Vorhaben im kostenlosen Erstgespräch durch. In 30 Minuten klären wir, welche Anforderungen ins Lastenheft gehören, was in eine erste Etappe passt und wie eine sinnvolle Konzeptphase aussieht. Mehr zu Projekten dieser Art finden Sie unter Individualsoftware.