Pflichtenheft

Nach DIN 69901-5 enthält das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes“.

Ein Pflichtenheft ist ein zentrales Dokument im Projektmanagement. Es beschreibt detailliert, was ein System oder Produkt können muss, um die Anforderungen der Auftraggeberin oder des Auftraggebers zu erfüllen. Im Gegensatz zum Lastenheft, das die Wünsche aus Sicht der Auftraggeberin oder des Auftraggebers formuliert, präzisiert das Pflichtenheft die Umsetzung aus der Sicht der Auftragnehmerin oder des Auftragnehmers. Es ist somit die verbindliche Arbeitsgrundlage für alle Projektbeteiligten und bildet die Basis für die Abnahme des fertigen Produkts.

Lastenheft und Pflichtenheft beinhalten meist einen intensiven Kommunikationsprozess, um die Anforderungen und den Lösungsweg für beide Parteien zu klären und schriftlich festzulegen. Lastenheft und Pflichtenheft fließen als Vertragsbestandteile in einen Werkvertrag ein, so dass alle relevanten Abnahmekriterien beschrieben und abprüfbar sind (Quelle: Balzert, Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering ,2009, Seite 490 ff).

Bestandteile eines Pflichtenhefts

Ein typisches Pflichtenheft ist in verschiedene Abschnitte gegliedert, die eine umfassende Beschreibung des Projekts ermöglichen. Hier sind die wichtigsten Punkte, die du als angehender Fachinformatiker kennen solltest:

1. Einleitung und Zielsetzung

Dieser Abschnitt gibt einen Überblick über das Projekt. Er beantwortet Fragen wie:

• Was ist das Ziel des Projekts?
• Welches Problem soll gelöst werden?
• Wer sind die Stakeholder (Interessengruppen)?

2. Funktionale Anforderungen

Dieser Abschnitt beschreibt, was das System tun muss. Es sind die Kernfunktionen, die das Produkt erfüllen muss, um seinen Zweck zu erfüllen. Sie beschreiben die "Was-Frage" des Systems. Beispiele sind:

• Ein Benutzer muss sich einloggen können.
• Das System muss eine Rechnung erstellen können.
• Die Software muss Daten exportieren können.

3. Nicht-funktionale Anforderungen

Hier geht es um die Qualitätsmerkmale des Systems. Sie beschreiben, wie gut das System etwas tun muss. Typische nicht-funktionale Anforderungen sind:

• Performance: Wie schnell muss die Anwendung reagieren?
• Skalierbarkeit: Wie viele Benutzer kann das System gleichzeitig verarbeiten?
• Sicherheit: Welche Sicherheitsmechanismen müssen implementiert werden?
• Usability (Ergonomie): Wie benutzerfreundlich ist das System?
• Zuverlässigkeit: Wie stabil muss das System sein?
• Ein wichtiger Aspekt in diesem Bereich ist die Ergonomie. Sie bezieht sich darauf, wie einfach und effizient die Software zu bedienen ist, um eine optimale Benutzererfahrung zu gewährleisten. Dazu gehören intuitive Navigation, verständliche Fehlermeldungen und ein übersichtliches Layout.

Verknüpfung mit UML

Die Unified Modeling Language (UML) ist eine grafische Modellierungssprache, die häufig zur Visualisierung von Software-Systemen im Pflichtenheft genutzt wird. Anstatt lange Texte zu schreiben, können komplexe Zusammenhänge durch Diagramme dargestellt werden. Dies schafft Klarheit und beugt Missverständnissen vor.

Hier sind einige relevante UML-Diagramme, die im Pflichtenheft verwendet werden können:

Anwendungsfalldiagramm (Use Case Diagram): Zeigt die funktionalen Anforderungen aus der Sicht der Benutzer. Es stellt dar, wer mit dem System interagiert und welche Aufgaben (Anwendungsfälle) er ausführen kann.

Klassendiagramm (Class Diagram): Beschreibt die Struktur des Systems, indem es die Klassen, ihre Attribute (Eigenschaften) und Methoden (Verhalten) sowie die Beziehungen untereinander darstellt.

Aktivitätsdiagramm (Activity Diagram): Visualisiert den Ablauf von Prozessen oder Arbeitsflüssen im System.

Sequenzdiagramm (Sequence Diagram): Es stellt den zeitlichen Ablauf von Interaktionen zwischen verschiedenen Objekten oder Systemkomponenten dar. Es zeigt, in welcher Reihenfolge Nachrichten (Methodenaufrufe) ausgetauscht werden. Dies ist besonders nützlich, um die dynamischen Aspekte eines Anwendungsfalls detailliert zu beschreiben.

Zustandsdiagramm (State Machine Diagram): Es modelliert die verschiedenen Zustände, die ein System im Laufe seines Lebens einnehmen kann, sowie die Übergänge zwischen diesen Zuständen. Es beschreibt, welche Ereignisse einen Zustandswechsel auslösen und welche Aktionen dabei ausgeführt werden. Mit diesem Diagramm lassen sich Automaten beschreiben.

Die Verwendung von UML im Pflichtenheft hilft dabei, die funktionalen und nicht-funktionalen Anforderungen präzise zu definieren und die Kommunikation zwischen Entwicklern und Auftraggebern zu verbessern.