Requirements Engineering – Anforderungsanalyse & UML-Diagramme ⚠️ LÜCKE

Requirements Engineering ist der systematische Prozess zur Ermittlung, Dokumentation und Verwaltung von Anforderungen an ein zu entwickelndes System. Anforderungen können textuell oder modellbasiert (UML-Diagramme) festgehalten werden. Prüfungsrelevant ist das Lesen und Interpretieren von UML-Diagrammen, nicht das Zeichnen.

Relevanz: Schritte des Requirements Engineering benennen; funktionale vs. nicht-funktionale Anforderungen unterscheiden; Kontext-, Use-Case- und Aktivitätsdiagramm lesen und interpretieren; extend vs. include in Use Case Diagrammen erklären.

• Requirements Engineering (RE): Systematischer Prozess zur Ermittlung (Elicitation), Dokumentation, Analyse und Verwaltung von Anforderungen. Ziel: vollständiges und konsistentes Verständnis, was ein System tun soll, bevor es gebaut wird.
• Schritte des Requirements Engineering: Anforderungen ermitteln (Interviews, Workshops, Beobachtung) → Anforderungen analysieren und prüfen → Anforderungen festhalten (textuell oder modellbasiert) → Anforderungen verwalten (Änderungen nachverfolgen).
• Funktionale Anforderungen: Beschreiben die Funktionalität, die das System bereitstellen soll. Beispiele: «Das System soll neue Kunden mit Vorname, Nachname und Adresse erfassen können», «Das System muss Berichte generieren können».
• Nicht-funktionale Anforderungen: Betreffen die Qualitätseigenschaften des Systems. Beispiele: Leistung/Performance, Sicherheit, Skalierbarkeit, Benutzerfreundlichkeit (Usability), Verfügbarkeit.
• Kontextdiagramm: Zeigt, welche externen Systeme und Akteure mit dem System interagieren. Das System erscheint als Black Box; es wird nur die Systemgrenze und die Kommunikation mit der Umgebung dargestellt.
• Use Case Diagramm (UML): Detailliert, welche Aktionen die Akteure im System durchführen können. Methode zur Definition funktionaler Anforderungen. Ziele: klare Systemabgrenzung, vollständige Erfassung der Systemfunktionalität, Festhalten der Hauptaufgaben der Akteure. Ein Akteur kann eine Person oder ein System sein.
• Use Case-Erweiterung (extend): Use Case B erweitert Use Case A an einer bestimmten Stelle, aber nur unter bestimmten Bedingungen (optional). Basis-Use-Case (A) kann ohne B existieren; B tritt nur in bestimmten Fällen auf.
• Use Case-Inkorporation (include): Use Case E ruft immer Use Case D auf, weil D eine notwendige Teilfunktion ist (nicht optional). D ist zwingend erforderlich und wird häufig wiederverwendet.
• Aktivitätsdiagramm (UML): Zeigt den detaillierten Ablauf einer Aktivität oder eines Geschäftsprozesses (Ablauflogik und Workflows). Stellt den Ablauf der Aktionen der Use Cases dar; kann Swimlanes für verschiedene Verantwortungsbereiche enthalten.
• Textuelle Anforderungsbeschreibung: Formulierung von Anforderungen in natürlicher Sprache, oft nach einem Schema (z.B. «Das System MUSS/SOLL/KANN...»).

• Requirements EngineeringSystematischer Prozess zur Ermittlung, Dokumentation, Analyse und Verwaltung von Anforderungen an ein IT-System.
• Funktionale AnforderungAnforderung, die eine konkrete Funktion oder ein Verhalten des Systems beschreibt (was das System tun soll).
• Nicht-funktionale AnforderungAnforderung, die eine Qualitätseigenschaft des Systems beschreibt (wie gut das System etwas tun soll), z.B. Performance, Sicherheit, Usability.
• AkteurIm Use Case Diagramm: Person oder externes System, das mit dem zu beschreibenden System interagiert.
• Use CaseBeschreibt eine typische Form der Anwendung eines IT-Systems zur Erfüllung einer bestimmten Aufgabe und hält Interaktionen zwischen einem Akteur und dem System fest.
• SystemgrenzeIm Use Case Diagramm: Linie, die das zu beschreibende System von seiner Umgebung (Akteuren, externen Systemen) trennt.
• extendUse-Case-Beziehung; ein Use Case erweitert einen anderen optional unter bestimmten Bedingungen.
• includeUse-Case-Beziehung; ein Use Case ruft zwingend einen anderen als notwendige Teilfunktion auf.
• KontextdiagrammZeigt das System als Black Box mit seinen Schnittstellen zu externen Akteuren und Systemen; dient der groben Systemabgrenzung.
• AktivitätsdiagrammUML-Diagramm, das den detaillierten Ablauf einer Aktivität oder eines Prozesses darstellt.
• SwimlaneStrukturierungselement im Aktivitätsdiagramm; trennt Aktivitäten nach Verantwortungsbereichen (z.B. Abteilungen oder Rollen).
• UMLUnified Modeling Language; standardisierte Modellierungssprache für die Dokumentation und Visualisierung von Softwaresystemen. ---