Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
70 % aller IT-Projekte scheitern an unklaren Anforderungen (Standish Chaos Report). Wer Anforderungen sauber erhebt, dokumentiert und priorisiert, gewinnt, egal ob Wasserfall, Scrum oder Banane.
Die Idee in einem Satz
Anforderungsanalyse (Requirements Engineering): Systematisches Erheben, Dokumentieren, Validieren und Verwalten aller Erwartungen an ein Software-System.
Die Hauptfrage: Was soll das System tun?
Das ist die zentrale Frage, aber sie reicht nicht. Es gibt 2 Hauptkategorien:
| Kategorie | Frage | Beispiel |
|---|---|---|
| Funktional | Was tut das System? | "System muss Benutzer per E-Mail registrieren können." |
| Nicht-funktional | Wie tut es das? Wie gut? | "Die Registrierung muss in < 2 Sekunden abgeschlossen sein." |
1. Funktionale Anforderungen (FA)
Definition: Beschreiben welche Funktionen das System bereitstellt.
Beispiele Online-Shop:
- Benutzer kann sich mit E-Mail und Passwort registrieren.
- Benutzer kann Produkte in den Warenkorb legen.
- System sendet Bestellbestätigung per E-Mail.
- Admin kann Produkt-Bestände bearbeiten.
Format: Oft als User Story ("Als <Rolle> möchte ich <Funktion>, um <Nutzen>") oder als Use Case.
2. Nicht-funktionale Anforderungen (NFA)
Definition: Beschreiben wie das System seine Funktionen erfüllt, Qualitäts-Eigenschaften.
ISO 25010 definiert 8 Qualitätsmerkmale (Klausur-Klassiker):
| Merkmal | Beispiel |
|---|---|
| Functional Suitability | Tut das System das, was gefordert ist? |
| Performance Efficiency | Antwortzeiten, Durchsatz, Ressourcen-Verbrauch |
| Compatibility | Mit welchen Browsern/OS funktioniert es? |
| Usability | Lernzeit, Effizienz, Zufriedenheit |
| Reliability | Verfügbarkeit, Fehlertoleranz, Recovery |
| Security | Vertraulichkeit, Integrität, Authentizität |
| Maintainability | Wartbarkeit, Modularität, Testbarkeit |
| Portability | Anpassbar an verschiedene Umgebungen |
Konkrete NFA-Beispiele:
- Performance: Login muss in < 2 Sekunden abgeschlossen sein.
- Verfügbarkeit: System muss 99,9 % verfügbar sein (= < 8,7 h Ausfall/Jahr).
- Sicherheit: Passwörter müssen mit bcrypt (cost ≥ 12) gehasht werden.
- Skalierbarkeit: System muss 10.000 gleichzeitige Nutzer unterstützen.
- Usability: Neue Nutzer sollen ohne Schulung 80 % der Funktionen finden.
3. Sonstige Anforderungs-Arten
- Domänen-Anforderungen: Aus dem Fachgebiet (z.B. "DSGVO-konform" bei EU-Software).
- Schnittstellen-Anforderungen: Wie integriert sich das System mit anderen Systemen?
Erhebungs-Techniken
| Technik | Wann? |
|---|---|
| Interview | Tiefes Verständnis einzelner Stakeholder |
| Workshop | Konsens-Bildung in Gruppen |
| Beobachtung | Realer Arbeitsablauf (etwa für Office-Tools) |
| Fragebogen | Viele Stakeholder, vergleichbare Antworten |
| Prototyping | Bei unklaren Anforderungen, "show, not tell" |
| Story-Telling | Persona + Customer Journey für UX-Anforderungen |
Dokumentations-Formate
| Format | Charakteristik |
|---|---|
| Lastenheft (DIN 69901) | Was der Kunde will (vom Auftraggeber) |
| Pflichtenheft | Wie es umgesetzt wird (vom Auftragnehmer) |
| User Story (Scrum) | "Als X möchte ich Y, um Z", kurz und nutzer-zentriert |
| Use Case (UML) | Detaillierter Ablauf inkl. Alternativen + Fehlerfälle |
Priorisierung: MoSCoW-Methode
| Buchstabe | Bedeutung |
|---|---|
| Must | Muss zwingend rein. Ohne diese Features ist das Projekt gescheitert. |
| Should | Sollte rein. Wichtig, aber nicht überlebenswichtig. |
| Could | Könnte rein, wenn Zeit ist. Nice-to-have. |
| Won't | Wird NICHT umgesetzt (in diesem Release). |
Alternative: Kano-Modell (Basis-/Leistungs-/Begeisterungs-Merkmale).
Klausur-Faustregeln
1. FA vs. NFA: Funktional = WAS, Nicht-funktional = WIE/WIE GUT.
2. NFAs auf -ität enden meist: Performance, Verfügbarkeit, Sicherheit, Usability, Skalierbarkeit, Wartbarkeit, Portabilität.
3. ISO 25010 hat 8 Qualitätsmerkmale, drei davon im Schlaf können: Performance, Reliability, Security.
4. Lastenheft = Kunde, Pflichtenheft = Auftragnehmer. Lasten "wir wollen", Pflichten "wir liefern".
5. SMART-Anforderungen: Specific, Measurable, Achievable, Relevant, Time-bound.
6. MoSCoW für Priorisierung, Must / Should / Could / Won't.
Häufige Stolpersteine
1. FA und NFA verwechseln. "System muss schnell sein" ist NFA (Performance). "System muss Produkte zeigen" ist FA. Daumenregel: wenn du es messen kannst (Sekunden, Prozent, GB), ist es oft NFA.
2. Vage Anforderungen. "Das System muss schnell sein", wie schnell? In welcher Situation? Besser: "Login muss in < 2 Sekunden bei 100 gleichzeitigen Nutzern erfolgen."
3. Lasten- und Pflichtenheft verwechseln. Lasten = WAS (Kunde formuliert), Pflichten = WIE (Auftragnehmer beschreibt seine Lösung).
4. Anforderungen mit Lösungen vermischen. Falsch: "System soll React Native nutzen". Richtig: "System muss auf iOS und Android laufen", die TECHNOLOGIE ist Sache des Entwurfs, nicht der Anforderung.
5. NFAs ignorieren. Wer nur FAs sammelt, baut funktionale Software, die niemand nutzt (zu langsam, unsicher, unbedienbar).
6. MoSCoW falsch verteilen. Wenn ALLES "Must" ist, ist nichts "Must". Faustregel: max. 60 % Must, ca. 20 % Should, 20 % Could.
Interaktiv verstehen
Anforderungen klassifizieren
Ordne Anforderungen den Kategorien funktional / nicht-funktional zu. Bei NFAs kannst du sehen, welches der 8 ISO-25010-Merkmale gemeint ist.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: In der Klausur kommen meistens Aufgaben wie "Klassifiziere folgende 5 Anforderungen". Daumenregel: kann ich es in Zahlen messen (Sekunden, Prozent, Zeichen, GB)? → NFA. Beschreibt es eine Funktion/Aktion des Systems? → FA.
Praxis-Übung
Anforderungsanalyse, Praxis-Übung
6 Aufgaben zu Klassifikation, Dokumentations-Formaten und Priorisierung.
Klausurfragen mit Lösungen (6)
- F1.Welche Anforderung ist NICHT-funktional?
Antwort: Login muss in unter 2 Sekunden abgeschlossen sein
Erklärung: Performance-Anforderung (< 2 Sek.) ist NFA, sie beschreibt WIE GUT eine Funktion erfüllt wird, nicht WAS sie tut. Die anderen 3 beschreiben Funktionen (FA: was tut das System).
- F2.Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Antwort: Lastenheft = was der Kunde will, Pflichtenheft = wie es umgesetzt wird
Erklärung: Lastenheft kommt vom AUFTRAGGEBER (Kunde): WAS soll gebaut werden, welche Anforderungen. Pflichtenheft kommt vom AUFTRAGNEHMER (Entwickler/Firma): WIE wird es umgesetzt, technisches Konzept. Eselsbrücke: Lasten (will) vs Pflichten (liefert).
- F3.Ordne die NFA-Beispiele den ISO-25010-Qualitätsmerkmalen zu.
Zuordnungen:
- Login < 2 Sek. → Performance Efficiency
- 99,9 % Verfügbarkeit → Reliability
- Passwörter bcrypt-gehasht → Security
- Neue Nutzer ohne Schulung 80 % der Funktionen → Usability
Erklärung: Die 4 wichtigsten NFA-Merkmale aus ISO 25010 in der Klausur: Performance (Geschwindigkeit/Ressourcen), Reliability (Verfügbarkeit/Fehlertoleranz), Security (Vertraulichkeit/Integrität), Usability (Bedienbarkeit). Im Schlaf können, sind in jeder zweiten Klausur dabei.
Typ: Zuordnung
- F4.MoSCoW-Methode: Welche Bedeutung hat das 'W'?
Antwort: Won't (wird in diesem Release NICHT umgesetzt)
Erklärung: MoSCoW = Must / Should / Could / Won't. Das 'W' bedeutet explizit 'WIRD NICHT umgesetzt', wichtig für klares Erwartungs-Management. Es ist kein 'vielleicht später' (das wäre Could), sondern eine bewusste Entscheidung gegen die Anforderung im aktuellen Release.
- F5.Die Anforderung 'Das System muss React Native nutzen' ist eine funktionale Anforderung.
Antwort: Falsch
Erklärung: FALSCH. Das ist eine Technologie-Entscheidung, gehört in den Entwurf, KEINE Anforderung. Eine korrekte Anforderung wäre: 'System muss auf iOS und Android laufen' (NFA: Portabilität/Kompatibilität). Die Wahl von React Native vs. native Apps vs. Flutter ist Sache des Architekten.
Typ: Wahr/Falsch
- F6.Welche Eigenschaft hat eine SMART-Anforderung?
Antwort: Specific, Measurable, Achievable, Relevant, Time-bound
Erklärung: SMART = Specific (eindeutig), Measurable (messbar), Achievable (erreichbar), Relevant (wichtig fürs Ziel), Time-bound (mit Zeit-Bezug). Beispiel: 'Performance < 2 Sek. unter 100 Nutzer-Last bis Release v1.5' ist SMART. 'Schnell und gut' ist es nicht.
Klausur-Quiz
Anforderungsanalyse, Klausur-Quiz
6 typische Klausurfragen zum Konzept, ISO 25010 und Praxis.
Klausurfragen mit Lösungen (6)
- F1.Welche der folgenden Anforderungen ist FUNKTIONAL?
Antwort: Benutzer kann sein Passwort per E-Mail zurücksetzen
Erklärung: Funktional = beschreibt eine FUNKTION. 'Passwort per E-Mail zurücksetzen' ist eine konkrete Funktion. Die anderen 3 sind alle NFA: DSGVO-konform (Compliance), 99,9 % verfügbar (Reliability), iOS+Android (Portability).
- F2.Was beschreibt das Lastenheft?
Antwort: Die Anforderungen aus Auftraggeber-Sicht
Erklärung: Das Lastenheft (DIN 69901) wird vom AUFTRAGGEBER formuliert und beschreibt die Anforderungen an das Produkt, WAS gebraucht wird. Der Auftragnehmer antwortet darauf mit dem Pflichtenheft (WIE er es umsetzen will).
- F3.Die Norm {{1}} 25010 definiert 8 Qualitätsmerkmale für nicht-funktionale Anforderungen. Drei davon sind {{2}} (Antwortzeiten), {{3}} (Verfügbarkeit) und Security.
Lösungen pro Lücke:
- {{1}}: ISO
- {{2}}: Performance / Performance Efficiency
- {{3}}: Reliability
Erklärung: ISO 25010 ist der Nachfolger der ISO 9126 und definiert 8 Qualitätsmerkmale: Functional Suitability, Performance Efficiency, Compatibility, Usability, Reliability, Security, Maintainability, Portability. Die wichtigsten 3 in Klausuren sind Performance, Reliability, Security, diese im Schlaf können.
Typ: Lückentext
- F4.Bringe die Phasen der Anforderungsanalyse in die richtige Reihenfolge.
Richtige Reihenfolge:
- Erhebung (was wollen die Stakeholder?)
- Dokumentation (Lastenheft / User Stories)
- Validierung (sind die Anforderungen richtig?)
- Verwaltung (Änderungen während Projekt)
Erklärung: Standard-Reihenfolge: 1) Erhebung (Interviews/Workshops mit Stakeholdern), 2) Dokumentation (Anforderungen formal niederschreiben), 3) Validierung (Stakeholder bestätigen, Verifikation prüft Korrektheit, Validierung prüft ob die richtigen Anforderungen erhoben wurden), 4) Verwaltung (Änderungsmanagement während des gesamten Projekts).
Typ: Reihenfolge
- F5.Ein Stakeholder sagt: 'Das System soll schnell sein'. Was ist das Problem mit dieser Anforderung?
Antwort: Sie ist nicht messbar (SMART-Kriterium 'Measurable' verletzt)
Erklärung: Die Anforderung verletzt das 'M' in SMART (Measurable). 'Schnell' ist subjektiv, 1 Sekunde? 100 ms? In welcher Last-Situation? Bei welcher Aktion? Bessere Version: 'Login muss in < 2 Sekunden unter 100 gleichzeitigen Nutzern abgeschlossen sein.' Dann kann man testen, ob die Anforderung erfüllt ist.
- F6.Bei der MoSCoW-Priorisierung sollten möglichst viele Anforderungen als 'Must' eingestuft werden, damit nichts vergessen wird.
Antwort: Falsch
Erklärung: FALSCH. Wenn ALLES Must ist, ist NICHTS Must, das Wort verliert seine Bedeutung. Faustregel: max. 60 % Must, dann ca. 20 % Should, 20 % Could. 'Must' bedeutet: ohne diese Anforderung ist das Projekt gescheitert. Tipp aus der Praxis: lass den Product Owner zuerst alle Anforderungen aufschreiben, dann zwingen ihn, max. 60 % als Must zu markieren, das schärft die Priorisierung enorm.
Typ: Wahr/Falsch
