Files
gitea-pages/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering.md

14 KiB

Requirements Engineering

Created: 2024-09-03 07:28:50 +0200

Modified: 2024-09-16 15:34:20 +0200


Die Anforderungsanalyse ist entscheidend, um sicherzustellen, dass die Software die Bedürfnisse und Erwartungen der Stakeholder erfüllt. Hier wird festgelegt, was die Software tun soll, bevor man sich darauf konzentriert, wie sie es tun soll.

Die Anforderungsanalyse baut auf mehreren Konzepten auf. Es versteht sich von selbst, dass für ein kleines Projekt nicht der gleiche Aufwand wie für ein grosses Projekt betrieben werden muss. Wenn aber mehrere Personen am Projekt arbeiten, ein wichtiger Termin einzuhalten ist und eine Software über Jahre im Betrieb sein soll, eine andere Herangehensweise gebraucht wird, als für eine kleine Schul-Programmieraufgabe.

In der Anforderungsanalyse gibt es eine gewisse logische Reihenfolge, in der die Konzepte üblicherweise angewendet werden, sowie Abhängigkeiten zwischen einigen der Konzepte. Andere Konzepte können parallel oder unabhängig voneinander betrachtet werden. Hier sind die einzelnen Konzepte in der Reihenfolge, in der sie typischerweise umgesetzt werden, sowie Hinweise zu ihren Abhängigkeiten und zur parallelen Bearbeitbarkeit:


Typische Reihenfolge der Konzepte und Abhängigkeiten


  1. Stakeholder-Analyse (Abhängigkeitsstufe: Hoch)

    • Definition: Die Stakeholder-Analyse identifiziert und analysiert alle Personen oder Organisationen, die von dem Projekt betroffen sind oder Einfluss darauf haben.
    • Zweck: Hilft, die Bedürfnisse, Erwartungen und Einflussmöglichkeiten der Stakeholder zu verstehen, um ihre Anforderungen gezielt zu berücksichtigen. Diese Analyse ist grundlegend, da sie bestimmt, von wem die Anforderungen gesammelt werden.
    • Schritte: Identifikation von Stakeholdern, Analyse ihrer Interessen und Einflussmöglichkeiten, Kommunikation und Abstimmung.
    • Abhängigkeit: Dies ist der Ausgangspunkt. Ohne Stakeholder-Analyse weiß man nicht, von wem Anforderungen gesammelt werden sollen.
    • Parallelität: Meist eigenständig und vor allem anderen durchgeführt.
  2. Anforderungsermittlung (Abhängigkeitsstufe: Hoch)

    • Definition: Die Anforderungsermittlung ist der Prozess, bei dem die Bedürfnisse, Wünsche und Erwartungen der Stakeholder gesammelt werden.
    • Zweck: Sammeln aller Anforderungen
    • Schritte: Hier einige Methoden, die zur Ermittlung von Anforderungen eingesetzt werden können:
      • Interviews: Direkte Gespräche mit den Stakeholdern, um ihre Bedürfnisse und Wünsche zu verstehen.
      • Workshops: Gruppendiskussionen mit Stakeholdern, um Anforderungen gemeinsam zu erarbeiten.
      • Beobachtung: Analyse von bestehenden Prozessen und Nutzerverhalten, um Anforderungen abzuleiten.
      • Fragebögen: Systematische Befragung von Stakeholdern zur Ermittlung ihrer Anforderungen.
      • Dokumentenanalyse: Untersuchung bestehender Dokumente (z.B. aktuelle Systeme, Verträge), um Anforderungen zu identifizieren.
    • Abhängigkeit: Die Anforderungsermittlung hängt direkt von der Stakeholder-Analyse ab, da die Stakeholder die Quelle der Anforderungen sind.
    • Parallelität: In dieser Phase können verschiedene Methoden zur Ermittlung der Anforderungen parallel angewendet werden (z.B. Interviews und Workshops).
  3. Persona-Erstellung (Abhängigkeitsstufe: Mittel)

    • Definition: Eine Persona ist ein fiktiver, repräsentativer Benutzer, der eine bestimmte Zielgruppe verkörpert.
    • Zweck: Hilft, die Bedürfnisse und Verhaltensweisen der Nutzer zu verstehen und diese in den Entwicklungsprozess zu integrieren.
    • Beispiel: „Lisa ist 35 Jahre alt, arbeitet als Marketing-Managerin und nutzt die Software, um Kampagnen zu planen und zu analysieren."
    • Abhängigkeit: Baut auf den Ergebnissen der Stakeholder-Analyse und der Anforderungsermittlung auf, da die Personas auf echten Nutzerdaten basieren.
    • Parallelität: Kann parallel zu anderen Analysemethoden erstellt werden, sobald erste Anforderungen bekannt sind.
  4. Use Cases / User Stories (Abhängigkeitsstufe: Mittel)


4.1. Use Case (Anwendungsfall)

  • Definition: Ein Use Case beschreibt eine Interaktion zwischen einem Benutzer (Akteur) und dem System, um ein bestimmtes Ziel zu erreichen.
  • Zweck: Dient dazu, die Funktionalitäten des Systems aus der Sicht des Nutzers zu erfassen und zu dokumentieren.
  • Struktur: Ein Use Case besteht aus dem Namen des Anwendungsfalls, dem Ziel, den beteiligten Akteuren und einer Beschreibung des Ablaufs.
  • Beispiel: „Buchung eines Tickets" -- der Benutzer wählt ein Ziel, gibt persönliche Daten ein, und bestätigt die Buchung.

4.2. User Story

  • Definition: Eine User Story ist eine kurze, einfache Beschreibung einer Funktion aus der Perspektive des Endbenutzers.
  • Zweck: Dient der klaren und verständlichen Kommunikation von Anforderungen und legt den Fokus auf den Nutzen für den Nutzer.
  • Struktur: „Als [Benutzerrolle] möchte ich [Ziel/Wunsch], um [Nutzen]."
  • Beispiel: „Als Marketing-Managerin möchte ich die Klickrate meiner Kampagnen sehen, um deren Erfolg zu bewerten."

4.3. Gemeinsamkeiten

  • Genereller Zweck: Spezifikation der Interaktionen zwischen Nutzern und dem System.
  • Abhängigkeit: Erfordert eine erste Erfassung der funktionalen Anforderungen und ein grundlegendes Verständnis der Stakeholder und deren Bedürfnisse.
  • Parallelität: Sobald die grundlegenden Anforderungen klar sind, können Use Cases oder User Stories unabhängig entwickelt werden.
  1. Business-Rule-Analyse (Abhängigkeitsstufe: Mittel)

    • Definition: Analyse von Geschäftsregeln, die die Entscheidungslogik innerhalb des Systems steuern.
    • Zweck: Sicherstellen, dass alle relevanten Geschäftsregeln korrekt und vollständig in den Anforderungen abgebildet sind.
    • Beispiel: „Eine Bestellung darf nur dann versendet werden, wenn die Zahlung bestätigt wurde."
    • Abhängigkeit: Baut auf den funktionalen Anforderungen auf, da Geschäftsregeln oft detailliertere oder spezifischere Bedingungen und Einschränkungen darstellen.
    • Parallelität: Kann parallel zu anderen Analysen durchgeführt werden, insbesondere zu Use Cases oder User Stories.
  2. Kontextdiagramm (Abhängigkeitsstufe: Mittel)

    • Definition: Ein Kontextdiagramm ist eine grafische Darstellung, die das System in seiner Umgebung zeigt und die Interaktionen mit externen Akteuren oder Systemen darstellt.
    • Zweck: Es gibt einen Überblick über das System und seine Schnittstellen zu anderen Systemen oder Benutzergruppen.
    • Beispiel: Ein Kontextdiagramm für eine Webanwendung könnte das System in der Mitte darstellen, umgeben von Benutzergruppen (z.B. Administratoren, Endnutzer) und externen Systemen (z.B. Datenbanken, Zahlungsgateways).
    • Abhängigkeit: Setzt eine grundlegende Ermittlung der Anforderungen voraus, da die Interaktionen und Schnittstellen erst bekannt sein müssen.
    • Parallelität: Kann parallel zu den User Stories/Use Cases entwickelt werden, sobald die Hauptakteure und externen Systeme klar sind.
  3. Prototyping (Abhängigkeitsstufe: Mittel)

    • Definition: Das Erstellen eines vereinfachten Modells (Prototyps) des Systems, um Anforderungen zu testen und zu verfeinern.
    • Zweck: Hilft, Anforderungen zu klären und frühes Feedback von Stakeholdern einzuholen.
    • Arten von Prototypen:
    • Low-Fidelity: Einfache Skizzen oder Wireframes.
    • High-Fidelity: Interaktive, aber nicht voll funktionsfähige Modelle des Systems.
    • Abhängigkeit: Prototypen basieren auf den funktionalen Anforderungen, Use Cases und den Ergebnissen der Persona-Erstellung.
    • Parallelität: Kann parallel zur Anforderungsermittlung und Validierung verwendet werden, da es auch ein Mittel zur Verfeinerung der Anforderungen ist.
  4. SWOT-Analyse (Abhängigkeitsstufe: Gering)

    • Definition: Eine SWOT-Analyse untersucht die Stärken (Strengths), Schwächen (Weaknesses), Chancen (Opportunities) und Risiken (Threats) eines Projekts.
    • Zweck: Unterstützt die strategische Planung und hilft, potenzielle Risiken frühzeitig zu erkennen. Bewertung der internen und externen Faktoren, die das Projekt beeinflussen könnten.
    • Anwendung: Oft eingesetzt, um die Rahmenbedingungen für das Projekt zu bewerten und daraus Anforderungen abzuleiten.
    • Abhängigkeit: Kann zu jedem Zeitpunkt durchgeführt werden, ist aber besonders nützlich, wenn die Anforderungen und Rahmenbedingungen des Projekts klarer werden.
    • Parallelität: Kann unabhängig von der detaillierten Anforderungsanalyse durchgeführt werden.
  5. Ergonomie- und Usability-Analyse (Abhängigkeitsstufe: Mittel)

    • Definition: Analyse der Benutzerfreundlichkeit und Ergonomie des Systems.
    • Zweck: Sicherstellen, dass das System für den Endnutzer leicht verständlich und bedienbar ist.
    • Techniken: Usability-Tests, Interviews mit Nutzern, Erstellung von Prototypen, um Feedback zur Benutzerfreundlichkeit zu sammeln.
    • Abhängigkeit: Die Benutzerinteraktionen (User Stories, Use Cases, Prototypen) müssen bekannt sein, damit die Benutzerfreundlichkeit bewertet werden kann.
    • Parallelität: Kann parallel mit Prototyping und User Stories durchgeführt werden, sobald erste Benutzerschnittstellen bekannt sind.
  6. Requirements Traceability Matrix (RTM) (Abhängigkeitsstufe: Hoch)

    • Definition: Eine Tabelle, die die Rückverfolgbarkeit von Anforderungen über den gesamten Entwicklungsprozess hinweg sicherstellt.
    • Zweck: Hilft, sicherzustellen, dass alle Anforderungen in den entsprechenden Entwicklungs- und Testaktivitäten berücksichtigt werden.
    • Struktur: Die Matrix verknüpft Anforderungen mit entsprechenden Testfällen, Design-Elementen und Implementierungsdetails.
    • Abhängigkeit: Diese Matrix kann erst erstellt werden, wenn die Anforderungen festgelegt sind.
    • Parallelität: Kann parallel zu Tests und Implementierung geführt werden, sobald die Anforderungen dokumentiert sind.
  7. Priorisierungstechniken (z.B. MoSCoW, Kano-Modell) (Abhängigkeitsstufe: Hoch)

    • MoSCoW-Methode: Anforderungen werden in Must-have, Should-have, Could-have und Won't-have kategorisiert.
    • Kano-Modell: Analysiert Anforderungen basierend auf den Erwartungen der Benutzer und kategorisiert sie in Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren.
    • Zweck: Anforderungen nach ihrer Wichtigkeit und Dringlichkeit priorisieren.
    • Abhängigkeit: Die Anforderungen müssen bekannt sein, bevor sie priorisiert werden können.
    • Parallelität: Kann in späteren Phasen der Anforderungsermittlung oder nach deren Erhebung durchgeführt werden.
  8. Risikomanagement (Abhängigkeitsstufe: Mittel)

    • Definition: Analyse und Management potenzieller Risiken, die die Erreichung der Projektziele gefährden könnten.
    • Zweck: Frühes Erkennen und Gegensteuern von Risiken, die sich aus den Anforderungen oder deren Umsetzung ergeben könnten.
    • Schritte: Risikoidentifikation, Risikoanalyse, Risikobewertung, Risikosteuerung.
    • Abhängigkeit: Die Anforderungen und Rahmenbedingungen des Projekts müssen bekannt sein, um Risiken richtig einschätzen zu können.
    • Parallelität: Kann während des gesamten Projekts laufend durchgeführt werden, aber ein Großteil der Analyse erfolgt in den frühen Phasen.
  9. Scope Management (Abhängigkeitsstufe: Hoch)

    • Definition: Verwaltung des Projektumfangs, um sicherzustellen, dass das Projekt nur die genehmigten Arbeiten umfasst.
    • Zweck: Verhindert „Scope Creep" (ungeplante Erweiterungen des Umfangs), der zu Verzögerungen und höheren Kosten führen kann.
    • Techniken: Definition eines klaren Projektumfangs, regelmäßige Überprüfungen und Anpassungen bei Änderungen.
    • Abhängigkeit: Muss in allen Phasen angewendet werden, insbesondere sobald Anforderungen erfasst und dokumentiert sind.
    • Parallelität: Wird während des gesamten Projekts angewendet, um sicherzustellen, dass der Umfang stabil bleibt.

