Pflichtenheft Vorlage

1 Einleitung
1.1 Zweck des Dokuments 5
1.2 Begriffsbestimmungen und Abkürzungen 5
1.3 Überblick über das Dokument 6

2 Allgemeine Beschreibung des Produkts 7
2.1 Zweck des Produkts 7
2.2 Überblick über die geforderte Funktionalität 7
2.3 Allgemeine Einschränkungen 7
2.4 Vorgaben zu Hardware und Software 8
2.5 Benutzer des Produkts 8

3 Detaillierte Beschreibung der geforderten Produktmerkmale 9
3.2 Abläufe (Szenarien) von Interaktionen mit der Umgebung 9
3.3 Ziele des Benutzers 10
3.4 Geforderte Funktionen des Produkts 10
3.4.1 <Funktion Bezeichnung a> 11
3.4.1.1 Wirkungsweise von <Funktion Bezeichnung a> 11
3.4.1.2 Abhängigkeiten / Randbedingungen 11
3.4.2 <Funktion Bezeichnung b> 11
3.5 Externe Schnittstellen des Produkts 11
3.5.1 Benutzerschnittstellen (User Interfaces) 11
3.5.2 Systemschnittstellen 12
3.5.2.1 <Schnittstelle a> 12
3.5.2.2 <Schnittstelle b> 12
3.6 Sonstige geforderte Produktmerkmale 12
3.6.1 Geschwindigkeitsmerkmale (performance) 13
3.6.2 Ressourcenmerkmale (resource) 13
3.6.3 Schutzmerkmale (security) 13
3.6.4 Sicherheitsmerkmale (safety) 13
3.6.5 Portabilitätsmerkmale (portability) 13
3.6.6 Stabilitätsmerkmale (reliability) 14
3.6.7 Wartungsmerkmale (maintenance) 14
3.6.8 Wiederverwendbarkeitsmerkmale (reuse) 14
3.6.9 Benutzbarkeitsmerkmale (usability) 14

4 Vorgaben an die Projektabwicklung 15
4.1 Anforderungen an die Realisierung 15
4.2 Fertige und zugekaufte Komponenten 15
4.3 Abnahmebedingungen 16
5 Anhang 19

Hinweise
Zweck des Dokuments
Der Zweck des vorliegenden Pflichtenhefts ist eine für die Entwicklung verbindliche und möglichst eindeutige Spezifikation von <xyz>. In diesem Sinn enthält es die Summe aller aus Projektsicht erforderlichen und akzeptierten Anforderungen an dieses Produkt und die Projektabwicklung.
Begriffsbestimmungen und Abkürzungen
Auflistung von Begriffsdefinitionen und Abkürzungen, die für das Verständnis des Pflichtenhefts wichtig sind (EDV-Fachausdrücke und Begriffe aus der Anwendungsdomäne).
Diese Auflistung wird normalerweise alphabetisch geordnet sein, sie kann aber ggf. auch hierarchisch organisiert werden, sodaß speziellere Begriffe (wie z.B. Transaktion mit einem Bankomaten) bei den entsprechend allgemeineren Begriffen (wie z.B. Transaktion) zu finden sind.
Die Begriffsdefinitionen sind deshalb so besonders wichtig, weil das Pflichtenheft die gemeinsame Verständnisbasis von Auftraggeber und Auftragnehmer darstellt.
Wenn diese Begriffe im Fließtext vorkommen, dann sollen sie typographisch hervorgehoben werden, um ihre Verwendung als Fachausdruck zu kennzeichnen.
Überblick über das Dokument
• Welche Inhalte enthält der Rest des Pflichtenhefts?
Wie ist das Pflichtenheft aufgebaut?
Zweck des Produkts
Welcher Zweck wird mit diesem Produkt verfolgt, was sind die wichtigen Merkmale und die entscheidenden Vorteile gegenüber der bisherigen Situation?
Falls das Produkt ein früheres Produkt ersetzen wird, dann sollen hier die Gründe für die Neuentwicklung beschrieben werden.
Überblick über die geforderte Funktionalität
Hier soll ein Überblick darüber gegeben werden, was das zu erstellende Produkt seiner Umgebung gegenüber (z.B. menschlichen Benutzern oder anderen Systemen) leisten soll.
Diese Beschreibung soll gegenüber der detaillierten Produktbeschreibung in Kapitel 3 lediglich einen Überblick vermitteln.
Allgemeine Einschränkungen
Hier sollen die wesentlichen Vorgaben beschrieben werden, welche die Entwicklung und das Produkt einschränken (z.B. Vorgaben hinsichtlich Schnittstellen, Standards, Methoden).
Vorgaben zu Hardware und Software
• In welcher HW-Umgebung soll das Zielsystem laufen?
• In welcher SW-Umgebung soll das Zielsystem laufen?
• In welcher HW-Umgebung soll das System entwickelt werden?
• In welcher SW-Umgebung soll das System entwickelt werden (Betriebssysteme, Entwicklungstools, etc.)?
Benutzer des Produkts
• Hier soll charakterisiert werden, welche Benutzer das zu erstellende Produkt einsetzen werden (z.B. Ausbildung und Vorkenntnisse bei der Anwendung von Software und Computern).
• Dabei ist ggf. zu beachten, daß es verschiedene Benutzerklassen geben
Produktmerkmale
Jedes geforderte Merkmal sollte:
• eindeutig bezeichnet sein (Bezeichnung / Identifier)
• bei Bedarf priorisiert werden (Priorität / Priority), etwa in Hinsicht auf Ausbaustufen
• die Herkunft der Anforderung beinhalten (Ursprung / Origin), sofern es dabei Unklarheiten geben kann, wer etwas fordert
• sofern ein Lastenheft vorliegt, den Bezug zu den entsprechenden Anforderungen in diesem (möglichst mit Verweis auf eine eindeutige Bezeichnung) beinhalten (Quelle / Source);
wenn nicht zu allen Anforderungen im Lastenheft Bezüge herstellbar sind (im Falle von Einschränkungen der Funktionalität), so sollten auch Verweise auf solche Anforderungen im Lastenheft mit entsprechenden Hinweisen gemacht werden.
Abläufe

Hier sollen typische Abläufe beschrieben werden, wie ein (oder mehrere) Benutzer bzw. ein anderes System in der Umgebung des zu erstellenden Produkts mit diesem interagieren. Solche Abläufe werden oft auch als Szenarien bezeichnet.

• Alle vom Produkt durchzuführenden Aktionen müssen mittels entsprechender Funktionen realisiert werden können. Auf diese sollte so genau wie möglich und explizit verwiesen werden
• Alle Szenarien sollten ein oder mehrere Ziele verfolgen.
• Jedes der unten zu beschreibenden Ziele des Benutzers sollte durch mindestens einen Ablauf erreicht werden können.


Ziele des Benutzers

Hier sollen alle Ziele des Benutzers beschrieben werden, welche durch die in den Szenarien oben beschriebenen Interaktionen mit dem Produkt erreicht werden

Geforderte Funktionen des Produkts
Hier muß detailliert beschrieben werden, was das zu erstellende Produkt leisten soll (es geht dabei um eine Beschreibung aus Sicht der Reaktionen des Systems, wobei die Anforderungen aus den Abläufen abgebildet werden müssen).
Diese Beschreibung muß mit dem Überblick über die geforderte Funktionalität (in Kapitel 2) übereinstimmen.
Für die Beschreibung eignet sich üblicherweise eine hierarchische Gliederung der Funktionen (Funktionsbaum). Für die hierarchische Gliederung bieten sich grundsätzlich zwei Arten an:
1. Wenn auf allen Ebenen konkrete Funktionen beschrieben werden, geht es darum, die Teilfunktionen den übergeordneten zusammengesetzten Funktionen zuzuordnen.
(z.B. setzt sich die konkrete Funktion "Identifizierung eines Bankkunden" (unter anderem) aus den konkreten Funktionen "Aufforderung zum Eingeben eines Codes" und "Überprüfen eines eingegebenen Codes" zusammen.)
2. Wenn nur auf unterster Ebene konkrete Funktionen beschrieben werden, dann geht es darum, Klassen solcher Funktionen zu definieren und die konkreten Funktionen den entsprechenden Klassen zuzuordnen.
(z.B. enthält die Klasse von "Funktionen zur Identifizierung eines Bankkunden" durch einen Bankomaten die konkreten Funktionen "Aufforderung zum Eingeben eines Codes" und "Überprüfen eines eingegebenen Codes".)
Wenn eine zusammengesetzte Funktion (wie in diesem Beispiel "Identifizierung eines Bankkunden") bei Ihrer Durchführung Interaktionen mit dem Benutzer erfordert (hier das Eingeben des Codes), dann ist es möglicherweise günstiger, die hierarchische Gliederung gemäß der zweiten Art mittels Klassen von Funktionen durchzuführen. In diesem Fall sollte jede solche Klasse (im Beispiel "Funktionen zur Identifizierung eines Bankkunden") einen eigenen Unterabschnitt des Dokuments ausmachen, in dem die zugehörigen konkreten Funktionen beschrieben werden. Grundsätzlich ist es auch möglich und oft sinnvoll, zu solchen Klassen von Funktionen speziellere Unterklassen zu definieren, um eine tiefergehende hierarchische Gliederung zu erreichen.
Jede Beschreibung einer konkreten Funktion muß eine eindeutige Bezeichnung, eine Beschreibung (Wirk