Lastenheft für Software: Vorlage und Anleitung für KMU

Lastenheft und Pflichtenheft: Was ist der Unterschied?

In kleineren Projekten verschmelzen beide oft: Das Lastenheft wird in einem gemeinsamen Termin ergänzt, und das Angebot beschreibt die Umsetzung. Das ist in Ordnung, solange am Ende schriftlich feststeht, was geliefert wird.

Warum lohnt sich die Arbeit?

• Vergleichbare Angebote: Wenn alle Anbieter dasselbe Dokument bekommen, vergleichen Sie Preise für dieselbe Leistung.
• Bessere Festpreise: Je klarer der Umfang, desto weniger Sicherheitsaufschlag braucht ein Anbieter.
• Weniger Missverständnisse: Begriffe, die in Ihrem Betrieb selbstverständlich sind, sind es für Außenstehende nicht.
• Grundlage für die Abnahme: Was im Lastenheft als Muss steht, wird am Ende geprüft.
• Hilfe bei Förderanträgen: Förderstellen verlangen meist eine nachvollziehbare Projektbeschreibung. Für Wien beschreibt das der Ratgeber zur Förderung von Digitalisierung in Wien.

Die Vorlage: vollständige Gliederung zum Übernehmen

Die folgenden 14 Abschnitte decken ein typisches Projekt im KMU ab, von der internen Anwendung bis zum Kundenportal. Streichen Sie, was nicht passt, aber lassen Sie die Abschnitte 1, 4, 5 und 12 nie weg. Ein Satz zu jedem Punkt ist besser als ein leerer Abschnitt.

1. Ausgangslage und Ziel

• Ihr Unternehmen in zwei Sätzen: Branche, Größe, Standorte.
• Was heute nicht gut läuft, möglichst mit Zahlen: Stunden pro Woche, Fehler pro Monat, Durchlaufzeiten.
• Was nach der Einführung anders sein soll, in ein bis drei überprüfbaren Zielen.
• Was ausdrücklich nicht Ziel des Projekts ist.

2. Ablauf heute

• Der wichtigste Ablauf Schritt für Schritt, vom Auslöser bis zum Ergebnis.
• Welche Programme, Tabellen und Papierformulare beteiligt sind.
• Wo Daten doppelt erfasst oder von Hand übertragen werden.

3. Beteiligte und Rollen

• Wer mit der Software arbeitet: Büro, Außendienst, Lager, Geschäftsführung, Kunden, Lieferanten.
• Wie viele Personen je Rolle, heute und in drei Jahren.
• Wer was sehen, ändern und freigeben darf.

4. Anwendungsfälle

Beschreiben Sie fünf bis fünfzehn typische Situationen im Format „Als [Rolle] möchte ich [Tätigkeit], damit [Nutzen].“ Ein Beispiel: „Als Monteur möchte ich das Arbeitsprotokoll beim Kunden am Handy ausfüllen, damit das Büro am selben Tag die Rechnung schreiben kann.“ Ergänzen Sie zu jedem Fall, was bei Sonderfällen passieren soll, etwa bei Storno, Teillieferung oder Vertretung im Urlaub.

5. Anforderungen mit Priorität

• Jede Anforderung bekommt eine Nummer, damit Angebot und Abnahme darauf verweisen können.
• Priorität: Muss (ohne geht es nicht), Soll (wichtig, aber verschiebbar), Kann (wenn Budget bleibt).
• Zu jeder Anforderung ein Satz, wozu sie gebraucht wird.

6. Daten und Mengen

• Welche Daten verwaltet werden: Kunden, Artikel, Aufträge, Dokumente, Fotos.
• Mengen heute und erwartetes Wachstum, etwa Aufträge pro Monat oder Artikel im Sortiment.
• Welche Altdaten übernommen werden müssen, aus welchem System und in welcher Qualität.

7. Schnittstellen

• Mit welchen Systemen Daten ausgetauscht werden: Buchhaltung, Warenwirtschaft, Webshop, Bank, Kalender, E-Mail.
• In welche Richtung und wie oft: einmal täglich, sofort, auf Knopfdruck.
• Ob der Anbieter des anderen Systems eine dokumentierte Schnittstelle anbietet. Mehr dazu im Ratgeber zur Anbindung der Buchhaltung per Schnittstelle.

8. Anforderungen an Bedienung und Betrieb

• Geräte: Büro-PC, Tablet, Handy, Terminal.
• Arbeiten ohne Netz, etwa im Keller oder auf der Baustelle.
• Sprachen der Oberfläche.
• Barrierefreiheit, besonders wenn Verbraucher die Anwendung nutzen.
• Erreichbarkeit: Welcher Ausfall ist vertretbar, und wer muss dann informiert werden?

9. Datenschutz und Sicherheit

• Welche personenbezogenen Daten verarbeitet werden, und ob besonders schützenswerte darunter sind, etwa Gesundheitsdaten.
• Wo die Daten liegen sollen, zum Beispiel bei einem Hoster in der EU.
• Anmeldung, etwa mit Bestätigung über einen zweiten Faktor, Protokoll von Änderungen und Datensicherung.

