Zielbestimmung
Im Rahmen der Zielbestimmung werden die Ziele des Produktes in einer Art Prioritätenliste exakt eingegrenzt, die in drei weitere Kategorien gegliedert ist, die als Muß-, Wunsch- und Abgrenzungskriterien bezeichnet werden. Zu den Mußkriterien zählen die Produktfunktionen, die für ein Funktionieren des Produktes unabdingbar sind. Ohne ihre Umsetzung geht einfach nichts, deshalb müssen sie erfüllt werden. Die nächste Kategorie, die Wunschkriterien, sind zwar entbehrlich, wurden aber ausdrücklich vom Auftraggeber gefordert. Ihre Umsetzung im Produkt ist also genauso eine Pflicht, wie die der ersten Kategorie, das Produkt würde aber auch ohne ihre Implementierung seinen Betrieb korrekt ausführen. Die letzte Kategorie von Kapitel 1 beschreiben die Abgrenzungskriterien. Sie sollen die Grenzen des Produktes klarmachen und sind von daher beinahe wichtiger als die beiden ersten Fälle denn sie hindern die Entwickler daran, über alle Ziele hinauszuschießen. Schreibt hier also genau die Punkte auf, die zwar in der Analyse irgendwo mal auftauchten, deren Umsetzung aber abgelehnt oder aufgeschoben wurde.
Produkteinsatz
Als nächstes stellt sich das Problem des Produkteinsatzes. Wir haben schon in den vergangenen Abschnitten der Analyse darauf hingewiesen, daß dem Umfeld der Anwendung große Beachtung geschenkt werden muss. Ein kleines Beispiel soll das erläutern. Software-Entwickler können auf ihrem Gebiet ebensolche Fachidioten (Entschuldigung für die grobe Ausdrucksweise, aber in dem Zusammenhang finde ich sie einfach angebracht um den Ernst der Situation klarer zu machen) sein, wie beispielsweise KFZ-Mechaniker wenn es um Motorpflege beim Auto geht. Sie heben sehr schnell in nicht mehr erreichbare Höhen ab, in denen sie von normalen EDV-Nutzern nicht mehr verstanden werden. So etwas kann sich sehr schnell auf ihre Programme auswirken, beispielsweise beim GUI-Design, wo dann viel zu viel Wert auf Funktionalität gelegt wird und die Benutzbarkeit für andere Nutzer auf der Strecke bleibt. Genau deshalb werden in diesem Kapitel die späteren Anwendungsbereiche, Zielgruppen und Betriebsbedingungen (physikalische Umgebung, tägliche Betriebszeit und ständige Beobachtung oder unbeaufsichtigter Betrieb) der Anwendung sehr genau definiert. Bei den Zielgruppen sollte auch auf das Qualifikationsniveau des Benutzers eingegangen werden.
Produktübersicht
Eine Übersicht über alle, die Anwendung betreffende, Geschäftsprozesse (Anwendungsfälle) in Form eines Anwendungsfall-Diagramms. Man ordnet alle mit dem Produkt umgesetzten Geschäftsprozesse untereinander an und ordnet ihnen die daran beteiligten Akteure zu. Eine Erklärung der einzelnen Anwendungsfälle folgt schließlich in Kapitel 4 mit den Produktfunktionen.
Produktfunktionen
Angelehnt an die Analyse der Aufgabenstellung wird nun für jede unterstützte Produktfunktion beschrieben, wie sie im Anwendungsfall abläuft, unter welchen Bedingungen sie aufgerufen wird, welche Akteure daran beteiligt sind und welche Auswirkungen sie auf andere Geschäftsprozesse hat. Die einzelnen Funktionen werden dabei nach folgendem Schema durchnummeriert: Die Darstellung der Ordnungsnummer erfolgt nach dem Schema "/Fxx/", wobei das "F" kennzeichnet, daß es sich hierbei um eine Produktfunktion handelt und "xx" die Nummer ist. Für sie gelten besondere Regeln, deren Einhaltung empfohlen wird. Nummeriert wird zunächst in 10er-Schritten in derselben Reihenfolge, wie die Produktfunktionen im Übersichtsdiagramm in Kapitel 3 bzw. der Prioritätenliste aus Kapitel 1 auftauchen. Bei der Nummerierung werden die Wunschkriterien durch ein "W", das auf das "F" folgt, gekennzeichnet. Die großen Abstände zwischen den Punkten dienen dazu, genug Platz zu lassen um im weiteren Verlauf der Entwicklung entstehende Anforderungen einfach einfügen zu können. Die Nummerierung selbst dient Referenzzwecken, damit man sich im weiteren Entwicklungsverlauf immer wieder auf die Punkte aus dem Pflichtenheft berufen kann, ohne jedesmal eine ellenlange Beschreibung machen zu müssen.
Produktdaten
Ich möchte den Leser an dieser Stelle darauf hinweisen, daß eine strikte Trennung zwischen Anforderung (Kap.4), Daten (Kap.5) und Funktionen der Benutzeroberfläche (Kap.8) vorgenommen wird. Bringt die Punkte dieser drei Kapitel nicht durcheinander. Kommen wir nun zu den Daten, worunter wir hier nur die langfristig (persistent) zu speichernden Informationen meinen. Zur Beschreibung gibt es zwei Wege. Als erstes natürlich wieder den verbalen Weg. Bezeichnet die Daten mit beschreibenden Namen (die Betonung liegt hier auf "beschreibend"! wir wollen an der Stelle keine kryptischen Variablenbezeichner wie m_strCWD sehen!) und erklärt in Worten die möglichen Inhalte des Datums und den dafür einzuplanenden Speicherplatzverbrauch. Die zweite Möglichkeit zur Beschreibung trifft besonders auf objektorientierte Entwicklungen zu. Hier reicht nämlich ein Klassendiagramm der Datenstrukturen mit einigen erläuternden Notizen zu jeder Klasse, was wieder den Speicherverbrauch etc. betrifft. Die Punkte dieses Kapitels sind wieder nach demselben Schema wie im letzten Abschnitt durchzunummerieren, nur das die Maske jetzt "/Dxx/" (natürlich steht das "D" für Daten) heißt.
Produktleistungen
Gibt es bezüglich einiger Produktfunktionen bestimmte Leistungsanforderungen (Zeit zur Ausführung, Genauigkeit der Berechnungen oder Datentransfervolumen und -dauer bei netzwerkfähigen Anwendungen), werden sie hier aufgelistet. Wie schon bei den letzten beiden Kategorien, werden sie zu Referenzzwecken durchnummeriert (Schema: "/Lxx/"). Ein paar Anmerkungen, ob die geforderten Leistungen mit denen in Kapitel 5 genannten Datenmengen auch erreicht werden können dürfen an dieser Stelle ebenfalls nicht fehlen.
Qualitätsanforderungen
In diesem Kapitel wird den Qualitätsmerkmalen Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit je eine Qualitätsstufe aus sehr gut, gut, normal und nicht relevant zugeordnet.
Benutzungsoberfläche
An dieser Stelle wird oft über alle möglichen Einzelheiten jedes noch so unwichtigen Dialogfensters der Anwendung geplaudert, was an dieser Stelle der Entwicklung noch gar nicht angebracht ist. Selbst das Benutzerhandbuch sollte noch nicht so detailliert sein, daß es alle Einzelheiten der Benutzeroberfläche kennt. Hierher gehören lediglich grundlegende Anforderungen, wie zum Beispiel die Art des Fensterlayouts, die Dialogstruktur und ob Mausbedienung gefordert wird oder nicht. Ein weiterer Punkt, der hier erwähnt werden sollte, ist die Art der Zugriffsrechte der einzelnen Charaktere (Endbenutzer, Akteure). Auch jetzt wird eine Nummerierung, diesmal nach dem Muster "/Bxx/", vorgenommen.
Nichtfunktionale Anforderungen
Hierher gehören alle Anforderungen an die zu erstellende Software, die nicht in die Kapitel 4, 5, 6 oder 7 einzuordnen sind. Balzert nennt auf Seite 117 die folgenden Beispiele:
- einzuhaltende Gesetze und Normen,
- Testat durch externe Prüfgesellschaft,
- Revisionsfähigkeit,
- Ordnungsmäßigkeit der Buchführung,
- Sicherheitsanforderungen, wie Passwortschutz, Mitlaufen von Protokollen und sichere Übertragungen sowie
- Plattformunabhängigkeiten.
Für die Durchführung des Praktikums sind davon lediglich die letzten 3 Fälle zu beachten.
Technische Produktumgebung
Dieser Abschnitt wird nochmal untergliedert in die Punkte Software, Hardware, Orgware und Produkt-Schnittstellen (wobei es bei Client/Server-Anwendungen zu einer weiteren Teilung kommt und der Client sowie die Serveranwendung getrennt betrachtet werden). Unter Software fallen alle Software-Systeme (Betriebssystem, Datenbanken, diverse Fenstersysteme, ...), die auf dem Zielsystem der Anwendung installiert sein müssen, damit sie korrekt funktionieren kann. Unter Hardware versteht man dasselbe, nur daß hier darauf eingegangen werden sollte, wie die Hardware-Konfiguration aussehen sollte, wenn das Produkt mit maximaler Last läuft. Unter den Punkt Orgware fallen alle organisatorischen Randbedingungen wie z.B. die Verfügbarkeit eines Netzwerkanschlusses wenn in das Produkt eine E-Mail Funktion eingebaut werden soll. Ohne diesen Anschluß hätte die Funktion nämlich überhaupt keinen Sinn. Soll das zu erstellende Produkt zur Laufzeit mit anderen Anwendungen in Verbindung treten, sollten diese und die genutzten Schnittstellen hier genannt (eine detaillierte Beschreibung kann im Anhang des Pflichtenheftes erfolgen) werden.
Spezielle Anforderungen an die Entwicklungsumgebung
Die Gliederung hier sieht der aus Kapitel 10 sehr ähnlich. Wir haben wieder Software, Hardware sowie Orgware, diesmal allerdings mit Bezug auf die Entwicklungsumgebung, zu beschreiben. Diese Angaben sind aber nur dann nötig, wenn an den Rechner für die Entwicklung des Produktes andere Anforderungen gestellt werden als an den für den Einsatz. Im Punkt Software sollten auch die zur Entwicklung des Produktes nötigen Software-Werkzeuge (CASE-Tools, Programmierumgebungen und Compiler) genannt werden. An die Stelle der Produkt-Schnittstellen treten jetzt aber die Entwicklungs-Schnittstellen, die beschreiben, über welche einzuhaltenden Hard- und Software-Schnittstellen Entwicklungs- und Zielmaschine gekoppelt sind.
Gliederung in Teilprodukte
Entwicklungen größeren Umfangs werden oft noch einmal in kleinere, überschaubarere Einheiten unterteilt damit man (sowohl die Entwickler als auch der Auftraggeber) nicht den Überblick verliert und schnell ein Fortschritt sichtbar wird. Diese Teilprodukte und die Funktionalität, die sie erfüllen sollen, werden hier genannt, bevor die Teilprodukte zueinander in Beziehung (Reihenfolge der Fertigstellung oder mögliche parallele Entwicklung) gesetzt werden. Laut Balzert beträgt die empfohlene Entwicklungsdauer für ein Teilprodukt ein halbes Kalenderjahr. Damit entfällt dieser Punkt für das Praktikum (wir wollten ihn aber aufgrund der Vollständigkeit trotzdem nennen).
Ergänzungen
Anforderungen an das Produkt, die in den vergangenen Kapiteln keinen Platz gefunden haben, werden hier aufgeführt. Dazu zählen beispielsweise spezielle Installationsbedingungen, zu berücksichtigende Normen, Vorschriften, Patente und Lizenzen.
Globale Testfälle
In diesem Abschnitt sollen die wichtigsten Testfälle festgehalten werden, die den größten Teil der Produkt-Funktionen abdecken. Erst wenn diese "globalen" Testfälle erfüllt sind und fehlerfrei funktionieren, kann man daran denken, das Produkt als fertig zu deklarieren. Sie werden im Pflichtenheft festgehalten, damit man nach der Implementierung das reale Programm mit den Anforderungen abgleichen kann. Sie sollten klar voneinander abgrenzbar sein, und jeweils nur einen Teilbereich abdecken. Es macht keinen Sinn alle möglichen Funktionen in einen Testfall zu packen. Dieser wäre nur mit sehr viel Arbeitsaufwand zu überprüfen. Die Testfälle sind stark von der Anwendung abhängig und lassen sich nicht allgemein formulieren. In einer Salespoint-Anwendung werden dies meist Kundengeschäfte oder Management-Tätigkeiten sein.