C MusterPflichtenheftKT001

Titelblatt

Grau unterlegte Felder sind unter Datei  Eigenschaften vereinbart!!!!

Muster Pflichtenheft

Dok-Nr.: FMB001

Dok-Name: FMB001aa.doc

Autor: Arthur ****

I n h a l t

1. Änderungen/Ergänzungen

====Abstract Dieses Dokument enthält das Muster eines Pflichtenheftes. Die Gliederung und der erklärende Text ist /1/: Balzert, H.: Lehrbuch der Software-Technik. Band 1. Heidelberg 2000/ entnommen.

Definitions/Abbreviations
Abkürzungen und Definitionen sind zu erläutern.

Hinweis auf weitere Dokumente/Files

 * verwendete Handbücher
 * Hinweis auf Bücher
 * Hinweis auf z.B. Web-Adressen
 * Hinweis auf spez. Software
 * usw. .......

Abgrenzungskriterien
In diesem Kapitel wird beschrieben, welche Ziele durch den Einsatz des Produkts erreicht werden sollen. Um den Entscheidungsraum für die Realisierung abzustecken und um die Gliederung in Teilprodukte zu erleichtern, erfolgt die Zielbestimmung durch die Festlegung von Muss, Wunsch und Abgrenzungskriterien. Unter Musskriterien wird aufgeführt, welche Leistungen für das Produkt unabdingbar sind, damit es für den vorgesehenen Einsatzzweck verwendet werden kann. Sie müssen auf jeden Fall erfüllt werden.

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 bewusst 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 Produkts zu definieren.

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 nichtvorgesehen 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, z.B. Büroumgebung, Produktionsanlage oder mobiler Einsatz,

- tägliche Betriebszeit, z.B. Dauerbetrieb bei Telekommunikationsanlagen,

- ständige Beobachtung des Systems durch Bediener oder unbeaufsichtigter Betrieb.

Produktübersicht
Gibt eine Übersicht über das Produkt, z.B. über alle wichtigen Geschäftsprozesse in Form eines Übersichtsdiagramms.

Produktfunktionen
In Abhängigkeit von den gewählten Konzepten erfolgt hier eine Konkretisierung und Detaillierung der Funktionen aus dem Lastenheft.

Wurde beispielsweise im Lastenheft die Funktionalität durch verbal beschriebene Geschäftsprozesse definiert, dann kann hier eine Detaillierung erfolgen, z.B.

unter Verwendung einer Geschäftsprozess Schablone. Die Produktfunktionen können gegliedert werden nach:


 * Geschäftsprozessen
 * Listen
 * Reports

Erfolgt die Beschreibung der Funktionen mit einem CASE-Werkzeug, dann reicht es aus, nur den Namen der Funktion und einen Verweis auf das mit dem CASE-Werkzeug erstellte Artefakt anzugeben.

Produktdaten
Die langfristig zu speichernden Daten sind aus Benutzersicht detaillierter zu beschreiben.

Im einfachsten Fall erfolgt eine verbale Beschreibung. Es bietet sich jedoch auch an, eine formale Beschreibung, z.B. in Form eines Data Dictionary, vorzunehmen, um eine größere Präzision zu erreichen.

Bei einer objektorientierten Software-Entwicklung kann die Daten-Spezifikation auch als Attribut-Spezifikation im Klassen-Diagramm erfolgen. Vom Pflichtenheft aus ist dann auf das entsprechende Klassen-Diagramm zu verweisen.

Unabhängig von der verwendeten Methode sollten die Produktdaten jedoch im Pflichtenheft grob untergliedert und mit Namen benannt werden, z.B. Kundendaten bestehen aus: Kunden-Nr., Name, Adresse, Kommunikationsdaten, Geburtsdatum, Funktion, Umsatz, Kurzmitteilung, Notizen, Info-Material, Kunde seit. Name, Adresse usw. sind hier nicht weiter aufzugliedern, da diese Verfeinerungen in der Regel in den CASE-Werkzeugen zur Wiederverwendung zur Verfügung stehen und nicht jeder Systemanalytiker diese Begriffe neu definieren soll.

Das Mengengerüst bei den Daten ist bei Bedarf zu ergänzen, beispielsweise um Durchschnittswerte und Spitzenbelastungen beim Datendurchsatz usw.

Produktleistungen
Werden an einzelne Funktionen und Daten Leistungsanforderungen bzgl. Zeit oder Genauigkeit gestellt, dann werden sie hier aufgeführt und mit /Lnn/ markiert. Zu prüfen ist, ob die gewünschten Leistungen mit den in 5 genannten Datenmengen erreicht werden können.

Bei netzwerkfähigen Anwendungen ist der Datentransfer über das Netz zu schätzen.

Qualitätsanforderungen
In diesem Kapitel wird festgelegt, welche Qualitätsmerkmale das zu entwickelnde Produkt in welcher Qualitätsstufe besitzen soll.

Voraussetzung für die Qualitäts-Zielbestimmung ist, dass die Qualitätsmerkmale in operationalisierter Form vorliegen.

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

Gibt es in einem Unternehmen einen festgelegten Qualitätsstandard für alle Produkte, dann sind hier nur Abweichungen davon aufzuführen und zu begründen.

Benutzungsoberfläche
In diesem Kapitel werden grundlegende Anforderungen an die Benutzungsoberfläche festgelegt, z.B. Fensterlayout, Dialogstruktur und Mausbedienung

entsprechend dem Windows-Gestaltungs-Regelwerk (style guide) oder unternehmenseigenen Gestaltungs-Regelwerken.

Die Festlegungen sollten sich auf die produktspezifischen Ausprägungen beschränken. Details werden durch Prototypen oder Pilotsysteme spezifiziert.

Gibt es verschiedene Rollen, die das Produkt benutzen, z.B. Kundensachbearbeiter und Seminarsachbearbeiter, dann sind für jede Rolle die Zugriffsrechte, differenziert nach Lese- und Schreibrechten, aufzuführen.

Die einzelnen Anforderungen werden analog wie die Funktionsanforderungen nummeriert, allerdings mit dem vorangesetzten Buchstaben B.

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

Nichtfunktionale Anforderungen
Es werden alle Anforderungen aufgeführt, die sich nicht auf die Funktionalität, die Leistung und die Benutzungsoberfläche beziehen, z.B.


 * einzuhaltende Gesetze
 * einzuhaltende Normen
 * Testat durch externe Prüfungsgesellschaft
 * Revisionsfähigkeit
 * Ordnungsmäßigkeit der Buchführung
 * Sicherheitsanforderungen, z.B. Passwortschutz, Mitlaufen von Protokollen, sichere Übertragung
 * Plattformabhängigkeiten

Produkt-Schnittstellen
In diesem Kapitel wird die technische Umgebung des Produkts beschrieben. Bei Client/Server-Anwendungen ist die Umgebung jeweils für Clients und Server getrennt anzugeben.

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, z.B. WebBrowser auf dem Client.

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 einsetzbar, wenn die wichtigsten Empfänger organisatorisch und technisch in das elektronische Postsystem eingegliedert sind, d.h. ein LAN Anschluss ist erforderlich«).

Unter Produkt-Schnittstellen wird das Produkt in eine bestehende oder geplante Produkt-Familie eingeordnet oder die geforderten bzw. genutzten Schnittstellen zu anderen Produkten, z.B. Office-Familie von Microsoft, werden definiert bzw. vereinbart (z.B. Schnittstelle zum Ferndiagnosesystem).

Entwicklungs-Schnittstellen
In diesem Kapitel wird die Entwicklungs-Umgebung des Produkts beschrieben. Es wird festgelegt, weiche Konfiguration bzgl. Software, Hardware und Orgware für die Entwicklung des Produkts benötigt wird. Diese Festlegungen sind insbesondere dann notwendig, wenn Entwicklungs- und Zielmaschine unterschiedlich sind.

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

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

Gliederung in Teilprodukte
Das Produkt wird in Teilprodukte aufgeteilt, die getrennt - aus Sicht des Auftraggebers - entwickelt werden sollen. Die Funktionalität wird den einzelnen Teilprodukten zugeordnet. Die Teilprodukte werden in eine Rangfolge gebracht, die die Realisierungsreihenfolge festlegt.

Jedes Teilprodukt sollte einen Umfang besitzen, der in maximal einem halben Kalenderjahr realisierbar ist.

Ergänzungen
In diesem Kapitel werden Ergänzungen oder spezielle Anforderungen beschrieben, die über die aufgeführten Kapitel 1 bis 12 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.