Grundlagen des Requirements Engineering

Einführung in das Requirements Engineering

Das Requirements Engineering (RE) bildet das Fundament erfolgreicher Software‑ und Systemprojekte. Es umfasst das systematische Ermitteln, Dokumentieren, Validieren und Verwalten von Anforderungen. In diesem Kurs lernen Sie die wichtigsten Prinzipien, Rollen, Methoden und häufige Fallstricke kennen – alles, was Sie für die Prüfung zum Thema Grundlagen des Requirements Engineering benötigen.

1. Zentrale RE‑Prinzipien

1.1 Wertorientierung

Ein zentrales Prinzip ist die Wertorientierung. Sie besagt, dass der Nutzen einer Anforderung den Aufwand übersteigen muss. Der Mehrwert (z. B. gesteigerte Produktivität, höhere Kundenzufriedenheit) muss also größer sein als die entstehenden Kosten. Dieses Prinzip stellt sicher, dass Ressourcen effizient eingesetzt werden.

• Mehrwert > Kosten = Wertorientierung
• Prüfen Sie jede Anforderung auf ihren wirtschaftlichen Nutzen.

1.2 Stakeholder‑Prinzip

Das Stakeholder‑Prinzip fordert die Identifikation, Priorisierung und Abstimmung aller Interessen. Bei widersprüchlichen Anforderungen hilft dieses Prinzip, Konflikte zu erkennen und zu lösen, indem die jeweiligen Stakeholder einbezogen werden.

• Interessen abgleichen, Konflikte klären.
• Regelmäßige Workshops mit allen Beteiligten.

1.3 Evolution‑Prinzip

Im RE‑Kontext bedeutet Evolution, dass Anforderungen im Laufe des Projekts weiterentwickelt werden können. Dieses Prinzip ist besonders wichtig in agilen Umgebungen, wo Änderungen als Chance gesehen werden.

2. Die Rolle des Requirements Engineers

Der Requirements Engineer ist kein Programmierer, sondern ein Informationsmanager. Seine Kernaufgaben umfassen:

• Ermittlung von Anforderungen (Interviews, Beobachtungen, Workshops).
• Dokumentation in klaren, prüfbaren Formulierungen.
• Validierung – Sicherstellung, dass die Anforderungen korrekt, vollständig und konsistent sind.
• Verwaltung – Änderungen nachverfolgen, Versionierung, Traceability.

Denken Sie immer an den Ablauf: Anforderung → Dokument → Kontrolle → Pflege.

3. RE‑Ansätze im Entwicklungsmodell

3.1 Wasserfallmodell

Im klassischen Wasserfallmodell wird RE typischerweise zu Projektbeginn durchgeführt. Die Anforderungen sollen stabil sein, weil nach der Anforderungsphase kaum Änderungen erwartet werden.

• RE am Anfang des Projekts mit geringer Volatilität.
• Späte Änderungen sind kostenintensiv.

Stabile Anforderung = Wasserfall

3.2 Agile Modelle

Im Gegensatz dazu steht das kontinuierliche RE in agilen Methoden (Scrum, Kanban). Hier wird in kurzen Iterationen immer wieder neu validiert und angepasst.

4. Funktionale vs. nicht‑funktionale Anforderungen

Ein häufiges Missverständnis besteht darin, funktionale und nicht‑funktionale Anforderungen zu vermischen. Funktionale Anforderungen beschreiben, was das System tun soll (z. B. „Der Nutzer kann ein Dokument hochladen“). nicht‑funktionale Anforderungen definieren Qualitätsmerkmale wie Usability, Effizienz oder Sicherheit.

• Beispiel für eine funktionale Anforderung: Eine neue Benutzerfunktion (keine nicht‑funktionale Anforderung).
• Beispiele für nicht‑funktionale Anforderungen: Benutzbarkeit, Effizienz, Sicherheitsanforderungen.

Merke: Funktionen ≠ Qualitätsziele.

5. Standards und Formulierungsrichtlinien

5.1 ISO 29148 – Satzschablone

Die internationale Norm ISO 29148 definiert eine Satzschablone für klare Anforderungsformulierungen. Ein wichtiger Schritt ist die Festlegung der rechtlichen Verbindlichkeit, also zu bestimmen, ob ein Requirement vertraglich bindend ist.

• Rechtlich bindend = Vertraglich festgeschrieben.
• Klare Formulierungen reduzieren Missverständnisse.

5.2 Vermeidung von Universalquantoren

Der häufige Fehler bei der Nutzung von Universalquantoren („für alle“) ist die Auslassung von Ausnahme‑ oder Sonderfällen. Wenn man sagt „Alle Benutzer können …“, vergisst man oft Ausnahmen wie Administratoren oder System‑Bots.

• Prüfen Sie immer, ob Ausnahmen nötig sind.
• Formulieren Sie stattdessen: „Alle regulären Benutzer, außer Administratoren, …“.

6. Systemgrenzen und Kontext

Die Kontext‑Grenze eines Systems trennt das System von seiner Umgebung. Sie definiert, welche Komponenten zum System gehören und welche extern sind. Diese Grenze ist nicht statisch – sie kann sich im Projektverlauf ändern, wenn neue Schnittstellen oder externe Dienste integriert werden.

• Grenze = Trennlinie zwischen System und Umwelt.
• Sie ist nicht immer durch regulatorische Vorgaben bestimmt, sondern durch technische und funktionale Überlegungen.

7. Praktische Tipps für die Prüfung

Um die Konzepte sicher zu beherrschen, sollten Sie folgende Lernstrategien anwenden:

• Aktives Wiederholen: Erstellen Sie Karteikarten zu jedem Prinzip (Wertorientierung, Stakeholder‑Prinzip, etc.).
• Fallbeispiele analysieren: Nehmen Sie ein Projekt Ihrer Wahl und ordnen Sie die RE‑Aktivitäten den jeweiligen Entwicklungsmodellen zu.
• Formulierungsübungen: Schreiben Sie Anforderungen nach ISO 29148 und prüfen Sie sie auf Universalquantoren.
• Quiz‑Durchläufe: Testen Sie Ihr Wissen regelmäßig mit Multiple‑Choice‑Fragen, um die richtigen Antworten zu festigen.

Mit diesen Techniken erhöhen Sie nicht nur Ihr Verständnis, sondern auch Ihre Prüfungsleistung.

Fazit

Das Requirements Engineering ist ein komplexes, aber strukturiertes Feld. Durch das Verständnis der Prinzipien, der Rolle des Requirements Engineers, der Unterschiede zwischen funktionalen und nicht‑funktionalen Anforderungen sowie der Anwendung von Standards wie ISO 29148 legen Sie das Fundament für qualitativ hochwertige Systeme. Nutzen Sie die hier vorgestellten Lernmethoden, um das Wissen zu festigen und erfolgreich anzuwenden.