Lastenheft erstellen mithilfe von Quality Function Deployment (QFD)

Mit Quality Function Deployment (QFD) können Sie Anforderungen und Wünsche der Nutzer und Betroffenen in konkrete Leistungen eines Unternehmens und in Funktionen eines Produkts übersetzen.

Diese Methode leitet in mehreren Schritten aus einer einzelnen Anforderung aus Nutzer- oder Kundensicht ab, welches Merkmal, welche Funktion oder welche Leistung aus Techniksicht erbracht werden muss, um die Anforderung zu erfüllen.

Die einzelnen Elemente des QFD und ihre Beziehung zueinander werden in einem Bild dargestellt, das die Form eines Hauses hat. Deshalb wird dieses Bild als House of Quality bezeichnet (Abbildung 1).

Abbildung 1: Aus Anforderungen werden mit QFD Leistungsmerkmale

Black-Box-Analyse für das Lastenheft nutzen

Bei der Black-Box-Analyse wird ein Vorhaben, ein Produkt, ein Projekt oder ein System in einzelne Elemente oder Komponenten zerlegt (siehe Abbildung 2). Das können zum Beispiel sein: Bauteile, Einzelteile, Funktionen oder Materialien sowie Arbeitspakete, Teilschritte, Teilergebnisse, Meilensteine etc.

Diese Elemente werden soweit notwendig spezifiziert, beschrieben und erläutert. Was nicht spezifiziert werden muss, wird nicht weiter ausgearbeitet und bleibt offen – wie eine „Black Box“ (in der Abbildung auf Systemebene 2).

Diese Elemente oder Merkmale werden im Lastenheft nur allgemein benannt, aber nicht genauer erläutert. Der Anbieter kann dann selbst eine Lösung finden; er legt fest, was in der „Black Box“ abläuft.

Abbildung 2: Zerlegung eines Systems in einzelne Elemente mit der Black-Box-Analyse

Analytic Hierarchy Process oder Analytische Hierarchieprozess (AHP)

Der Analytic Hierarchy Process oder Analytische Hierarchieprozess (AHP) ist ein systematisches Verfahren, um komplexe Aufgaben, Fragen, Probleme oder Entscheidungen zu strukturieren und zu lösen. Dazu wird das ursprüngliche System ähnlich wie bei der Black-Box-Methode in Einzelteile oder einzelne Kriterien zerlegt und in mehreren Ebenen (Hierarchie) dargestellt:

  • Ebene 1: Ziele und Ergebnisse, die erreicht werden sollen.
  • Ebene 2: Aspekte, die dafür betrachtet, Lösungen, die entwickelt, Kriterien, die erfüllt, Projekte, die dafür durchgeführt werden sollen.
  • Ebene 3: Teil-Elemente oder Teil-Lösungen, die es dafür jeweils braucht; Kriterien, die beachtet werden müssen.
  • Ebene 4 und weitere (optional): Weitere Zerlegung der Teil-Elemente, Teil-Lösungen und Kriterien soweit wichtig.
  • Ebene 5: Alternative (Teil-) Lösungen, die dabei möglich sind.

Anschließend wird durch paarweisen Vergleich der Kriterien auf den einzelnen Ebenen ermittelt, welchen Beitrag diese für die übergeordnete Ebene leisten. Die Ergebnisse werden mithilfe mathematischer Verfahren aggregiert, sodass am Ende sichtbar wird, welche (Teil-)Lösung wie wichtig ist für die Zielerreichung.

So lassen sich unterschiedliche Anforderungen an eine Lösung vergleichen und bewerten. Zudem erhalten Sie darüber Gewichtungen, die Ihnen später beim Auswerten der Angebote der Anbieter helfen.

Requirements Engineering – Systemanalyse und Anforderungsanalyse

Grundlage für das Erstellen eines Lastenhefts ist das Requirements Engineering. Das ist ein Sammelbegriff, der eine Vielzahl von Methoden und Werkzeugen umfasst, um Systeme zu analysieren und Anforderungen systematisch zu ermitteln. Die einzelnen Aufgaben des Requirements Engineering sind:

  • Anforderungen ermitteln
  • Anforderungen beschreiben und dokumentieren
  • Anforderungen prüfen und bewerten
  • Anforderungen verwalten

Eine Anforderung ist das, was eine Person als Nutzer, Betroffener oder Stakeholder des Systems in Bezug auf die gewünschte oder geforderte Leistung, Funktion, Merkmal oder Eigenschaft benennt. System ist dabei ein übergreifender Begriff, der Produkte, Prozesse, Anlagen, Maschinen, Werkzeuge, Projekte, Testfälle oder Dokumente umfassen kann.

Um die Aufgaben zu erfüllen, bedient sich das Requirements Engineering unterschiedlichster Methoden und Werkzeuge.

Für das Ermitteln und Sammeln von Anforderungen müssen Nutzer, Betroffene und Stakeholder befragt und beobachtet werden. Auch Kreativitätstechniken und moderierte Workshops kommen dafür zum Einsatz. Dokumente, vergleichbare Systeme und Vorgängerprodukte werden analysiert und getestet.

Für das Beschreiben und Dokumentieren eignen sich formale Beschreibungssprachen und Modelle wie Unified Modeling Language (UML) oder Prozessdarstellungen sowie Sprachschablonen wie die Sophist-Satzschablone.

Das Prüfen und Bewerten der Anforderungen erfolgt mit Methoden des Qualitätsmanagements, Messen, Testen, Bewerten. Hilfreich sind paarweise Vergleiche oder Punktbewertungen.

Beim Verwalten der Anforderungen ist wichtig, dass diese gespeichert und bei Bedarf (wieder) genutzt werden – zum Beispiel für Lastenhefte. Da sich Anforderungen im Laufe der Zeit ändern, sollten sie auch versioniert werden.

Bei der Entwicklung eines Systems, wenn die Anforderungen abgearbeitet werden, ist es notwendig, den sogenannten Change Request, die immer wieder veränderten Anforderungen, zu bewältigen.

Praxis

Beispiele für Lastenhefte

Auch wenn es mit der VDI/VDE-Richtlinie 3694 oder mit dem Standard for Software Requirements Specification (SRS) der IEEE (ANSI/IEEE Std 29148-2018) Standards für Inhalte und Gliederung eines Lastenhefts gibt, so sind Lastenhefte immer Einzelfertigungen für jedes Unternehmen und jedes Vorhaben.

Um das eigene Lastenheft zu erstellen, kann es hilfreich sein, sich Beispiele anzuschauen: Wie haben andere das gemacht? Hier finden Sie einige Beispiele für Lastenhefte von unterschiedlichen Unternehmen und Anwendungsfällen:

Dazu im Management-Handbuch

Weitere Kapitel zum Thema