Lastenheft für individuelle Software im KMU erstellen: was wirklich rein muss

Du willst eine eigene Anwendung bauen lassen, weil Excel-Listen und E-Mail-Ketten jeden Tag Zeit fressen. Dazu Nachfragen von Kunden. Der Anbieter fragt nach einem Lastenheft, du sitzt vor einer leeren Seite. Ein Lastenheft für individuelle Software hält Ziele und Umfang so fest, dass alle verstehen, was gebaut werden soll, ohne dass die Lösung vorweggenommen wird, und genau das schafft den Rahmen für belastbare Angebote. In Projekten sehen wir, dass saubere Ziele, ein klarer Scope, beschriebene Abläufe, verständliche Anforderungen, erwartete Schnittstellen sowie nachvollziehbare Abnahmekriterien Aufwand und Risiko greifbar machen und Missverständnisse aus dem Weg räumen. Ich würde hier zuerst Klarheit schaffen, dann über Technik sprechen.

Lastenheft individuelle Software: Zweck und Abgrenzung zum Pflichtenheft

Das Lastenheft beschreibt dein Vorhaben aus fachlicher Sicht. Es hält fest, warum du etwas ändern willst, welchen Nutzen du erwartest und welche Prozesse betroffen sind. Außerdem stehen dort die Daten und Rollen, die beteiligt sind, und die Kriterien, mit denen du am Ende prüfst, ob es passt. Du steckst damit die Spielregeln ab, nicht die Spielzüge. Keine Klickpfade, keine UI-Layouts, keine Vorgaben zur Datenbank oder zum Framework.

Der oft gesuchte Pflichtenheft Unterschied ist in der Praxis simpel und hilft bei der Rollenklärung. Der Auftraggeber beschreibt das Was, der Anbieter das Wie. Das Lastenheft kommt von dir, das Pflichtenheft schreibt der Anbieter. Dort steht, wie er dein Ziel umsetzt, welche Komponenten er wählt, wie Schnittstellen technisch aussehen und wie er testet sowie ausrollt. Dein Job ist Bedarf und Grenzen zu definieren, Akzeptanzkriterien ebenso. Sein Job ist die Planung der Lösung auf dieser Basis. Bei uns hat es sich bewährt, Lastenheft und Pflichtenheft wie zwei Seiten einer Medaille zu behandeln, aber nacheinander zu schreiben, denn erst der Bedarf führt zur passenden Lösung.

Ziele und Scope festlegen, Nicht-Ziele klarziehen

Bevor Funktionen notiert werden, braucht es ein Zielbild. Was soll im Tagesgeschäft bald anders aussehen. Beispiel aus dem Büroalltag: Heute kommen Aufträge per E-Mail, eine Kollegin überträgt sie in Excel, zwei weitere fragen fehlende Daten beim Kunden nach, Rechnungen werden manuell erstellt, Status und Rückfragen hängen in einzelnen Postfächern. Zielbild: Eingänge landen strukturiert, fehlende Angaben werden früh sichtbar, alle sehen den gleichen Status, Rechnungen entstehen ohne Abschreiben, Kunden erhalten verlässliche Rückmeldungen.

Jetzt den Scope festlegen. Was gehört hinein, was bleibt bewusst draußen. Ein häufiger Fehler in Angeboten, die später kippen: zu breit schneiden und alles von CRM bis Buchhaltung gleichzeitig anfassen. Besser eng schneiden. Starte mit dem Auftragsfluss von Anfrage bis Rechnung. Lass Marketing-Features und komplexe Auswertungen außen vor. Eine ERP-Ablösung ebenso. Nicht-Ziele sind Gold wert, wenn der Tag stressig ist und Wünsche reinrutschen, die du heute nicht tragen willst. Schreib sie explizit auf, das schützt vor schleichender Ausweitung und zwingt zu Prioritäten, die du auch intern vertreten kannst.

Wenn du dich noch fragst, ob sich eine Eigenentwicklung für dein Vorhaben überhaupt lohnt, zeigt der Beitrag Auftragssoftware im Handwerk vom Excel zur eigenen Anwendung, wie so eine Abwägung in der Praxis aussieht.

Prozesse beschreiben, wo heute Reibung entsteht

Ein gutes Lastenheft erzählt den Alltag so, dass ein Dritter ihn versteht. Nicht seitenlang, aber konkret. Nimm die Kernprozesse, in denen Reibung steckt: Auftragsverwaltung, Angebote, Rechnungen, Rückfragen von Kunden. Beschreibe, wer wann was tut, welche Informationen gebraucht werden, wo entschieden wird und wo Medienbrüche auftreten. Szene statt Schlagwort, sonst bleiben Auslegungsräume, die später teuer werden. Beispiel: Die Sachbearbeitung prüft eingehende E-Mails auf Pflichtangaben, kopiert Kundendaten aus einer alten Excel-Liste, ruft beim Vertrieb nach, wenn der Rabatt fehlt, und legt die Auftragsnummer nach der Freigabe manuell an.

