Lastenheft für Software: Aufbau, Beispiel, VorlageLastenheft für Software: Aufbau, Beispiel, Vorlage

Bevor eine Agentur eine Website oder eine Software offerieren kann, muss sie wissen, was Sie brauchen. Meistens kommt diese Information in einer E-Mail mit drei Sätzen und einem Link auf die Website der Konkurrenz. Die Offerten, die darauf folgen, lassen sich kaum vergleichen, weil jede Agentur die Lücken anders füllt.

Ein Lastenheft schliesst diese Lücken. Es beschreibt in Ihren Worten, was das Projekt leisten soll, für wen und woran Sie das Ergebnis messen. Dieser Ratgeber richtet sich an Inhaberinnen, Geschäftsführer und Projektleitende in kleinen und mittleren Unternehmen, die demnächst eine Website, eine Webanwendung oder eine App in Auftrag geben. Am Ende haben Sie ein Lastenheft mit acht Teilen, das ein Team prüfen und offerieren kann und an dem Sie das Ergebnis später abnehmen. Wer gleich loslegen will, lädt die kostenlose Word-Vorlage herunter und liest daneben mit.

Lastenheft oder Pflichtenheft: wer schreibt was?

Die beiden Begriffe werden oft verwechselt, dabei ist die Aufteilung einfach. Das Lastenheft schreiben Sie als Auftraggeber. Es hält fest, was Sie brauchen und warum. Die Norm DIN 69901-5 beschreibt es als die vom Auftraggeber festgelegte «Gesamtheit der Forderungen an die Lieferungen und Leistungen». Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf. Es legt fest, wie die Anforderungen umgesetzt werden, was das kostet und wann es fertig ist.

Kurz gesagt: Das Lastenheft beschreibt das Was und das Wozu, das Pflichtenheft das Wie. Wenn Sie im Lastenheft bereits vorschreiben, mit welcher Datenbank oder welchem Framework gebaut wird, nehmen Sie der Agentur die Arbeit ab, für die Sie sie bezahlen, und übernehmen gleichzeitig das Risiko für diese Entscheidung.

In der Schweiz ist der Sprachgebrauch weniger streng. Auch das Dokument des Auftraggebers heisst hier oft Pflichtenheft, etwa in Projekten, die nach HERMES geführt werden, der Projektmanagementmethode des Bundes. Lassen Sie sich davon nicht verwirren: Entscheidend ist nicht der Name, sondern wer das Dokument schreibt und was darin steht. Wer sich vertiefen will, findet in der Richtlinie VDI 2519 eine ausführliche Anleitung zum Aufbau beider Dokumente. Für ein Website- oder Softwareprojekt eines KMU reicht der Aufbau, den wir hier zeigen.

Was in ein Lastenheft gehört

Ein gutes Lastenheft für eine Website oder Software hat acht Teile. Sie bauen aufeinander auf: Aus dem Ziel folgen die Nutzer, aus den Nutzern die Abläufe, aus den Abläufen die Funktionen. Am Schluss stehen die Rahmenbedingungen, also Qualität, Abnahme, Budget und Termine.

Damit die Teile nicht abstrakt bleiben, begleitet uns ein Beispiel durch den ganzen Ratgeber. Es ist erfunden, aber typisch: ein Sanitärbetrieb mit 25 Mitarbeitenden im Kanton Freiburg. Die Kundschaft spricht Deutsch oder Französisch. Aufträge laufen heute auf Papier, die Rechnungen schreibt der Betrieb bereits mit Bexio. Nun soll eine Software die Papierzettel ablösen. Wir geben dem Betrieb keinen Namen und nennen keine Beträge.

Ziel und Ausgangslage

Beginnen Sie mit dem Grund für das Projekt. Was läuft heute schlecht, was soll danach besser sein, und woran erkennen Sie, dass es funktioniert hat? Beschreiben Sie auch, was es heute schon gibt: Systeme, Dokumente, Gewohnheiten. Ein Ziel wie «Digitalisierung» hilft niemandem. Ein Ziel wie «kein Rapport wird mehr abgetippt» lässt sich überprüfen.

Beispiel: Heute schreiben die Monteure ihre Rapporte von Hand. Am Abend tippt das Büro sie ab, und erst dann kann die Rechnung in Bexio erstellt werden. Dabei gehen Stunden und Material verloren, und Rechnungen gehen oft erst Tage nach dem Einsatz hinaus. Ziel: Jeder Auftrag wird vom Anruf bis zur Rechnung digital erfasst. Der Erfolg zeigt sich daran, dass das Büro keinen Rapport mehr abtippt und die Rechnung am Tag nach dem Einsatz bereit ist.

Nutzer und Rollen

Halten Sie fest, wer mit dem System arbeitet, wie viele Personen das sind und was jede Rolle sehen und tun darf. Rollen bestimmen Berechtigungen, und Berechtigungen bestimmen einen grossen Teil des Aufwands. Denken Sie auch an Personen, die das System nur selten nutzen, etwa die Geschäftsleitung oder eine externe Treuhänderin.

Beispiel: Drei Personen im Büro erfassen Aufträge und planen Einsätze. Rund 20 Monteure sehen nur ihre eigenen Aufträge und erfassen Rapporte auf dem Handy. Der Inhaber sieht alles und gibt Rechnungen frei. Die Kundinnen und Kunden arbeiten nicht im System, sie erhalten nur eine SMS und die Rechnung.

Abläufe

Beschreiben Sie Schritt für Schritt, wie die Arbeit heute abläuft und wie sie im neuen System laufen soll. Wer macht was, in welcher Reihenfolge, und wo wechselt die Verantwortung? An diesen Übergaben entstehen die meisten Fehler, und dort bringt eine Software am meisten.

Beispiel: Der Kunde ruft an. Das Büro erfasst den Auftrag und plant einen Monteur ein. Der Monteur erhält den Auftrag auf dem Handy. Vor Ort hält er Fotos, Material, Stunden und die Unterschrift des Kunden fest. Das Büro prüft den Rapport, die Rechnung geht an Bexio, und der Kunde erhält sie. Heute liegt zwischen dem vierten und dem fünften Schritt ein Rapport auf Papier, der am Abend abgetippt wird. Genau diesen Schritt soll das Projekt ablösen.

Funktionen nach Priorität

Listen Sie die Funktionen auf, die sich aus den Abläufen ergeben, und ordnen Sie jeder eine Priorität zu: Muss, Soll, Kann oder Nicht jetzt. Die Muss-Funktionen bilden die erste Version. Ohne sie hat das Projekt sein Ziel verfehlt. Soll-Funktionen kommen dazu, wenn Budget und Zeit reichen. Kann-Funktionen sind Ideen für später, und Nicht jetzt hält fest, was bewusst draussen bleibt. Diese letzte Spalte ist wichtiger, als sie aussieht: Sie verhindert, dass ein Wunsch nebenbei mitwächst.

Beispiel: Muss: Aufträge erfassen, Einsätze planen, Rapport auf dem Handy mit Fotos und Unterschrift, Rechnung an Bexio. Soll: eine SMS an den Kunden vor dem Einsatz und wiederkehrende Wartungsaufträge. Kann: Online-Terminbuchung für Kunden und Auswertungen pro Monteur. Nicht jetzt: ein Kundenportal und eine Lagerverwaltung. Die erste Version umfasst alle vier Muss-Funktionen und die SMS vor dem Einsatz.

Daten und Schnittstellen

Schreiben Sie auf, welche Daten Sie führen, woher sie kommen und mit welchen Systemen das neue System verbunden sein muss. Nennen Sie bestehende Programme beim Namen und sagen Sie, in welche Richtung die Daten fliessen. Wenn alte Daten übernommen werden sollen, gehört auch das hierher, mit einer groben Menge.

Beispiel: Die Kundendaten liegen heute in Bexio und sollen dort bleiben. Das neue System liest Kunden und Adressen aus Bexio und schreibt freigegebene Rechnungen mit Positionen für Stunden und Material zurück. Fotos und Unterschriften bleiben beim Auftrag gespeichert. Alte Papierrapporte werden nicht übernommen.

Qualität

Hier stehen die Anforderungen, die keine Funktion sind, aber über Erfolg und Misserfolg entscheiden: Ladezeiten, Sicherheit, Sprachen, Geräte und Barrierefreiheit. Schreiben Sie jede so, dass man sie prüfen kann, mit einer Zahl oder einer klaren Bedingung. Für die Schweiz gehört der Datenschutz dazu: Personendaten fallen unter das Datenschutzgesetz (DSG), und wer Kundschaft in der EU bedient, muss unter Umständen auch die DSGVO beachten. Halten Sie fest, wo die Daten gespeichert werden dürfen.

Beispiel: Die Oberfläche für die Monteure gibt es auf Deutsch und Französisch, die SMS geht in der Sprache des Kunden hinaus. Die App läuft auf gängigen Android- und iOS-Handys und funktioniert auch im Keller ohne Empfang: Der Rapport wird gespeichert und später übertragen. Jede Seite lädt auf einem gängigen Handy über mobile Daten in unter 2,5 Sekunden. Die Daten liegen in der Schweiz oder in der EU.

Abnahme

Beschreiben Sie, wie Sie das fertige Ergebnis prüfen, bevor Sie es abnehmen. Wer testet, mit welchen Daten, und was muss dabei herauskommen? Wer die Abnahme schon im Lastenheft festlegt, schreibt automatisch klarere Anforderungen, denn jede Anforderung braucht eine Prüfung. Halten Sie auch fest, was Sie bei der Übergabe erhalten: Zugänge, Dokumentation und eine Einführung für das Team.

Beispiel: Das Büro und zwei Monteure spielen 20 Testaufträge vom Anruf bis zur Rechnung durch. Die Abnahme gilt als bestanden, wenn alle freigegebenen Rechnungen ohne Abtippen in Bexio ankommen und ein neuer Monteur seinen ersten Rapport ohne Schulung in unter drei Minuten erfasst. Bei der Übergabe erhält der Betrieb alle Zugänge und eine kurze Anleitung für Büro und Monteure.

Budget, Termine und Rechte am Code

Nennen Sie einen Budgetrahmen, auch wenn er grob ist. Ein Rahmen ist kein Verhandlungsnachteil. Er erlaubt der Agentur, eine Lösung vorzuschlagen, die hineinpasst, statt zu raten. Nennen Sie die Termine, die wirklich feststehen, und sagen Sie, warum. Und klären Sie, wem der Code danach gehört. Bei uns gehört er dem Kunden, aber das ist nicht überall so, und es lohnt sich, das schriftlich festzuhalten.

Beispiel: Budgetrahmen für die erste Version: CHF ___ bis CHF ___. Die erste Version soll vor der Heizungssaison im Herbst laufen, weil dann die meisten Aufträge eingehen. Der Betrieb erhält den gesamten Quellcode und alle Zugänge und kann das System später auch von einem anderen Team weiterentwickeln lassen.

Anforderungen, die man prüfen kann

Die meisten Lastenhefte scheitern nicht an fehlenden Funktionen, sondern an vagen Formulierungen. «Die App soll schnell sein» klingt vernünftig, aber niemand kann prüfen, ob es erfüllt ist. Die Agentur versteht darunter etwas anderes als Sie, und bei der Abnahme beginnt die Diskussion.

Eine prüfbare Anforderung hat drei Teile: was gemessen wird, der Grenzwert und wie geprüft wird. Die internationale Norm ISO/IEC/IEEE 29148 verlangt von guten Anforderungen unter anderem genau das: Sie sollen eindeutig und überprüfbar sein. Sie müssen die Norm nicht lesen. Es reicht, jede Anforderung mit der Frage zu prüfen: Wie würde ich bei der Abnahme feststellen, ob das erfüllt ist?

Im Beispiel sieht das so aus:

• Die App soll schnell sein. Prüfbar: Jede Seite lädt in unter 2,5 Sekunden, gemessen auf einem gängigen Handy über mobile Daten. Der Wert ist ein Beispiel. Er entspricht Googles Schwelle für einen guten Largest Contentful Paint, den Moment, in dem das grösste Element einer Seite erscheint.
• Die App soll einfach sein. Prüfbar: Ein neuer Monteur erfasst seinen ersten Rapport in unter drei Minuten, ohne Schulung.
• Die App soll mit Bexio verbunden sein. Prüfbar: Alle freigegebenen Rechnungen kommen ohne Abtippen in Bexio an, geprüft mit 20 Testaufträgen bei der Abnahme.

