Schritt 5: Wie sieht kann ein Pflichtenheft aussehen?
Schritt 1 bis 4 habe ich in Anforderungsanalyse für kleine und mittelständische Unternehmen skizziert. Im folgenden werden wir eine Gliederung für ein solches Pflichtenheft vorstellen und unsere Ideen und Erfahrungen dazu dokumentieren. Diese Gliederung ist keine neue Idee sondern basiert auf dem IEEE-Standard 830-1998. Gut aufbereitet in Basiswissen: Requirement Engineering von Pohl und Rupp. Wir haben die Gliederung an „unsere“ Realität angepasst und unsere Ideen bzw. die Ideen von Pohl und Rupp verfeinert.
1 Einleitung
1.1 Zweck dieses Pflichtenheftes
- Dieser erste Abschnitt beschreibt mit welchem Ziel das Anforderungsdokument verfasst wurde und vermittelt dem Leser an welche Zielgruppe das Dokument gerichtet ist.
1.2 Problemidentifikation und Projektziel
- Darstellen des aktuellen Ist-Zustandes und des daraus ergebenden Problem
- Klare Formulierung des Projektzieles (z.B. unternehmensweites Wikisystem oder Pilotprojekt für Abteilung XYZ)
1.3 Stakeholder
- Liste der identifizierten und relevanten Stakeholder (Geschäftsführer, zukünftige Benutzer, IT Abteilung die den Helpdesk übernimmt, …)
- Liste kann in der Form Name, Position und Funktion im beschriebenen Anfoderungsanalyseprozess dargestellt werden
- Zusätzlich führen wir hier auch noch die Stakeholder von unserer Seite auf: Name – Projektrolle – Position im Unternehmen
1.4 Erläuterungen zu Begriffen und Abkürzungen
- Abkürzung und Akronyme erläutern (Hier kann es große Differenzen geben, also lieber zu viel als zu wenig Begriffe auflisten)
1.5 Übersicht
- Je nach Umfang kann an dieser Stelle die weiteren Kapitel kurz erläutert werden.
2 Allgemeine Beschreibung
2.1 Systemperspektive (zu anderen Softwareprodukten)
- In welche bestehende oder noch aufzubauende IT-Landschaft gliedert sich das beschriebene System/Anwendung ein
2.2 Systemfunktionalität (Zusammenfassung und Übersicht)
- Zusammenfassung und kurze Übersicht der Kernfunktionen des Systems. Hier bietet sich der Einsatz von Use-Case-Diagrammen an (Zur Darstellung komplexer Zusammenhänge in bälde mehr).
2.3 Nutzer und Zielgruppe
- Benutzermerkmale der zu erwartenden Nutzer (z.B. Bildungsgrad, bisherige IT-Erfahrung, Sachkenntisse, …)
- Umfang der angedachten Schulung je nach Vorwissen.
- Welche Fähigkeiten werden für die Administration benötigt, in welche Zeitraum ist dieses zu erwerben.
2.4 Randbedingungen und Einschränkungen.
- Meist sind das Einschränkungen für den Entwickler
2.5 Annahmen und Abhängigkeiten
- Hier werden Entscheidungen erwähnt,welche Anforderungen nicht umgesetzt werden obwohl diese wünschenswert wären. Dies erspart später „ja das brauchen wir, das hat niemand gesagt das dies nicht geht…“ und weitere leidige Diskussionen was denn eigentlich vereinbart war.
- Weiter können Annahmen dokumentiert auf welchen die weiteren Anforderungen basieren.
- Jede Annahme durchnummerieren, so kann man diese später direkt adressieren.
3 Anwendungsfunktionen/ spezifische Anforderungen
- Die konkreten und spezifischen Anforderungen finden hier ihren Eintrag
- Jede Anforderung durchnummerieren, so kann man diese später direkt adressieren.
4 Qualitätsanforderungen
- Performance, Sicherheit, Verfügbarkeit, etc. also alle nicht funktionalen Anforderungen an das System werden hier dokumentiert. Eine Gewichtung der einzelnen Punkte sollte vorgenommen werden.
- Jede Qualitätsanforderung durchnummerieren, so kann man diese später direkt adressieren.
5 Anhang
Wenn nötig können zu den einzelnen oben aufgeführten Punkten Hintergrundinformationen bereitgestellt werden.
6 Index
Der formhalber ist der Index hier mit aufgeführt, wir nutzen ein Inhaltsverzeichnis und aussagekräftige Über- und Zwischenüberschriften.
Weitere Quellen…
… die wir bis dato gefunden und z.T. gelesen haben
- Korrekturseiten, mit dem IEEE Standard unter http://www.swc.rwth-aachen.de/se_buch/korrekturen/S_363f.pdf
- Interessanter Vorschlag: Benutzerhandbuch als Systemspezifikation
- Für später Grundlagen der Passiv-Aktiv-Transformation