Qualitätskriterien für Anforderungen
Lernziele
Nach diesem Kapitel können Sie: * Die 9 C-Requirements (IEEE) anwenden * Anforderungen auf Qualität prüfen * Schlechte von guten Anforderungen unterscheiden * Anforderungen optimieren
1. Einführung: Warum Qualitätskriterien wichtig sind
Zitat
"Eine schlechte Anforderung ist schlimmer als gar keine Anforderung. Sie verführt zu Fehlannahmen." — unbekannt
1.1 Kosten schlechter Anforderungen
Statistiken zeigen die Dramatik:
| Problem | Häufigkeit der Ursache | Kosten-Faktor |
|---|---|---|
| Rework (Nacharbeit) | 40% → Anforderungen geändert | 3-10x |
| Projektverzögerungen | 70% → Fehlende Anforderungen | 2-5x |
| Nicht erfüllte Erwartungen | 80% → Falsche Anforderungen | 10-100x |
Cost of Fix: * Im Requirements-Stage: 1x * Im Development-Stage: 10x * Im Testing-Stage: 100x * Im Deployment-Stage: 1.000x
1.2 Die 9 C-Requirements (IEEE)
Das IEEE (Institute of Electrical and Electronics Engineers) definiert 9 Qualitätskriterien für Anforderungen:
| C-Kriterium | Bedeutung | Warum wichtig? |
|---|---|---|
| Complete | Vollständig | Fehlende Anforderungen führen zu Rework |
| Correct | Korrekt | Falsche Anforderungen führen zum falschen System |
| Consistent | Konsistent | Widersprüche führen zu Konflikten |
| Clear | Klar | Unklare Anforderungen führen zu Missverständnissen |
| Concise | Prägnant | Lange Anforderungen werden nicht gelesen |
| Concrete | Konkret | Abstrakte Anforderungen sind nicht testbar |
| Atomic | Atomar | Komplexe Anforderungen sind nicht priorisierbar |
| Unique | Einzigartig | Dopplungen führen zu Redundanzen |
| Traceable | Nachverfolgbar | Ohne Traceability keine Verknüpfung zu Geschäftszielen |
2. Die 9 C-Requirements im Detail
2.1 C1: Complete (Vollständig)
Eine Anforderung ist vollständig, wenn sie alle notwendigen Informationen enthält.
Was bedeutet Vollständigkeit:
| Aspekt | Was muss vorhanden sein? |
|---|---|
| Beschreibung | Detaillierte Beschreibung der Funktionalität |
| Akzeptanzkriterien | Wann ist die Anforderung erfüllt? |
| Randbedingungen | Welche Einschränkungen gibt es? |
| Verknüpfungen | Mit welchen Anforderungen steht sie in Beziehung? |
| Stakeholder | Wer fordert diese Anforderung? |
Vollständigkeit: Schlecht vs. Gut
Schlecht: "Kunde kann bestellen" * ❌ Welche Daten braucht der Kunde? * ❌ Welche Zahlungsmethoden sind möglich? * ❌ Was passiert bei Fehler?
Gut: "Kunde kann Artikel in den Warenkorb legen, Liefer- und Rechnungsadresse eingeben und mit Kreditkarte (Visa, Mastercard), PayPal oder Sofortüberweisung bezahlen. Bei Fehler wird dem Kunden eine klare Fehlermeldung angezeigt."
2.2 C2: Correct (Korrekt)
Eine Anforderung ist korrekt, wenn sie faktisch richtig ist und keine Fehler enthält.
Was bedeutet Korrektheit:
| Aspekt | Was muss erfüllt sein? |
|---|---|
| Faktische Richtigkeit | Aussage ist faktisch korrekt |
| Keine Fehler | Keine Tippfehler, keine logischen Fehler |
| Machbar | Anforderung ist technisch realisierbar |
| Relevant | Anforderung ist relevant für das Projekt |
Korrektheit: Schlecht vs. Gut
Schlecht: "Kunde kann mit Bitcoin bezahlen" * ❌ Faktisch falsch (Bitcoin wird nicht angeboten) * ❌ Nicht relevant (Business-Ziel ist keine Krypto-Integration)
Gut: "Kunde kann mit Kreditkarte (Visa, Mastercard), PayPal oder Sofortüberweisung bezahlen" * ✅ Faktisch richtig (Diese Zahlungsmethoden werden angeboten) * ✅ Relevant (Business-Ziel ist Umsatzsteigerung)
2.3 C3: Consistent (Konsistent)
Eine Anforderung ist konsistent, wenn sie keine Widersprüche zu anderen Anforderungen aufweist.
Arten von Widersprüchen:
| Typ | Beispiel |
|---|---|
| Logischer Widerspruch | Anforderung A: "System muss in < 1 Sekunde antworten" vs. Anforderung B: "System muss komplexe Berechnungen durchführen" |
| Semantischer Widerspruch | Anforderung A: "Kunde muss E-Mail validieren" vs. Anforderung B: "Kunde kann ohne E-Mail registrieren" |
| Funktionaler Widerspruch | Anforderung A: "System muss offline funktionieren" vs. Anforderung B: "System benötigt permanente Internetverbindung" |
!!! example "Konsistenz: Widerspruch erkennen Anforderung A: "Das System muss 99.9% verfügbar sein" Anforderung B:** "Das System muss täglich für 2 Stunden gewartet werden"
**Widerspruch:** 99.9% Verfügbarkeit = 8,76 Stunden Downtime/Jahr = ~0,02 Stunden/Tag
**Lösung:** Wartung in Wartungsfenster integrieren oder Verfügbarkeit anpassen
2.4 C4: Clear (Klar)
Eine Anforderung ist klar, wenn sie eindeutig verständlich ist und keine Missverständnisse zulässt.
Was bedeutet Klarheit:
| Aspekt | Was muss erfüllt sein? |
|---|---|
| Eindeutig | Nur eine Interpretation möglich |
| Kein Fachjargon | Alle Beteiligten verstehen die Anforderung |
| Keine Unklarheiten | Keine "vielleicht", "möglich", "wenn Zeit vorhanden" |
| Präzise | Keine vagen Begriffe ("schnell", "benutzerfreundlich") |
Klarheit: Schlecht vs. Gut
Schlecht: "Das System muss schnell sein" * ❌ Was bedeutet "schnell"? * ❌ Wie wird "schnell" gemessen? * ❌ Unter welchen Bedingungen?
Gut: "Das System muss in < 2 Sekunden auf eine Anfrage antworten bei 1000 gleichzeitigen Benutzern" * ✅ Präzise (2 Sekunden) * ✅ Messbar (1000 gleichzeitige Benutzer) * ✅ Eindeutig (keine Interpretation)
2.5 C5: Concise (Prägnant)
Eine Anforderung ist prägnant, wenn sie kurz und bündig formuliert ist, aber alle notwendigen Informationen enthält.
Warum Prägnanz wichtig ist: * Lange Anforderungen werden nicht gelesen * Kurze Anforderungen sind leichter zu verstehen * Prägnante Anforderungen sind leichter zu priorisieren
Prägnanz: Schlecht vs. Gut
Schlecht: "Der Benutzer des Systems muss in der Lage sein, sich mit seinem Benutzernamen und seinem Passwort, das er bei der Registrierung festgelegt hat, in das System einzuloggen, wobei das Passwort sicher verschlüsselt übertragen werden muss und der Benutzer nach drei fehlerhaften Versuchen für 5 Minuten gesperrt wird, bevor er es erneut versuchen kann."
Gut: "Benutzer login mit Benutzername und Passwort. Passwort verschlüsselt. Nach 3 fehlerhaften Versuchen: 5-Minuten-Sperrung." * ✅ Kurz und bündig * ✅ Alle Informationen enthalten
2.6 C6: Concrete (Konkret)
Eine Anforderung ist konkret, wenn sie verifizierbar und testbar ist.
Was bedeutet Konkretheit:
| Aspekt | Was muss erfüllt sein? |
|---|---|
| Verifizierbar | Kann überprüft werden, ob die Anforderung erfüllt ist |
| Testbar | Kann mit Tests validiert werden |
| Messbar | Kann mit Metriken gemessen werden |
| Keine Subjektivität | Keine subjektiven Aussagen ("benutzerfreundlich", "gut") |
Konkretheit: Schlecht vs. Gut
Schlecht: "Das System muss benutzerfreundlich sein" * ❌ Nicht testbar (Was ist "benutzerfreundlich"?) * ❌ Nicht messbar (Wie wird "benutzerfreundlich" gemessen?) * ❌ Subjektiv (Für wen ist es benutzerfreundlich?)
Gut: "Ein neuer Benutzer kann sich in < 3 Minuten registrieren und ohne Training erste Aufgaben erledigen" * ✅ Testbar (Zeitmessung möglich) * ✅ Messbar (3 Minuten) * ✅ Konkret (Registrierung, erste Aufgaben)
2.7 C7: Atomic (Atomar)
Eine Anforderung ist atomar, wenn sie nicht aufspaltbar ist und genau ein Thema behandelt.
Was bedeutet Atomarität:
| Aspekt | Was muss erfüllt sein? |
|---|---|
| Nicht aufspaltbar | Kann nicht in mehrere Anforderungen aufgeteilt werden |
| Genau ein Thema | Behandelt genau eine Funktionalität |
| Priorisierbar | Kann eigenständig priorisiert werden |
Atomarität: Schlecht vs. Gut
Schlecht: "Der Benutzer kann sich registrieren, einloggen, Passwort vergessen, Profil bearbeiten, Bestellung aufgeben, bezahlen und Bestellung stornieren" * ❌ Nicht atomar (7 verschiedene Themen) * ❌ Nicht priorisierbar (Alle oder nichts)
Gut (aufgeteilt in 7 atomare Anforderungen): 1. FR-001: Benutzerregistrierung 2. FR-002: Benutzerlogin 3. FR-003: Password Reset 4. FR-004: Profil bearbeiten 5. FR-005: Bestellung aufgeben 6. FR-006: Bezahlen 7. FR-007: Bestellung stornieren
2.8 C8: Unique (Einzigartig)
Eine Anforderung ist einzigartig, wenn sie nicht doppelt dokumentiert ist.
Warum Einzigartigkeit wichtig ist: * Dopplungen führen zu Redundanzen * Dopplungen führen zu Inkonsistenzen (Änderung an一处, nicht an anderer) * Dopplungen führen zu Verwirrung
!!! example "Einzigartigkeit: Dopplung erkennen FR-001: "Benutzer kann sich mit Benutzername und Passwort einloggen" FR-005:** "Benutzer authentifiziert sich mit E-Mail und Passwort"
**Dopplung:** Beide Anforderungen beschreiben das Login
**Lösung:** Anforderungen zusammenführen oder klar unterscheiden (Benutzername vs. E-Mail als Login-Methode)
2.9 C9: Traceable (Nachverfolgbar)
Eine Anforderung ist nachverfolgbar, wenn sie mit Geschäftszielen, Stakeholdern und anderen Anforderungen verknüpft ist.
Warum Traceability wichtig ist: * Traceability zeigt, welche Anforderungen welchen Geschäftszielen dienen * Traceability ermöglicht Impact-Analyse bei Änderungen * Traceability ist Voraussetzung für Compliance und Audits
Traceability-Matrix:
| Geschäftsanforderung (BR) | Funktionale Anforderung (FR) | NFR | Stakeholder |
|---|---|---|---|
| BR-001: Umsatz +10% | FR-001: Mobile App | NFR-P001: Performance | CEO, CRO |
| FR-002: Personalisierung | NFR-U001: Usability | Product Owner | |
| FR-003: KI-Scoring | NFR-S001: Security | Data Scientist |
3. Die SMART-Kriterien
Das SMART-Prinzip ist eine Alternative oder Ergänzung zu den 9 C-Requirements.
| S | Specific (Spezifisch) | Konkret, eindeutig | | M | Measurable (Messbar) | Quantifizierbar, verifizierbar | | A | Achievable (Erreichbar) | Realistisch, machbar | | R | Relevant (Relevant) | Wichtig, notwendig | | T | Time-bound (Terminiert) | Zeitrahmen definiert |
SMART vs. 9 C
Anforderung: "Login in < 2 Sekunden"
SMART: * Specific: ✅ (2 Sekunden) * Measurable: ✅ (Zeitmessung) * Achievable: ✅ (Mit Optimierung machbar) * Relevant: ✅ (Performance-Anforderung) * Time-bound: ❌ (Kein Zeitrahmen definiert)
9 C: * Complete: ❌ (Nur Response Time, keine weiteren Bedingungen) * Correct: ✅ * Consistent: ✅ * Clear: ✅ * Concise: ✅ * Concrete: ✅ * Atomic: ✅ * Unique: ✅ * Traceable: ❌ (Nicht mit Geschäftszielen verknüpft)
4. Praxis-Beispiel: Qualitätsprüfung von Anforderungen
Szenario: CRM-System
Sie prüfen die Qualität der Anforderungen für ein CRM-System.
4.1 Anforderungen prüfen
Anforderung 1: "Der Benutzer kann sich in das System einloggen"
| C-Kriterium | Bewertung | Bemerkung |
|---|---|---|
| Complete | ❌ | Fehlende Details (Was für ein Login? Welche Credentials?) |
| Correct | ✅ | Faktisch korrekt |
| Consistent | ✅ | Keine Widersprüche zu anderen Anforderungen |
| Clear | ✅ | Einfach verständlich |
| Concise | ✅ | Kurz und bündig |
| Concrete | ❌ | Nicht testbar (Welche Credentials? Welche Validation?) |
| Atomic | ✅ | Ein Thema (Login) |
| Unique | ✅ | Keine Dopplung |
| Traceable | ❌ | Nicht mit Geschäftszielen verknüpft |
Verbesserte Anforderung: "Benutzer kann sich mit Benutzername/E-Mail und Passwort einloggen. Passwort muss mind. 8 Zeichen enthalten, davon mind. 1 Großbuchstabe, 1 Kleinbuchstabe und 1 Zahl. Nach 3 fehlerhaften Versuchen: 5-Minuten-Sperrung. Verknüpft mit BR-001 (Umsatzsteigerung durch bessere Kundenbindung)."
Anforderung 2: "Das System muss schnell sein"
| C-Kriterium | Bewertung | Bemerkung |
|---|---|---|
| Complete | ❌ | Fehlende Details (Was ist "schnell"?) |
| Correct | ✅ | Faktisch korrekt |
| Consistent | ✅ | Keine Widersprüche |
| Clear | ❌ | "Schnell" ist vage |
| Concise | ✅ | Kurz |
| Concrete | ❌ | Nicht testbar |
| Atomic | ❌ | Nicht spezifisch |
| Unique | ✅ | Keine Dopplung |
| Traceable | ❌ | Nicht verknüpft |
Verbesserte Anforderung: "Das System muss in < 2 Sekunden auf eine Anfrage antworten bei 1000 gleichzeitigen Benutzern. Login-Prozess muss in < 2 Sekunden abgeschlossen sein. Produktsuche muss Ergebnisse in < 1 Sekunde zurückgeben. Checkout-Prozess muss in < 3 Sekunden abgeschlossen sein."
4.2 Qualitäts-Checkliste
Für jede Anforderung prüfen Sie:
| C-Kriterium | Frage | Ja/Nein |
|---|---|---|
| Complete | Enthält die Anforderung alle notwendigen Informationen? | ☐ |
| Correct | Ist die Anforderung faktisch korrekt? | ☐ |
| Consistent | Gibt es Widersprüche zu anderen Anforderungen? | ☐ |
| Clear | Ist die Anforderung eindeutig verständlich? | ☐ |
| Concise | Ist die Anforderung kurz und bündig? | ☐ |
| Concrete | Ist die Anforderung verifizierbar und testbar? | ☐ |
| Atomic | Ist die Anforderung nicht aufspaltbar? | ☐ |
| Unique | Gibt es Dopplungen zu anderen Anforderungen? | ☐ |
| Traceable | Ist die Anforderung mit Geschäftszielen verknüpft? | ☐ |
5. Häufige Fehler bei Anforderungen
| Fehler | Warum problematisch | Lösung |
|---|---|---|
| "Das System muss benutzerfreundlich sein" | Nicht testbar, subjektiv | "Neue Benutzer können sich in < 3 Minuten registrieren" |
| "Das System muss schnell sein" | Nicht konkret | "Antwortzeit < 2 Sekunden bei 1000 Usern" |
| "Wenn möglich, dann Feature X" | Nicht priorisierbar | Priorisierung: MoSCoW (Must, Should, Could, Won't) |
| "Das System soll Feature X und Y haben" | Nicht atomar | Aufteilung in FR-001 (Feature X) und FR-002 (Feature Y) |
| "Das System muss 100% verfügbar sein" | Nicht realistisch | "99.9% Verfügbarkeit (8,76 Stunden Downtime/Jahr)" |
| "Das System muss DSGVO-konform sein" | Nicht atomar | Aufteilung in mehrere Anforderungen (Consent, Data Deletion, Data Portability) |
6. Zusammenfassung und Checkliste
6.1 Erfolgsfaktoren
- Qualitätskriterien anwenden: Nutzen Sie die 9 C-Requirements oder SMART
- Iterativ prüfen: Anforderungen mehrfach prüfen und verbessern
- Stakeholder involvieren: Lassen Sie Stakeholder Anforderungen validieren
- Beispiele nutzen: Nutzen Sie Beispiele für gute Anforderungen
- Dokumentation: Alle Anforderungen dokumentieren
6.2 Checkliste für Ihre Anforderungen
Für jede Anforderung prüfen Sie:
Qualitätsprüfung
- Complete: Enthält die Anforderung alle Informationen?
- Correct: Ist die Anforderung faktisch korrekt?
- Consistent: Gibt es Widersprüche?
- Clear: Ist die Anforderung eindeutig?
- Concise: Ist die Anforderung kurz und bündig?
- Concrete: Ist die Anforderung testbar?
- Atomic: Ist die Anforderung nicht aufspaltbar?
- Unique: Gibt es Dopplungen?
- Traceable: Ist die Anforderung verknüpft?
Validierung
- Stakeholder involviert: Rückmeldung erhalten?
- Beispiele geprüft: Beispiele für gute Anforderungen genutzt?
- Iterativ verbessert: Anforderungen mehrfach überarbeitet?
7. Weiterführende Themen
- Anforderungsermittlung: Methoden (Interviews, Workshops, Persona, Kano-Modell)
- Anforderungsanalyse: Verifikation, Priorisierung (MoSCoW, Kano)
- Anforderungsmanagement: Traceability, Change Management, Versionierung
Nächster Schritt: Lernen Sie Methoden zur Anforderungsermittlung (Kapitel 03).