6. Demand Management und Requirements Management

Lernziele

Nach diesem Kapitel können Sie: - Demand Management zur Erfassung und Bewertung geschäftlicher Bedarfe durchführen - Requirements Management zur Überführung von Bedarfen in Anforderungen anwenden - Qualitätsvereinbarungen zur Sicherung der Servicequalität gestalten - Die Verbindung zwischen Demand Management und Requirements Management herstellen - Kundenanforderungen strukturiert erfassen und bewerten

Modul Übersicht

Modul 13 - Kapitel 6" Lesezeit: ~15 Min Quelle:** FS-ITB-13-B-Kundenbeziehungen-Analyse V2.pdf

1. Grundlagen: Anforderungen verstehen

Ein zentraler Bestandteil einer erfolgreichen IT-Beratung ist das umfassende Verständnis der Kundenanforderungen. Ziel ist es, gemeinsam mit dem Kunden effiziente und störungsfreie IT-Systeme zu entwickeln, die den täglichen Geschäftsbetrieb optimal unterstützen.

Die Bedeutung im IT-Beratungsprozess

Im Rahmen der Beratung werden gemeinsam Qualitätsvereinbarungen zur Bereitstellung und Weiterentwicklung der IT-Systemleistungen getroffen. Diese dienen dazu, klare Erwartungen zu definieren, Verantwortlichkeiten festzulegen und die Qualität der IT-Services langfristig zu sichern.

Ein strukturierter Dialog über:

bestehende Systeme
zukünftige Anforderungen
betriebliche Rahmenbedingungen

bildet dabei die Grundlage für eine durchgehende Kundenorientierung und eine vertrauensvolle Zusammenarbeit.

Praxisbeispiel

Ein Unternehmen plant die Digitalisierung seiner Personalabteilung. Der IT-Berater muss nicht nur die technischen Anforderungen verstehen (z. B. Integration ins bestehende ERP-System, Sicherheit, Compliance), sondern auch die geschäftlichen Anforderungen (z. B. Prozesseffizienz, User Experience, Kostensenkung). Nur durch ein umfassendes Verständnis aller Anforderungen kann eine Lösung entwickelt werden, die sowohl technisch als auch geschäftlich erfolgreich ist.

2. Demand Management

Das Demand Management erfasst und bewertet die geschäftlichen Bedarfe des Kunden, priorisiert sie nach Nutzen und Wirtschaftlichkeit und sorgt dafür, dass IT-Leistungen zielgerichtet geplant werden.

Definition und Zweck

Demand Management ist ein strukturierter Prozess zur Erfassung, Bewertung und Priorisierung von geschäftlichen IT-Bedarfen.

Zwecke:

Bedarfe systematisch erfassen
Bedarfe nach Nutzen und Wirtschaftlichkeit bewerten
Bedarfe priorisieren
IT-Leistungen zielgerichtet planen

Der Demand Management-Prozess

flowchart LR
    A[Bedarfserfassung] --> B[Bedarfsanalyse]
    B --> C[Bewertung & Priorisierung]
    C --> D[Service-Katalog-Abgleich]
    D --> E[Kapazitäts- & Budgetplanung]
    E --> F[Freigabe & Planung]

    style A fill:#e1f5e1
    style B fill:#fff4e1
    style C fill:#e1f0ff
    style D fill:#ffe1e1
    style E fill:#e1f5e1
    style F fill:#fff4e1

2.1 Bedarfserfassung

Zweck: Systematische Erfassung aller geschäftlichen IT-Bedarfe.

Quellen für Bedarfe:

Quelle	Beispiele
Strategische Planung	Digitalisierungsstrategie, Unternehmensziele
Geschäftsbereiche	Anforderungen aus Fachabteilungen (z. B. HR, Marketing, Produktion)
Projekte	Anforderungen aus laufenden oder geplanten Projekten
Operativer Betrieb	Bedarfe aus dem Tagesgeschäft, Support-Tickets, Verbesserungsvorschläge
Externe Faktoren	Gesetzesänderungen, Marktveränderungen, Wettbewerber

Methoden der Bedarfserfassung:

Interviews: Strukturierte Gespräche mit Ansprechpartnern
Workshops: Kollaborative Bedarfsdefinition
Umfragen: Breite Erfassung von Anforderungen
Beobachtung: Analyse der Arbeitspraktiken
Dokumentenanalyse: Auswertung vorhandener Dokumentationen

Praxistipp

Erfassen Sie Bedarfe immer mit Kontext: Wer benötigt was, warum, wann, wie? Das "Warum" ist besonders wichtig, da es die eigentlichen geschäftlichen Ziele offenlegt. Oft wird ein konkreter Bedarf genannt, aber das dahinterliegende Ziel ist nicht klar. Durch das Verständnis der Ziele können oft bessere Lösungen gefunden werden.

2.2 Bedarfsanalyse

Zweck: Analyse und Klärung der erfassten Bedarfe.

Aktivitäten:

Bedarfe klären: Sind die Bedarfe verständlich und vollständig?
Bedarfe kategorisieren: Welche Art von Bedarf ist es (z. B. Service, Projekt, Infrastruktur)?
Bedarfe strukturieren: Zusammenhänge und Abhängigkeiten identifizieren
Bedarfe validieren: Sind die Bedarfe realistisch und machbar?

Kategorisierung von Bedarfen:

Kategorie	Beschreibung	Beispiele
Strategisch	Bedarfe, die die strategischen Ziele unterstützen	Digitale Transformation, neue Geschäftsmodelle
Operativ	Bedarfe für den laufenden Betrieb	Performance-Verbesserung, Fehlerbehebung
Taktisch	Bedarfe für mittelfristige Optimierungen	System-Integration, Prozessoptimierung
Compliance	Bedarfe zur Einhaltung von Vorschriften	GDPR-Compliance, ISO-Zertifizierung

2.3 Bewertung und Priorisierung

Zweck: Bewertung der Bedarfe nach Nutzen und Wirtschaftlichkeit sowie Priorisierung.

Bewertungskriterien:

Kriterium	Beschreibung	Beispiele
Nutzen	Welcher geschäftliche Nutzen wird erwartet?	Kostensenkung, Effizienzsteigerung, Umsatzsteigerung
Wirtschaftlichkeit	ROI, Amortisationszeit, Kosten-Nutzen-Verhältnis	ROI > 1, Amortisation < 2 Jahre
Strategische Bedeutung	Beitrag zu strategischen Zielen	Unterstützung der Digitalisierungsstrategie
Dringlichkeit	Wie dringend ist der Bedarf?	Kritisch für den Geschäftsbetrieb vs. nice-to-have
Risiko	Welche Risiken bestehen bei Nicht-Implementierung?	Compliance-Verstoß, Wettbewerbsnachteil
Aufwand	Wie hoch ist der Aufwand für die Umsetzung?	Zeit, Kosten, Ressourcen

Priorisierungsmethoden:

MoSCoW-Methode:
- M - Must have: Wichtig, ohne Umsetzung scheitert das Projekt
- S - Should have: Wichtig, aber temporär verzichtbar
- C - Could have: Nützlich, aber nicht notwendig
- W - Won't have: In diesem Umfang nicht umsetzen
Punkte-System:
- Vergabe von Punkten für jedes Kriterium (z. B. 1-5)
- Summe der Punkte ergibt Priorität
100-Dollar-Methode:
- Verteilung von 100 "Dollar" auf die Bedarfe
- Je mehr "Dollar", desto höher die Priorität

Priorisierung mit Punkte-System

Drei Bedarfe werden mit einem Punkte-System (1-5 Punkte je Kriterium) bewertet:

|------------|------------------------|------------------------------|----------------------------| | Nutzen | 4 | 5 | 3 | | Wirtschaftlichkeit | 3 | 4 | 2 | | Strategische Bedeutung | 4 | 5 | 4 | | Dringlichkeit | 3 | 4 | 2 | | Risiko | 4 | 3 | 3 | | Summe | 18 | 21 | 14 |

**Priorisierung:** Bedarf B (21 Punkte) > Bedarf A (18 Punkte) > Bedarf C (14 Punkte)

2.4 Service-Katalog-Abgleich

Zweck: Abgleich der Bedarfe mit dem Service-Katalog.

Aktivitäten:

Prüfung, ob der Bedarf durch bestehende Services abgedeckt werden kann
Identifikation von Lücken im Service-Katalog
Planung neuer Services oder Erweiterung bestehender Services

Service-Katalog: Ein Verzeichnis aller Services, die ein IT-Dienstleister anbietet, mit Beschreibung, Kosten, SLAs und Verantwortlichkeiten.

Zweck des Service-Katalogs

Der Service-Katalog schafft Transparenz über angebotene Services, ermöglicht eine standardisierte Service-Erbringung, und bildet die Grundlage für die Kommunikation mit Kunden über verfügbare Services.

2.5 Kapazitäts- und Budgetplanung

Zweck: Planung der Kapazitäten und des Budgets zur Erfüllung der Bedarfe.

Aktivitäten:

Kapazitätsanalyse: Welche Ressourcen werden benötigt (Mitarbeiter, Systeme, Budget)?
Budgetplanung: Wie hoch sind die Kosten für die Umsetzung der Bedarfe?
Kapazitätsallokation: Zuweisung von Ressourcen zu Bedarfen
Priorisierung bei Ressourcenengpässen

2.6 Freigabe und Planung

Zweck: Freigabe der Bedarfe und Planung der Umsetzung.

Aktivitäten:

Entscheidungsfindung: Welche Bedarfe werden genehmigt?
Projektplanung: Zeitplanung, Ressourcenzuweisung
Budgetfreigabe: Freigabe der finanziellen Mittel
Kommunikation: Information an alle Beteiligten

3. Requirements Management

Das Requirements Management überführt die geschäftlichen Bedarfe in klare, überprüfbare Anforderungen an Systeme, Prozesse und Services.

Definition und Zweck

Requirements Management ist ein strukturierter Prozess zur Erfassung, Analyse, Spezifikation, Validierung und Verwaltung von Anforderungen.

Zwecke:

Überführung von Bedarfen in Anforderungen
Sicherstellung der Qualität und Vollständigkeit der Anforderungen
Verwaltung von Änderungen an Anforderungen
Rückverfolgbarkeit von Anforderungen bis zur Implementierung

Der Requirements Management-Prozess

flowchart LR
    A[Requirements-Erfassung] --> B[Requirements-Analyse]
    B --> C[Requirements-Spezifikation]
    C --> D[Validierung]
    D --> E[Management]
    E --> F[Verfolgung]

    style A fill:#e1f5e1
    style B fill:#fff4e1
    style C fill:#e1f0ff
    style D fill:#ffe1e1
    style E fill:#e1f5e1
    style F fill:#fff4e1

3.1 Requirements-Erfassung

Zweck: Erfassung aller Anforderungen aus verschiedenen Quellen.

Quellen für Anforderungen:

Quelle	Beispiele
Bedarfe aus Demand Management	Priorisierte geschäftliche Bedarfe
Stakeholder	Anforderungen von Anwendern, Management, IT-Abteilung
Richtlinien & Standards	Compliance-Anforderungen, Sicherheitsstandards
Best Practices	Empfehlungen aus Branchenstandards oder Frameworks
Technische Rahmenbedingungen	Anforderungen aus bestehenden Systemen

Anforderungsarten:

