This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Alternatives Vorgehen: Grob-Beschreibung fachlicher Anforderungen bei gleichzeitiger Ableitung der Zielarchitektur
Jede Anforderung auf maximal einer Seite beschreiben - Anzahl der Anforderungen geht vor Detailgrad.
Fachliche Beschreibung
Priorisierung aus fachlicher Perspektive, jeweils hoch/mittel/niedrig (z.B. Umsatzerhöhung, Kostensenkung, Qualität, …)
Titel der Anforderung
Andere Priorisierung (gesetzlich/regulatorisch, technisch, … Unterscheidung zwischen zwingend und optional)
Schnittstellen zu anderen Systemen (welche Daten werden benötigt, welche Art der Schnittstelle, auf welche Funktionen in anderen Systemen soll zugegriffen werden?)
Umsetzungsaufwand (hoch/mittel/niedrig)
Stand der Abstimmung zu der Anforderung/Entscheidungsbedarfe
Anmerkungen
Basis für Priorisierung der Anforderungen
Basis für Herleitung und Bewertung einer IT-Architektur/
Technologie-Architektur
+
• Formalisierung Projekt• RfP/Ausschreibung• Detaillierung• Start der Umsetzung
Ableitung der grundsätzlichen Szenarien zur Systemarchitektur: Eher Geschäftslogik als technische Umsetzung beachtenBeispiel: CRM-Anwendung für Telekommunikationskonzern mit Geschäftsfeldern mit jeweiliger Profit- und Loss-Verantwortung
Frühzeitige Priorisierung der Anforderungen als Basis einer Releaseplanung
Geschäftsnutzen
Umse
tzun
gsau
fwan
d
hoch
niedrig
hochniedrig
optionale Anforderung
Muss-Anforderung
Release 1.0
Release 2.0
• Alle Anforderungen an ein neues oder bereits existierendes IT-System werden einheitlich priorisiert anhand ihres Umsetzungsaufwands und ihres Nutzens (Grundlage der Nutzen- und Aufwandsschätzung: Expertenschätzung, keine Doktorarbeit!)
• Muss-Anforderungen haben Priorität in der Umsetzung
• Die Abgrenzung der Releases erfolgt auf Basis der verfügbaren finanziellen und personellen Ressourcen
Rollierende Priorisierung von Anforderungen und Release-Planung