ProgrammierPraktikum SS99

Das Pflichtenheft

Das Pflichtenheft ist 'das Ergebnisdokument einer Anforderungsdefinition.' Es ist verbal, aber mehr oder weniger streng formalisiert, und dient häuftig als Vertragsgrundlage zwischen Kunde und Softwarehersteller. Hat man bereits ein Lastenheft erstellt, kann man dies sinnvoll zum Pflichenheft fortschreiben (wir machen genau das mit dem Lastenheftschema). Genauer beschreiben läßt sich ein Pflichtenheft mit den Eigenschaften
Adressaten
Kunde oder Kunden/Benutzerrepräsentant einerseits, Softwareproduzent durch Projektleiter/Systemanalytiker andererseits.
Aufgabe
Enthält alle fachlichen Anforderungen an der Produkt aus Sicht des Auftraggebers.
Inhalt
Beschrieben wird was geleistet werden soll, nicht wie die Leistung entsteht. Festgelegt werden muß der gesamte fachliche Funktions- , Daten-, Leistungs- und Qualitätsumfang. Das Pflichtenheft muß Grundlage eines Vertrages sein können, d.h. anhand der hier beschriebenen Forderungen muß das Endprodukt abgenommen werden können.
Form
Die Form folgt einer standardisierten Gliederung. Die Aufgaben werden verbal detailliert beschrieben. Die Einzelpunkte werden für spätere Bezüge sauber numeriert.
Lesbarkeit
Das Pflichtenheft sollte gut lesbar sein und damit eine leichte Einarbeitung in das Projekt ermöglichen. So sollten z. Bsp. Mitarbeiter, die später zum Projet dazustossen, nach lesen des Pflichteheftes in der Lage sein im Projekt ohne grössere Schwierigkeiten mitzuarbeiten.
Zeitpunkt
Das Pflichtenheft ist das erste Dokument nach der Planungsphase. Die Erstellung erfolgt iterativ. Nach der Fertigstellung erfolgen ggf. notwendige Änderungen, aber nur nach Absprache und ggf. Zusatzvertrag mit dem Kunden.
Umfang
Der Leistungsumfang muß aus Sicht des Auftraggebers auf hinreichendem Abstraktionsniveau detailliert genug beschrieben werden können. Der Umfang ist also nicht beschränkt. Andererseits ist ein zu langes Pflichtenheft nicht mehr lesbar.
Ein mögliches Plichtenheftgliederungsschema folgt. Die dort aufgeführten Beispiele geben im Fließtext die Zuordnung der Sätze zur Gliederung an, für ein Pflichtenheft müßten sie bei den entsprechenden Punkten aufgestellt sein.

Plichtenheftschema

(Das Schema ist auch ohne Anmerkungen zu haben)
  1. Zielbestimmung:
    1. Mußkriterien
    2. Sollkriterien
    3. Muß-Nicht-Kriterien
    Im Unterschied zum Lastenheft wird genau zwischen unbedingten und wünschenswerten Leistungen unterschieden. Außerdem wird festgelegt, welche Anforderungen der Produkt nicht notwendig erfüllen sollte oder muß.
    Beispiel:
    Ein geplantes Textverarbeitungsprogramm (1) muß Silbentrennung beherrschen, (2) Rechtschreibcheck und -korrektur ist wünschenswert, und (3) beides muß in Spezialfällen nicht automatisch funktionieren, es kann dann interaktiv nachgefragt werden.

  2. Produkteinsatz
    1. Anwendungsbereiche
    2. Zielgruppen
    3. Betriebsbedinungen
    Beispiel:
    (1)Die o.g. Textverarbeitung soll im Redaktionsbetrieb einer Zeitung (Büro) eingesetzt werden. (2) Sie wird von den Redakteuren bedient, die EDV-kundig sind, aber bislang nur DROW-3 benutzt haben. (3) Das Produkt wird von einer EDV-Systemgruppe installiert und vollzeit-betreut.

    Beispiel:
    Eine Software ist (1) für Geldautomaten vorgesehen. (2) Die Bedienung erfolgt durch Benuter alle Art. (3) Die Software wird nicht vor Ort gepflegt. Sie muß nach Installation im 24h-Betrieb funktionieren, Die Eingaben sind durch den Automaten beschränkt.

  3. Produktumgebung
    1. Software
    2. Hardware
    3. Orgware
    4. Schnittstellen
    Beispiel:
    Die Textverarbeitung soll von den Redakteuren (2) auf Rechnern mit Intel-Prozessoren unter (1) dem Betriebssystem OS/2 mit üblichem Umfeld: (2) Maus, Keyboard, Farbmonitor in SVGA-Auflösung. Die Ausgabe erfolgt zunächst auf (2) HP5-kompatiblen Laserduckern und dann auf (2) einer Satzmaschine der Fa. Linotype mit den dort beschafften Zeichensätzen (in 1200dpi). Damit der Datentransport zur Satzmaschine sinnfoll erfolgen kann, müssen die Redakteursrechner über (3) Ethernet mit der Satzmaschine verbunden sein. Das erleichtert auch die verteilte Datenhaltung der Lexika und der fertigen Artikel auf einem (3) Server. Die Software sollte (4) Daten aus dem Office-Paket übernehmen können, und Bilder aus (4) Adobe-Photoshop.

  4. Produktfunktionen
    1. Funktion 1
    2. Funktion 2
    3. ...
    Hier ist darauf zu achten, Muß-Funktionen und Soll-Funktionen deutlich zu kennzeichen. Größerer Einzelfunktionen sind mit sauberer Untergliederung genauer durch Unterfunktionen zu beschreiben. Hier sollte also pro Punkt eine gewünschte Funktion (die später im Programm so zur Verfügung steht) mit einem Satz beschrieben werden.
    Beispiel:
    Der (1) Erfassen von Texten mit (2) Bildern ist notwendig. (3W) Freies Positionieren der Bilder ist wünschenswert. Zur Texterfassung soll (1.1) Blockmarkierung und Behandlung mit der Maus möglich sein. ...

  5. Produktdaten
    1. Daten 1
    2. Daten 2
    3. ...
    Wie bei den Funktionen wenn nötig genauere Untergliederung vornehmen.
    Beispiel:
    (1) Die fertigen Artikel müssen in komprimierter, aber einfach referenzierbarer Form archiviert werden.

  6. Leistungen:
    Ggf. sind besonderer Leistungsdaten festzuhalten. Nummerierung wie oben.
    Beispiel:
    Bei der Silbentrennung sollte die Fehlerrate nicht über 0.5% liegen.

  7. Benutzeroberfläche:
    Bildschirmlayout, ggf. Tastaturmakros, Drucklayout Dialogstruktur etc. werden hier festgelegt.
    Beispiel:
    (1) Die Gesamtseite muß auf dem Monitor dargestellt werden können. (2) Die Anweisungen zum Satz, Druck erc. sollen über Fall-Down-Menüs mit Windows96-Look&Feel gehandhabt werden.

  8. Qualitätsziele:
    Hier muß in meßbarer Form niedergelegt werden, welche Qualitätsbedingungen das Produkt erfüllen muß.
    Beispiel:
    (1) Bei Störungen im Netzwerk dürfen keine Daten verlorengehen. (2) Datenverlust darf nicht bei einer einzigen Fehlbedienung auftreten.

  9. Testszenarien/Testfälle:
    1. Test1
    2. Test 2
    3. ...
    Hier sind Testszenarien vorzustellen, die die Gesamtfunktion (oder zumindest mehrere Einzelfunkionen) überprüfen und zu Abnahmezwecken verwendet werden können.
    Beispiel:
    (1) Zum Test des verlangten Umgangs mit Netzstöruungen wird ein Arbeitsplatz während einer Artikelerstellung vom Netz getrennt. Es dürfen keine Daten verlorengehen, und die Daten sollten transparent an einem anderen Arbeitsplatz weiterbearbeitet werden können. (2) ...

  10. Entwicklungsumgebung:
    1. Software
    2. Hardware
    3. Orgware
    4. Schnittstellen
    Entwicklungshard- und Software ist festzulegen, sofern sie nicht mit der Zielhardware übereinstimmt. Für die Entwicklung benötigte (Software-)Hilfsmittel wie Compiler etc. sollten aufgeführt werden.
    Beispiel:
    Entwickelt wird unter und für das (1) Betriebssystem Windows95 auf Rechnern der (2) Intel-Pentium-Architektur. Es wird ein InterData-C-Compiler und die Internetsoftware Explorer-X.3 benutzt. Als Ersatz für die Linotype wird eine Simulationshardware eingesetzt, deren Programmierung durch den Softwareanbieter nach Handbüchern zu erstellen ist. ... Für Testzwecke steht ein (2) üblicher Zielarbeitsplatz zur Verfügung, und in Freizeiten darf nach Absprache bis zu 100h gesamt auf die Satzmaschine zugegriffen werden.

  11. Ergänzungen:
    Besondere Absprachen, die nicht durch die vorangehenden Punkte abgedeckt sind.
    Beispiel:
    Zur Installation steht der Ostersonntag zur Verfügung, bei Problemen ggf. noch der Vormittag des Ostermontags zur Verfügung. Am Ostermontag-Nachmittag muß der Betrieb des alten oder neuen Systems bei einer Konventionalstrafe von DM 180000 gewährleistet sein.




[vorige Seite] [nächste Seite] [Inhalt] [Literatur] [Stichworte]
Dietmar Lammers
Last modified: Fri Apr 30 13:32:43 MET DST 1999