Anforderungsanalyse und -management

Aktives Lernen funktioniert hier besonders gut, weil Anforderungsanalyse und -management vor allem durch Erfahrung und Reflexion gelernt werden. Schüler:innen verstehen Methoden und Dokumente besser, wenn sie sie direkt anwenden und ihre Wirkung erleben. Die Stationenrotation und Gruppenarbeiten zeigen sofort, warum strukturiertes Vorgehen wichtig ist und wie sich Anforderungen in realen Projekten entwickeln.

• Klasse 13
• Informatik Oberstufe: Komplexe Systeme und Theoretische Grundlagen
• 4 Aktivitäten
• 30 Min.–60 Min.

Lernziele

1. Analysieren Sie die Auswirkungen von Änderungen der Anforderungen auf Zeitpläne, Kosten und Qualität eines Softwareprojekts.
2. Entwerfen Sie eine Methode zur Erhebung von Benutzeranforderungen unter Berücksichtigung verschiedener Stakeholder-Gruppen.
3. Bewerten Sie die Eignung verschiedener Dokumentationsformate (z.B. User Stories, Use Cases) für spezifische Projektkontexte.
4. Erstellen Sie ein einfaches Change-Management-Protokoll für eine hypothetische Anforderungsänderung.
5. Klassifizieren Sie Anforderungen in funktionale und nicht-funktionale Kategorien und begründen Sie die Klassifizierung.

Fallstudienanalyse

⏱ 50 Min.·Kleingruppen

Stationenrotation: Erhebungsmethoden

Richten Sie vier Stationen ein: Interviews (Rollenspiele), Umfragen (Fragebögen entwerfen), Workshops (Brainstorming) und Beobachtung (Szenario-Video analysieren). Gruppen rotieren alle 10 Minuten, erheben Anforderungen zu einem fiktiven App-Projekt und dokumentieren sie. Abschließend vergleichen sie Ergebnisse.

Vorbereitung & Details

Erklären Sie die Bedeutung klar definierter Anforderungen für den Projekterfolg.

Moderationstipp: Stellen Sie bei der Stationenrotation sicher, dass jede Methode mit einem konkreten Beispiel aus der Praxis eingeführt wird, z.B. ein Interview-Leitfaden oder ein Workshop-Ablaufplan.

Setup: Gruppentische mit Platz für die Fallunterlagen

Materials: Fallstudien-Paket (3-5 Seiten), Arbeitsblatt mit Analyseraster, Präsentationsvorlage

• Analysieren
• Bewerten
• Erschaffen
• Entscheidungsfähigkeit
• Selbststeuerung

Fallstudienanalyse

⏱ 30 Min.·Partnerarbeit

Paararbeit: User Stories schreiben

Teilen Sie ein Stakeholder-Szenario aus. Paare führen ein kurzes Interview, identifizieren Anforderungen und formulieren User Stories im Format 'Als [User], möchte ich [Feature], damit [Nutzen]'. Sie priorisieren und präsentieren.

Vorbereitung & Details

Designen Sie Methoden zur Erhebung und Dokumentation von Benutzeranforderungen.

Moderationstipp: Bei der Paararbeit zu User Stories achten Sie darauf, dass beide Partner abwechselnd die Rolle des Entwicklers und des Stakeholders einnehmen, um Perspektiven zu wechseln.

Setup: Gruppentische mit Platz für die Fallunterlagen

Materials: Fallstudien-Paket (3-5 Seiten), Arbeitsblatt mit Analyseraster, Präsentationsvorlage

• Analysieren
• Bewerten
• Erschaffen
• Entscheidungsfähigkeit
• Selbststeuerung

Fallstudienanalyse

⏱ 60 Min.·Kleingruppen

Gruppenprojekt: Change Management

Gruppen erhalten ein Requirements-Dokument und simulierte Änderungsanfragen. Sie führen Impact-Analysen durch, aktualisieren das Dokument und erstellen einen Change-Log. Diskutieren Sie Auswirkungen auf den Projektplan.

Vorbereitung & Details

Analysieren Sie die Auswirkungen sich ändernder Anforderungen auf den Entwicklungsprozess.

Moderationstipp: Beim Gruppenprojekt zu Change Management geben Sie den Schülern eine klare Rolle im Projektteam vor, z.B. Projektleiter:in oder Qualitätsmanager:in, um Verantwortung zu fördern.

Setup: Gruppentische mit Platz für die Fallunterlagen

Materials: Fallstudien-Paket (3-5 Seiten), Arbeitsblatt mit Analyseraster, Präsentationsvorlage

• Analysieren
• Bewerten
• Erschaffen
• Entscheidungsfähigkeit
• Selbststeuerung

Fallstudienanalyse

⏱ 40 Min.·Ganze Klasse

Klassenrunde: Requirements Review

Jede Gruppe präsentiert ihr Requirements-Set. Die Klasse stellt Fragen als Stakeholder, bewertet Vollständigkeit und Klarheit. Sammeln Sie Feedback in einer gemeinsamen Tabelle.

Vorbereitung & Details

Erklären Sie die Bedeutung klar definierter Anforderungen für den Projekterfolg.

Moderationstipp: In der Klassenrunde zum Requirements Review moderieren Sie die Diskussion aktiv, indem Sie gezielt nach Begründungen für Priorisierungen oder Dokumentationsentscheidungen fragen.

Setup: Gruppentische mit Platz für die Fallunterlagen

Materials: Fallstudien-Paket (3-5 Seiten), Arbeitsblatt mit Analyseraster, Präsentationsvorlage

