Pflichtenheft

Aufbau Kurzform

Zielbestimmungen

In diesem Abschnitt werden die Ziele definiert, die das zu realisierende System erfüllen muss / kann. Es werden dabei folgende Unterscheidungen getroffen:

=Muss – Kriterien

Führen Sie hier alle Ziele auf, die vom System unbedingt erfüllt werden müssen. (Hinweis: Kann eines der hier aufgeführten Ziele nicht erfüllt werden, dann ist das ganze System für den vorgesehenen Zweck nicht einsetzbar.)

Kann – Kriterien

Führen Sie hier alle Ziele auf, die das System zwar erfüllen sollte, auf die aber zunächst verzichtet werden kann.

Abgrenzungskriterien

Nennen Sie hier die Ziele, die von dem System bewusst nicht erreicht werden sollen, die aber in vergleichbaren Systemen durchaus vorkommen können.

Einsatz

Anwendungsbereiche

Wo kommt das System zum Einsatz?

Zielgruppen

Nennen Sie hier mögliche Zielgruppen für das System

Betriebsbedingungen

Beschreiben Sie hier die Betriebsbedingungen, z. Bsp. beaufsichtigter / unbeaufsichtigter Betrieb, physikalische Umgebung u.s.w.

Umgebung

Software

Nennen Sie hier die Software, die für den Betrieb zur Verfügung stehen muss (einschließlich der Versionsnummern).

Hardware

Beschreiben Sie hier die (minimalen) Hardwarevoraussetzungen.

Orgware

Beschreiben Sie hier organisatorischen Voraussetzungen / Schritte müssen erfüllt sein bzw. unternommen werden?

Schnittstellen

(falls vorhanden)

Funktionalität

In diesem Abschnitt werden die Funktionalitäten, die das System erfüllen soll beschrieben.

Daten

langfristig zu speichernde Daten und deren Umfang.

Leistungen

Nennen Sie hier alle zeitlichen Anforderungen an das System.

Benutzungsoberfläche

(entfällt im Netzwerkbereich)

Qualitätsziele

Nennen Sie hier Qualitätsziele für das System, z. Bsp. größtmögliche Sicherheit

Testszenarien

Nennen und beschreiben Sie hier Testszenarien, die die Gesamtfunktion (oder zumindest mehrere Einzelfunktionen) überprüfen und die zu Abnahmezwecken verwendet werden können.

Ausführlich

Zielbestimmung

Formulieren Sie Ziele (z.B. Mindestabstand von Artikeln automatisch sicherstellen) und nicht die für deren Erreichung notwendigen Funktionen (z.B. Erstellung von Bestellvorschlagslisten für Artikel, deren Mindestbestand unterschritten ist). Oft wird ein Ziel durch eine Funktion realisiert. Dann ist die Abgrenzung unter Umständen schwierig

Muss-Kriterien

Nennen Sie alle Ziele die das Softwaresystem unbedingt erfüllen muss. Kann eines der Muss-Kriterien nicht realisiert werden, dann ist das ganze System für den vorgesehenen Zweck nicht einsetzbar.

Beispiel:

Bei einem Werkzeug zur Erstellung von OO-Modellen sind folgende Muss-Kriterien sinnvoll:
- Unterstützung der UML-Notation
- Mehrbenutzerfähigkeit
- Automatische Erstellung der Dokumentation.

Kann-Kriterien

Nennen Sie hier diejenigen Ziele, die das Produkt zwar erfüllen sollte, auf die aber zunächst verzichtet werden kann. Diese Abgrenzung ist ein wichtiges Instrument der Projektplanung. Bei Terminproblemen ist somit eine Konzentration auf die Muss-Kriterien möglich.

Beispiel:

Bei einem Buchhaltungsprogramm ist das automatische Erstellen einer Umsatzsteuer-Voranmeldung ein Muss-Kriterium.
Das Ausdrucken dieser Voranmeldung auf einem von den Finanzämtern genehmigten Formular stellt ein Kann-Kriterium
dar, weil der Benutzer das Programm auch ohne diese Funktionalität benutzen kann und nur die Programmdaten
handschriftlich auf ein Formular übertragen muss.

Abgrenzungskriterien

Machen Sie deutlich, welche Ziele mit dem Produkt bewusst nicht erreicht werden sollen, die aber in vergleichbaren Anwendungen durchaus vorkomme.

Beispiel:

Bei einem Werkzeug zur Erstellung von OO-Modellen erfolgt keine automatische Optimierung bei der 
Darstellung von Diagrammen

Einsatz

Die Analyse des Einsatzes liefert wichtige Informationen für die Benutzungsoberfläche und die Qualitätsanforderungen des zukünftigen Systems.

Anwendungsbereiche

z.B. Buchhaltung von Unternehmen

Zielgruppen

z.B. Buchhalter

Betriebsbedingungen

Dazu gehören Angaben über

• die physikalische Umgebung des Softwaresystems (z.B. Büroumgebung)
• die tägliche Betriebszeit (z.B. 8 Stunden) und
• ob eine ständige Beobachtung des Softwaresystems durch den Bediener oder ein unbeaufsichtigter Betrieb vorliegt.

Umgebung

Software

Welche Softwaresysteme (einschließlich Versiensnummern) müssen für den Betrieb zur Verfügung stehen? Wenn das Produkt nicht als stand-alone-Produkt geplant ist, so sind die geplanten Schnittstellen zu anderen Softwareprodukten aufzuführen.

Hardware

Welche Hardware-Voraussetzungen müssen für den Betrieb erfüllt sein?

Orgware

Welche organisatorschien Voraussetzungen müssen für den Betrieb gegeben sein? Welche organisatorischen Schritte müssen durchgeführt werden, damit das Softwaresystem eingesetzt werden kann?

Beispiel:

Vor dem Einsatz eines Buchhaltungsprogramms muss zunächst von einem Buchhalter ein Kontenplan 
für das Unternehmen erstellt werden.

Funktionalität

Die Funktionalität des Systems ist auf oberster Abstraktionsebene zu beschreiben. Das bedeutet, dass die typischen Arbeitsabläufe, die mit dem zu erstellenden System durchgeführt werden sollen, zu nennen sind. Zu diesem führen Zeitpunkt ist noch nicht abzusehen, ob diese Arbeitsabläufe vollständig durch Software realisiert werden oder auch organisatorische Schritte beinhalten. Ein Arbeitsablauf soll immer zu einem Ergebnis für den Bediener führen. Das bedeutet, dass nicht mehrere Arbeitsabläufe kombiniert werden müssen, um ein Ergebnis zu halten. Die hier beschriebenen Arbeitsabläufe bilden die Grundlage für die im Rahmen der objektorientierten Analyse erstellten Geschäftsprozesse.

Informationssysteme enthalten im allgemeinen eine Reihe von Verwaltungsfunktionen, z.B. Erfassen eines neuen Artikels, Aktualisieren der Artikeldaten, Löschen alter Artikel aus dem System. Diese Funktionalität ist hier nicht aufzuführen.

Außerdem erstellen viele Informationssysteme eine Reihe von Reports, Berichten etc., von denen die wichtigsten hier aufzuführen sind. Auf Funktionen, die nur elementare Listen (z.B. Liste aller Artikel) erstellen, ist jedoch zu verzichten.

Bei der Formulierung dieses Kapitels ist zu berücksichtigen, dass hier die Basis für das spätere OOA-Modell gelegt werden soll, und dass keine vollständige textuelle Beschreibung der funktionalen Anforderungen verlangt wird.

Daten

Die langfristig zu speichernden Daten und deren voraussichtlicher Umfang sind aus Benutzersicht aufzuführen.

Beispiel:

- 50.000 bis 200.000 Artikel
- 3000 Kunden

Leistungen

Führen Sie alle zeitlichen Anforderungen auf. Quantifizieren Sie alle Angaben, z.B. max. 2 Sekunden für das Auffinden eines Artikels. Überlegen Sie, ob die gewünschte Leistungen mit den in Kapitel 5 genannten Datenmengen und der in Kapitel 3.2 aufgeführten Hardware erreicht werden können.

Benutzungsoberfläche

Formulieren Sie grundlegende Anforderungen an die Benutzungsoberfläche. Berücksichtigen Sie die jeweiligen Eigenschaften der zukünftigen Benutzer und die voraussichtliche Art der Benutzung. Die genaue »Spezifikation« der Benutzungsoberfläche erfolgt durch den Prototyp.

Beispiel:

Außerdem erstellen viele Informationssysteme eine Reihe von Reports, Berichten etc., von denen die wichtigsten 
hier aufzuführen sind. Auf Funktionen, die nur elementare Listen (z.B. Liste aller Artikel) erstellen, ist 
jedoch zu verzichten.

Bei der Formulierung dieses Kapitels ist zu berücksichtigen, dass hier die Basis für das spätere OOA-Modell gelegt werden soll, und dass keine vollständige textuelle Beschreibung der funktionalen Anforderungen verlangt wird. [Bearbeiten] 5 Daten

Die langfristig zu speichernden Daten und deren voraussichtlicher Umfang sind aus Benutzersicht aufzuführen.

Beispiel:

Ein Buchhalter, der täglich mehrere hundert Buchungssätze eingibt, benötigt eine andere Benutzungsoberfläche
als ein Freiberufler, der monatlich seine Umsatzsteuer-Voranmeldung mit einem Buchhaltungsprogramm erstellt.

Qualitätsziele

Welche Qualität soll das neue Softwaresystem besitzen? Beispielsweise wird eine hohe Portabilität benötigt, wenn das Softwaresystem auf verschiedenen Plattformen laufen soll. Bei den meisten Softwareprodukten sind Änderbarkeit und Wartbarkeit wichtige Qualitätsziele.

Ergänzungen

Wenn die bisherigen Kapitel nicht ausreichen, um die Anforderungen an ein Softwaresystem zu beschreiben, dann kann das Pflichtenheft individuell erweitert werden.