Anforderungsart	Beschreibung	Beispiele
Funktionale Anforderungen	Was das System tun soll	Benutzer-Login, Bestellung erfassen, Rechnung erstellen
Nicht-funktionale Anforderungen	Wie das System es tun soll	Performance, Verfügbarkeit, Sicherheit, Skalierbarkeit
Benutzeranforderungen	Anforderungen aus Sicht der Anwender	Benutzerfreundlichkeit, intuitive Navigation
Systemanforderungen	Anforderungen aus technischer Sicht	Interoperabilität, Architektur, Technologie-Stack
Geschäftsanforderungen	Anforderungen aus geschäftlicher Sicht	Compliance, Kostensenkung, Prozesseffizienz

Praxistipp: SMART-Anforderungen

Anforderungen sollten nach dem SMART-Prinzip formuliert werden: * S - Spezifisch: Klar und eindeutig * M - Messbar: Überprüfbar und quantifizierbar * A - Akzeptiert: Von allen Stakeholdern akzeptiert * R - Realistisch: Machbar und umsetzbar * T - Terminiert: Mit klaren Zeitrahmen

3.2 Requirements-Analyse

Zweck: Analyse und Klärung der erfassten Anforderungen.

Aktivitäten:

Anforderungen klären: Sind die Anforderungen verständlich?
Anforderungen kategorisieren: Zuordnung zu Anforderungsarten
Anforderungen strukturieren: Zusammenhänge und Abhängigkeiten identifizieren
Anforderungen konsolidieren: Zusammenfassung redundanter Anforderungen

Analyse-Methoden:

Use Case-Analyse: Identifikation der Anwendungsfälle
Benutzerstorys: Beschreibung der Anforderungen aus Sicht der Benutzer
Stakeholder-Analyse: Identifikation aller Stakeholder und deren Anforderungen
Glossar: Definition von Begriffen und Fachbegriffen

3.3 Requirements-Spezifikation

Zweck: Dokumentation der Anforderungen in einem Requirements-Lastenheft.

Struktur eines Requirements-Lastenhefts:

Abschnitt	Inhalt
Einleitung	Zweck, Geltungsbereich, Zielsetzung
Stakeholder-Übersicht	Beteiligte Stakeholder und deren Rollen
Geschäftsziele	Ziele, die mit der Umsetzung erreicht werden sollen
Funktionale Anforderungen	Detaillierte Beschreibung der Funktionalitäten
Nicht-funktionale Anforderungen	Performance, Sicherheit, Verfügbarkeit, Skalierbarkeit
Benutzeranforderungen	Anforderungen an Benutzeroberfläche und Benutzerfreundlichkeit
Systemanforderungen	Technische Anforderungen und Architektur
Randbedingungen	Einschränkungen, Rahmenbedingungen, Annahmen
Akzeptanzkriterien	Kriterien, die erfüllt sein müssen, um die Anforderungen als erfüllt zu betrachten

Anforderungs-Spezifikation: Funktionale Anforderung

Anforderung: Benutzer-Login

Beschreibung: Benutzer können sich mit Benutzername und Passwort im System authentifizieren.

Funktionalität: * Benutzer kann Benutzername und Passwort eingeben * System validiert Benutzername und Passwort * Bei erfolgreicher Validierung wird Benutzer zur Startseite weitergeleitet * Bei fehlgeschlagener Validierung wird Fehlermeldung angezeigt

Nicht-funktionale Anforderungen: * Login-Dauer < 2 Sekunden * Maximale gleichzeitige Login-Versuche: 1.000 * Passwörter müssen verschlüsselt gespeichert werden

Akzeptanzkriterien: * Benutzer kann sich mit korrekten Daten erfolgreich einloggen * Benutzer erhält Fehlermeldung bei falschen Daten * System weist Fehlermeldung nach 3 fehlgeschlagenen Login-Versuchen aus

3.4 Validierung

Zweck: Überprüfung, ob die Anforderungen die Bedarfe und Erwartungen der Stakeholder erfüllen.

Validierungs-Methoden:

Reviews: Systematische Überprüfung der Anforderungen durch Experten
Prototyping: Entwicklung von Prototypen zur Validierung der Anforderungen
Walkthroughs: Gemeinsame Durchgänge der Anforderungen
Stakeholder-Feedback: Feedback der Stakeholder zu den Anforderungen

Validierungs-Kriterien:

Erfüllen die Anforderungen die Bedarfe?
Sind die Anforderungen vollständig?
Sind die Anforderungen konsistent?
Sind die Anforderungen verständlich?
Sind die Anforderungen realistisch?

3.5 Requirements-Management

Zweck: Verwaltung von Änderungen an Anforderungen während des Projekts.

Aktivitäten:

Änderungsmanagement: Verwaltung von Änderungen an Anforderungen
Versionsverwaltung: Nachverfolgung von Versionen der Anforderungen
Rückverfolgbarkeit: Verfolgung von Anforderungen bis zur Implementierung
Abhängigkeitsmanagement: Verwaltung von Abhängigkeiten zwischen Anforderungen

Change Management für Anforderungen:

flowchart LR
    A[Änderungsanfrage] --> B[Änderungsanalyse]
    B --> C{Auswirkungen bewerten}
    C -->|Gering| D[Kleine Änderung<br/>Schnellgenehmigung]
    C -->|Hoch| E[Änderungs-Review<br/>Entscheidungsprozess]
    E --> F[Genehmigt?]
    F -->|Ja| G[Anforderung anpassen]
    F -->|Nein| H[Änderung ablehnen]
    G --> I[Stakeholder informieren]
    D --> I
    I --> J[Implementierung planen]

4. Verbindung zwischen Demand Management und Requirements Management

Das Demand Management und das Requirements Management sind eng miteinander verbunden. Das Demand Management liefert die priorisierten geschäftlichen Bedarfe, die das Requirements Management in konkrete Anforderungen an Systeme und Services überführt.

graph LR
    A[Geschäftliche Bedarfe] --> B[Demand Management]
    B --> C[Priorisierte Bedarfe]
    C --> D[Requirements Management]
    D --> E[Anforderungen]
    E --> F[System-/Service-Spezifikation]
    F --> G[Implementierung]

    style A fill:#ffe66d
    style B fill:#e1f5e1
    style C fill:#e1f0ff
    style D fill:#ffe1e1
    style E fill:#e1f5e1
    style F fill:#fff4e1
    style G fill:#95e1d3

Die Schnittstelle

Übergabe-Informationen:

Priorisierte Bedarfe
Geschäftsziele
Stakeholder-Analyse
Randbedingungen und Einschränkungen
Budget und Zeitrahmen

Rückfluss-Informationen:

Anforderungsspezifikationen
Technische Machbarkeit
Aufwandsabschätzungen
Risikobeurteilung
Akzeptanzkriterien

Wichtigkeit der Schnittstelle

Eine klare Schnittstelle zwischen Demand Management und Requirements Management ist entscheidend für den Projekterfolg. Die Business-Seite (Demand Management) definiert, WAS benötigt wird, und die IT-Seite (Requirements Management) definiert, WIE dies umgesetzt wird. Eine gute Kommunikation und Zusammenarbeit zwischen beiden Seiten ist daher essenziell.

5. Qualitätsvereinbarungen

Qualitätsvereinbarungen definieren klare Erwartungen und Verantwortlichkeiten, um die Servicequalität langfristig zu sichern.

Arten von Qualitätsvereinbarungen

Vereinbarungsart	Beschreibung	Beispiele
SLA (Service Level Agreement)	Vereinbarung über Servicequalität zwischen Dienstleister und Kunde	Verfügbarkeit 99,9%, Reaktionszeit < 2 Std.
OLA (Operational Level Agreement)	Vereinbarung zwischen internen Abteilungen über Servicequalität	SLA für interne Datenbank-Services
UC (Underpinning Contract)	Vertrag mit Externen über die Bereitstellung von Services	Wartungsvertrag mit Hardware-Lieferant
SOP (Standard Operating Procedure)	Standardisierte Ablaufbeschreibungen für Prozesse	Prozess für Incident Management

Komponenten von Qualitätsvereinbarungen

5.1 Service-Beschreibung

Klare Beschreibung des Services:

Service-Beschreibung: Was wird bereitgestellt?
Service-Ziel: Welches Problem wird gelöst?
Service-Umfang: Was ist inklusive, was ist exklusive?
Service-Einschränkungen: Gibt es Einschränkungen?

5.2 Service-Levels

Definition der Servicequalität:

Verfügbarkeit: Wie oft muss der Service verfügbar sein?
Reaktionszeit: Wie schnell wird auf Anfragen reagiert?
Wiederherstellungszeit: Wie schnell werden Störungen behoben?
Qualität: Welche Qualität muss der Service haben?

5.3 Verantwortlichkeiten

Klare Definition der Verantwortlichkeiten:

Dienstleister-Verantwortlichkeiten: Was übernimmt der Dienstleister?
Kunden-Verantwortlichkeiten: Was muss der Kunde tun?
Gemeinsame Verantwortlichkeiten: Was wird gemeinsam getan?

5.4 Messung und Berichterstattung

Definition der Messmethoden und Berichterstattung:

KPIs: Welche Kennzahlen werden gemessen?
Messmethoden: Wie werden die Kennzahlen gemessen?
Berichtszeitraum: Wie oft werden Berichte erstellt?
Berichtsformat: Wie sehen die Berichte aus?

5.5 Konsequenzen bei Nichteinhaltung

Definition der Konsequenzen bei SLA-Verletzung:

Service Credits: Gutschriften bei Nichteinhaltung
Vertragsstrafen: Zusätzliche Strafzahlungen bei grober Verletzung
Sonderkündigungsrecht: Recht zur Kündigung bei wiederholter Verletzung

Schlüsselbegriffe

Begriff	Definition
Demand Management	Prozess zur Erfassung, Bewertung und Priorisierung von geschäftlichen IT-Bedarfen
Requirements Management	Prozess zur Erfassung, Analyse, Spezifikation, Validierung und Verwaltung von Anforderungen
Bedarf	Geschäftlicher Bedarf an IT-Services oder -Systemen
Anforderung	Konkrete, überprüfbare Forderung an ein System oder Service
Funktionale Anforderung	Anforderung, die beschreibt, WAS ein System tun soll
Nicht-funktionale Anforderung	Anforderung, die beschreibt, WIE ein System eine Funktionalität erfüllt
MoSCoW-Methode	Priorisierungsmethode: Must have, Should have, Could have, Won't have
SMART-Anforderungen	Spezifisch, Messbar, Akzeptiert, Realistisch, Terminiert
Qualitätsvereinbarung	Vereinbarung über die Qualität eines Services
SLA	Service Level Agreement; Vereinbarung über Servicequalität zwischen Dienstleister und Kunde
OLA	Operational Level Agreement; Vereinbarung über Servicequalität zwischen internen Abteilungen
UC	Underpinning Contract; Vertrag mit Externen über Service-Bereitstellung
KPI	Key Performance Indicator; Leistungskennzahl zur Erfolgsmessung

Verständnisfragen

Frage 1: Demand Management vs. Requirements Management

Ein Unternehmen möchte ein neues Kundenbeziehungsmanagement-System einführen. Beschreiben Sie, welche Aufgaben das Demand Management und welche das Requirements Management in diesem Szenario übernimmt und wie beide Prozesse zusammenarbeiten.

Lösung: Demand Management: * Bedarfserfassung: Erfassung des geschäftlichen Bedarfs an einem CRM-System * Bedarfsanalyse: Analyse, warum das CRM-System benötigt wird (z. B. Kundenzufriedenheit steigern, Prozesseffizienz erhöhen) * Bewertung & Priorisierung: Bewertung des Nutzens (z. B. Umsatzsteigerung, Kostensenkung) und Priorisierung gegenüber anderen Bedarfen * Service-Katalog-Abgleich: Prüfung, ob ein CRM-System bereits angeboten wird oder entwickelt werden muss

Requirements Management: * Requirements-Erfassung: Erfassung aller Anforderungen an das CRM-System (funktionale Anforderungen wie Kundenverwaltung, Auftragsbearbeitung; nicht-funktionale Anforderungen wie Performance, Sicherheit) * Requirements-Analyse: Analyse und Klärung der Anforderungen, Strukturierung der Anforderungen * Requirements-Spezifikation: Dokumentation der Anforderungen in einem Requirements-Lastenheft * Validierung: Validierung der Anforderungen mit den Stakeholdern

Zusammenarbeit: Das Demand Management liefert die priorisierten geschäftlichen Bedarfe (z. B. "CRM-System zur Steigerung der Kundenzufriedenheit") an das Requirements Management. Das Requirements Management überführt diese Bedarfe in konkrete Anforderungen (z. B. "Benutzer können Kundendaten erfassen, bearbeiten und löschen"). Beide Prozesse arbeiten eng zusammen, um sicherzustellen, dass die geschäftlichen Bedarfe in technische Anforderungen übersetzt werden.

Frage 2: Priorisierung mit MoSCoW

Ein Unternehmen hat folgende Bedarfe für ein neues IT-Projekt: A) Integration mit dem bestehenden ERP-System (muss für den Geschäftsbetrieb) B) Mobile App für die Dateneingabe (würde die Benutzerfreundlichkeit erhöhen) C) Berichtsfunktionalität (wäre für die Analyse hilfreich) D) Automatische Datensicherung (kritisch für die Sicherheit)

Priorisieren Sie diese Bedarfe mit der MoSCoW-Methode und begründen Sie Ihre Entscheidung.

Lösung:

Bedarf	MoSCoW-Kategorie	Begründung
A) Integration mit ERP-System	M - Must have	Kritisch für den Geschäftsbetrieb; ohne Integration ist das System nicht verwendbar
D) Automatische Datensicherung	M - Must have	Kritisch für die Sicherheit; ohne Datensicherung droht Datenverlust bei Ausfällen
B) Mobile App	S - Should have	Wichtig für die Benutzerfreundlichkeit, aber temporär verzichtbar (Desktop-Lösung möglich)
C) Berichtsfunktionalität	C - Could have	Nützlich für die Analyse, aber nicht notwendig für den Betrieb (manuelle Berichte möglich)

Zusammenfassung: * Must have (M): Bedarfe A und D sind kritisch und müssen im ersten Release umgesetzt werden. * Should have (S): Bedarf B ist wichtig, kann aber temporär aufgeschoben werden, wenn Ressourcenengpässe bestehen. * Could have (C): Bedarf C wäre nützlich, ist aber nicht notwendig. * Won't have (W): Keine Bedarfe wurden als "Won't have" eingestuft (alle haben zumindest "Could have"-Niveau).

Frage 3: SMART-Anforderungen formulieren

Folgende Anforderungen wurden formuliert. Prüfen Sie, ob sie den SMART-Kriterien entsprechen, und verbessern Sie sie bei Bedarf:

"Das System sollte schnell sein."
"Benutzer können sich einloggen."
"Die Datenbank muss sicher sein."
"Das System muss bis zum nächsten Jahr fertig sein."

Lösung:

Anforderung	SMART-Prüfung	Verbesserung
1. Das System sollte schnell sein.	Nicht SMART: Nicht spezifisch ("schnell"), nicht messbar	"Das System muss Seitenladezeiten von < 2 Sekunden bei 100 gleichzeitigen Benutzern haben."
2. Benutzer können sich einloggen.	Nicht SMART: Nicht messbar (keine Kriterien für erfolgreichen Login), nicht terminiert	"Benutzer können sich mit Benutzername und Passwort innerhalb von 2 Sekunden erfolgreich einloggen."
3. Die Datenbank muss sicher sein.	Nicht SMART: Nicht spezifisch ("sicher"), nicht messbar	"Die Datenbank muss alle Daten mit AES-256 verschlüsselt speichern und muss alle 24 Stunden automatisch gesichert werden."
4. Das System muss bis zum nächsten Jahr fertig sein.	Nicht SMART: Nicht spezifisch ("nächstes Jahr"), nicht terminiert	"Das System muss bis zum 31.12.2026 vollständig implementiert und getestet sein."

SMART-Kriterien: * S - Spezifisch: Klar und eindeutig * M - Messbar: Überprüfbar und quantifizierbar * A - Akzeptiert: Von allen Stakeholdern akzeptiert * R - Realistisch: Machbar und umsetzbar * T - Terminiert: Mit klaren Zeitrahmen

Frage 4: Qualitätsvereinbarungen gestalten

Ein IT-Dienstleister möchte mit einem Kunden ein SLA für einen kritischen Geschäftsservice vereinbaren. Beschreiben Sie, welche Komponenten in das SLA aufgenommen werden sollten und geben Sie konkrete Beispiele.

Lösung:

Komponenten des SLA:

1. Service-Beschreibung: * Service: ERP-System für Auftrags- und Kundenverwaltung * Service-Ziel: Unterstützung der täglichen Geschäftstätigkeit und Effizienzsteigerung der Auftragsbearbeitung * Service-Umfang: Inklusive alle Module (Auftragsbearbeitung, Kundenverwaltung, Rechnungswesen), Exklusive: Individuelle Anpassungen

2. Service-Levels: * Verfügbarkeit: 99,5% (außerhalb geplanter Wartungsfenster) * Reaktionszeit: * Priorität 1 (Kritisch): ≤ 15 Minuten * Priorität 2 (Hoch): ≤ 1 Stunde * Priorität 3 (Mittel): ≤ 4 Stunden * Priorität 4 (Niedrig): ≤ 1 Arbeitstag * Wiederherstellungszeit: * Priorität 1 (Kritisch): ≤ 4 Stunden * Priorität 2 (Hoch): ≤ 8 Stunden * Priorität 3 (Mittel): ≤ 24 Stunden * Priorität 4 (Niedrig): ≤ 3 Arbeitstage

3. Verantwortlichkeiten: * Dienstleister: Systembetrieb, Updates, Support, Monitoring * Kunde: Benutzerverwaltung, Testen von Updates, Meldung von Störungen * Gemeinsam: Regelmäßige Service Reviews, Testen neuer Releases

4. Messung und Berichterstattung: * KPIs: Verfügbarkeit, Reaktionszeit, Wiederherstellungszeit, Kundenzufriedenheit (CSAT) * Messmethoden: Automatisches Monitoring, Ticket-System * Berichtszeitraum: Monatlich * Berichtsformat: Dashboard mit Echtzeit-Daten, monatlicher Bericht

5. Konsequenzen bei Nichteinhaltung: * Service Credits: * Verfügbarkeit 99,4% - 99,5%: 5% Gutschrift * Verfügbarkeit 99,0% - 99,4%: 10% Gutschrift * Verfügbarkeit < 99,0%: 20% Gutschrift * Sonderkündigungsrecht: Bei dreifacher Nichteinhaltung der Verfügbarkeit in einem Quartal

Dieses SLA schafft Klarheit über die Servicequalität, definiert messbare Kriterien, und schafft Transparenz für beide Parteien.