Was gehört in ein Lastenheft?

Was hineingehört

Ausgangslage

Wie läuft es heute? Welche Systeme, welche Tabellen, welche Zettel?

Ziel

Was soll danach anders sein – möglichst messbar. „Weniger Aufwand" ist kein Ziel. „Angebotserstellung von 40 auf 10 Minuten" ist eines.

Abläufe mit Sonderfällen

Der Normalfall ist schnell beschrieben. Die Kosten stecken in den Ausnahmen: Was passiert bei einer Stornierung? Bei einem Teillieferung? Bei einem Kunden ohne Steuernummer? Diese Fragen früh zu beantworten ist der grösste Hebel für eine belastbare Schätzung.

Betroffene Systeme

Welche Systeme müssen angebunden werden, wer betreibt sie, gibt es eine dokumentierte Schnittstelle?

Mengengerüst

Wie viele Datensätze, wie viele Nutzerinnen und Nutzer, wie viele Vorgänge am Tag? Das entscheidet über die Architektur.

Rahmenbedingungen

Termine, Budget, rechtliche Vorgaben, wo die Daten liegen dürfen.

Was nicht hineingehört

Technische Vorgaben ohne Grund. „Muss in PHP entwickelt werden" ist nur sinnvoll, wenn Sie es selbst weiterentwickeln wollen. Sonst schränkt es ein, ohne zu nützen.

Lösungsbeschreibungen statt Anforderungen. „Es braucht einen Knopf, der X macht" verrät nicht, welches Problem X löst – und verhindert, dass jemand eine bessere Lösung vorschlägt.

Wenn Sie kein Lastenheft schreiben können

Das ist kein Hindernis. Häufig ist es sinnvoller, gemeinsam eine Anforderungsanalyse durchzuführen – ein bis zwei Termine, in denen der Ablauf aufgenommen und geordnet wird. Das Ergebnis ist besser als ein Dokument, das zwischen Tür und Angel entstanden ist.