Die Grenzwerte müssen nicht perfekt sein. Wichtig ist, dass es einen gibt. Wenn eine Agentur einen Wert für unrealistisch hält, sagt sie es Ihnen in ihren Rückfragen, und Sie können ihn gemeinsam anpassen. Das ist besser, als bei der Abnahme festzustellen, dass beide Seiten etwas anderes gemeint haben.

Was nicht ins Lastenheft gehört

Ein Lastenheft wird nicht besser, je mehr darin steht. Drei Dinge machen es sogar schlechter:

• Eine Technologie ohne Grund vorschreiben. «Muss mit React gebaut werden» ist eine Entscheidung über das Wie. Wenn es einen echten Grund gibt, etwa weil Ihr eigenes Team den Code später mit genau dieser Technologie pflegt, schreiben Sie den Grund dazu. Sonst überlassen Sie die Wahl dem Team, das dafür die Verantwortung trägt.
• Bildschirmentwürfe als Anforderungen. Skizzen helfen beim Erklären, aber sie sind keine Anforderung. Ein Entwurf legt fest, wie etwas aussieht, nicht was es leisten muss. Beschreiben Sie den Zweck und legen Sie die Skizze als Anregung bei.
• Die Funktionsliste der Konkurrenz. Ein Konkurrent hat seine Funktionen für seine Kundschaft und seine Abläufe gebaut. Wer sie kopiert, bezahlt für Funktionen, die niemand nutzt, und vergisst die eigenen Abläufe.

Was nach dem Versand passiert

Wenn Sie uns Ihr Lastenheft schicken, lesen wir es und melden uns mit Rückfragen. Fast jedes Lastenheft lässt etwas offen, und das ist normal: Die Rückfragen zeigen, wo Annahmen stecken. Danach erhalten Sie eine Offerte mit Umfang, Preis und Zeitplan, die sich auf Ihre acht Teile bezieht. Das ist im Kern das Pflichtenheft aus dem ersten Abschnitt.

Nach der Zusage folgen Design, Umsetzung, Abnahme und Übergabe. Die Abnahme prüft genau das, was Sie in Teil 7 Ihres Lastenhefts beschrieben haben. Wie lange die Umsetzung dauert, hängt vom Umfang ab. Unser Kostenratgeber nennt die Zeitangaben, mit denen wir arbeiten: eine Unternehmenswebsite in 1–2 Wochen, eine Webanwendung ab 2 Monaten, die erste Version einer mobilen App in 1–2 Monaten. Dort finden Sie auch die Preisspannen dazu. Ein Projekt wie das Beispiel, mit Büro, Monteuren und einer Anbindung an Bexio, ist eine Webanwendung. Mehr darüber, wie wir solche Anwendungen bauen, steht auf unserer Seite zu Webanwendungen.

Lastenheft in agilen Projekten

Oft heisst es, agile Projekte bräuchten kein Lastenheft, weil sich die Anforderungen ohnehin ändern. Das stimmt nur zur Hälfte. Die Details ändern sich, das Ziel nicht. Auch ein agiles Team muss wissen, wozu es baut, für wen, innerhalb welcher Grenzen und wie das Ergebnis abgenommen wird.

In einem agilen Projekt legt das Lastenheft deshalb das Ziel, die Grenzen, die Prioritäten und die Art der Abnahme fest. Die einzelnen Funktionen werden nicht bis ins letzte Detail beschrieben. Sie wandern als Einträge in ein Backlog, eine geordnete Liste, die das Team Schritt für Schritt abarbeitet und die Sie laufend neu priorisieren können. Die Priorisierung aus Teil 4 ist dafür der Ausgangspunkt. Im Beispiel bleibt das Ziel fest: Kein Rapport wird mehr abgetippt. Ob die SMS vor dem Einsatz in die erste Version kommt oder in die zweite, kann sich unterwegs ändern.

Häufige Fehler

Diese Fehler sehen wir in Lastenheften am häufigsten:

• Kein Ziel, nur Funktionen. Ohne Ziel kann niemand entscheiden, welche Funktion wichtiger ist.
• Alles ist Muss. Wenn jede Funktion Priorität hat, hat keine Priorität. Die erste Version wird zu gross und zu teuer.
• Vage Qualitätsanforderungen. «Schnell», «sicher» und «benutzerfreundlich» ohne Grenzwert lassen sich nicht abnehmen.
• Bestehende Systeme vergessen. Eine Anbindung an Buchhaltung, CRM oder Lager, die erst während der Umsetzung auftaucht, verschiebt Budget und Termine.
• Kein Budgetrahmen. Ohne Rahmen offerieren drei Agenturen drei verschiedene Projekte.
• Die Abnahme fehlt. Wer nicht festlegt, wie geprüft wird, diskutiert am Ende darüber.
• Rechte am Code nicht geklärt. Wem der Code gehört, sollte vor dem Start feststehen, nicht beim ersten Wechsel des Anbieters.

Die kostenlose Vorlage

Unsere Vorlage enthält die acht Teile aus diesem Ratgeber, jeweils mit einer kurzen Erklärung und Platz für Ihre Antworten. Sie ist eine Word-Datei, die Sie frei bearbeiten und weitergeben können. Wir verlangen keine E-Mail-Adresse.

• Lastenheft-Vorlage auf Deutsch
• Vorlage auf Englisch
• Vorlage auf Albanisch

Füllen Sie zuerst Ziel, Nutzer und Abläufe aus. Daraus ergeben sich die Funktionen fast von selbst. Lassen Sie leer, was Sie nicht wissen, und schreiben Sie dazu, dass es offen ist. Eine ehrliche Lücke ist besser als eine geratene Antwort.

Häufige Fragen

Was heisst Lastenheft auf Englisch?

Auf Englisch heisst das Dokument des Auftraggebers meist project brief oder requirements document, in Produktteams auch PRD (product requirements document). Das Gegenstück zum Pflichtenheft ist die specification, in der Softwareentwicklung oft die software requirements specification (SRS) nach ISO/IEC/IEEE 29148. Eine wörtliche Übersetzung gibt es nicht, deshalb hilft es, bei englischsprachigen Partnern kurz zu sagen, wer das Dokument geschrieben hat.

Lastenheft oder Pflichtenheft: Was brauche ich?

Als Auftraggeber brauchen Sie ein Lastenheft. Das Pflichtenheft schreibt die Agentur als Antwort darauf, meist als Teil der Offerte oder nach der Zusage. In der Schweiz heisst auch das Dokument des Auftraggebers oft Pflichtenheft. Dann ist damit trotzdem Ihr Dokument gemeint, also das, was dieser Ratgeber beschreibt.

Wie detailliert muss ein Lastenheft sein?

So detailliert, dass eine Agentur ohne zu raten offerieren kann, und nicht mehr. Für eine Webanwendung wie im Beispiel reichen oft wenige Seiten. Wichtiger als die Länge ist, dass alle acht Teile vorkommen und jede Qualitätsanforderung einen Grenzwert hat. Details, die sich erst beim Bauen klären lassen, gehören ins Backlog.

Brauche ich für eine kleine Website ein Lastenheft?

Ein ausführliches Dokument brauchen Sie nicht, die Fragen dahinter schon. Auch für eine kleine Website sollten Sie wissen, wozu sie dient, wer sie besucht, welche Seiten und Sprachen sie braucht, wer die Inhalte liefert und welchen Rahmen das Budget hat. Eine Seite mit den acht Überschriften der Vorlage genügt oft.

Schicken Sie uns Ihr Lastenheft

Wenn Ihr Lastenheft steht, auch wenn noch Lücken darin sind, schicken Sie es uns über die Kontaktseite. Wir lesen es, melden uns mit unseren Rückfragen und erstellen danach eine Offerte. Wenn Sie wissen möchten, worauf Sie bei der Wahl eines Teams achten sollten, hilft unser Ratgeber zur Zusammenarbeit mit einem Softwareunternehmen in Kosovo.

Quellen

• Wikipedia, Lastenheft, mit der Definition nach DIN 69901-5 und dem Verweis auf VDI 2519
• HERMES, die Projektmanagementmethode des Bundes
• web.dev, Largest Contentful Paint: ein guter Wert liegt bei 2,5 Sekunden oder weniger
• ISO/IEC/IEEE 29148, Anforderungen an Systeme und Software