====== Das Lastenheft ====== Das Lastenheft ist das zentrale Ausgangsdokument eines Projektauftrags. Darin hält der Auftraggeber fest, //was// erreicht werden soll und //wofür//. Wie das Ergebnis technisch umgesetzt wird, steht nicht im Lastenheft. Diese Frage beantwortet der Auftragnehmer später im Pflichtenheft. Im Modul [[teaching:ba:courses:projektmanagement|Projektmanagement]] stellen die Betreuenden der Projekte das Lastenheft bereit. Auf dieser Grundlage erstellen die Teams ihr [[pflichtenheft|Pflichtenheft]] und den Projektplan. ===== Definition ===== Die DIN 69901-5 definiert das Lastenheft als die > „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“ (DIN 69901-5:2009-01). Das Pflichtenheft umfasst dagegen die > „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes“ (DIN 69901-5:2009-01). Wie man beim Erstellen beider Dokumente vorgeht, beschreibt die Richtlinie VDI 2519 Blatt 1. ===== Lastenheft und Pflichtenheft im Vergleich ===== ^ Merkmal ^ Lastenheft ^ Pflichtenheft ^ | Verfasser | Auftraggeber | Auftragnehmer (hier: das Projektteam) | | Leitfrage | Was soll erreicht werden und wofür? | Wie und womit wird es umgesetzt? | | Inhalt | Ziele, Anforderungen, Randbedingungen, Abnahmeerwartung | Lösungskonzept, technische Spezifikation, Prüfkriterien | | Detailgrad | lösungsneutral, so konkret wie nötig | lösungsbezogen, so konkret wie möglich | | Zeitpunkt | vor Projektbeginn | nach Analyse des Lastenhefts, vor der Umsetzung | | Verbindlichkeit | Grundlage für Angebot bzw. Auftrag | Grundlage für Umsetzung und Abnahme | Beide Dokumente bauen aufeinander auf. Jede Position im Pflichtenheft muss sich auf mindestens eine Forderung im Lastenheft zurückführen lassen. Umgekehrt muss jede Forderung des Lastenhefts im Pflichtenheft beantwortet werden. ===== Wozu ein Lastenheft? ===== * Es schafft ein gemeinsames Verständnis von Ziel und Umfang des Projekts, bevor Aufwand entsteht. * Es dient als Vertragsgrundlage zwischen Auftraggeber und Auftragnehmer. * Es grenzt den Projektumfang ab: Was nicht im Lastenheft steht, ist zunächst nicht beauftragt. * Es bildet den Maßstab für die Abnahme am Projektende. * Es macht Änderungen nachvollziehbar, weil jede Änderung dokumentiert und versioniert wird. ===== Aufbau ===== Für Lastenhefte gibt es keine allgemein verbindliche Gliederung. Die Vorlage für das Modul Projektmanagement ist wie folgt aufgebaut: ^ Abschnitt ^ Inhalt ^ | Deckblatt | Projektname, Auftraggeber, Betreuung, Ausgabe und Änderungsstand | | Änderungsdokumentation | Datum, Beschreibung und Bearbeiter jeder Änderung | | 1 Zielsetzung | Ausgangssituation, Problemstellung, angestrebtes Ergebnis | | 2 Organisatorische Rahmenbedingungen | Termine, Gruppengröße, Arbeitsort, Hilfsmittel, Budget, Sicherheit, Ansprechpartner | | 3 Leistungsbeschreibung | Aufgaben und Arbeitsumfang, Anforderungen mit IDs, erwartete Ergebnisse und Abnahme | | 4 Voraussetzungen | hilfreiche Vorkenntnisse (optional) | | 5 Mitgeltende Unterlagen | Ordnungen, Datenblätter, Normen, die für das Projekt verbindlich sind | ===== Anforderungen formulieren ===== ==== Arten von Anforderungen ==== * //Funktionale Anforderungen// beschreiben, was das System tun soll, zum Beispiel: „Das System fährt definierte Positionen an.“ * //Nichtfunktionale Anforderungen// beschreiben, wie gut oder unter welchen Bedingungen es das tun soll, etwa Genauigkeit, Zuverlässigkeit, Sicherheit oder Ergonomie. * //Randbedingungen// sind Vorgaben, die den Lösungsraum einschränken, zum Beispiel vorhandene Bauteile, Budget, Termine oder geltende Normen. ==== Priorität ==== * //Muss//: Die Anforderung ist zwingend. Wird sie nicht erfüllt, ist der Auftrag nicht erfüllt. * //Kann//: Die Anforderung ist eine erwünschte Erweiterung. Sie wird umgesetzt, wenn die Muss-Anforderungen erfüllt sind und Ressourcen verbleiben. ==== Qualitätskriterien ==== Eine einzelne Anforderung sollte nach ISO/IEC/IEEE 29148:2018 unter anderem folgende Eigenschaften haben: * notwendig: Ohne sie fehlt dem Ergebnis eine benötigte Eigenschaft. * eindeutig: Sie lässt nur eine Interpretation zu. * vollständig: Sie ist ohne zusätzliche Erläuterung verständlich. * singulär: Sie beschreibt genau einen Sachverhalt. * umsetzbar: Sie ist mit den verfügbaren Mitteln realisierbar. * überprüfbar: Ihre Erfüllung lässt sich durch Test, Messung oder Inspektion nachweisen. ==== Beispiele ==== ^ Ungeeignet ^ Problem ^ Besser ^ | „Die Winde soll schnell und genau sein.“ | nicht prüfbar, zwei Sachverhalte | „Verfahrgeschwindigkeit und Positioniergenauigkeit werden vor Konstruktionsbeginn quantitativ festgelegt.“ (Randbedingung) | | „Der Wagen soll praktisch sein.“ | subjektiv, nicht prüfbar | „Komponenten und Werkzeuge sind ohne Umräumen zugänglich.“ | | „Ein ESP32 steuert einen Schrittmotor an.“ | nimmt die Lösung vorweg; gehört ins Pflichtenheft | „Die aktuelle Position der Last wird erfasst.“ | ===== IDs und Rückverfolgbarkeit ===== Jede wesentliche Anforderung und Randbedingung erhält eine eindeutige ID, z. B. ''LH-001'', ''LH-002'' usw. Diese ID bleibt während des gesamten Projekts unverändert. Wird eine Anforderung gestrichen, wird ihre ID nicht neu vergeben. Im Pflichtenheft verweisen die Positionen auf diese IDs. So entsteht eine eindeutige Verknüpfung zwischen Forderung (Lastenheft) und Umsetzung (Pflichtenheft). Bei der Abnahme lässt sich für jede ID zeigen, ob und wie sie erfüllt wurde. Zusätzlich können zwei weitere Kennungen verwendet werden: * ''OP-001'', ''OP-002'' usw. kennzeichnen //offene Punkte//, die noch geklärt werden müssen. * ''AN-001'', ''AN-002'' usw. kennzeichnen //Annahmen//. Eine Annahme ist eine vorläufig als gültig gesetzte Randbedingung, die im Projektverlauf bestätigt oder verworfen werden muss. Beispiel für die Verknüpfung: ^ Lastenheft ^ Pflichtenheft ^ | ''LH-009'' Die Last wird im Stillstand und bei Stromausfall sicher gehalten. | ''PH-014'' (bezieht sich auf ''LH-009''): Antrieb über selbsthemmendes Schneckengetriebe; Nachweis durch Halteversuch mit Prüflast bei getrennter Versorgung. | ===== Typische Fehler ===== * Lösungen werden vorgegeben, statt Anforderungen zu beschreiben. * Anforderungen sind nicht prüfbar, zum Beispiel „benutzerfreundlich“, „robust“ oder „möglichst schnell“. * Mehrere Anforderungen stehen in einem Satz. * Muss- und Kann-Anforderungen sind nicht unterschieden. * Abnahmekriterien fehlen. * Änderungen werden nicht dokumentiert oder IDs werden neu vergeben. ===== Ablauf im Modul Projektmanagement ===== - Die Betreuenden stellen die Lastenhefte der angebotenen Projekte bereit. - Die Teams analysieren das Lastenheft und klären offene Punkte mit der Betreuung. - Die Teams erstellen das Pflichtenheft. Jede Position verweist auf die zugehörigen IDs aus dem Lastenheft. - Arbeitsumfang, Zuständigkeiten und überprüfbare Abnahmekriterien werden mit der Betreuung abgestimmt. - Bei der Abnahme wird für jede Muss-Anforderung nachgewiesen, dass sie erfüllt ist. ===== Quellen und weiterführende Literatur ===== * DIN 69901-5:2009-01: //Projektmanagement – Projektmanagementsysteme – Teil 5: Begriffe.// Berlin: Beuth. * VDI 2519 Blatt 1:2001-12: //Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften.// Düsseldorf: VDI. [[https://www.vdi.de/mitgliedschaft/vdi-richtlinien/details/vdi-2519-blatt-1-vorgehensweise-bei-der-erstellung-von-lasten-pflichtenheften|VDI-Richtliniendetails]] * ISO/IEC/IEEE 29148:2018: //Systems and software engineering – Life cycle processes – Requirements engineering.// Genf: ISO. * [[https://de.wikipedia.org/wiki/Lastenheft|Wikipedia: Lastenheft]]