Schreibe die Schritte fachlich, nicht technisch. Statuswechsel helfen beim Verständnis: Anfrage eingegangen, Daten geprüft, Freigabe intern, Angebot versendet, Auftrag erfasst, Lieferung geplant, Rechnung gestellt, Zahlung eingegangen. Dazu die Übergaben: Wer übergibt was an wen, in welchem Format, mit welchem Auslöser. Excel-Anhänge und PDFs. Auch Telefonnotizen. Entscheidungen sind zentral, weil sie oft zu Wartezeiten führen und dann Flaschenhälse bilden. Wer darf Rabatte freigeben, ab wann ist eine Position lieferbar, wann geht eine Rückfrage an den Kunden.

Bei uns hat sich gezeigt, dass drei bis fünf Kerndurchläufe reichen, um das Bild scharf zu stellen. Tiefer gehen wir erst in der Umsetzung, wenn offene Stellen sichtbar werden. Worauf ich achte, wenn wir Prozesse beschreiben: Engpässe benennen, nicht verschönern. Wo wartet jemand auf Rückmeldung. Wo werden Daten doppelt erfasst. Wo entstehen Missverständnisse. Und was passiert in Ausnahmen, wenn eine Bestellung unvollständig ist oder ein Kunde storniert.

Anforderungen formulieren, ohne die Lösung zu diktieren

Anforderungen präzisieren den Bedarf, ohne die Umsetzung zu diktieren. Nimm die Perspektive der Akteure aus dem Prozess und beschreibe kurze Use-Cases, die ein Ereignis auslösen und zu einem überprüfbaren Ergebnis führen. Wer stößt was an und warum. Welches Ergebnis folgt, das für den Alltag zählt. Beispiel: Die Sachbearbeiterin erfasst eine neue Kundenanfrage, das System prüft Pflichtangaben und weist auf fehlende Felder hin, anschließend erzeugt es eine Vorgangsnummer und legt den Status auf Datenprüfung.

Viele Anforderungen lassen sich als Regeln ausdrücken, und Regeln sind für Angebote greifbar. Wenn ein Rabatt über einem Schwellenwert liegt, braucht es eine interne Freigabe. Wenn eine E-Mail-Anfrage ohne Kundennummer eintrifft, bietet das System die Suche in bestehenden Kundendaten an. Wenn ein Auftrag storniert wird, darf die Rechnung nicht erstellt werden oder muss storniert werden. Prioritäten helfen bei der Planung und lassen sich mit dem Nutzen verbinden. Muss- und Soll-Kriterien. Kann später. In Projekten sehen wir, dass Klarheit über Muss-Kriterien Versprechen im Angebot belastbar macht, weil Test und Abnahme daran hängen.

Denke an Datenqualität. Welche Felder sind Pflicht und warum. Welche Formate sind erlaubt. Welche Duplikate müssen verhindert werden. Formuliere auch, welche Informationen berechnet oder abgeleitet werden. Positionssummen und Fälligkeiten. Oder ein plausibler Liefertermin. Ein Satz zu Suche und Filter gehört dazu, wenn sie täglich gebraucht werden. Exporte. Einfaches Reporting. Du diktierst damit nicht die Oberfläche, sondern die Ergebnisse, die eine Person braucht, um ihre Aufgabe zu erledigen.

Schnittstellen, Daten und Berechtigungen ins Bild holen

Fast jedes KMU hat bestehende Systeme, die bleiben sollen. Buchhaltung, Warenwirtschaft, E-Mail, vielleicht ein Kundenportal. Beschreibe, welche Daten fließen müssen, in welcher Richtung und in welchem Ereignisfall. Stammdaten wie Kunden und Artikel. Bewegungsdaten wie Aufträge und Belege wie Angebote sowie Rechnungen. Reicht ein regelmäßiger Import einer CSV-Datei aus Excel. Oder soll eine automatisierte Übergabe stattfinden, sobald ein Status wechselt. Das sind keine technischen Details, sondern fachliche Erwartungen an Verfügbarkeit und Aktualität, die später das technische Design steuern.

Schreibe auch, was nicht integriert wird. Vielleicht bleibt die Buchhaltung in ihrer Software, erhält aber Belegdaten zum Buchen. Oder eine vorhandene Auftragsbearbeitung bleibt erhalten, und die neue Lösung ergänzt nur die Kommunikation mit Kunden. Das öffnet Alternativen zu großen Wechseln, die Kapazitäten binden.

Berechtigungen sind heikel, wenn sie fehlen, und umso unauffälliger, wenn sie von Beginn an gedacht werden. Wer darf was sehen und anlegen. Wer ändert oder gibt frei. Lesezugriff für den Vertrieb auf Rechnungen, Schreibrecht nur für die Buchhaltung. Kunden dürfen ihren eigenen Auftragsstatus sehen, interne Kommentare bleiben geschützt. Wenn besondere Datenkategorien im Spiel sind, notiere Anforderungen an Datenschutz und Aufbewahrung. Das spart später Diskussionen in der Abnahme und vermeidet Überraschungen im Rollout.

Abnahmekriterien, Qualität und Betrieb mitdenken

Schreibe auf, woran du die Abnahme festmachst. Nicht als Bauchgefühl, sondern als prüfbare Kriterien, die zu deinen Use-Cases passen und im Test reproduzierbar sind. Beispiel: Für den Use-Case Angebot erstellen gilt die Anforderung als erfüllt, wenn eine Sachbearbeiterin mit Testdaten ein Angebot mit Pflichtangaben erstellen, als PDF ausgeben und per E-Mail versenden kann, und der Vorgang den Status wechselt. Für Ausnahmen definierst du ebenfalls erwartete Ergebnisse, sonst fehlen dir im Test genau die Fälle, die im Alltag zuerst aufschlagen.

Nicht-funktionale Anforderungen gehören dazu, weil sie im Betrieb den Ton angeben. Performance im Alltag und Reaktionszeiten im Büro. Verhalten bei schwacher Internetverbindung. Verständlichkeit von Fehlermeldungen. Barrierefreiheit, sofern nötig. Protokollierung von Änderungen, wenn Nachvollziehbarkeit zählt. Schreib, was für dich ausreichend ist, und wende dieselbe Sprache an, die du im Team nutzt. Sicherheitsanforderungen wie Passwortrichtlinien sind ebenfalls Teil des Spiels, Protokollierung von Logins ebenso.

Denke an Betrieb und Wartung. Wer betreibt die Anwendung und wie werden Updates eingespielt. Wer reagiert bei Störungen, welche Wege sind vorgesehen. Backups im Alltag. In Projekten erleben wir, dass diese Fragen früh beantwortet viel Stress am Ende verhindern, weil niemand dann mehr Zeit für Grundsatzdebatten hat. Wenn du tiefer einsteigen willst, hilft dir unser Überblick zu Aufwand und Aufgaben: Wartung und Betrieb von Individualsoftware Kosten und Aufgaben im KMU

Beispiel Lastenheft: schlanke Gliederung für KMU

Wenn du loslegen willst, hilft eine kurze, praxistaugliche Struktur. So bleibt dein Dokument lesbar und nützlich, auch wenn mehrere Personen mitarbeiten. Wir nutzen dafür eine klare Reihenfolge von Fachlichkeit zu Betrieb, kurz und präzise, mit Beispielen aus deinem Alltag.

• Ausgangslage und Problem beschreiben, mit einer kurzen Szene aus dem Tagesgeschäft.

• Ziele und Nutzen formulieren, also was nach der Einführung anders ist.

• Scope und Nicht-Ziele festhalten, damit drin bleibt, was tragen soll, und draußen, was stört.

• Betroffene Prozesse skizzieren, mit Rollen, Status sowie typischen Medienbrüchen.

• Begriffe klären, zentrale Datenobjekte in Worten benennen, inklusive relevanter Felder.

• Use-Cases auflisten, je Akteur mit Auslöser, erwarteten Ergebnissen und einer Priorität.

• Fachliche Regeln und Validierungen sammeln, inklusive der Ausnahmen, die häufig auftreten.

• Schnittstellen und Datenflüsse benennen, Import und Export aus heutiger Sicht einordnen.

• Rollen und Berechtigungen festlegen, wer was sehen darf und was er tun kann.

• Qualitätsanforderungen sammeln, Performance nennen, Sicherheit und Protokollierung ergänzen.

• Abnahmekriterien pro Use-Case definieren, wie du prüfst und was zählt.

• Betrieb und Wartung beschreiben, Zuständigkeiten und Erwartungen festhalten.

• Risiken und Annahmen dokumentieren, was unklar ist oder später entschieden wird.

• Roadmap grob skizzieren, mögliche Phasen und spätere Erweiterungen andeuten.

• Offene Fragen sammeln, die du mit Anbietern klären willst.

Wenn du willst, geben wir dir ein ehrliches Feedback auf dein Lastenheft oder deine Skizze. Ob sich Entwicklung lohnt und wie du den Scope schneidest, klären wir im kurzen Erstgespräch: Individuelle Softwareentwicklung