Pflichtenheft

Das Pflichtenheft dient der genauen Definition von Anforderungen an eine Software.
Anhand des Pflichtenheftes kann beurteilt werden, ob eine Software die geforderten Merkmale in sich vereint. Dies ist wichtig, um z.B. spätere Rechtsansprüche geltend machen zu können.
In den seltensten Fällen ist ein Pflichtenheft in seiner ersten Version vollständig, da in komplexen Gebilden immer einige Dinge nicht bedacht werden. Es wird später außer bei sehr einfachen Produkten immer neue Anforderungen geben.

Übersicht
1. Zielbestimmung 1.1 Mußkriterien 1.2 Wunschkriterien 1.3 Abgrenzungskriterien 2. Produkt-Einsatz 2.1 Anwendungsbereiche 2.2 Zielgruppen 2.3 Betriebsbedingungen 3. Produkt-Umgebung 3.1 Software 3.2 Hardware 3.3 Orgware 3.4 Produkt-Schnittstellen 4. Produkt-Funktionen 4.1 Funktion 1 4.2 Funktion 2 5. Produkt-Daten 5.1 Daten 1 5.2 Daten 2 6. Produkt-Leistungen 7. Benutzungsoberfläche 8. Qualitäts-Zielbestimmung 9. Globale Testszenarien / Testfälle 10. Entwicklungs-Umgebung 11. Ergänzungen

Das Ergebnisdokument einer Anforderungsdefinition wird oft als Pflichtenheft bezeichnet. Aufgrund der Erfahrungen wurde ein verbales Pflichtenheftschema mit numerierten Anforderungen entwickelt, welches einfacher als das IEEE SRS-Schema ist. Der Einsatz in der industriellen Praxis hat gezeigt, daß in den meisten Fällen dieses Schema ausreichend ist. Im folgenden wird die Funktion des Pflichtenheftes zunächst definiert. Anschließend wird das verwendete Gliederungsschema erläutert.

Aufgabe:
Das Pflichtenheft enthält eine Zusammenfassung aller fachlichen Anforderungen, die das zu entwickelnde Software - Produkt aus der Sicht des Auftraggebers erfüllen muß. Adressaten: Auftraggeber(extern oder intern, z.B. Fachabteilung), Auftragnehmer repräsentiert durch den Projektleiter und die Systemanalytiker, Entwerfer, Qualitätskontrolle, Benutzerrepräsentant oder ausgewählte potentielle Benutzer.

Inhalt :
Fachlicher Funktions-, Daten-, Leistungs- und Qualitätsumfang des Produktes. Beschreibung des WAS, nicht des WIE. Das Pflichtenheft muß so abgefaßt sein, daß es als Basis eines juristischen Vertrages dienen kann. Das Pflichtenheft stellt also die vertragliche Beschreibung des Lieferumfangs dar. Anhand des Pflichtenheftes soll das fertige Produkt abgenommen werden können. Die beschriebenen Anforderungen sollen realistischer sein. Entwurfs- und Implementierungentscheidungen sollen nicht vorweggenommen oder unnötig eingeschränkt werden.

Form:
Vorgegebenes, standardisiertes, grobes Gleiderungsschema mit festgelegten Inhalten, um Pflichtenhefte gut lesen und vergleichen zu können.

Sprache :
Detaillierte verbale Beschreibung mit Numerierung einzelner Anforderungen. Die Numerierung von Anforderungen ist notwendig, um sich in anderen Dokumenten und späteren Phasen darauf beziehen zu können (Traceability).

Didaktik:
Das Gliederungsschema ist so aufgebaut, daß das Pflichtenheft gut lesbar ist und eine leichte Einarbeitung erlaubt. Die Erstellung selbst kann iterativ erfolgen.

Zeitpunkt:
Das Pflichtenheft ist das erste Dokument, das nach Abschluß der Planungsphase erstellt wird. Ergibt sich die Notwendigkeit, Anforderungen im Pflichtenheft zu ändern (neue Pflichenheftversion), dann sind diese Änderungen vom Auftraggeber schriftlich zu bestätigen.

Umfang:
Die notwendigen Anforderungen müssen in ausreichender Detaillierung und ausreichendem Präzisionsgrad beschrieben werden. Der Funktions- Daten- und Leistungsumfang muß aus Sicht des Benutzers bzw. Auftraggebers auf hinreichendem Abstraktionsniveau vollständig beschrieben sein. Im Pflichtenheft soll festgelegt sein, WAS das Produkt, bezogen auf Funktionen und Leistungen, erfüllen soll, nicht WIE es sie erfüllen soll.

1. ZIELBESTIMMUNG

1.1 Mußkriterien
1.2 Wunschkriterien
1.3 Abgrenzungskriterien

In diesem Kapitel wird beschrieben, welche Ziele durch den Einsatz des Produktes erreicht werden sollen. Um den Entscheidungsraum für die Realisierung abzustecken und um die Wahl von Realisierungsalternativen zu erleichtern, erfolgt die Zielbestimmung durch die Festlegung von Muß-, Wunsch- und Abgrenzungskriterien.

Unter Mußkriterien wird aufgeführt, welche Leistungen für das Produkt unabdingbar sind, damit es für den vorhergesehenen Einsatzzweck verwendet werden kann. Sie müssen auf jeden Fall erfüllt sein.

Wunschkriterien beschreiben Wünsche an das zu entwickelnde Produkt, die nicht unabdingbar sind, deren Erfüllung aber so gut wie möglich angestrebt werden sollte. Abgrenzungskriterien sollen deutlich machen, welche Ziele mit dem Produkt bewußt nicht erreicht werden sollen. Da die Wünsche an ein Produkt im allgemeinen sehr umfangreich und oft leicht formulierbar sind, soll dieser Abschnitt dazu dienen, Abgrenzungen des Produktes zu definieren.

2. PRODUKT - EINSATZ

2.1 Anwendungsbereiche
2.2 Zielgruppen
2.3 Betriebsbedingungen

Da der geplante Produkteinsatz wesentliche Auswirkungen auf die funktionale Mächtigkeit und auf die Qualitätsmerkmale hat, werden in diesem Abschnitt die Anwendungsbereiche, z.B. Textverarbeitung im Büro, und die Zielgruppen, z.B. Sekretärinnen, Schreibkräfte, definiert. Unter Umständen sollte auch festgelegt werden, von welchen Voraussetzungen, z.B. bezüglich des Qualifikationsniveaus des Benutzers, ausgegangen wird.

Ebenfalls kann es sinnvoll sein, explizit anzugeben, für welche Anwendungsbereiche und Zielgruppen das Produkt nicht vorgesehen ist, z.B. für den DV-unkundigen Benutzer. Deckt das Produkt verschiedene Anwendungsbereiche und Zielgruppen ab, dann ist eine Aufführung der unterschiedlichen Bedürfnisse und Anforderungen nötig.

Unter Betriebsbedingungen werden folgende Punkte beschrieben:

- physikalische Umgebung des Systems,
- tägliche Betriebszeit,
- ständige Beobachtung des Systems durch Bediener oder unbeaufsichtigter Betrieb.

3. PRODUKT - UMGEBUNG

3.1 Software
3.2 Hardware
3.3 Orgware
3.4 Produkt - Schnittstellen

In diesem Kapitel wir die Umgebung des Produktes beschrieben.

Unter Software wird angegeben, welche Software - Systeme (Betriebssystem, Laufzeitsystem, Datenbank, Fenstersystem usw.) auf der Zielmaschine (Maschine, auf der das fertiggestellte Produkt eingesetzt werden soll) zur Verfügung stehen. Unter Hardware wird aufgeführt, welche Hardware -Komponenten (CPU, Peripherie, z.B. Grafikbildschirm, Drucker) in minimaler und maximaler Konfiguration für den Produkteinsatz vorgesehen sind.

Unter Orgware wird aufgeführt, unter welchen organisatorischen Randbedingungen bzw. Voraussetzungen das Produkt eingesetzt werden soll (z.B. Elektronische Post ist nur dann sinnvoll, wenn die wichtigsten Empfänger organisatorisch und technisch In das elektronische Postsystem eingegliedert sind, d.h. ein LAN-Anschluß ist erforderlich.

Unter Produkt - Schnittstellen wird das Produkt in eine bestehende oder geplante Produkt - Familie eingeordnet oder die geforderte bzw. gemeinsam genutzte Schnittstellen zu anderen Produkten werden definiert, bzw. vereinbart (z.B. Schnittstelle zum Ferndiagnosesystem). Außerdem kann auf andere Produkte verwiesen werden, die denselben Anwendungsbereich abdecken, oder dieselbe Zielgruppe ansprechen.

4. PRODUKT - FUNKTIONEN

4.1 Funktion 1
4.2 Funktion 2 usw. ...

Unter Produktfunktionen erfolgt die funktionale Beschreibung des Produktes aus der Benutzersicht.

Diese Kapitel sollte in so viele Abschnitte gegliedert werden, wie das Produkt Funktionen oder Funktionsbereiche aufweist. Eine Funktion kann auch durch Aufgliederung in Unterabschnitte weiter verfeinert werden.

Es sollte hier besonders darauf geachtet werden, daß nicht das WIE, sondern ausschließlich das WAS definiert wird.

Innerhalb jeder Funktion sollen Einzelanforderungen in verbaler Form beschrieben werden . Jede Einzelanforderung ist durch eine vorangestellte Zahl mit vorangesetztem F, eingeschlossen in Schrägstriche, zu markieren (z.B. /F10W/), um eindeutige Referenzierungen zu erlauben..

Handelt es sich bei der Einzelanforderung um ein Wuschkriterium, dann wird hinter der Ziffer ein W gesetzt (s.o.).

Bei der Erstellung des Pflichtenheftes sollten die Anforderungen in Zehnerschritten durchnumeriert werden, um später Ergänzungen leichter einfügen zu können. Die Funktionsweise sollte unabhängig von einen bestimmten Bildschirm-Layout oder einer bestimmten Tastenbelegung beschrieben werden. Die Festlegung erfolgt erst im Kapitel 7 Benutzerschnittstelle.

Bei Produkten, welche keine Benutzeroberfläche besitzen, werden hier analog die Funktionen beschrieben, die das anwendende System benötigt.

5. PRODUKT-DATEN

5.1 Daten 1
5.2 Daten 2 usw. ...

Beschreibung der langfristig zu speichernden Daten aus Benutzersicht. Referenzierung: /D10/ usw.

6. PRODUKT-LEISTUNGEN

Unter Produkt-Leistungen werden alle Anforderungen aufgeführt, die Zeitbezogen oder umfangsbezogen sind, z.B. maximale Dialogantwortzeiten bei speziellen Funktionen, maximaler Datenumfang bzw. Datendurchsatz (Durchschnittswerte und Spitzenbelastungen), Genauigkeit bei numerischen Daten usw.

Die einzelnen Leistungsanforderungen werden analog wie die Funktionsanforderung numeriert, allerdings mit dem vorangestellten Buchstaben L (z.B. /L20/).

7. BENUTZUNGSOBERFLÄCHE

In diesem Kapitel werden grundlegende Anforderungen an die Benutzungsoberfläche festgelegt. In Abhängigkeit vom Produkt sollten folgende Gesichtspunkte berücksichtigt bzw. festgelegt werden :

- Bildschirmlayout
- Drucklayout
- Tastaturbelegung
- Dialogstruktur usw.

Die Festlegungen sollten sich auf die produktspezifischen Ausprägungen beschränken, die nicht durch das Qualitätsmerkmal in Kapitel 6 Qualitäts - Zielbestimmung abgedeckt wird. Die einzelnen Anforderungen werden analog wie die Funktionsanforderungen numeriert, allerdings mir dem vorausgesetzten Buchstaben B.

Bei Produkten, die keine Benutzungsoberfläche besitzen, werden hier analog die Schnittstellenkonventionen beschrieben, die für das anwesender System wichtig sind.

8. QUALITÄTS / ZIELBESTIMMUNGEN

In diesem Kapitel wird festgelegt, welche Qualitäts - Merkmale das zu entwickelnde Produkt in welcher Qualitätsstufe besitzen soll.

Voraussetzung für die Qualitäts - Zielbestimmung ist, daß die Qualitäts / Merkmale in operationalisierter Form vorliegen.

Die operationalisierten Qualitäts / Merkmale sind als Anhang dem Pflichtenheft beizufügen, wenn sie nicht als allgemeine Richtlinie (Standard, Werknorm) zur Verfügung stehen.

9. GLOBALE TESTSZENARIEN / TESTFÄLLE

9.1 Testfall 1
9.2 Testfall 2 usw. ...

In diesem Kapitel werden anwendungsbezogene Testfälle zusammengestellt, welche im allgemeinen mehrere Produkte / Funktionen in Anspruch nehmen.

Während die Testfälle pro Funktion aus den Funktionsanforderungen abgeleitet werden, sollten in diesem Kapitel globale Testfälle aufgeführt werden. Diese Testfälle sind dann für den Abnahmetest zu verwenden.

10. ENTWICKLUNGS - UMGEBUNG

10.1 Software
10.2 Hardware
10.3 Orgware
10.4 Entwicklungs - Schittstellen

In diesem Kapitel wird die Entwicklungs - Umgebung des Produktes beschrieben. Es wird festgelegt, welche Konfiguration bezüglich Software, Hardware und Orgware für die Entwicklung des Produktes benötigt wird. Diese Feststellung sind insbesondere dann notwendig, wenn Entwicklungs- und Zielmaschine unterschiedlich sind.

Bei Entwicklungs - Schnittstellen ist unter Umständen aufzuführen, über welche einzuhaltenden Hardware- und Software - Schnittstellen Entwicklungs- und Zielrechner gekoppelt sind.

Unter Software ist insbesondere aufzuführen, welche Software-Werkzeuge, z.B. Compiler usw. benötigt werden.

11. ERGÄNZUNGEN

In diesem Kapitel werden Ergänzungen oder spezielle Anforderungen beschrieben, die über die aufgeführten Kapitel 1 - 10 hinausgehen.

Beispielsweise können hier Installationsbedingungen festgelegt werden wie:

- bauliche und räumliche Voraussetzungen
- Bereitstellung von Testdaten
- Bereitstellung von Hilfspersonal

Außerdem können hier zu berücksichtigende Normen, Vorschriften, Patente und Lizenzen aufgeführt werden.

Oft ist es sinnvoll , alle im Pflichtenheft verwendeten Fachbegriffe zu definieren. Damit soll sichergestellt sein, daß eine einheitliche Terminologie auch in den späteren Phasen verwendet wird. Außerdem sollen dadurch Mißverständnisse von vornherein vermieden werden. Ein solches Glossar oder Begriffslexikon kann in diesem Kapitel oder im Anhang angelegt werden.

Quelle

Informatik-Unterricht BBS1 - Oldenburg (Neddermann)