Übungsaufgaben: funktionale und nichtfunktionale Anforderungen

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Übungsaufgaben: funktionale und
nichtfunktionale Anforderungen“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/anforderungsanalyse
- https://oer-informatik.de/anforderungsanalyse-ermittlung
- https://oer-informatik.de/anforderungsanalyse-dokumentieren
- https://oer-informatik.de/softwarequalitaet
- https://oer-informatik.de/stakeholderanalyse
- https://oer-informatik.de/usability-barrierefreiheit
- Stilbeispiel: https://oer-informatik.de/anforderungsarten-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Anforderungsanalyse
- Funktionale Anforderungen
- Nichtfunktionale Anforderungen
- Anforderungsermittlung
- Ist-Aufnahme
- Schwachstellenanalyse
- Akzeptanzkriterium
- Verfügbarkeit
- ISO/IEC 25010

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Nennung (3 × 1 Punkt), z. B.:

• Interview (z. B. mit Thomas Becker, Andrea Wolf oder Svenja Krämer)

• Fragebogen / Online-Umfrage (an alle pendelnden Auszubildenden)

• Beobachtung (wie Fahrgemeinschaften heute organisiert werden)

• Workshop mit der Schülervertretung, z. B. mit Brainstorming

• Dokumentenanalyse (Datenschutzregeln der Schule, Schultage der Klassen, Fahrpläne)

• Prototyp bzw. Klickdummy, der Testpersonen vorgeführt wird

Beschreibung (2 Punkte), z. B. für den Fragebogen: Das Team verschickt über das Schulkonto einen kurzen Online-Fragebogen an alle Klassen. Gefragt wird nach Wohnort bzw. nächstem Haltepunkt, Schultagen, gewünschter Ankunftszeit, ob ein Auto vorhanden ist und welche drei Funktionen am wichtigsten sind. Die Auswertung zeigt, welche Haltepunkte und Uhrzeiten die App unbedingt abdecken muss. Der Fragebogen wird anonym ausgewertet.

Ebenso richtig ist z. B. ein Interview mit Andrea Wolf mit vorbereitetem Leitfaden zu Einwilligungen, Löschfristen und den Daten auf den Monitoren oder die Beobachtung, wie sich Auszubildende heute über Messenger-Gruppen und Aushänge verabreden. Eine Beschreibung ohne Bezug zu RatzFahrt erhält höchstens 1 Punkt.

Je Gedanke 1 Punkt, z. B.:

• Ein Fragebogen erfasst nur, was die Befragten vorher kennen und benennen können. Viele Barrieren fallen erst bei der Bedienung auf, z. B. unbeschriftete Schaltflächen, eine unlogische Reihenfolge beim Durchblättern mit dem Screenreader oder eine Zeitbegrenzung beim Bestätigen.

• Bei der Beobachtung sieht das Team, an welcher Stelle Lukas hängen bleibt, und kann gezielt nachfragen. Daraus entstehen konkrete, prüfbare Anforderungen (z. B. „Jede Schaltfläche hat einen Namen, den der Screenreader vorliest“).

• Ein Fragebogen ist selbst nicht unbedingt barrierefrei; außerdem gibt es nur wenige betroffene Personen, sodass sich eine statistische Auswertung kaum lohnt.

• Funktionale Anforderungen (1 Punkt) beschreiben, was das System tun soll: seine Funktionen, sein Verhalten bei bestimmten Eingaben und seine Ergebnisse.

• Nichtfunktionale Anforderungen (1 Punkt) beschreiben, wie gut oder unter welchen Bedingungen das System seine Funktionen erfüllt. Dazu gehören Qualitätsanforderungen (z. B. Verfügbarkeit, Antwortzeit, Benutzbarkeit, Sicherheit) und Randbedingungen (z. B. gesetzliche oder technische Vorgaben, Budget, Termine).

• Beispiel funktional (1 Punkt): Fahrer*innen können eine Fahrt anbieten; Mitfahrende können eine Anfrage stellen, die bestätigt oder abgelehnt wird.

• Beispiel nichtfunktional (1 Punkt): Die Anmeldung muss über das vorhandene Schulkonto erfolgen (technische Vorgabe, Randbedingung) oder die Monitore dürfen keine Namen zeigen (Datenschutzvorgabe).

Achtung: „Die Monitore zeigen offene Angebote“ ist funktional (Anzeige von Daten). Nichtfunktional ist die Bedingung „ohne Namen“.

Je Zeile 2,5 Punkte: 0,5 Punkte für die richtige Art, 1 Punkt für eine passende Anforderung als ganzer Satz mit Bezug zu RatzFahrt, 1 Punkt für ein prüfbares Akzeptanzkriterium (Messgröße, Bedingung, Grenzwert oder eindeutig beobachtbares Ergebnis). Ein Stichwort wie „Usability“ allein erhält höchstens 0,5 Punkte. Dieselbe Anforderung in zwei Formulierungen zählt einmal.

Weitere passende funktionale Anforderungen, z. B.:

• Beim Anbieten einer Fahrt wählt die Fahrerin oder der Fahrer den Treffpunkt nur aus einer Liste öffentlicher Haltepunkte aus.

• Die App prüft den Kostenbeitrag anhand der Entfernung zwischen Haltepunkt und Schule und lehnt Beträge über 0,10 € je km und Person mit einem Hinweis ab.

• Eine Anfrage einer minderjährigen Person ist nur möglich, wenn in ihrem Konto die Einwilligung der Erziehungsberechtigten eingetragen ist.

• 30 Minuten vor der Abfahrt erhalten Fahrer*in und bestätigte Mitfahrende eine Erinnerung per Push-Nachricht oder E-Mail an das Schulkonto.

• Zum Ende des Schuljahres löscht die App alle Angebote, Gesuche und Buchungen des Schuljahres.

Weitere passende nichtfunktionale Anforderungen, z. B.:

• Antwortzeit: Die Liste der offenen Angebote wird auch bei 300 gleichzeitigen Nutzenden in 95 % der Abrufe in höchstens 2 Sekunden angezeigt.

• Barrierefreiheit: Die App erfüllt die WCAG 2.2 auf Stufe AA und ist vollständig mit einem Screenreader bedienbar (die Schule ist eine öffentliche Stelle).

• Benutzbarkeit: Acht von zehn Testpersonen ohne Vorkenntnisse können ohne Hilfe innerhalb von zwei Minuten eine Fahrt anbieten.

• Sprache: Alle Texte gibt es auf Deutsch und auf Englisch.

• Sicherheit und Datenschutz: Die Daten werden nur verschlüsselt (TLS) übertragen und auf Servern der Schul-IT OWL bzw. in der EU gespeichert; Verarbeitung nach DSGVO und den Datenschutzregeln der Schule.

„Die App läuft auf Android und iOS“ ist keine Funktion. Als funktionale Anforderung eingetragen, erhält die Zeile für die Art keinen Punkt; als nichtfunktionale Anforderung (Randbedingung) ist sie richtig, wenn ein prüfbares Kriterium dazu gehört.

Je Zeile 1 Punkt (richtige Zuordnung mit passender Begründung):

Bei Zeile 2 ist F mit der Begründung „Anmeldefunktion“ nur dann richtig, wenn deutlich wird, dass es um die Funktion und nicht um die Vorgabe des Verfahrens geht. Bei Zeile 5 ist Q mit der Begründung „Sicherheit/Datenschutz“ vertretbar.

Je Formulierung 1 Punkt für das Problem und 1 Punkt für eine prüfbare Neufassung, z. B.:

1. Problem: „schnell“ und „modern“ sind vage und nicht prüfbar; außerdem stecken zwei Anforderungen in einem Satz. Neufassung: „Die Liste der offenen Angebote eines Haltepunkts wird bei bis zu 300 gleichzeitigen Nutzenden in 95 % der Abrufe in höchstens 2 Sekunden angezeigt.“ (Für „modern“ eine eigene Anforderung, z. B. „Die Oberfläche hält die Gestaltungsrichtlinie der Schule ein (Farben, Schrift, Logo).“)

2. Problem: Das ist eine Lösung bzw. Entwurfsentscheidung, keine Anforderung; sie sagt nicht, was die Nutzenden brauchen. Neufassung: „RatzFahrt läuft als Web-App in den jeweils aktuellen Versionen von Chrome, Edge, Firefox und Safari auf Smartphone, Tablet und PC.“ (Randbedingung) – oder die eigentlich gemeinte Funktion als Anforderung beschreiben.

3. Problem: „rechtzeitig“ ist unklar; offen bleibt auch, wer erinnert wird und auf welchem Weg. Neufassung: „30 Minuten vor der Abfahrt erhalten die Fahrerin bzw. der Fahrer und alle bestätigten Mitfahrenden eine Erinnerung per Push-Nachricht oder E-Mail an ihr Schulkonto.“

Erläuterung (1 Punkt): Ein stärkerer Server hätte höchstens den Absturz vom 04.10. verhindert. Die Netzstörung beim Hoster und das fehlgeschlagene Update hätten ihn genauso getroffen: Der einzelne Server bleibt ein Single Point of Failure. Außerdem bemerkte niemand die Ausfälle rechtzeitig, und es gab keinen zweiten Standort, auf den man hätte umschalten können.

Anforderungen (je 2 Punkte: 1 Punkt passende Anforderung mit Bezug zum Protokoll, 1 Punkt richtige Art), z. B.:

Funktional:

• Die Infrastruktur stellt Backend und Datenbank an beiden Standorten bereit und schaltet bei Ausfall eines Standorts automatisch auf den anderen um (Netzstörung am 11.10.).

• Ein Überwachungsdienst (Monitoring) prüft die Erreichbarkeit der REST-API jede Minute und alarmiert bei einem Ausfall die Rufbereitschaft (Neustart erst nach Beschwerden am 04.10.).

• Ein Lastverteiler (Load Balancer) verteilt die Anfragen der Apps auf mehrere Backend-Container (Absturz bei hoher Last am 04.10.).

• Updates werden zuerst auf einer Testumgebung eingespielt; schlägt der Start fehl, wird automatisch die vorherige Version gestartet (18.10.).

Nichtfunktional:

• Die App ist je Kalendermonat zu mindestens 99,95 % verfügbar.

• Die REST-API antwortet auch bei der dreifachen Last eines Sonntagnachmittags in 95 % der Anfragen in höchstens 500 ms.

• Nach dem Ausfall eines Standorts ist die App nach spätestens 15 Minuten wieder erreichbar.

• Beide Rechenzentren liegen in Deutschland (Randbedingung aus dem Datenschutz).

Geg.: t_M = 31 \cdot 24 \cdot 60\,\mathrm{min} = 44\,640\,\mathrm{min} (Dauer des Monats), Ausfälle t_A = 75\,\mathrm{min} + 68\,\mathrm{min} + 92\,\mathrm{min} = 235\,\mathrm{min}, Vorschläge V_1 = 99{,}5\,\% = 0{,}995 und V_2 = 99{,}95\,\% = 0{,}9995

Ges.: V_{ist} (Verfügbarkeit im Oktober)

Die Verfügbarkeit ist der Anteil der Zeit, in der das System erreichbar ist (2 Punkte):

V = \frac{t_M - t_A}{t_M}

V_{ist} = \frac{44\,640\,\mathrm{min} - 235\,\mathrm{min}}{44\,640\,\mathrm{min}} = \frac{8881}{8928} \approx 0{,}99474 \approx \underline{\underline{99{,}474\,\%}}

Ges.: t_{A,max} (höchstens zulässige Ausfallzeit) für beide Vorschläge (2 Punkte)

V = \frac{t_M - t_A}{t_M} \quad | \cdot t_M

V \cdot t_M = t_M - t_A \quad | + t_A - V \cdot t_M

t_A = t_M - V \cdot t_M = t_M \cdot (1 - V)

t_{A,max,1} = 44\,640\,\mathrm{min} \cdot (1 - 0{,}995) = \frac{1116}{5}\,\mathrm{min} \approx \underline{\underline{223{,}200\,\mathrm{min}}}

t_{A,max,2} = 44\,640\,\mathrm{min} \cdot (1 - 0{,}9995) = \frac{558}{25}\,\mathrm{min} \approx \underline{\underline{22{,}320\,\mathrm{min}}}

Entscheidung (2 Punkte): Mit 235 Minuten Ausfall hätte der Oktober selbst Yusufs Vorschlag knapp verfehlt (223,2 Minuten zulässig). 99,5 % würde also fast den heutigen Zustand mit einem einzigen Server festschreiben und erlaubt im Monat mehr als drei Stunden Ausfall – genau die Sonntagsausfälle, die der Umzug beenden soll. In den Vertrag gehört deshalb der strengere Wert von 99,95 %: Dann darf die App im ganzen Monat höchstens rund 22 Minuten ausfallen, kein einzelner Ausfall aus dem Oktober wäre noch zulässig. Das erreicht der Betreiber nur mit zwei Standorten und automatischer Umschaltung. Vertretbar ist auch eine begründete Entscheidung für einen Wert dazwischen, wenn sie die Kosten der höheren Verfügbarkeit abwägt.

Je Anforderung 2 Punkte (1,5 Punkte Beschreibung mit Bezug, 0,5 Punkte richtige Zuordnung), z. B.:

• funktional: Meldungen aus der App werden über eine Schnittstelle (REST-API) automatisch als Ticket angelegt – mit Meldungsnummer, gemeldetem Konto, betroffener Aktivität und Begründung.

• funktional: Ein Ticket kann einer Person aus dem Moderationsteam zugewiesen werden; jeder Bearbeitungsschritt wird mit Zeitpunkt und bearbeitender Person im Verlauf dokumentiert.

• funktional: Ist eine Meldung nach 24 Stunden noch unbearbeitet, erhält die Leitung des Moderationsteams einen Hinweis.

• nichtfunktional: Die Software läuft im Browser und ist mit den vorhandenen Windows- und macOS-Arbeitsplätzen kompatibel, ohne dass eine lokale Installation nötig ist.

• nichtfunktional: Neue Moderierende können nach einer Einweisung von höchstens einer Stunde Tickets selbstständig bearbeiten.

• nichtfunktional: Die Daten werden ausschließlich in Rechenzentren in der EU gespeichert; der Anbieter schließt einen Vertrag zur Auftragsverarbeitung ab.

Je Randbedingung 1 Punkt, je passendes Beispiel 1 Punkt, z. B.:

Je Gedanke 1 Punkt, z. B.:

• Die Aussage greift zu kurz: Gesetzliche Vorgaben wie die DSGVO sind Randbedingungen und gehören damit zu den nichtfunktionalen Anforderungen. Sie müssen genauso dokumentiert werden wie andere Anforderungen.

• Das Gesetz legt nicht fest, wie es bei Let’s Meet umgesetzt wird. Daraus folgen konkrete Anforderungen, z. B. welche Daten ein Ticket enthält, wer Tickets lesen darf, wann Tickets gelöscht oder anonymisiert werden und dass der Anbieter einen Vertrag zur Auftragsverarbeitung abschließt.

• Nur dokumentierte Anforderungen fließen in die Auswahl der Software, in den Vertrag, in die Tests und in die Abnahme ein. Deshalb sollte die Datenschutzbeauftragte Dr. Marta Kowalczyk von Anfang an beteiligt werden.

Beschreibung 2 Punkte, Akzeptanzkriterium 2 Punkte, Testfall 1 Punkt, Priorität mit Begründung 1 Punkt, z. B.:

Beschreibung (2 Punkte), z. B. für die Antwortzeit: In einem Lasttest erzeugt ein Werkzeug (z. B. Apache JMeter) auf der Testumgebung die dreifache Zahl an Anfragen eines typischen Sonntagnachmittags, und zwar mit realistischen Abläufen (Aktivitäten suchen, anmelden, Chat öffnen). Gemessen werden die Antwortzeiten der REST-API; geprüft wird, ob 95 % der Anfragen in höchstens 500 ms beantwortet werden.

Ebenso richtig: Ausfalltest für die Umschaltung (ein Standort wird gezielt abgeschaltet, gemessen wird, wann die App wieder erreichbar ist) oder Auswertung der Monitoring-Daten über einen Monat für die Verfügbarkeit.

Erläuterung (2 Punkte): Ohne einen messbaren Wert gibt es kein eindeutiges „bestanden“ oder „nicht bestanden“. Formulierungen wie „die App soll schnell sein“ führen bei der Abnahme zu Streit, weil Auftraggeber und Auftragnehmer sie unterschiedlich auslegen. Mit Messgröße, Messbedingungen und Grenzwert lässt sich der Test wiederholen und das Ergebnis objektiv beurteilen.

Je Quelle mit passender Anforderung 1 Punkt, z. B.:

• E-Mails der Sammeladresse der letzten Monate (Dokumentenanalyse): häufige Anliegen ergeben feste Ticket-Kategorien und Antwortvorlagen.

• Tabelle meldung in der Datenbank (bestehendes System): Felder wie gemeldetes Konto, Aktivität, Grund und Status müssen ins Ticket übernommen werden.

• Gesetze (DSGVO, Digital Services Act): Die meldende Person erhält eine Eingangsbestätigung; Ticketdaten werden nach festgelegten Fristen gelöscht.

• Löschkonzept der Datenschutzbeauftragten: Tickets zu gelöschten Konten werden nach 30 Tagen anonymisiert.

• Bewertungen im App-Store: Beschwerden über fehlende Rückmeldung ergeben die Anforderung, Nutzende über den Abschluss ihrer Meldung zu informieren.

• Beobachtung des Moderationsteams bei der Arbeit mit dem E-Mail-Postfach: Tickets brauchen eine Zuweisung, damit keine Meldung doppelt oder gar nicht bearbeitet wird.

Je Merkmal 0,5 Punkte, z. B.:

• nach FURPS+: Benutzbarkeit (Usability), Zuverlässigkeit (Reliability), Leistung bzw. Effizienz (Performance), Wartbarkeit (Supportability) und „+“ (z. B. Vorgaben zu Implementierung, Schnittstellen, Betrieb, Lizenzen)

• nach ISO/IEC 25010: Leistungseffizienz, Kompatibilität, Benutzbarkeit bzw. Interaktionsfähigkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit, Übertragbarkeit bzw. Flexibilität, Betriebssicherheit (Fassung 2023)

„Funktionalität“ bzw. „funktionale Eignung“ ist kein Merkmal für nichtfunktionale Anforderungen und zählt hier nicht.

Je Methode 1 Punkt, je passende Anwendung 1 Punkt, z. B.:

1 Punkt für zwei passende, voneinander verschiedene Themenbereiche; je Zeile 1 Punkt für eine offene, konkrete Frage mit Bezug zur Geräteausleihe und 1 Punkt für den Zweck. Geschlossene Ja-/Nein-Fragen erhalten höchstens 0,5 Punkte.

Ebenso passende Themenbereiche mit Fragen, z. B.:

• Termine und Mittel: Bis zu welchem Schulhalbjahr muss die Ausleihe laufen, und welche Mittel stellt der Schulträger dafür bereit? – zeitlicher und finanzieller Rahmen.

• Technik: Mit welchen Konten arbeiten Schüler*innen und Lehrkräfte heute, und welche Geräte stehen in der Bibliothek zur Verfügung? – technische Randbedingungen, z. B. Anmeldung mit dem Schulkonto.

• Regeln der Ausleihe: Wie soll künftig mit verspäteten Rückgaben und beschädigten Geräten umgegangen werden? – Abläufe, die das System abbilden muss.

Je Schwachstelle mit Folge 2 Punkte, z. B.:

• Medienbruch und Doppelerfassung: Die Daten werden auf Papier erfasst und erst wöchentlich abgetippt. Dabei entstehen Tippfehler, und bis zur Übertragung weiß niemand genau, welches Gerät wo ist.

• Unsichere Datenhaltung: Die Tabelle liegt nur auf dem Bibliotheks-PC, ohne Sicherung und ohne Zugriff für andere. Fällt der PC aus, sind alle Ausleihdaten verloren.

• Keine verlässliche Reservierung: Reservierungen per E-Mail oder Zuruf werden nicht zentral geführt; Geräte werden doppelt vergeben, und Lehrkräfte können sich für Klassenarbeiten nicht auf die Geräte verlassen.

• Eingeschränkte Verfügbarkeit: Ausleihen und Rückgaben sind nur zu den Öffnungszeiten möglich; am Freitag oder nachmittags kommt niemand an ein Gerät.

• Keine Nachverfolgung und Rückgabeprüfung: Ohne Erinnerungen und Kontrolle gehen Geräte verloren (2 im letzten Jahr), und Schäden fallen erst beim nächsten Ausleihenden auf.

Je beschriebene Anforderung mit Bezug zur Situation 2 Punkte, z. B.:

• Anmeldung mit dem Schulkonto: Schüler*innen und Lehrkräfte melden sich mit ihrem vorhandenen Schulkonto an (Anbindung an den Verzeichnisdienst der Schul-IT), sodass keine zusätzlichen Zugangsdaten nötig sind und Abgänger*innen automatisch keinen Zugriff mehr haben.

• Erfassung per Code: Jedes Gerät erhält einen Barcode oder QR-Code; bei Aus- und Rückgabe wird er gescannt, damit Gerätenummern nicht mehr von Hand eingetragen werden.

• Zentrale Datenhaltung mit Sicherung: Die Daten liegen auf einem Server der Schul-IT mit täglicher Sicherung und sind von jedem berechtigten Gerät aus abrufbar.

• Rollen und Rechte: Schüler*innen sehen nur ihre eigenen Ausleihen, das Bibliotheksteam alle; Auswertungen sind nur für berechtigte Personen möglich.

• Erinnerungen: Das System verschickt automatisch eine E-Mail vor Ablauf der Leihfrist und meldet überfällige Geräte an das Bibliotheksteam.

• Verschlüsselte Übertragung: Alle Zugriffe laufen über HTTPS, weil personenbezogene Daten übertragen werden.

Je 2 Punkte, z. B.:

• Vorteil: Lehrkräfte können jederzeit, auch abends, sehen, welche Geräte frei sind, und sie verbindlich reservieren. Doppelvergaben entfallen, und das Bibliotheksteam muss keine E-Mails mehr abgleichen.

• Nachteil: Lehrkräfte, die selten digital arbeiten, brauchen eine Einweisung; außerdem besteht die Gefahr, dass Geräte „auf Vorrat“ reserviert und dann nicht abgeholt werden. Daraus folgt eine weitere Anforderung, z. B. automatische Freigabe nicht abgeholter Reservierungen nach 30 Minuten.

Weitere Nachteile: Ausfall des Systems legt die Planung lahm; zusätzliche Kosten für Betrieb und Pflege.

Je Feld 1 Punkt, z. B.: