Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen

Nur in der Granularität und dem Detailgrad unterscheiden sie sich. Schon aus regulatorischer Sicht sollten Sie die Begriffe Lastenheft und Pflichtenheft gegeneinander abgrenzen.

Allgemeines zu Lastenheften und Pflichtenheften

Das Konzept von Lasten- und Pflichtenheften ist ein eher deutsches. Im angloamerikanischen Sprachraum findet es keine direkte Entsprechung, ebenso wenig in Projektstandards wie PRINCE. Am ehesten ist ein Lastenheft mit „Statement of Work“ (SoW) zu übersetzen.

Die Aufteilung in ein Lastenheft und ein Pflichtenheft geht von eher einer Beziehung zwischen einem Auftragnehmer und einem Betreiber, denn von einer Beziehung zwischen einem Auftragnehmer und einem Entwicklungsdienstleister aus. Lastenhefte und Pflichtenhefte gibt es beispielsweise in der Baubranche und im Anlagenbau.

Sowohl das Lastenheft als auch das Pflichtenheft sollen Vertragsbestandteil zwischen Auftragnehmer und Auftraggeber sein.

Lastenheft

Das Lastenheft sollte die Anforderungen an das Produkt bzw. die Projektergebnisse aus Sicht des Auftraggebers beschreiben. Diese Ergebnisse nennt man die Lasten, woher das Lastenheft seinen Namen hat. Lastenhefte beschreiben allerdings meist mehr als nur die zu erbringenden Projektergebnisse.

Die Auftraggeber verfassen das Lastenheft auch, um Angebote bei potenziellen Auftragnehmern einzuholen. Es dient den Auftragnehmern später als Grundlagen für das von ihm, dem Auftragnehmer, zu erstellende Pflichtenhefts.

a) Typische Inhalte eines Lastenhefts

• Stakeholder-Anforderungen (z.B. regulatorische Anforderungen, Nutzungsanforderungen, fachliche Anforderungen) ODER Anforderungen an das Produkt (Systemanforderungen) (mehr zu der Aufteilung weiter unten)
• Abnahmekriterien, um zu prüfen, ob die entsprechenden Anforderungen erfüllt sind
• Informationen zur Verwendung des Produkts z.B. die Anwender, die Häufigkeit der Nutzung, Volumina von Daten oder Materialien
• Anforderungen an die Voraussetzungen, um das Produkt zu betreiben (z.B. physikalische Umgebung, Versorgungsnetze, Zubehör)
• Ggf. Einschränkung des Lösungsraums z.B. zu verwendende Technologien, Materialien, Komponenten
• Anforderungen an den Auftragnehmer (Personal, Zertifizierung, Prozesse, V&V-Aktivitäten und Methoden)
• Anforderungen an die Dokumentation
• Sonstige Anforderungen an das Projekt (insbesondere Dauer, Kosten, Meilensteine)

Die Anforderungen an den Auftragnehmer lassen sich alternativ auch in einer Qualitätssicherungsvereinbarung festlegen.

b) Typische Fehler beim Verfassen von Lastenheften

Vermischen von Aspekten

Ein Lastenheft sollte aus Auftraggeber-Sicht das Entwicklungsprojekt beschreiben. Leider beinhalten viele Lastenhefte eine krude Mischung verschiedenster Aspekte wie

• Nutzungsanforderungen
• Marktanforderungen
• Gesetzliche Anforderungen
• System-Anforderungen
• Technische und organisatorische Rahmenbedingungen
• Business-, Markt- und Umsatzerwartungen
• Vorgaben für Prozesse, Methoden und Werkzeuge.

Abb. 1: Lastenhefte und Pflichtenhefte vermengen oft verschiedene Aspekte. Zum Vergrößern klicken

Wie man Lastenhefte und Pflichtenhefte richtig verfasst, finden sie weiter unten beschrieben.

Auftragnehmer verfasst beide Dokumente

Oft übertragen die Auftraggeber sogar das Verfassen des Lastenhefts dem Auftragnehmer. Das führt jedoch dazu, dass letzterer das Dokument so verfassen wird, dass es seinen eigenen Interessen dient und den eigenen Fähigkeiten entspricht. Vorsicht!

Wer (als Auftraggeber) sein eigenes Gehirn outsourced, darf sich über die Folgen nicht wundern.

Pflichtenheft

Basierend auf dem Lastenheft formuliert der Auftragnehmer das Pflichtenheft. Die Inhalte dieses Pflichtenhefts benötigt der Auftragnehmer selbst, um die Kosten zu kalkulieren.

Ähnlich wie beim Pflichtenheft gibt es kein einheitliches Verständnis dieses Begriffs.

a) Inhalt eines Pflichtenhefts

Meist beschreibt das Pflichtenheft:

• Spezifikation des Ergebnisses:
  • Entweder die Produkt-/Systemspezifikation (z.B. als Blackbox) (oder eine Verfeinerung dieser)
  • Oder die technische Realisierung des Produkts, wenn das Lastenheft bereits diese Spezifikation beinhaltet. In diesem Fall enthält das Pflichtenheft die System-Architektur sowie die Wahl von Materialien, Technologien und Komponenten Dritter.
• Geplante Vorgehensweise des Auftragnehmers
  • z.B. Entwickungsprozess
  • Detaillierterer Projektplan inkl. interne Meilensteine
  • Festlegung bezüglich Kommunikation insbesondere zur Eskalation und Rücksprache mit Auftraggeber
• Ggf. Benennung konkreter Ressourcen
  • Personen
  • Partner (z.B. Testhäuser, Unterauftragnehmer)
  • Maschinen, Produktionsmittel

Meist diskutieren der Auftragnehmer und der potenzielle Auftragnehmer das Pflichtenheft zusammen mit dem Angebot des Auftragnehmers.

b) Typische Fehler

Die meisten Pflichtenhefte vermischen die o.g. Aspekte wie Stakeholder- und Systemanforderungen sowie Projektanforderungen ebenso wie die Lastenhefte.

• Das erschwert die Entwicklung
• Es führt zu unklaren Verantwortlichkeiten und Kompetenzen
• Es wird zum zum anderen zum Problem wird, weil die Normen und Gesetze eine Trennung von Stakeholder-Anforderungen und Systemanforderungen kennen und das Tracen dazwischen verlangen.

Daher stehen Entwicklungsprojekte regelmäßig von Beginn an im teilweisen Widerspruch zu den gesetzlichen und normativen Anforderungen.

Lastenheft und Pflichtenheft: Der bessere Ansatz

Zuerst müssen beim Verfassen von Lastenheften und Pflichtenheften zwei Beziehungen zwischen Auftragnehmer unterschieden werden.

a) Lasten- und Pflichtenheft in einer Hersteller-Betreiber-Beziehung

Die Definition der Begriffe „Lastenheft“ und Pflichtenheft“ gehen ursächlich von einer Betreiber-Herstellerbeziehung aus. Die grundsätzliche Idee bei der Trennung von Lastenheft und Pflichtenheft richtet sich an der Trennung von Kern-Kompetenzen aus, um damit verbundene (Produkt-/Projekt-)Risiken zu vermeiden. So hat ein Betreiber typisch wenig Lösungskompetenz, aber dafür ein Hersteller.

Auf diese Form der Lastenhefte und Pflichtenhefte geht dieser Artikel nicht weiter ein.

b) Lasten- und Pflichtenheft in einer Beziehung zwischen „Hersteller“ und Entwicklungsdienstleister

Eine andere Situation liegt vor, wenn ein Hersteller bzw. ein „Inverkehrbringer“ ein Lastenheft schreibt, um ein Produkt von einem Dienstleister entwickeln zu lassen. Zu den Gründen für solch eine Entscheidung zählen Kosten, Ressourcen und Kompetenzen. Tipp

Der besten Ansatz besteht in diesem Fall darin, auf die Begriffe „Lastenheft“ und „Pflichtenheft“ ganz zu verzichten. Es mag einen Grund haben, dass sich diese außerhalb des deutschen Sprachgebiets nicht durchgesetzt haben.

In diesem Fall sollte das Lastenheft aus Auftraggebersicht das zu entwickelnde Produkt beschreiben, das Pflichtenheft den Entwicklungsauftrag aus Sicht des Auftragnehmers d.h. Entwicklungsdienstleisters.

Die Inhalte dieser beiden Dokumente hängen jedoch von der der Aufteilung der Aufgaben ab:

Optionen zum Aufteilen der Verantwortlichkeiten und Aufgaben

Hier gibt es mehrere Möglichkeiten, wie Auftraggeber die Schnittstelle zu seinem Auftragnehmer festlegt (s. Abb. 2):

1. Der Hersteller formuliert im seinem Lastenheft die Stakeholder-Anforderungen z.B. die Nutzungsanforderungen (rote Linie). Dann würde der Auftragnehmer im Pflichtenheft die Lösung spezifizieren, mit der die Nutzungsanforderungen erfüllt werden. Es bliebe die Aufgabe des Herstellers zu prüfen, dass die im Pflichtenheft formulierte Systemspezifikation/ Systemanforderungen tatsächlich die im Lastenheft formulierten Stakeholder-Anforderungen erfüllen.
2. Alternativ kann der Hersteller im Lastenenheft soweit gehen, die „Lösung über der Haube“ zu beschreiben (z.B. in Form eines User-Interface-Prototypen), was einer Systemspezifikation entspricht (grüne Linie). Dann würde der Auftragnehmer im Pflichtenheft spezifizieren, wie er diese Lösung technisch realisieren möchte. Das entspräche einer System-Architektur.

Tipps zum Formulieren von Lastenheften und Pflichtenheften

Das Johner Institut empfiehlt bei Formulieren von Lasten- und Pflichtenheften:

• Nutzen Sie professionelle Requirements Engineers, die die Stakeholder-Anforderungen insbesondere die Nutzungsanforderungen in den gegebenen Nutzungskontexten erheben. Das gelingt durch direkte Befragen der Nutzer nur unzureichend.
• Sie benötigen Usability-Experten, die Ihnen helfen, die „Lösung über der Haube“ zu spezifizieren. Diese Experten leiten systematisch aus den Nutzungsanforderungen Nutzungsszenarien und daraus Interface-Spezifikationen ab.
• Nutzen Sie Prototyping-Werkzeuge, um die Interface-Spezifikationen einer formativen Evaluation der Gebrauchstauglichkeit zu unterziehen (d.h. diese zu validieren).
• Legen Sie als Hersteller und als Auftragnehmer genau fest, welche der beiden o.g. Varianten Sie wählen. Der Inhalt der Lastenhefte und Pflichtenhefte hängt davon ab!

Weiterführende Informationen

In der Kategorie zum Usability und Requirements Engineering finden Sie Artikel dazu, wie Sie Nutzungsanforderungen systematisch identifizieren und daraus Systemanforderungen herleiten.

c) Fazit

Lastenhefte können somit grundsätzlich alles diktieren, was ein Lieferant liefern soll. Um die Risiken für das Projekt zu minimieren, sollte jedoch alle Vorgaben mit Stakeholder-Anforderungen abgesichert sein.

Wenn das Lastenheft so weit geht, dass es alles vorgibt, würde man in einem Pflichtenheft nur noch beschreiben müssen, was notwendig ist, um die Kosten für die Lösung unter der Haube abzuschätzen. Zur Erinnerung!

Pflichtenheft = Entscheidungsgrundlage für die Auftragsvergabe. Es ist das ‚Angebot des Auftragnehmers auf der Grundlage eines Lastenhefts‘.

Wie Sie sehen, unterscheidet sich der Inhalt von Lastenheften bzw. Pflichtenheften bei Hersteller-/Betreiberbeziehungen deutlich von denen bei einer Hersteller-/Auftragnehmerbeziehung.

Typische Probleme bei der Erstellung von Lastenheft und Pflichtenheft

a) Mangelnde Kompetenz

Meist verfügen weder die Auftraggeber noch die Auftragnehmer über die notwendige Kompetenz (v.a. des Usability und Requirements Engineerings), um sowohl Stakeholder- als auch Systemanforderungen systematisch zu erheben.

b) Vermischen von Aspekten

Das führt dazu, dass die Lastenhefte und Pflichtenhefte eine krude Mischung aus Projektplan, Software-Anforderungen, Architektur, SSRS, PEMS-Anforderungen, SDS und Intended Use sind. D.h. die Dokumente trennen die verschiedenen konzeptionellen Aspekte nicht.

In einer Software-Spezifikation, um ein Beispiel zu nennen, finden sich die Zweckbestimmung, Marktanforderungen, Vorgaben zur zu erstellenden Dokumentation oder Vorgaben zur Lösung. Die haben in einer Systemspezifikation nichts verloren. Diese sollte sich – wie kürzlich beschrieben – auf die Blackbox-Beschreibung des Softwaresystems beschränken.

c) Detaillierungsgrad anstatt konzeptioneller Trennung

Lastenheft und Pflichtenheft unterscheiden sich vielmehr im Detaillierungsgrad, was oft zu wenig sinnvollen „Traces“ führt und zudem die Trennung zwischen Verifizierung (Prüfen der Systemspezifikation) und Validierung (Prüfen der Nutzungsanforderungen) zumindest erschwert.

Die Präzision, die in den Dokumenten fehlt, wird nicht nur zum Traceability-Problem, sondern sie führt zu einer unpräzisen und damit aufwendigen, von unnötigen Iterationsschleifen und unangenehmen Diskussionen geprägten Entwicklung.

d) Unklare Verantwortlichkeiten, unklare Definitionen

Die Normen legen nicht fest, wer – also Auftragnehmer oder Auftraggeber – für die Erstellung eines Lastenheftes oder eines Pflichtenheftes verantwortlich sein soll. Die Begriffe Lastenheft und Pflichtenheft sollten aber Auftraggeber und Auftragnehmer ebenso einheitlich verstehen wie die Begriffe Nutzungsanforderung, Systemanforderung und Systemspezifikation. Dies ist für eine erfolgreiche und normenkonforme Entwicklung (nicht nur) von Software unabdingbar.

Regulatorische Anforderungen an Lastenhefte und Pflichtenhefte

a) Regularien fordern und unterscheiden Stakeholder-Anforderungen und Design Input

Weder Normen noch Gesetze kennen die Begriffe Lastenheft und Pflichtenheft. Insofern gibt es keine regulatorischen Anforderungen daran. Aber: Sowohl eine ISO 13485 also auch die FDA im 21 CFR part 820 unterscheiden zwischen Stakeholder-Anforderungen und Design Input:

• Stakeholder-Anforderungen umfassen die Nutzungsanforderungen, die gesetzlichen Anforderungen, Marktanforderungen sowie die fachlichen und organisatorischen Anforderungen.
• Der Design Input kann beispielsweise als Systemspezifikation (z.B. in Form eines UI-Prototyps) vorliegen.

b) Regularien fordern Planungsdokumente

Weiter kennen die Regularien neben den produktspezifischen „Vorgaben“ auch die Projektaspekte, die Hersteller beschreiben müssen in Form von

• Entwicklungsplan
• Software-Entwicklungsplan
• Risikomanagementplan
• Verifizierungs- und Validierungsplan (so nicht Teil der Entwicklungspläne).

c) Fazit

Natürlich lassen sich alle diese eben genannten Aspekte in einem Lastenheft und Pflichtenheft dokumentieren. Nur die Prüfung der Konformität mit den gesetzlichen Vorgaben wird damit schwerer.  Was noch schwerer wiegt: Die mangelnde Präzision und Abgrenzung in Lastenheften und Pflichtenheften führt zu ebenso unpräzisen Produkten und Projekten.