Startseite
Wissen kompakt
Requirements Engineering

Requirements Engineering

Inhaltsverzeichnis: Definition – Aktivitäten – Gründe – Fragen – Tools – Download – Hinweise

Wissen kompakt: Requirements Engineering ist das systematische Vorgehen beim Spezifizieren und Verwalten von Anforderungen an ein System, ein Produkt oder eine Software.

Requirements Engineering – eine Frage der Definition

Wer sich mit der Entwicklung von Produkten, Systemen oder einer Software beschäftigt, stellt sich verschiedene Fragen:

Was sind die Anforderungen – also die Fähigkeiten und Eigenschaften – des gewünschten Produkts?
Wie lassen sich diese Anforderungen spezifizieren – also erheben, analysieren, dokumentieren und validieren?
Wie sollten Anforderungen verwaltet – also freigegeben, evtl. verändert und rückverfolgt – werden?

Die Antworten auf diese Fragen liefert das Requirements Engineering (RE): RE ist das systematische Vorgehen beim Spezifizieren und Verwalten von Anforderungen an ein System, ein Produkt oder eine Software.

Requirements Engineering - das systematische Vorgehen beim Spezifizieren und Verwalten von Anforderungen

Die Aktivitäten im Requirements Engineering

Viele Definitionen von Requirements Engineering variieren im Detail. Das International Requirements Engineering Board (IREB), das versucht, sowohl RE als auch Business Analyse (BA) zu professionalisieren, nennt vier zentrale Aktivitäten:

Die Ermittlung von Anforderungen inklusive Detaillierung und Verfeinerung
Die Dokumentation als adäquate Beschreibung von Anforderungen
Die Prüfung und Abstimmung von Anforderungen mit dem Ziel, die Qualität sicherzustellen
Die Verwaltung – auch als Requirements Management bezeichnet – von Anforderungen

Das International Institute of Business Analysis (IIBA) adressiert bspw. die Anforderungserhebung der Stakeholder, das Anforderungsmanagement inklusive Kommunikation und die Anforderungsanalyse. Und IEEE 24765:2017 spricht von Anforderungserhebung (Requirements Elicitation), Anforderungsanalyse (Requirements Analysis), Anforderungsspezifikation (Requirements Specification) und Anforderungsbewertung (Requirements Validation).

Aufgrund dieser unterschiedlichen Definitionen und Interpretationen werden auch viele Begriffe synonym zu Requirements Engineering genutzt. Vor allem Anforderungsmanagement und Anforderungsanalyse werden häufig genannt. Diese Begriffe können aber auch unter RE subsumiert werden. Wichtig ist hier, dass Klarheit zwischen den Kommunikationspartnern herrscht, so dass keine Missverständnisse entstehen.

Gründe für Requirements Engineering

Es gibt eine Reihe von guten Gründen für die Durchführung von Requirements Engineering:

Was erwarten die Stakeholder? Nur wer weiß, was Stakeholder erwarten, ist in der Lage, ein Produkt zu entwickeln, das entsprechende Erwartungen erfüllen kann. Aus diesem Grund ist das Stakeholdermanagement, bestehend aus der Identifikation, Analyse und Kommunikation, ein zentraler Bestandteil von RE.
Technische Systeme und Software lassen sich nur erfolgreich implementieren, sofern es eine möglichst vollständige, eindeutige und widerspruchsfreie Spezifikation aller Anforderungen – bspw. in Form einer SRS – gibt. Die Erstellung einer solchen Spezifikation ist Aufgabe des RE.
Nur wer zumindest einen wesentlichen Teil der Anforderungen kennt, kann beginnen, Prognosen über Termine und Kosten aufzustellen, Pläne zu entwerfen und zu kommunizieren. RE ist somit ein zentraler Bestandteil nicht nur in der Produktentwicklung, sondern im gesamten Unternehmen.
Requirements Engineering hilft, Entwicklungskosten zu reduzieren, denn idealerweise lassen sich Fehlentwicklung vermeiden oder zumindest frühzeitig erkennen. So ist bspw. die Korrektur einer missverstandenen Anforderung in einer frühen Phase einer Entwicklung deutlich günstiger, als die realisierte Funktion in einer Anwendung oder einem System im laufenden Betrieb zu korrigieren. Konsequenterweise fallen auch geringere Supportkosten an.
Randbedingungen, Funktionswünsche, Begeisterungsmerkmale, Ziele, aber auch Normen und Gesetze etc. ändern sich häufig bereits im Zeitraum einer Entwicklung, sicherlich aber während des Betriebs einer Lösung. RE schafft die Basis für eine Weiterentwicklung von Produkten, Systemen oder Software. Und das ist auch der Grund, warum Publikationen, die darauf abzielen, Requirements Engineering als eine Phasentätigkeit zu Beginn einer Entwicklung zu deklarieren, einen wichtigen Punkt übersehen: RE ist eine kontinuierliche Aufgabe.
Zu guter Letzt führt der CHAOS Report der Standish Group regelmäßig unklare Anforderungen als einen wesentlichen Faktor für gescheitere Projekte und Entwicklungen an.

Bei allen Gründen, die für die Durchführung von Requirements Engineering sprechen, ein Aspekt sollte dennoch beachtet werden: Wirtschaftlich betrachtet wirkt RE lediglich indirekt, bspw. in dem sich Kosten reduzieren lassen oder die Kundenzufriedenheit gesteigert wird. RE als Tätigkeit verursacht aber immer Kosten. Hier gilt es also für Organisationen ein “vernünftiges Maß” zu finden.

Fragen im Kontext von Requirements Engineering

Es gibt eine lange Liste an Fragen im Kontext von RE. Auf einige der Fragen finden Sie Antworten in unserem Blog:

Sicherlich fallen Ihnen noch weitere Fragen ein. Melden Sie sich gerne bei uns und wir versuchen Ihre Fragen zu beantworten oder entsprechende Beiträge zu publizieren.

Tools für Requirements Engineering

Es gibt sehr viele Tools im Requirements Engineering. Hier finden Sie eine kleine Liste mit Tools ohne Anspruch auf Vollständigkeit und ohne Bewertung:

YAKINDU von Itemis
ReqSuite RM von OSSENO Software
Polarion Requirements von Siemens
DOORS Next von IBM
Enterprise Architekt von Sparx Systems
CaliberRM von Borland
Reqtify von Dassault Systems
Reqchecker von Khilogic
Jama Connect von Jama Software
PREEVision von Vector
Helix ALM von Perforce

Visure Requirements
TraceCloud
Cradle von 3SL
SpiraTest von Inflecta

Sicherlich lässt sich die Liste leicht ergänzen, zumal es zahlreiche Produkte gibt, die in Organisationen für die Arbeit mit Anforderungen genutzt werden (bspw. MS Excel, MS Word oder Jira), originär aber einen anderen Vermarktungsschwerpunkt haben.