Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen

Die Vorstellungen darüber, was Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma.

Das liegt u. a. daran, dass die beiden Dokumente die verschiedenen Anforderungstypen nicht konsequent unterscheiden. Vielmehr unterscheiden sie sich in der Granularität und dem Detailgrad.

1. Allgemeines zu Lastenheften und Pflichtenheften

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

Das Konzept von ‚Lastenheft und Pflichtenheft‘ findet im angloamerikanischen Sprachraum keine direkte Entsprechung, ebenso wenig in Projektstandards wie PRINCE. Am ehesten ist ein Lastenheft mit „Statement of Work“ (SoW) zu übersetzen.

2. Das Lastenheft

a) Ziel des Lastenhefts

Das Lastenheft beschreibt die Anforderungen an ein Produkt bzw. an die Projektergebnisse aus Sicht des Auftraggebers. Diese Ergebnisse nennt man Lasten, woher das Lastenheft seinen Namen hat.

Lastenhefte beschreiben oft mehr als nur die zu erbringenden Projektergebnisse. Ein Auftraggeber verfasst ein Lastenheft auch, um Angebote bei potenziellen Auftragnehmern einzuholen. Es dient dem Auftragnehmer später als Grundlagen für das von ihm zu erstellende Pflichtenheft.

b) Typische Inhalte eines Lastenhefts

Meist beschreibt ein Lastenheft:

• 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. Anwender, 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)

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

c) Typische Fehler beim Verfassen von Lastenheften

Fehler 1: Vermischen von Aspekten

Ein Lastenheft sollte aus Auftraggeber-Sicht das Entwicklungsprojekt beschreiben. Leider beinhalten viele Lastenhefte eine Mischung verschiedenster Aspekte, z. B.:

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

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

Fehler 2: Auftragnehmer verfasst beide Dokumente

Oft übertragen die Auftraggeber 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.

3. Das Pflichtenheft

a) Ziel des Pflichtenhefts

Basierend auf dem Lastenheft formuliert der Auftragnehmer das Pflichtenheft. Die Inhalte dieses Pflichtenhefts benötigt der Auftragnehmer, um

• seine Kosten und Aufwände abzuschätzen,
• ein Angebot kalkulieren zu können und
• ggf. einen Vertrag mit dem Auftraggeber zu erstellen.

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

b) Typische 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. Entwicklungsprozess
  • 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 Auftraggeber und der potenzielle Auftragnehmer das Pflichtenheft zusammen mit dem Angebot des Auftragnehmers.

c) Typische Fehler beim Verfassen von Pflichtenheften

Fehler: Vermischen von Aspekten

Die meisten Pflichtenhefte vermischen (wie die Lastenhefte) Aspekte wie Stakeholder- und Systemanforderungen sowie Projektanforderungen. Das erschwert die Entwicklung und führt zu unklaren Verantwortlichkeiten und Kompetenzen.

Dieser Fehler ist problematisch, 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 teilweise im Widerspruch zu den gesetzlichen und normativen Anforderungen.

4. Erstellung von Lastenheft und Pflichtenheft

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

a) Beziehung zwischen Hersteller und Betreiber

Die Definition der Begriffe Lastenheft und Pflichtenheft geht ursächlich von einer Hersteller/Betreiber-Beziehung aus.

Die grundsätzliche Idee bei der Trennung von Lastenheft und Pflichtenheft richtet sich an der Trennung von Kernkompetenzen aus, um damit verbundene (Produkt-/Projekt-)Risiken zu vermeiden. Beispielsweise hat ein Betreiber wenig Lösungskompetenz, ein Hersteller dafür eine umso größere. Umkehrt verfügt der Hersteller über kaum über Erfahrungen beim Betrieb von Systemen.

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

b) 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 ein Vorgehen zählen Kosten, Ressourcen und Kompetenzen.

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

Die Inhalte dieser beiden Dokumente hängen von der Aufteilung der Aufgaben ab (Abb. 2).

Optionen zum Aufteilen der Verantwortlichkeiten und Aufgaben

Es gibt verschiedene Möglichkeiten, die Schnittstelle zwischen Auftraggeber und Auftragnehmer festzulegen (s. Abb. 2):

