Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Lastenheft und Pflichtenheft: Unterschiede

Donnerstag 23. Februar 2017

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen:
Die Vorstellungen darüber, was diese Dokumente enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma.

Lastenheft und PflichtenheftRegelmäßig beobachte ich, dass alle mehrere Dokumente etwa die gleichen Anforderungen beschreiben. Nur in der Granularität und dem Detailgrad unterscheiden sie sich. Schon aus regulatorischer Sicht sollten Sie die Begriffe Lastenheft und Pflichtenheft gegeneinander abgrenzen.

Lastenheft und Pflichtenheft: Zweck und Inhalt

a) Lastenheft: Zweck und Inhalt

Ein Lastenheft beschreibt aus Auftraggeber-Sicht das Entwicklungsprojekt. Häufig beinhalten Lastenhefte eine krude Mischung verschiedenster Aspekte wie

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

Lastenheft und Pflichtenheft: Anforderungen

Daher enthalten die darauf basierenden Pflichtenhefte ebenso verschiedene Aspekte, was zum einen die Entwicklung erschwert und zum anderen zum Problem wird, weil die Normen und Gesetze eine Trennung von Stakeholder-Anforderungen und Systemanforderungen kennen und das Tracen dazwischen verlangen.

Weiterführende Informationen

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

b) Pflichtenheft: Zweck und Inhalt

Ein Pflichtenheft beschreibt auf Auftragnehmersicht das zu entwickelnde Produkt bzw. das umzusetzende Projekt. Ebenso wie viele Lastenhefte umfassen Pflichtenhefte verschiedenste Aspekte und trennen nicht sauber zwischen

  • Stakeholder-Anforderungen
  • System-Anforderungen
  • System-Architektur
  • Prozessvorgaben
  • Organisatorische und technische Rahmenbedingungen

Daher sind viele Entwicklungsprojekte von Beginn an teilweise im Widerspruch zu den gesetzlichen und normativen Anforderungen.

Lastenheft und Pflichtenheft versus Stakeholder und System-Anforderungen

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.

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

Wenn jedoch ein Hersteller ein Lastenheft schreibt, um ein Gerät aus Kostengründen / Ressourcengründen von einem Partner entwickeln zu lassen, kann dieser Hersteller natürlich auch die „gesamte Lösung über der Haube“ (Systemspezifikation/Systemanforderungen) diktieren und dieses Dokument Lastenheft nennen. Wesentlich ist dann nur, dass er alle Systemanforderungen und „Lösungsvorgaben“ auf Stakeholder-Anforderungen zurückführt. Gegen letztere muss dann validiert werden. Genau dieses Ableiten von Systemanforderungen aus Stakeholer-Anforderungen finden wir häufig nicht, was ein Risiko (für den Auftraggeber) bedeutet.

Inzwischen kann man beim Lastenheft soweit gehen, dass dieses die „Lösung über der Haube“ beschreibt, z.B. in Form eines User-Interface-Prototypen. Mehr und mehr Betreiber holen sich Partner ins Haus, um die „Lösung über der Haube“ zu beschreiben. Mit Hilfe von Prototyping-Tools und Notationen wie den Nutzungsszenarien können Auftraggeber (in Verbindung mit gekaufter User-Interface-Kompetenz) Lastenhefte beschreiben, die schon umfassende und konkrete Lösungsvorgaben enthalten. Wesentlich ist nur, dass diese von den zugrundeliegenden Stakeholder-Anforderungen abgeleitet sind.

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.

Reminder: 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.

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.

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.

Lastenhefte und Pflichtenhefte enthalten überlapende Inhalte

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.


Kategorien: Beliebteste Beiträge, Software & IEC 62304, Systementwicklung, Usability & IEC 62366
Tags: ,

Kommentar schreiben