Anforderungen – der Lebenszyklus
Von Stefan Jung | 26. April 2013 | Kategorie: Anforderungsmanagement | Keine KommentareIm Gegensatz zu anderen Themen ist Anforderungsmanagement in den meisten Projekten unterrepräsentiert. Weil das so ist, möchte ich eine kurze Gegenüberstellung bieten – zum Spiegeln, Reflektieren und schließlich Verbessern im nächsten Projekt.
Wie es laufen könnte…
1. System und Systemkontext ermitteln
Vor der Ermittlung von Anforderungen werden System und Systemkontext inkl. Kontextgrenzen identifiziert, dokumentiert und abgestimmt.
Wie es läuft… 🙂
1. System und Systemkontext ermitteln
Die Beteiligten sind sich einig über System und Systemkontext. Vor diesem Hintergrund wird auf Dokumentation verzichtet.
Während der Umsetzung wird der Verzicht auf Dokumentation und Abstimmung insbesondere in Bezug auf Integrationen mit weiteren Systemen zu weiteren Aufwänden führen.
2. Anforderungen ermitteln
Die Anforderungsermittlung erfolgt strukturiert in Themen / Prozessbereichen. In die Ermittlung gehen der Kontext sowie die Kontextgrenzen ein. Die Ergebnisse werden dokumentiert. Eingehende Vorbereitung führt zur Erfassung eines Großteils der später umzusetzenden Anforderungen.
Die Dokumentation erfolgt in geeigneten Notationen und ist allen relevanten Stakeholdern zugänglich.
2. Anforderungen ermitteln
Die Anforderungsermittlung erfolgt dokumentiert jedoch wenig strukturiert. Da die Abgrenzung von System und Systemkontext nur bedingt vorliegt und unterschiedliche Stakeholder beteiligt sind, ergeben sich erste Unsicherheiten.
Im ungünstigsten Fall wird die Anforderungsermittlung im Rahmen der Beauftragung eines Dienstleisters durchgeführt. Warum das ungünstig ist? Weil die Gespräche durch Vertrieb (und möglicherweise Pre-Sales) begleitet werden. Dabei tun sich einerseits methodische Lücken auf (weil Vertriebsmitarbeiter in Account Management, Customer Relationship Management, … geschult werden und nicht in Projektmethoden) und die Zielstellungen nicht zwingend identisch sind.
Die Dokumentation erfolgt in einem Angebotsdokument (was besser ist als gar keine Dokumentation zu haben). Die Notation ist großteils ungeeignet und das Dokument ist auf Grund einiger Passagen, die als ‚Confidential‘ eingeordnet wurden, nicht allen Beteiligten zugänglich.
3. Anforderungen prüfen und abstimmen
Die Anforderungsbasis wird gegen die Zielstellung, System und Systemkontext sowie auf Widersprüche geprüft. In einer anschließenden Iteration werden die Anforderungen abgestimmt.
3. Anforderungen prüfen und abstimmen
Anforderungen werden nicht geprüft und auch nicht mit allen entscheidenden Stakeholdern abgestimmt. Die Folgen sind unter anderem:
- Es sind Widersprüche enthalten.
- Einige Stakeholder haben den Eindruck, dass ihre Anforderungen nicht in ausreichendem Maß enthalten sind.
- Der ursprüngliche Systemkontext ist zwar im Großen und Ganzen berücksichtigt, es liegen allerdings Anforderungen vor, die architektonisch Berücksichtigung finden müssten, dies aber auf Grund von geringer Sichtbarkeit nicht werden (Dokumentation dieser übergreifenden Anforderungen in hoher Detailtiefe).
- …
4. Anforderungen verwalten
Die in die Umsetzungsphase übernommenen Anforderungen dienen als Basis für die Implementierung. Sie werden statusbasiert bearbeitet, bei Änderungen versioniert und regelmäßig gereviewt. Änderungen werden über einen vereinbarten Change Prozess eingepflegt. Das schließt ein, dass alle Beteiligten jederzeit Zugriff auf die letzte gültige Version haben und diese auch identifizieren können.
Der Projektabschluss wird durch eine Testphase eingeleitet. Testfälle werden basierend auf Anforderungen aufgestellt.
4. Anforderungen verwalten
In der Startphase der Umsetzung wird gegen das lückenhafte Anforderungsdokument (respektive Vertrag mit einem Dienstleister) gearbeitet. Fragen werden ad hoc beantwortet und nicht nachdokumentiert. Das Projektverständnis der Beteiligten läuft auseinander und die Menge an Widersprüchen nimmt zu.
Es liegt keine bekannte und anerkannte Anforderungsbaseline vor. Aus diesem Grund werden in Vorbereitung auf den Test Testfälle generiert. Ein Teil der Testfälle sind neue, noch gänzlich unbekannte Anforderungen, die noch nicht umgesetzt sind. Der Projektabschluss wird schwierig.
5. Ergebnis
Die Anforderungen werden in ein Testframework überführt. Die Baseline für die Abnahme ist allen Projektbeteiligten bekannt.
5. Ergebnis
Der Scope der Umsetzung wackelt. Während der Testvorbereitung werden neue Anforderungen identifiziert, die nicht in die Anforderungsdokumentation aufgenommen werden sondern als Test Cases zu fehlgeschlagenen Testergebnissen führen. Die Ursache sind dabei weniger Unzulänglichkeiten im Test als vielmehr Versäumnisse während der Laufzeit. Das Vorhaben birgt ein hohes Risiko und wird nicht im vereinbarten Zeitfenster abgeschlossen. Die Mehrkosten sind erheblich.
6. Wie gehts weiter?
Anforderungsmanagement wirkt übergreifend. Die dargestellten Muster sind lediglich Beispiele und sind für eine Verankerung eines strukturierten Ansatzes nicht ausreichend.
Sollten Sie Fragen haben, wie sich über ein Projekt eine funktionierende Anforderungsbasis etablieren lässt, können Sie gern mit mir Kontakt aufnehmen.
