1. Dokumente im Projektverlauf
2. Projektauftrag
Auch "Projektvereinbarung" genannt.
| Der Auftraggeber autorisiert den Projektmanager das Projekt innerhalb des hier abgesteckten Rahmens durchzuführen. |
- Inhalte
-
-
Zielsetzung
-
Erwartete Ergebnisse / Projektnutzen
-
Randbedingungen
-
Verantwortlichkeiten (ggf. auch Rollen)
-
geplante Personal- und Sachressourcen
-
übereinstimmende Willensbekundung der Beteiligten
-
- Weitere mögliche Inhalte
-
-
Ausgangslage
-
Projektorganisation und Berichtswesen
-
Schnittstellen zu anderen Projekten
-
Budgetrahmen (= Sachressourcen)
-
Projektdauer
-
Wirtschaftlichkeitsbewertung (Kosten-Nutzen-Analyse)
-
Chancen und Risiken
-
Mitwirkungspflichten des Auftraggebers
-
3. Lastenheft
Im internationalen Raum wird der Begriff "Anforderungsspezifikation" verwendet.
Auftraggeber oder Auftraggeber und Projektleiter legen die Anforderungen an das Projekt fest. Dieser Schritt ist entscheiden um sicherzustellen, dass der Kunde beim Projektabschluss auch das Ergebnis erhält, das er benötigt.
| Was der Kunde sich wünscht ≠ was der Kunde benötigt! → Insbesondere im Prozess der Softwareerstellung sind so viele Fachbereiche in die Kommunikation involviert und ist die Kommunikation oft so fachspezifisch, dass hier genau aufgepasst werden muss. Stichwort: Requirements Engineering! |
- Inhalte
-
- Ausgangssituation
-
-
Ausgangslage und Anlass zur Durchführung des Projektes
-
- Ziele
-
-
welche Ziele sollen umgesetzt werden und welche Vorteile werden durch das Projektergebnis erwartet?
-
- Produkteinsatz
-
-
Anforderungsbereiche und Zielgruppen
-
- Produktübersicht
-
-
Zusammenhänge von Produkt und Umgebung
-
Schnittstellen zu Anwender, Unterstützungs- und Nachbarsystemen
-
- Funktionale Anforderungen
-
-
welche Leistungen erwartet der Anwender, um ein fachliches Problem zu lösen?
-
- Nicht-funktionale Anforderungen
-
-
Benutzbarkeit, Zuverlässigkeit, Effizienz, Änderbarkeit, Übertragbarkeit
-
- Lieferumfang
-
-
Ergebnisse/Dienstleistungen, die der Auftragnehmer zu liefern hat
-
zum Abschluss aber auch während des Projektes
-
- Abnahmekriterien
-
-
was muss das Projektergebnis erfüllen, um beim Abnahmetest erfolgreich zu sein
-
4. Pflichtenheft bzw. Soll-Konzeption
Im internationalen Raum wird der Begriff "Systemspezifikation" verwendet.
- Inhalte
-
- Zielbestimmung
-
-
Muss-, Soll-, Kann- und Abgrenzungskriterien
-
- Produkteinsatz
-
-
Anwendungsbereiche, Zielgruppen und Betriebsbedingungen
-
Physikalische Umgebung, tägliche Betriebszeit, etc.
-
- Produktübersicht
-
-
kurze Übersicht (z. B. ein Produktstrukturplan)
-
- Produktfunktionen
-
-
detaillierte Beschreibung von Geschäftsprozessen, Listen, Reports, …
-
- Produktleistungen
-
-
Anforderungen bzgl. Zeit und Genauigkeit der Produktfunktionen
-
- Produktdaten
-
-
langfristig zu speichernde Daten
-
- Qualitätsanforderungen
-
-
weitere messbare Kriterien zu Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit, Übertragbarkeit
-
- Benutzeroberfläche
-
-
grundlegende Anforderungen
-
Zugriffsrechte
-
- weitere nicht-funktionale Anforderungen
-
-
Gesetze und Normen, Sicherhetsanforderungen, Plattformunabhängigkeiten
-
- Technische Produktumgebung
-
-
Software (Client, Server)
-
Hardware (Client, Server)
-
Orgware (organisatorische Rahmenbedingungen)
-
Produktschnittstellen
-
- Anforderungen an Entwicklungsumgebung
-
-
Software, Hardware, Orgware
-
Entwicklungsschnittstellen
-
- Gliederung in Teilprodukte
-
-
Teilprodukte
-
Abhängigkeiten
-
Liefertermine
-
- Glossar
-
-
Verzeichnis von technischem und Fachvokabular
-
5. Internationaler Kontext
Lasten- und Pflichtenheft sind spezifische Formulierungen für den deutschsprachigen Raum. In international genutzten Projektmanagementstandards gibt es dafür keine exakten Entsprechungen.
Im Requirements-Eingineering wird stattdessen der Begriff der Spezifikation verwendet. Dabei gilt:
-
Anforderungsspezifikation ⇔ Lastenheft
-
Systemspezifikation (grob, fein) ⇔ Pflichtenheft