Konzepte, die parallel laufen können:

  • SWOT-Analyse: Da sie eher auf Rahmenbedingungen als auf spezifische Anforderungen fokussiert ist, kann sie weitgehend unabhängig durchgeführt werden.
  • Stakeholder-Analyse und Anforderungsermittlung: Diese beiden Konzepte können eng zusammenarbeiten und auch parallel stattfinden, insbesondere bei komplexeren Projekten mit mehreren Stakeholdern.
  • Ergonomie- und Usability-Analyse: Sobald Prototypen oder erste Entwürfe vorliegen, kann parallel die Benutzerfreundlichkeit getestet werden.
  • Business-Rule-Analyse: Geschäftsregeln lassen sich oft unabhängig von den funktionalen Anforderungen detailliert betrachten.

Fazit zur Reihenfolge und Abhängigkeiten:

Die Anforderungsanalyse beginnt typischerweise mit der Stakeholder-Analyse und der Anforderungsermittlung, da diese die Basis für viele andere Konzepte liefern. Darauf aufbauend folgen spezifizierende und strukturierende Techniken wie Use Cases, Kontextdiagramme und Business-Rule-Analysen. Einige Konzepte, wie Prototyping, können parallel zur weiteren Verfeinerung der Anforderungen durchgeführt werden, während andere, wie das Risikomanagement oder die Usability-Analyse, den gesamten Prozess begleiten und in mehreren Phasen zum Einsatz kommen.

Hier ist ein Gantt-Diagramm, das die Reihenfolge und Dauer der verschiedenen Konzepte in der Anforderungsanalyse visualisiert. Es zeigt, welche Aufgaben parallel laufen können und wie sie zeitlich aufeinander abgestimmt sind.

Bild ausgeben{width="4.78125in" height="3.21875in"}