Das Lastenheft ist eine formlose Anforderungsspezifikation, d. h. es ist eine Präzisierung und Ergänzung des Projektauftrages. Es wird vor dem eigentlichen Projektauftrag oder in einer frühen Phase des Projektes erstellt.

Wie bereits erwähnt ist das Lastenheft formlos. Für jedes Projekt kann es individuell gestaltet werden. Es ist aber trotzdem wichtig das der Inhalt möglichst prezise ohne Spielraum für Interpretationen formuliert wird, denn es bildet die Grundlage für das Pflichtenheft, welches Rechtlich bindend ist.

Das Lastenheft wird vom Auftraggeber geschrieben und and den Auftragnehmer versendet. Dabei kann es sich sogar um mehrere verschieden Auftragnehemer handeln wodurch sich Aufwand sparen lässt.

Auch wenn jedes Lastenheft noch so unterschiedlich ist gibt es einige grobe wiederkehrende Punkte, die bei jedem Lastenheft vorhanden sein sollten.

Der wichtigste Zweck des Lastenheftes ist das Problem des Auftraggebers möglichst exakt zu beschreiben. Wichtig ist noch, wie in das Problem in der Vergangenheit behandelt wurde und wie dringend der Handlungsbedarf zur Lösung des Problems ist.

Wenn der Kunde bereits eine existierende IT-Infrastruktur hat, möchte er meist das neue System mit den alten Integrieren. Dabei kann es sich um SQL-Datenbanken (MySQL, PostgreSQL, Oracle DB) oder Unterstützung von älteren Datenformaten (MS Word dokumente) handeln. Auch grundlegende Dinge wie die unterstützten Betriebssysteme sind wichtig zu erfassen.
Protokolle zählen auch dazu.

Es geht auch umgekehrt. Soll das neue System beispielsweise eine REST Schnittstelle haben?

Sobald das Problem verständlich erklärt wurde kommt es anschließend zu der Zielsetzung. Hier geht es darum unter welchen Bedingungen das Projekt abgeschlossen ist.

Die Ziele sollen den SMART-Kriterien unterliegen.
Spezifisch: Die Ziele müssen eindeutig und präzise sein.
Messbar: Der Fortschritt der Ziele muss messbar sein.
Akzeptiert: Die Ziele müssen an die Empfänger übermittelt und akzeptiert werden.
Realistisch: Die Ziele müssen erreichbar sein.
Terminiert: Es gibt einen klaren Termin, wann das Problem spätestens erreicht werden soll.

Meist eine einfache Liste von gewünschten und erforderlichen Funktionen, die das Produkt können soll und dementsprechend priorisieren.

Beispielsweise

Es ist sinnvoll zu erfassen, welche Funktionen nicht erwünscht sind, um Zeit und Geld zu sparen.

Kunden wünschen sich zusätzlich zu den Funktionen aber auch andere technische Anforderungen, die sich positiv auf die Endnutzer der Software auswirken.

Erweiterbarkeit
Hohe "Uptime"
Zuverlässigkeit
Toleranzen
Bedienbarkeit

Hiermit schließe ich die Präsentation ab.