„Wir brauchen ungefähr fünf Funktionen. Was kostet das?“
Für eine erste Größenordnung kann man Softwareprojekte grob einordnen. Ein belastbares Angebot benötigt jedoch mehr als eine Liste von Funktionsnamen.
Requirements Engineering schafft diese Grundlage. Es strukturiert, was ein System leisten soll, für wen es gebaut wird, welche Geschäftsregeln gelten und welche technischen Randbedingungen berücksichtigt werden müssen.
Requirements Engineering ist keine Dokumentation um der Dokumentation willen. Es reduziert Unsicherheit vor der Entwicklungsphase.
Was ist Requirements Engineering?
Requirements Engineering umfasst das Ermitteln, Dokumentieren, Prüfen und Verwalten von Anforderungen an ein System.
Für ein mittelständisches Softwareprojekt bedeutet das in der Praxis: Der reale Geschäftsprozess wird verstanden und in fachliche sowie technische Anforderungen übersetzt.
Warum Funktionslisten nicht ausreichen
Variante A: Termine anzeigen und bearbeiten.
Variante B: Mitarbeiter, Räume und Maschinen planen, Konflikte verhindern, Berechtigungen prüfen, Serienlogik abbilden und Benachrichtigungen auslösen.
Beide Projekte enthalten formal einen „Kalender“. Der technische Aufwand ist dennoch völlig unterschiedlich.
1. Ziel und Ausgangslage klären
- Welches Problem soll gelöst werden?
- Welche Arbeit verursacht heute Aufwand?
- Welche Verbesserung wird erwartet?
- Welche Systeme existieren bereits?
2. Nutzer und Rollen verstehen
- Mitarbeitende
- Teamleitung
- Administration
- Kunden
- externe Partner
Für jede Rolle muss geklärt werden, welche Daten sichtbar und welche Aktionen erlaubt sind.
3. Prozess und Zustände aufnehmen
- Statuswechsel
- Freigaben
- Rücksprünge
- Sonderfälle
- Abbruchbedingungen
- Vertretungen
4. Daten und Beziehungen verstehen
Welche Informationen werden benötigt? Wo entstehen sie? Welches System ist führend?
Beispielsweise können Kunden, Aufträge, Mitarbeitende, Dokumente, Ressourcen und Termine miteinander verknüpft sein. Diese Beziehungen beeinflussen das Datenmodell und damit die technische Architektur.
5. Schnittstellen prüfen
- Systemname und Version
- API-Dokumentation
- Authentifizierung
- Testzugang
- Datenumfang
- Übertragungsrichtung
Eine unbekannte Schnittstelle kann einen erheblichen Risikofaktor für eine Kalkulation darstellen.
6. Systemgrenzen definieren
Im Projekt: Auftragsübersicht, Statusworkflow, Dokumente, ERP-Schnittstelle.
Nicht im Projekt: vollständige Buchhaltung, CRM-Neuentwicklung, HR-System.
7. Nichtfunktionale Anforderungen klären
- Sicherheit
- Performance
- Verfügbarkeit
- Protokollierung
- Backup und Wiederherstellung
- Wartbarkeit
- Skalierbarkeit
Was ist das Ergebnis einer Konzept- und Anforderungsphase?
- dokumentierter Zielprozess
- Systemgrenzen
- Rollen und Berechtigungen
- priorisierte Funktionen
- Daten- und Schnittstellenübersicht
- technische Randbedingungen
- erste Architekturentscheidungen
- belastbarere Aufwandsschätzung
Wann ist Requirements Engineering besonders wichtig?
- unklarer Projektumfang
- komplexe Geschäftsprozesse
- ERP- oder Legacy-Systeme
- mehrere unbekannte Schnittstellen
- Datenmigration
- viele Rollen und Berechtigungen
- geschäftskritische Anwendungen
Kann man kleine Projekte ohne große Anforderungsphase umsetzen?
Ja. Requirements Engineering muss zum Projekt passen.
Eine kleine interne Erweiterung benötigt keine monatelange Spezifikationsphase. Auch dort sollten Ziel, Scope, Nutzer und Akzeptanzkriterien allerdings klar genug sein, um Missverständnisse zu vermeiden.
Fazit
Requirements Engineering beantwortet die Fragen, die vor einer Individualentwicklung ohnehin geklärt werden müssen.
Je früher Prozesse, Rollen, Daten, Schnittstellen und Systemgrenzen verstanden werden, desto geringer ist die Unsicherheit in der späteren Umsetzung.
Häufige Fragen
Was ist Requirements Engineering einfach erklärt?
Requirements Engineering strukturiert, was ein Softwaresystem leisten soll. Dazu werden Ziele, Prozesse, Nutzer, Rollen, Daten, Schnittstellen und technische Randbedingungen ermittelt und dokumentiert.
Warum ist Requirements Engineering vor einem Softwareprojekt wichtig?
Es reduziert Unsicherheit über Funktionsumfang, Sonderfälle und technische Risiken und schafft damit eine bessere Grundlage für Architektur, Aufwandsschätzung und Angebot.
Braucht jedes Softwareprojekt eine große Anforderungsphase?
Nein. Umfang und Tiefe sollten zur Projektgröße passen. Ziel, Scope, Nutzer und wichtige Randbedingungen sollten aber auch bei kleinen Projekten ausreichend klar sein.
Was kommt am Ende eines Requirements Engineering heraus?
Je nach Projekt entstehen unter anderem Zielprozess, Rollen, Systemgrenzen, priorisierte Anforderungen, Schnittstellenübersicht und eine belastbarere Grundlage für die technische Planung.