Pflichtenheft: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Der Seiteninhalt wurde durch einen anderen Text ersetzt: „*Kurzform *Ausführlich“)
 
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
=Aufbau Kurzform=
+
*[[Kurzform]]
==Zielbestimmungen==
+
*[[Ausführlich]]
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.
 
==Ergänzungen==
 
=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:
 
<pre style="color:blue">
 
Bei einem Werkzeug zur Erstellung von OO-Modellen sind folgende Muss-Kriterien sinnvoll:
 
- Unterstützung der UML-Notation
 
- Mehrbenutzerfähigkeit
 
- Automatische Erstellung der Dokumentation.
 
</pre>
 
 
 
===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:
 
<pre style="color:blue">
 
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.
 
</pre>
 
 
 
===Abgrenzungskriterien===
 
 
 
Machen Sie deutlich, welche Ziele mit dem Produkt bewusst ''nicht'' erreicht werden sollen, die aber in vergleichbaren Anwendungen durchaus vorkomme.
 
 
 
Beispiel:
 
<pre style="color:blue">
 
Bei einem Werkzeug zur Erstellung von OO-Modellen erfolgt keine automatische Optimierung bei der
 
Darstellung von Diagrammen
 
</pre>
 
 
 
==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:
 
<pre style="color:blue">
 
Vor dem Einsatz eines Buchhaltungsprogramms muss zunächst von einem Buchhalter ein Kontenplan
 
für das Unternehmen erstellt werden.
 
</pre>
 
 
 
==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:
 
<pre style="color:blue">
 
- 50.000 bis 200.000 Artikel
 
- 3000 Kunden
 
</pre>
 
 
 
==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:
 
<pre style="color:blue">
 
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.
 
</pre>
 
 
 
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:
 
<pre style="color:blue">
 
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.
 
</pre>
 
 
 
==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.
 

Aktuelle Version vom 31. Januar 2013, 14:01 Uhr