Lastenheft – Leistungsverzeichnis
Requirements Specification - Anforderungsspezifikation
Am Anfgang bei IT-Projekten steht immer die Frage: „Was soll die gewünschte IT-Unterstützung leisten?“ Diese Frage muss der Fachbereich beantworten. Ob das hierfür zu erstellende Dokument als Fachkonzept, Fachspezifikation, Anforderungsbeschreibung, Anforderungskatalog, Leistungsverzeichnis (LV), User Story oder Lastenheft bezeichnet wird, spielt dabei eine untergeordnete Rolle.
Das Lastenheft beschreibt die Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers (Service Provides).
Das Lastenheft – auch Anforderungsspezifikation, Anforderungskatalog, Produktskizze, Produktstrukturplan, Leistungsverzeichnis, Statmenet of Work (SoW), Kundenspezifikation oder englisch Requirements Specification genannt – beschreibt ergebnisorientiert die „Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines (Projekt-) Auftrags“ (DIN 69901-5). Grundsätzlich sollte der Auftraggeber bzw. der Fachbereich das Lastenheft formulieren. Es dient dann als Grundlage zur Einholung von Angeboten (Ausschreibung, Angebotsanfragen). Insbesondere im Bau und Anlagenbau wird das Lastenheft auch als Leistungsverzeichnis (LV) bezeichnet. Es ist z. B. im Software-Bereich das Ergebnis einer Anforderungsanalyse und damit ein Teil des Anforderungsmanagements.
Bei einem formell korrekten Vorgehen setzt der Auftragnehmer nach Erhalt des Lastenhefts die zu erbringenden Ergebnisse (Lasten) in erforderliche Tätigkeiten (Pflichten) um und erstellt das sogenannte Pflichtenheft als Teil des Angebots an den Auftraggeber.
Die einfachste Form des Pflichtenhefts ist die Benennung des Liefertermins und des Preises. Die ausführlichste Form enthält bereits die vollständige Projektplanung (z.B. den Vertragsterminplan). Bei Projekten mit engem Abstimmungsbedarf zwischen Auftragnehmer und Auftraggeber wird die Erarbeitung des Pflichtenhefts in einer gemeinsamen Arbeitsgruppe oder Arbeitsgemeinschaft durchgeführt. Bei Großprojekten ist die Erstellung und vertragliche Vereinbarung des Pflichtenhefts bereits selbst ein Projekt.
Das Lastenheft kann der Auftraggeber in einer Ausschreibung verwenden und an mehrere mögliche Auftragnehmer verschicken. Mögliche Auftragnehmer erstellen auf Grundlage des Lastenheftes ein Pflichtenheft, welches in konkreterer Form beschreibt, wie der Auftragnehmer die Anforderungen im Lastenheft zu lösen gedenkt. Der Auftraggeber wählt dann aus den Vorschlägen den für ihn geeignetsten aus. Die Anforderungen in einem Lastenheft sollten durch ihre Formulierung so allgemein wie möglich und so einschränkend wie nötig formuliert werden. Hierdurch hat der Auftragnehmer die Möglichkeit, optimale Lösungen zu erarbeiten, ohne durch zu konkrete Anforderungen in seiner Lösungskompetenz eingeschränkt zu sein.
Im Rahmen eines Werkvertrages oder Werkliefervertrages und der dazugehörenden formellen Abnahme beschreibt das Lastenheft präzise die nachprüfbaren Leistungen und Lieferungen.
Was ist die Struktur und der Inhalt eines Lastenheftes?
Die Gliederung eines Lastenhefts sollte folgende Punkte enthalten:
- Die Spezifikation des zu erbringenden Werks (Liefergegenstand (Deliverables), Lieferobjekt, Projektprodukt)
- Die Anforderungen an das Produkt bei seiner späteren Verwendung (z.B. Temperaturbereich)
- Rahmenbedingungen (Conditions) für Produkt und Leistungserbringung (z.B. Normen, Richtlinien, Materialien usw.)
- vertragliche Konditionen (z.B. Erbringen von Teilleistungen, Gewährleistungsanforderungen, Risikomanagement usw.)
- Anforderungen an den Auftragnehmer (z.B. Zertifizierungen)
- Anforderungen an das Projektmanagement des Auftragnehmers (z.B. Projektdokumentation, Controlling-Methoden)
Hintergund
Lasten- und Pflichtenheft sollten stets Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer sein.
Der PMBOK(R) Guide 2008 fasst das Statement Of Work (SOW) ein wenig enger als die DIN 69901-5 das Lastenheft. Das SOW ist dort als Beschreibung der zu erbringenden Dienstleistungen oder Werke definiert. Dies umfasst lediglich die Spezifikation des Produkts oder der Dienstleistung.
Die ICB 3.0 verzichtet auf die explizite Benennung eines Lastenhefts. Statt dessen spricht sie lediglich von „project scope“ und „deliverables„. In der deutschen Competence Baseline ICB 3.0 wird ergänzend zumindest das Begriffspaar „Lastenheft/Pflichtenheft bei der technischen Kompetenz „Leistungsumfang und Lieferobjekte“ benannt.
PRINCE2 verzichtet völlig auf die Systematik von Lastenheft und Pflichtenheft, da es die Beschaffungsprozesse nicht beschreibt. Inhaltlich treten an die Stelle des Lastenhefts bei PRINCE2 für das Gesamtprojekt das Projektmandat und die Beschreibung des Projektprodukts. Anstelle von Lastenheften, die im Rahmen des Projekts zu erstellen sind, treten bei PRINCE2 der Produktstrukturplan und die Produktbeschreibungen.
Unter einem Epic versteht man im Kontext des Anforderungsmanagements die Beschreibung einer Anforderung an eine neue Software auf einer hohen Abstraktionsebene. Die Beschreibung der Anforderung geschieht dabei in der Alltagssprache analog zu User Story. Bei der sogenannten Story Decomposition wird ein Epic in mehrere User Stories zerlegt, mit dem Ziel einer besseren Detaillierung. Durch dieses Verfahren findet eine Transformation vom Groben zu einer niedrigeren Abstraktionsebene mit mehr Details und Informationen statt, damit eine Umsetzung durch das Entwicklungs-Team erfolgen kann. Hierbei kommen zur Beschreibung der Anwendungsfälle neben Alltagssprache auch Visualisierungen, z. B. durch UML-Diagramme, zum Einsatz. Der Begriff „Epic“ wird vor allem im Umfeld der agilen Softwareentwicklung bzw. des agilen Requirements Engineering verwendet. Epics dienen dabei zur Entwicklung eines Product Backlogs im Rahmen von Scrum. Sie geben dem Autor die Möglichkeit, zunächst eine aggregierte, grobgranulare Sicht auf neue Produktanforderungen zu entwickeln, ohne auf die Details einer Anforderung eingehen zu müssen. Epics können insofern nicht direkt in Software-Coding umgesetzt werden, sondern bedürfen der Detaillierung, die unter Scrum in der Vorbereitung eines Sprint-Planungsmeetings geschieht. Das Epic steht dabei in Kontrast zur User Story, die eine Anforderung feingranular beschreibt und eine Detaillierung des Epics auf eine in Software-Code umsetzbare Granularitätsstufe darstellt.