um euch einen Anhaltspunkt zu geben, wie der erste Abschnitt des Projekts (das Pflichtenheft) bewertet wird, hier eine Liste der wichtigsten Inhalte.
Es kann sein, dass Auftraggeberwünsche davon abweichen. Dann bekommen wir (mindestens) die hier genannten Bestandteile und die Auftraggeber was sie sehen wollen. Abweichungen von dieser Liste können natürlich Auftreten, bedürfen aber der Begründung (Beispiel: bei nicht vorhandener Benutzerschnittstelle brauchen keine Bildschirmphotos davon gemacht werden. Dies sollte aber trotzdem zumindest im Dokument erwähnt sein).
Bei Unklarheiten, ist das kommende Steering Committe (Nummer 2) auch für euch eine Platform zur Klärung.
Generell werden wir anschliessend noch einmal detailiertes Feedback zu jeder Gruppe in einem gesonderten Termin geben. Grundlage werden hier die von euch zu diesem SC abgegebenen Vorabversionen der Pflichtehefte sein.
Hinweis: Die augelisteten Bestandteile des Pflichtenheftes spiegeln keine Kapitelstruktur wider, wobei einige Bestandteile offensichtliche Kandidaten für gleich lautende Kapitel sind.
- Istzustand
Knappe, ausformulierte Beschreibung der Problemstellung und wie sie zur Zeit gelöst wird. Ggf. die Feststellung, dass das Problem derzeit nicht gelöst wird - Sollzustand
Knappe, ausformulierte Beschreibung des Sollzustands. Es sollte eine klare Vision entstehen, wie die im Istzustand beschriebene Problemstellung in Zukunft gelöst werden soll und welche Rolle das Projekt dabei spielt. - Funktionale Beschreibung
Das Kernstück des Pflichtenhefts. Detaillierte Beschreibung der funktionalen Anforderungen an das Projekt, meist in Form von Use Cases. Es wird erwartet, dass sowohl einzelne Anforderungen inklusive Ausnahmefällen auf ”Use Case Step“ Niveau erfasst sind als auch ein Überblick (z.B. in Form von Use Case Diagrammen) über die Anforderungen gegeben wird. Es muss ersichtlich sein, welche Benutzerrollen existieren und wie sich diese in ihren Aufgaben und Möglichkeiten unterscheiden. Es kann (und sollte i.A.) von einem Schalenmodell Gebrauch gemacht werden, das die Funktionalität in die Bereiche ”wird definitiv implementiert“, ” wird u.U. implementiert“ und ”wird nur entworfen“ aufteilt. Dementsprechend sollten die Use-Cases dann auch ausgearbeitet sein: Use-Cases die definitiv implementiert werden sind sehr detailliert auszuarbeiten, optionale halbwegs detailliert und Use Cases die nur im Entwurf bedacht werden sind sehr knapp gehalten.
Oft kann man nicht alle funktionalen Anforderungen als Use-Cases beschreiben. Die geeignete Form der Anforderungen variiert von Projekt zu Projekt. Die Beispiele sind: statische Modelle der Domäne, Geschäftregeln, Datenflüße, Spezifikationen von Inputs und Outputs, Konfigurationsmöglichkeiten, usw. Die Anforderungen können sowohl als Text als auch durch Diagramme erfasst werden.
Die Spezifikation muss möglichst (1) vollständig, (2) genau und (3) verständlich sein. Man sollte nur klar definierte Begriffe verwenden, Referenzen geben wenn nötig (siehe Glossar). Die Anforderungen müssen konsistent strukturiert und numeriert werden. Die Diagramme müssen eine klare Notation verwenden. Nicht standardisierte Notationen müssen beschrieben werden. - Beschreibung der Benutzungsschnittstelle
Eine genaue Beschreibung der Benutzungsschnittstelle mit Hilfe von Screenshots und gegebenenfalls erklärendem Text. - Nicht-funktionale Anforderungen
Spezielle Anforderungen des Auftraggebers, z.B. bezüglich der maximalen Anzahl an gleichzeitigen Benutzern, dem Laufzeitverhalten aber auch Anforderungen bzgl. Wartbarkeit oder der Verwendung eines speziellen Style-Guides Beschreibung der angestrebten Architektur, ggf. mit Aufteilung in Komponenten - Rechtliche Anforderungen
an das Produkt (z.B. Datenschutz) - Produktumgebung
Präzise (möglichst inklusive von Versionsnummern) Aufstellung der verwendeten Technologie (sowohl Soft- als auch Hardware) Beschreibung der verwendeten Entwicklungsumgebung (inkl. Versionsverwaltung) - Prozessmodell
Beschreibung der Teamorganistion. Rollenverteilung, Arbeitsabläufe, Entwicklungsmodell. - Projekt-Monitoring/Controlling
Was wird kontrolliert, gemessen? Wie? Mit welcher Regelmäßigkeit? Wer ist dafür zuständig? Wie werden auf Abweichungen vom Plan fesgestellt? Wie wird dann vorgegangen? Wann und wie wird der Projektplan (Work-Breakdown; Schätzungen; Zeitplannung) verfeinert und geändert? Wie werden die konkrete Aufgaben verteilt? Was und mit welcher Regelmäßigkeit wird an den Auftraggeber berichtet? Weitere organisatoriche Aufgaben, z.B. Protokollierung von Treffen, Kommunikation mit dem Auftraggeber, die organisatorische Verpflichtugen der beiden Seiten, - Change-Request-Verfahren
Die Beschreibung des Verfahrens. - Risikomanagement
Spezifische Risiken des Projekts; Einschätzung der Eintrittswahrscheinlicheit, die Schwere; die Vermeidungs- und Minderungsmaßnahmen; Monitoring und Aktualisierung der Risiken. - Zeitschätzung und Zeitplanung
Die angewandten Aufwandsschätzungsmethoden; Die aktuelle Work-Breakdown-Structure des Projekts; Die aktuellen Schätzungen; Abhängigkeiten zwischen den geplanten Aufgaben; Planung der (genau beschriebenen) Meilensteine und Releases (externe und interne); Die aktuelle (detalierte) Zeitplannung. - Deliverables
Knappe, präzise Aufstellung der Dinge, die von der Projektgruppe ausgeliefert werden (Installations-CD, Handbücher, Source-Code etc.) Beschreibung der Termine, an denen die Deliverables ausgeliefert werden. - QS
Angabe der durch den Kunden priorisierten QS-Ziele (Wartbarkeit, Performance, Modularität…) Beschreibung der QS-spezifischen Tätigkeiten, die von der Gruppe während des Projekts durchgeführt werden sowie ggf. der damit verfolgten Ziele (Verwendung von Testwerkzeugen, Metriken, Pair-Programming, Style-Guide etc.) Angabe von angestrebten Testendekriterien Abnahmetestbeschreibung (siehe auch QualitätsSicherungsDoku) - Rechte
Das obligatorische Rechtekapitel… geregelt sollten sein Fragen des Urheberrechts und der Haftung bzw. vielmehr des Haftungsausschlusses - Glossar
Beschreibung der für die Zielgruppe interessanten (also möglicherweise unklaren) Begriffe aus der Problemdomäne. - Gesamteindruck
Übersichtlichkeit, generelle Verständlichkeit und Form (Orthographie, Layout, Sprache) des Pflichtenhefts.