10. Rechtliche und branchenspezifische Vorgaben

• Vorgaben, die Sie kennen, ohne sie juristisch auszuformulieren: etwa Registrierkassenpflicht bei Barumsätzen, Aufbewahrung von Belegen oder Pflichten im Onlinehandel.
• Wer diese Vorgaben fachlich beurteilt, etwa Ihre Steuerberatung oder Rechtsberatung.
• Für Kassenfragen bietet der Ratgeber zur Registrierkassenpflicht und Software einen Einstieg.

11. Rahmenbedingungen

• Budgetrahmen, auch wenn er nur grob ist. Ohne Rahmen bekommen Sie Angebote für sehr unterschiedliche Lösungen.
• Wunschtermin und feste Termine, etwa Saisonbeginn oder Jahreswechsel.
• Wer im Betrieb Ansprechperson ist und wie viel Zeit sie pro Woche für das Projekt hat.
• Wer die Software danach betreibt: Dienstleister, eigene IT oder ein Hoster.

12. Abnahmekriterien

• Woran Sie erkennen, dass eine Anforderung erfüllt ist, am besten mit einem Testfall aus dem Alltag.
• Wer abnimmt und in welchem Zeitraum.
• Was als Fehler gilt, der die Abnahme verhindert, und was als Nachbesserung danach erledigt werden kann.

13. Rechte, Übergabe und Wartung

• Welche Nutzungsrechte Sie am Code erwarten und ob Quellcode und Zugänge übergeben werden. Die Hintergründe erklärt der Beitrag Wem gehört der Code?.
• Dokumentation und Einschulung.
• Wartung, Updates und Änderungen nach dem Start.

14. Offene Fragen und Begriffe

• Was Sie noch nicht wissen und mit dem Anbieter klären möchten.
• Ein kurzes Glossar mit Begriffen aus Ihrem Betrieb, etwa was bei Ihnen ein „Auftrag“, eine „Baustelle“ oder ein „Kunde“ genau ist.

Wie klingt eine gute Anforderung?

Welche Fehler passieren am häufigsten?

• Lösungen statt Probleme beschreiben: „Wir brauchen eine App“ statt „Unsere Monteure tippen abends Protokolle ab“.
• Alles ist Muss. Wenn jede Anforderung gleich wichtig ist, hilft die Liste bei keiner Entscheidung.
• Sonderfälle vergessen: Storno, Teillieferung, Gutschrift, Vertretung. Gerade sie machen einen großen Teil des Aufwands aus.
• Den Prospekt eines Produkts abschreiben. Damit bekommen Sie Angebote für dieses Produkt, nicht für Ihren Bedarf.
• Kein Budgetrahmen. Für dieselbe Beschreibung kann ein Anbieter eine schlanke Lösung oder einen Ausbau mit allen Extras anbieten.

Wie lang muss ein Lastenheft sein?

So lang, dass ein Außenstehender Ihren wichtigsten Ablauf versteht, und so kurz, dass Sie es in zwei oder drei Arbeitssitzungen schreiben können. Für ein erstes Angebot reichen oft die Abschnitte 1 bis 5 und 11; den Rest kann man gemeinsam ergänzen. Wenn Sie zuerst klären wollen, ob eine kleine erste Ausbaustufe genügt, hilft der Ratgeber zur MVP-Entwicklung.

Was mit Ihrem Lastenheft bei uns passiert

Wenn Sie uns ein Lastenheft schicken, antworten wir schriftlich mit Rückfragen und einer Ersteinschätzung: ob ein bestehendes Produkt passt, ob eine Web-App oder Individualsoftware sinnvoll ist und in welchem Kostenrahmen. Danach folgt das Angebot. Die Umsetzung läuft in vier Phasen: Prozessanalyse, Konzept und Datenmodell, Entwicklung mit regelmäßigen Demos, dann Migration und Start mit Einschulung. Wie das im Detail aussieht, zeigen die Seite Projektablauf und der Ratgeber Softwareprojekt verständlich erklärt.

Sie haben noch kein Lastenheft, aber eine Excel-Tabelle, die nicht mehr reicht? Dann ist der Beitrag Excel ablösen ein guter Startpunkt. Für Portale, in denen Geschäftskunden bestellen, beschreibt der Beitrag zum B2B-Bestellportal typische Anforderungen.

Nächster Schritt: Kostenrahmen vor dem Schreiben klären

Ein Budgetrahmen macht jedes Lastenheft besser. Der Projektkosten-Rechner gibt einen ersten Rahmen auf Basis unserer Richtpreise, der Software-Kostenvergleich zeigt, ob Miete oder Eigenentwicklung über mehrere Jahre günstiger ist. Danach schicken Sie Ihr Lastenheft, gern auch als Entwurf, über das Anfrageformular.