© Ekaphon maneechot/Shutterstock.com
Eine Einführung am Beispiel des besonderen elektronischen Anwaltspostfachs

Requirements Engineering


In der Welt der Softwareentwicklung existiert neben Architektur, Qualitätssicherung und Projektleitung eine weitere Disziplin: das Requirements Engineering (RE). Theoretische Ausführungen über RE finden sich in Lehrbüchern, aber häufig fehlt es dort an guten Praxisbeispielen.

Ein solches Beispiel will dieser Artikel zeigen und darstellen, dass es sich bei RE eben nicht um ein akademisches Konzept, sondern um eine sehr praxisnahe und für den Projekterfolg besonders wichtige Disziplin handelt. Das Beispiel ist das besondere elektronische Anwaltspostfach – ein Projekt, das die Autoren 2013 als Require­ments Engineers begleiten durften.

Das besondere elektronische Anwaltspostfach – das beA-Projekt

Die Bundesrechtsanwaltskammer (BRAK) ist in der Verantwortung, das Gesetz zur Förderung des elektronischen Rechtsverkehrs mit den Gerichten [1] umzusetzen. Aus diesem Gesetz ergibt sich die Aufgabe, bis zum 1. Januar 2016 besondere elektronische Anwaltspostfächer (kurz beA) einzurichten. Diese speziellen Postfächer sollen eine sichere Kommunikation zwischen der Anwaltschaft und der Justiz ermöglichen. Zu Beginn des Projekts war die Ausgangssituation recht übersichtlich: Es gab lediglich einen Gesetzentwurf. Zudem konnte zu diesem Zeitpunkt niemand abschätzen, welche Dimensionen die aus dem Gesetz resultierenden Anforderungen an die BRAK und das Projekt haben würden.

Der erste Reflex: einen Plan machen

Was ist der erste Schritt, wenn man den Auftrag bekommt, ein solches System zu konzipieren? Der erste Reflex, der sich in solchen Situationen üblicherweise beobachten lässt, ist, einen Projektleiter einzusetzen und einen Projektplan zu erstellen. Dieser enthält Meilensteine, Termine, Fristen, Aufgaben und oft auch schon Ressourcen für das Projekt. Dazu soll oft eine Kostenschätzung vom Projektleiter erstellt werden, die ein Budget für ein Umsetzungsprojekt festlegt – möglichst mit einem fest definierten Kostenrahmen.

Die industrielle Praxis zeigt, dass ein solches Vorgehen mit deutlichen Risiken verbunden ist, insbesondere wenn zum Projektstart keine ausreichenden Informationen über das geplante System vorliegen. Genau in solchen Situationen kann das RE einen wertvollen Beitrag leisten.

Requirements Engineering

Das Ziel des Requirements Engineerings [2] besteht darin, die Anforderungen an ein System diszipliniert und systematisch zu managen und zu spezifizieren, um

  • die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu den vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.

  • die Wünsche und Bedürfnisse der Stakeholder zu verstehen und zu dokumentieren.

  • die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.

Die Abgrenzung zwischen RE und Projektleitung kann wie folgt formuliert werden: Der Projektleiter kümmert sich um den Projektplan und darum, wann, wo und wie das zu entwickelnde System fertig sein muss. Die Aufgabe des Requirements Engineers besteht darin, die inhaltliche Gestalt des Systems zu erarbeiten.

Diese Aussage scheint einen Zirkelschluss zu beinhalten. Auf der einen Seite soll der Projektleiter den Projektplan erstellen und verwalten, auf der anderen Seite erstellt der Requirements Engineer zeitgleich die Inhalte. Die berechtigte Frage ist: Wie kann ein Projektplan entstehen, ohne die konkreten Inhalte zu kennen?

Die Lösung dieses Dilemmas ist recht simpel: Die Requirements Engineers erhalten einen gewissen Vorsprung, d. h. das Projekt beginnt mit einem kleinen Team von Requirements Engineers, die das Projekt inhaltlich strukturieren und ausarbeiten. Dieses Vorgehen wird oft als „Vorstudie“ oder „Grobspezifikation“ bezeichnet. Aus Sicht der Autoren sind diese beiden Begriffe aber schlicht falsch, da es sich weder um eine Studie handelt noch etwas grob zu spezifizieren ist. Es geht vielmehr darum, ein möglichst realistisches und konkretes Bild des zu entwickelnden Systems zu erhalten. Genau hier liegt die Stärke des RE. Es bietet die entsprechenden Methoden und Kompetenzen, um genau dies zu tun.

Und wie funktioniert das Ganze jetzt? Hilfestellung bietet beispielsweise das „International Requirements Engineering Board“ (IREB), das 2006 als Zusammenschluss von internationalen Experten gegründet wurde, um „die Standardisierung der Aus- und Weiterbildung im Requirements Engineering zu fördern.“ Zum Vorgehen in solchen Projekten macht das IREB zunächst eine eher negative Aussage: Es gibt kein standardisiertes Vorgehensmodell. Das heißt, es gibt kein Rezept, mit dem sich die Anforderungen an ein System möglichst schnell und vollständig erfassen lassen. Das IREB ist der Meinung, dass das RE ein Erkenntnisprozess ist und bietet stattdessen einen Leitfaden und einen detaillierten Methodenbaukasten zur individuellen Umsetzung des Leitfadens. Der Leitfaden besteht im Wesentlichen aus den folgenden Aktivitäten:

  • Identifikation der Anforderungsquellen und Erhebung der Anforderungen

  • Dokumentation der Anforderungen

  • Prüfung und Abstimmung der Anforderungen mit den Stakeholdern

  • Verwaltung der Anforderungen

Dieser Leitfaden stellt allerdings keine feste Abfolge dar, vielmehr müssen die Aktivitäten abhängig von...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang