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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
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.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
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.
Anforderungsanalyse (Requirements Engineering): Systematisches Erheben, Dokumentieren, Validieren und Verwalten aller Erwartungen an ein Software-System.
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." |
Definition: Beschreiben welche Funktionen das System bereitstellt.
Beispiele Online-Shop:
Format: Oft als User Story ("Als <Rolle> möchte ich <Funktion>, um <Nutzen>") oder als Use Case.
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:
| 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 |
| 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 |
| 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).
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.
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.
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.
6 Aufgaben zu Klassifikation, Dokumentations-Formaten und Priorisierung.
Klausurfragen mit Lösungen (6)
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).
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).
Zuordnungen:
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
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.
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
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.
6 typische Klausurfragen zum Konzept, ISO 25010 und Praxis.
Klausurfragen mit Lösungen (6)
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).
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).
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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.
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