• Analysieren
• Bewerten
• Erschaffen
• Entscheidungsfähigkeit
• Selbststeuerung

Dieses Thema unterrichten

Erfahrene Lehrkräfte setzen auf iterative Prozesse, bei denen Schüler:innen Anforderungen zunächst grob erfassen und dann schrittweise verfeinern. Wichtig ist, Misserfolge wie unklare Anforderungen oder Priorisierungskonflikte als Lernchance zu nutzen. Vermeiden Sie es, fertige Lösungen vorzugeben, sondern lassen Sie die Klasse selbst Lösungswege entwickeln. Forschung zeigt, dass kollaboratives Arbeiten und der Einsatz von Rollenspielen die Transferleistung in reale Projekte stark fördert.

Was Sie erwartet

Erfolg zeigt sich, wenn Schüler:innen Anforderungen nicht nur sammeln, sondern auch priorisieren, dokumentieren und im Team diskutieren können. Sie erkennen, dass Anforderungen lebendig sind und sich durch neue Erkenntnisse ändern. Die Artefakte wie User Stories oder Use Cases sollten klar, verständlich und für Stakeholder nachvollziehbar sein.

Vorsicht vor diesen Fehlvorstellungen

Häufige Fehlvorstellung

Während der Stationenrotation zu Erhebungsmethoden hören manche Schüler:innen nur oberflächlich zu und denken, Anforderungen seien ein einmaliger Schritt.

Was Sie stattdessen lehren sollten

Nutzen Sie die Stationenrotation, um direkt zu zeigen, wie sich Anforderungen durch Feedback entwickeln. Lassen Sie die Schüler:innen z.B. nach einem Stakeholder-Interview eine erste Version der Anforderungen aufschreiben und dann eine zweite Version nach einem Workshop erstellen. So sehen sie den Unterschied.

Häufige Fehlvorstellung

In der Paararbeit zu User Stories gehen manche davon aus, dass alle Anforderungen gleich wichtig sind.

Was Sie stattdessen lehren sollten

In der Paararbeit führen Sie die MoSCoW-Methode als festen Schritt ein. Lassen Sie die Schüler:innen jede User Story mit M, S, C oder W markieren und begründen, warum. Diskutieren Sie im Plenum, wie sich Prioritäten durch neue Erkenntnisse ändern können.

Häufige Fehlvorstellung

Was Sie stattdessen lehren sollten

Nutzen Sie die Klassenrunde, um den Wert schriftlicher Dokumentation konkret zu zeigen. Lassen Sie die Schüler:innen eine zuvor erstellte Requirements-Spezifikation mit einer mündlichen Zusammenfassung vergleichen und diskutieren, wo Missverständnisse entstehen könnten.

Ideen zur Lernstandserhebung

Diskussionsfrage

Nach der Stationenrotation zu Erhebungsmethoden stellen Sie die Frage: 'Welche Methode hat euch am meisten überrascht und warum? Welche Anforderungen hättet ihr mit dieser Methode besser erhoben?' Lassen Sie die Schüler:innen ihre Antworten in Kleingruppen sammeln und im Plenum vergleichen.

Lernstandskontrolle

Nach der Paararbeit zu User Stories geben Sie den Schüler:innen die Aufgabe, auf einem Zettel eine User Story zu formulieren, die eine Anforderung an ein Schulprojekt beschreibt. Fordern Sie sie auf, die Akzeptanzkriterien zu nennen und zu begründen, warum diese Story priorisiert wurde.

Kurze Überprüfung

Während des Gruppenprojekts zum Change Management lassen Sie die Schüler:innen in einer kurzen Reflexion notieren, wie sie mit einem Change Request umgegangen sind. Sammeln Sie die Notizen und diskutieren Sie im Plenum, welche Strategien erfolgreich waren und wo es haperte.

Erweiterungen & Unterstützung

• Fordern Sie schnelle Schüler:innen auf, eine Requirements-Spezifikation für ein fiktives, aber komplexes System wie ein Schulverwaltungsportal zu erstellen und mit MoSCoW zu priorisieren.
• Bei Unsicherheit im Umgang mit User Stories geben Sie den Schüler:innen eine Vorlage mit Mustersätzen und lassen Sie sie diese auf konkrete Anforderungen anpassen.
• Für vertiefende Einblicke lassen Sie die Klasse ein fiktives Change-Request-Verfahren durchspielen, z.B. die Anpassung eines Features nachträglich in ein bestehendes Projekt einzuplanen.

Schlüsselvokabular

Stakeholder	Eine Person oder Gruppe, die ein Interesse an einem Projekt hat oder davon betroffen ist. Dies können Nutzer, Kunden, Entwickler oder Manager sein.
User Story	Eine kurze, einfache Beschreibung einer Funktion aus der Perspektive des Benutzers, die typischerweise im Format 'Als ein [Rolle] möchte ich [Ziel], damit [Nutzen]' verfasst wird.
Use Case	Eine Beschreibung der Interaktion zwischen einem Benutzer (Akteur) und einem System zur Erreichung eines bestimmten Ziels, die alternative Abläufe und Fehlerfälle einschließt.
Scope Creep	Die unkontrollierte Erweiterung des Projektumfangs durch zusätzliche Funktionen oder Anforderungen, die nicht ursprünglich geplant waren und den Zeitplan sowie das Budget gefährden können.
Nicht-funktionale Anforderung	Eine Anforderung, die beschreibt, wie ein System funktionieren soll, anstatt was es tun soll. Beispiele sind Leistung, Sicherheit, Benutzerfreundlichkeit oder Wartbarkeit.