1. Entlang der roten Linie
   Der Hersteller formuliert im Lastenheft die Stakeholder-Anforderungen, z. B. die Nutzungsanforderungen. Der Auftragnehmer spezifiziert im Pflichtenheft die Lösung, mit der die Nutzungsanforderungen erfüllt werden. Es bleibt die Aufgabe des Herstellers zu prüfen, dass die im Pflichtenheft formulierte Systemspezifikationen bzw. Systemanforderungen tatsächlich die im Lastenheft formulierten Stakeholder-Anforderungen erfüllen.
2. Entlang der grünen Linie
   Alternativ beschreibt der Hersteller im Lastenheft die „Lösung über der Haube“ (z. B. in Form eines User-Interface-Prototypen), was einer Systemspezifikation entspricht. Der Auftragnehmer spezifiziert im Pflichtenheft, wie er diese Lösung technisch realisieren wird. Das entspräche einer System-Architektur.

Tipps zum Formulieren von Lastenheften und Pflichtenheften

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

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

c) Fazit

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

Wenn das Lastenheft alles vorgibt, beschreibt das Pflichtenheft nur noch, was notwendig ist, um die Kosten für die Lösung unter der Haube abzuschätzen.

Wie Sie sehen, unterscheidet sich die Inhalte von Lastenheften und Pflichtenheften bei einer Hersteller/Betreiber-Beziehung deutlich von denen bei einer Hersteller/Auftragnehmer-Beziehung.

5. Typische Probleme

a) Mangelnde Kompetenz

Meist verfügen weder Auftraggeber noch 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 Mischung aus Projektplan, Software-Anforderungen, Architektur, SSRS, PEMS-Anforderungen, SDS und Intended Use sind (siehe Abb. 1). Die Dokumente trennen die verschiedenen konzeptionellen Aspekte nicht.

Beispiel: In einer Software-Spezifikation finden sich Zweckbestimmung, Marktanforderungen, Vorgaben zur zu erstellenden Dokumentation oder Vorgaben zur Lösung. Diese haben in einer Systemspezifikation nichts verloren. Die Systemspezifikation sollte sich auf die Blackbox-Beschreibung des Softwaresystems beschränken.

c) Unterschiedlicher Detailgrad anstatt konzeptioneller Trennung

Lastenheft und Pflichtenheft unterscheiden sich 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 Entwicklung, die von unnötigen Iterationsschleifen und unangenehmen Diskussionen geprägt ist.

d) Unklare Verantwortlichkeiten, unklare Definitionen

Die Normen legen nicht fest, wer (also Auftragnehmer oder Auftraggeber) für die Erstellung eines Lastenhefts oder eines Pflichtenhefts 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.

6. Regulatorische Anforderungen

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 die 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 als Systemspezifikation vorliegen, z. B. in Form eines UI-Prototyps.

b) Regularien fordern Planungsdokumente

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

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

c) Fazit

Natürlich lassen sich auch diese Aspekte in einem Lastenheft und Pflichtenheft dokumentieren. Die Prüfung der Konformität mit den gesetzlichen Vorgaben wird dadurch jedoch erschwert.

Was noch schwerer wiegt: Die mangelnde Präzision und Abgrenzung in Lastenheften und Pflichtenheften führt zu ebenso unpräzisen Produkten und Projekten.

7. Fazit und Zusammenfassung

Für die Entwicklung von (Medizin-)Produkten sollten Hersteller nicht mit den Konzept ‚Lastenheft und Pflichtenheft‘ arbeiten, sondern die Aufteilung ihrer Tätigkeiten und Verantwortlichkeiten entlang der verschiedenen Anforderungstypen vornehmen. Damit reduzieren sie Missverständnisse und regulatorische Probleme.

---

Änderungshistorie

• 2023-11-11: Ziele von Lastenheften und Pflichtenheften als eigene Teilkapitel formuliert
• 2023-10-02: Artikel aktualisiert, redaktionelle Änderungen, Kapitel einheitlich nummeriert
• 2018-09-13: Erste Version verfasst