Wer schreibt was
Das Lastenheft kommt von dir als Auftraggeber. Es hält fest, was du brauchst: das Problem, das gelöst werden soll, die Rahmenbedingungen, unter denen die Software laufen muss, und die Anforderungen, die dir wichtig sind. Das Pflichtenheft kommt vom Auftragnehmer, also von der Agentur oder dem Entwicklungsteam. Es beschreibt, wie diese Anforderungen technisch umgesetzt werden. Das Lastenheft stellt die Aufgabe, das Pflichtenheft beantwortet sie.
Lastenheft: die Anforderungen aus deiner Sicht
Ein gutes Lastenheft beschreibt den Ist-Zustand, das gewünschte Ergebnis und die Grenzen, innerhalb derer sich die Lösung bewegen muss, etwa vorhandene Systeme, mit denen die neue Software sprechen muss, oder gesetzliche Vorgaben, die einzuhalten sind. Es muss nicht technisch sein. Ein Lastenheft, das schon Architekturentscheidungen trifft, ist eigentlich kein Lastenheft mehr, sondern greift dem Anbieter vor, der genau diese Entscheidungen fachlich einordnen soll.
Pflichtenheft: die Umsetzung aus Sicht des Anbieters
Das Pflichtenheft übersetzt das Lastenheft in eine technische Lösung: welche Architektur, welche Schnittstellen, welcher Funktionsumfang, welche Meilensteine. Weil es beschreibt, was konkret geliefert wird, wird es in vielen Projekten Teil des Vertrags. Das bedeutet, dass sich der Anbieter daran messen lassen muss. Wenn am Ende etwas fehlt, das im Pflichtenheft stand, ist das ein Mangel. Wenn etwas fehlt, das nur im Lastenheft stand, aber im Pflichtenheft nicht sauber übersetzt wurde, wird es unangenehm, weil dann strittig ist, wessen Fehler das war.
Warum das Pflichtenheft bei der Abnahme zählt
Die Abnahme prüft, ob geliefert wurde, was vereinbart war. Ohne ein Pflichtenheft, das diese Vereinbarung konkret macht, gibt es keinen klaren Maßstab, an dem sich Auftraggeber und Auftragnehmer orientieren können. Deshalb lohnt es sich, vor Projektstart genau zu lesen, was im Pflichtenheft steht, und nachzufragen, wo es vage bleibt. Vage Formulierungen sind später fast immer zulasten des Auftraggebers ausgelegt, weil der Anbieter sie geschrieben hat.
Ein Pflichtenheft, das nur allgemeine Begriffe verwendet, etwa “modernes Dashboard” oder “performante Anbindung”, ohne zu sagen, was das konkret heißt, lässt sich später kaum als Maßstab nutzen. Frag im Zweifel nach Beispielen oder Skizzen, die zeigen, wie eine Anforderung tatsächlich verstanden wurde. Das kostet vor Projektstart etwas Zeit, spart aber genau die Diskussion, die sonst bei der Abnahme entsteht, wenn beide Seiten dieselbe Formulierung unterschiedlich gelesen haben.
Brauchst du ein fertiges Lastenheft, um ein Angebot zu bekommen?
Nein, in der Regel nicht. Für eine erste Einschätzung reicht eine klare Beschreibung deines Problems und der wichtigsten Rahmenbedingungen völlig aus. Ein Anbieter, der ein vollständiges, formales Lastenheft verlangt, bevor er überhaupt mit dir spricht, verschiebt damit einen Teil seines eigenen Risikos auf dich: die Aufgabe, die Anforderungen sauber zu strukturieren, wandert zu dir, obwohl genau das Teil der fachlichen Arbeit ist, die ein erfahrenes Team gemeinsam mit dir leisten sollte. Ein gutes Erstgespräch klärt die offenen Fragen, statt sie dir als Vorleistung aufzuerlegen.
Wie du eine Problembeschreibung stattdessen aufbaust
Statt eines formalen Lastenhefts reicht für den Einstieg eine kurze, ehrliche Beschreibung: was heute nicht funktioniert oder fehlt, welche Systeme bereits im Einsatz sind und mit denen die Lösung zusammenspielen muss, wer die Software später nutzt, und welche harten Grenzen es gibt, etwa beim Zeitrahmen oder bei rechtlichen Vorgaben. Das ist in der Regel eine Seite Text, keine zwanzig. Ein erfahrenes Team kann daraus eine erste Einschätzung ableiten und die fachlichen Lücken im Gespräch schließen, statt sie dir vorab als Hausaufgabe zu geben.
Was bei uns stattdessen der erste Schritt ist
Bei abi services startet ein Projekt mit einem Gespräch und, wenn es passt, mit einem kostenlosen Architektur-Review, nicht mit der Erwartung eines fertigen Lastenhefts.