Eine Einführung am Beispiel des besonderen elektronischen Anwaltspostfachs

Requirements Engineering

Oliver Hehlert, Kim Lauenroth

© Shutterstock.com/Peshkova

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 Requirements 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 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 besteht darin, die Anforderungen an ein System diszipliniert und systematisch zu managen und zu spezifizieren, um

1. 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.
2. die Wünsche und Bedürfnisse der Stakeholder zu verstehen und zu dokumentieren.
3. 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 den Projektgegebenheiten durchgeführt werden. Als erster, sinnvoller Schritt bietet sich oft die Identifikation der Anforderungsquellen an.

Einführung Anforderungsquellen

Zu den Anforderungsquellen zählen Stakeholder, Systeme im Betrieb und Dokumente. Der Begriff Stakeholder wird nach Einschätzung der Autoren sehr inflationär gebraucht. Dennoch ist der Begriff hier in seinem ursprünglichen Sinne genau richtig. Der Begriff setzt sich aus den Wörtern stake (engl. Anteil oder Einsatz) und holder (engl. Halter) zusammen und meint somit all jene, die Anteil an einem System haben und Anforderungen an das System beisteuern können. Der wesentlichste Stakeholder eines Softwareprojekts ist der Endnutzer. Allerdings ist der Begriff Stakeholder im RE sehr weit gefasst. Das folgende Beispiel verdeutlicht dies.

Für Systeme im Betrieb gibt es drei unterschiedliche Arten: zuerst Altsysteme, die abgelöst werden sollen, dann Systeme, die an das geplante System angeschlossen werden sollten, und zu guter Letzt Konkurrenzprodukte und verwandte Systeme, d. h. Systeme mit ähnlicher Funktionalität. Zu den Dokumenten zählen Gesetze, Normen und Standards, die in einer Branche oder einer Domäne gelten. Nun müssen Requirements Engineers die Quellen identifizieren, damit ein initialer Erhebungsplan erstellt werden kann. Planen? Auch im Requirements Engineering werden Pläne erstellt, allerdings für den Erkenntnisprozess, d. h. für die Ermittlung und Ausarbeitung der Erkenntnisse rund um das Projekt. All das klingt wieder sehr technokratisch und soll deswegen anhand des Beispielprojekts erläutert werden.

Identifikation der Anforderungsquellen

Für das beA sind die Rechtsanwälte und ihre Mitarbeiter die wesentlichen Endnutzer. Die Anzahl der Rechtsanwälte ist der BRAK bekannt, jeder Rechtsanwalt benötigt schließlich eine Zulassung. Zum Projektstart im Jahr 2013 waren es circa 160 000 Rechtsanwälte. Über die Zahl der Mitarbeiter existierten nur grobe Schätzungen. Daher ging das Projektteam zunächst davon aus, dass jeder Rechtsanwalt mindestens einen Mitarbeiter beschäftigt. Diese Zahl sollte sich im weiteren Projektverlauf als zu gering herausstellen. Vielmehr stellte sich heraus, dass weit über 30 000 Mitarbeiter im anwaltlichen Umfeld arbeiten. Die Rechtsanwälte und ihre Mitarbeiter sind aber nicht die einzigen Nutzer. Das beA hat die Aufgabe, die elektronische Kommunikation zwischen Anwaltschaft und Justiz zu realisieren. Daher ist auch die Justiz ein Nutzer des Systems.

Der Nutzer ist aber nie der einzige Stakeholder, er selbst ist auch meist in ein Unternehmen oder eine andere Organisationsstruktur eingebettet. Ist der Endnutzer Teil eines Unternehmens, kommen die Vorgesetzten als Stakeholder hinzu. Rechtsanwälte arbeiten selten in größeren Unternehmensstrukturen. In der Regel sind sie selbstständig, weshalb die Kategorie „Vorgesetzte“ als Stakeholder ausscheidet. Dennoch finden sich auch in der Anwaltschaft weitere Organisationsstrukturen. Hier sind insbesondere die lokalen Rechtsanwaltskammern zu nennen. Sie organisieren die anwaltliche Selbstverwaltung und sind unter anderem für die Zulassung von Rechtsanwälten verantwortlich. Hinzu kommen diverse Verbände und Gremien, z. B. der Ausschuss „elektronischer Rechtsverkehr“, den es sowohl bei der BRAK als auch beim deutschen Anwaltsverein gibt. Eine weitere wichtige Quelle sind Unternehmen, die Software für Rechtsanwälte herstellen. Die Vertreter dieser Firmen sind ebenfalls Stakeholder, da es die Anforderung der Rechtsanwälte gibt, das beA in die Rechtsanwaltsprogramme zu integrieren.

Schlussendlich handelt es sich bei dem beA um ein besonders sicherheitskritisches System, womit sofort die Themen Datenschutz und Datensicherheit auf der Agenda stehen. Somit sind Datenschützer, insbesondere der Bundesdatenschutzbeauftragte und das BSI zu den Stakeholdern zu zählen. Die Liste der Stakeholder verzeichnet bereits eine Reihe von Einträgen und erweckt den Eindruck einer gewissen Vollständigkeit. Eine wichtige Gruppe von Stakeholdern fehlt allerdings noch: die Gruppe der „Hacker“.

Der Begriff des Hackers ist sehr umstritten: Zum einen bezeichnet er jemanden, der sich unberechtigterweise Zugang zu einem System verschafft. Auf der anderen Seite können Hacker nützlich sein, wenn sie beispielsweise Sicherheitslücken in bestehenden Systemen aufdecken. Wau Holland, Mitbegründer des Chaos Computer Clubs (CCC), soll einmal gesagt haben: „Ein Hacker ist jemand, der versucht, einen Weg zu finden, wie man mit einer Kaffeemaschine Toast zubereiten kann“. Genau diese Leute haben ein Interesse an diesem System. Daher wird auch der CCC zu den Stakeholdern gezählt. Beispielsweise wurden Vorträge des CCC mit Bezug zu beA (bspw. Vorträge über DE-Mail) ausgewertet.

Als weitere Quelle diente neben dem neuen Gesetz zum beA auch die aktuelle Gesetzgebung zur anwaltlichen Arbeit. Dazu zählen z. B. die Zivilprozessordnung oder die Bundesrechtsanwaltsordnung. Da das neue Gesetz erst in der Entstehung war, mussten die Requirements Engineers hier besonders darauf achten, ob sich evtl. noch Sachverhalte bis zur Verabschiedung ändern. Altsysteme im Betrieb gab es nicht, da das Vorhaben in Deutschland zum ersten Mal realisiert wird. Es gab aber verwandte Systeme in anderen Ländern und Systeme in Deutschland, die funktionale Ähnlichkeiten aufwiesen. Beispiele sind die DE-Mail und das elektronische Gerichts- und Verwaltungspostfach (EGVP).

Planung und Durchführung der Anforderungserhebung

Nach Abschluss der Identifikation der Anforderungsquellen war klar, dass über 300 000 Stakeholder, zahlreiche Dokumente und verwandte Systeme zu bearbeiten waren. Insbesondere die Anzahl der Stakeholder ist auf den ersten Blick kaum fassbar. Persönliche Interviews mit allen Stakeholdern scheiden somit aus praktischen Gründen unmittelbar aus. Schriftliche Befragungen oder Fragebögen sind ein erster Gedanke, der bei dieser Menge praktikabel erscheint. Allerdings bestand zu diesem Zeitpunkt das Problem, dass das beA von den Requirements Enginers nur unvollständig verstanden war und sich auf dieser Grundlage keine gehaltvollen Fragebögen erstellen ließen.

Stufe 1: Workshops

Das Instrument der Befragung wurde daher zurückgestellt. Stattdessen wurden Workshops mit möglichst repräsentativen Gruppen geplant. Workshops eignen sich in dieser Situation aus zwei Gründen. Das direkte Gespräch ist bestens geeignet, um an Informationen zu gelangen und ggf. Rückfragen zu Details und zum besseren Verständnis zu stellen. Weiterhin bietet die Gruppendiskussion zwischen den Teilnehmern die Möglichkeit, weiterführende Erkenntnisse zu gewinnen. Die Workshops waren nach Stakeholder-Gruppen organisiert: ein repräsentativer Querschnitt durch die Anwaltschaft, ein Querschnitt durch die anwaltliche Mitarbeiterschaft und Vertreter der Justiz. Insgesamt wurden acht eintägige Workshops mit über 200 Personen geplant. Das Ziel bestand darin, ein möglichst breites Spektrum von Anforderungen aus den einzelnen Gruppen zu erhalten. Daher war die Leitfrage jedes Workshops: „Was wünschen Sie sich von dem neuen System und was ist Ihnen besonders wichtig?“

Die Ergebnisse und die gesamte Diskussion wurde vom Projektteam protokolliert, sodass im Nachgang eine Nachvollziehbarkeit zwischen Workshopteilnehmern und Anforderung möglich war, um etwa Rückfragen stellen zu können. Die Ergebnisse wurden nach jedem Workshop gemeinsam mit der Geschäftsführung der BRAK durchgearbeitet, diskutiert und konsolidiert. Neben den Workshops haben die Requirements Engineers parallel mit einem Teil der Geschäftsführung der BRAK und dem Vorsitzenden des Ausschusses elektronischer Rechtsverkehr die vorhandenen Gesetze gesichtet und die sich daraus abzuleitenden Anforderungen erhoben. Zudem wurde in dieser Runde das weitere Vorgehen abgestimmt und erste Ideen zum System wurden diskutiert.

„Spezifikationen schreiben“ ist kein reines Aufschreiben

Die Ergebnisse aus den Workshops und den Diskussionen mit der Geschäftsführung mündeten in einer ersten Spezifikation. Nach Abschluss der Workshops lag ein Dokument mit über 100 Seiten vor, das das geplante System umriss und alle bis dahin bekannten Anforderungen enthielt. Die Erstellung des Dokuments darf allerdings nicht als reines Aufschreiben der Ergebnisse der individuellen Workshops oder der Analyse der Dokumente verstanden werden. Die Beschreibung ist ein erster Schritt zur Gestaltung des Systems beA. Dieses System entsteht nicht dadurch, dass die wesentlichen Erkenntnisse einfach hintereinander weggeschrieben werden. Vielmehr müssen die vielen gesammelten Anforderungen in einem System verbunden werden, das diesen Anforderungen genügt. Die Struktur und der Aufbau der Dokumente soll in diesem Artikel allerdings nicht das Thema sein (weiteres dazu hier).

Stufe 2: Onlinebefragungen

Nach Abschluss der Workshops wurde der Aktionsradius der Anforderungserhebung erweitert. Es lag ein erstes Verständnis über Gestalt und Umfang des beAs vor. Es fehlte allerdings noch eine Vorstellung über die Menge an Nachrichten, die das System bewältigen muss sowie über die typische Ausstattung (Betriebssystem, Bildschirme, Scanner etc.) in einer Anwaltschaft. Darüber hinaus waren belastbare Aussagen zu Aspekten der Barrierefreiheit von besonderer Bedeutung, da das Gesetz die Barrierefreiheit des Systems vorschrieb. Diese Informationen konnten durch Workshops nicht in der notwendigen Präzision erhoben werden. Daher wurde eine Reihe von Onlinebefragungen geplant, um unter anderem diese Fragen zu beantworten. Die BRAK stellte hierfür ihre E-Mail-Verteiler zur Verfügung und bat die lokalen Rechtsanwaltskammern, ihrerseits die Fragebögen zu verteilen. Als Untergrenze für eine sinnvolle Umfrage wurden 1 000 Rückmeldungen definiert. Überraschenderweise lagen bereits nach einer Woche mehr als 2 000 Rückmeldungen vor und am Ende der Umfrage sogar 3 500. Auf Basis der Daten konnte ein Mengengerüst aufgestellt werden. Darüber hinaus wurde klar, dass es „den“ prototypischen Arbeitsplatz nicht gibt. Vielmehr findet sich in der Anwaltschaft nahezu jedes Betriebssystem und jede erdenkliche technische Ausstattung. Die Umfrage zeigte darüber hinaus, dass ein signifikanter Anteil der Systemnutzer Menschen mit besonderen Bedürfnissen sind. Ihre Anforderungen müssen bei der Umsetzung zwingend berücksichtigt werden, wie z. B. die Verwendbarkeit von Brailletastaturen oder Kopfmäusen.

Abnahme und verbindliche Ergebnisse

Die Ergebnisse aus den Umfragen wurden von den Requirements Engineers in die vorliegende Spezifikation integriert. Die Endfassung der Spezifikation hatte einen Umfang von 131 Seiten und 34 669 Wörtern. Diese Spezifikation musste nun von den Auftraggebern abgenommen werden, denn sie sollte die Grundlage für die Beauftragung der Umsetzung des Systems werden. Naiv gedacht könnte die Abnahme so erfolgen, dass das Spezifikationsdokument den verantwortlichen Auftraggebern zur Abstimmung vorgelegt wird und diese ihre Zustimmung oder Ablehnung zu den Inhalten dokumentieren können. Solche Abnahmen scheitern nach Erfahrung der Autoren allerdings. Entweder stimmt der Auftraggeber dem Dokument nicht zu, da er es nicht versteht. Oder er stimmt dem Dokument zu, ist sich aber nicht im Klaren darüber, welcher Sache er zugestimmt hat. Daher muss auch die Abnahme wohldurchdacht vorbereitet sein.
Ausreichend Zeit zum Lesen der Spezifikation ist unerlässlich. Nach Erfahrung der Autoren ist ein Arbeitstag pro zehn Seiten Spezifikation eine gute Faustregel. Zeit allein reicht aber nicht aus. Die Verantwortlichen sind häufig nicht direkt in den RE-Prozess involviert und müssen auch inhaltlich auf ihre Aufgabe vorbereitet werden. Jedem Teilnehmer wird daher ein persönlicher Termin zur Vorbereitung angeboten, um offene Fragen zu klären. Zusätzlich wird ein Abnahmehandbuch entwickelt, das eine „Leseanleitung“ für Spezifikationen enthält. Im beA-Projekt wurde den Verantwortlichen beides angeboten. Die Hälfte nutzte das persönliche Gespräch, die Anderen wählten die „Leseanleitung“.

Neben ausreichend Zeit ist die Dokumentgestaltung wichtig, um das Durcharbeiten der Spezifikation zu erleichtern. Die Spezifikation wird als gebundenes Dokument an die Verantwortlichen geliefert. Es gibt eine Rechts- und eine Linkshänderversion. Was ist eine Linkshänderversion? Die Spezifikation wird so gebunden, dass der Text links liegt und die rechte Seite für Notizen freibleibt, es sei denn der Empfänger ist Linkshänder, dann gibt es das Ganze anders herum. So hat die „Schreibhand“ Raum für Notizen und stört den Lesefluss nicht.

Alle Teilnehmer der Abnahme müssen im bereits genannten Abnahmehandbuch ihre Entscheidungen, d. h. Zustimmung, Ablehnung, Änderungen etc. zu den einzelnen Artefakten dokumentieren. Das IREB empfiehlt diese feingranulare Abfrage, da die Spezifikation viele verschiedene Aspekte des geplanten Systems enthält, die einzeln zu entscheiden sind. Das bearbeitete Handbuch sollte eine Woche vor dem eigentlichen Abnahmeworkshop an die Requirements Engineers zurückgesendet werden. So liegen den Requirements Engineers die individuellen Meinungen von jedem Einzelnen vor und der Abnahmeworkshop kann von den Requirements Engineers effizient vorbereitet und durchgeführt werden.

Im Abnahmeworkshop besprechen die Verantwortlichen auf Auftragsgeberseite und die Requirements Engineers dann nur die Artefakte der Spezifikation, die von einem Verantwortlichen nicht abgenommen wurden. Alle anderen Artefakte sind damit automatisch abgenommen, ohne darüber gesprochen zu haben. Im beA-Projekt wurden 39 Prozent der Artefakte direkt abgenommen, bei 36 Prozent musste etwas geändert werden und bei 25 Prozent gab es unterschiedliche Meinungen. Alle strittigen Punkte konnten durch diese strukturierte Vorbereitung innerhalb eines Tages geklärt werden, sodass schließlich eine abgestimmte Version vorlag.

Zusammenfassung

Nach Abschluss der Abnahme lag eine vollständige Spezifikation für die Planung eines Umsetzungsprojekts für das beA vor. Der Zeitraum vom Projektstart bis zum hier beschriebenen Abnahmetermin umfasste fünf Monate. In den Workshopphasen bestand das RE-Team aus bis zu vier Personen. Der Aufwand für das hier beschriebene Projekt lag deutlich unter einem Personenjahr. Mit vergleichsweise wenig Aufwand wurde so die Grundlage für ein nachhaltiges und effizientes Entwicklungsprojekt bereitgestellt. Das Beispiel des beA zeigt, dass das RE eine wichtige und sehr nützliche Disziplin der Softwareentwicklung ist. Das RE bietet Methoden und Techniken, um ein System effizient zu verstehen und zu konzipieren. Durch die Einbeziehung aller relevanten Anforderungsquellen entsteht eine umfassende Spezifikation. Wichtig ist, dass Menschen mit den passenden Qualifikationen die Aufgaben des RE übernehmen. Nur so kann gewährleistet werden, dass das RE angemessen geplant und durchgeführt werden kann. Umfassende Informationen zur Aus- und Weiterbildung finden sich beispielsweise auf den Internetseiten des IREB. Die Aufgaben des RE sind an dieser Stelle aber noch lange nicht beendet. Es leistet auch im Verlauf von Entwicklungsprojekten einen wesentlichen Beitrag zum Projekterfolg. Aber das ist ein Thema für einen anderen Artikel.

Aufmacherbild: Businessman designing a plan on a touch screen interface von Shutterstock / Urheberrecht: Peshkova

Verwandte Themen:

Geschrieben von
Oliver Hehlert
Oliver Hehlert ist Senior Consultant bei der adesso AG. Er arbeitete zehn Jahre in der Versicherungsbranche, bevor er 2012 zu adesso wechselte. Seine Schwerpunkte sind Beratung, Projektmanagement und Requirements Engineering.
Kim Lauenroth
Dr. Kim Lauenroth ist Competence-Center-Leiter und Chief Requirements Engineer bei der adesso AG. Nach dem Studium der Informatik, BWL und Psychologie an der Universität Dortmund zog es ihn 2003 an die Universität Duisburg-Essen, dort promovierte er 2009 im Bereich Requirements Engineering. Neben Beruf und Familie engagiert er sich im IREB e.V. für die Aus- und Weiterbildung im Requirements Engineering.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: