Anforderungsmanagement mit JIRA und ReqSuite®

Einleitung

Anforderungsmanagement mit JIRA

Atlassian’s JIRA hat in den vergangenen Jahren einen bemerkenswerten Einzug in eine Vielzahl von Unternehmen gehalten und es ist mehr als ein Gefühl, dass fast jedes Unternehmen, in dem Softwareentwicklung eine Rolle spielt, inzwischen JIRA (oder ähnliche Produkte wie Microsoft’s Team Foundation Server) im Einsatz hat. Ursprünglich als Anwendung für Fehlermanagement, Problembehandlung und operatives Projektmanagement verwendet, nutzen immer mehr Firmen JIRA auch für das Aufgaben- und Anforderungsmanagements innerhalb der (agilen) Softwareentwicklung. Böse Zungen behaupten inzwischen deshalb nicht ganz zu Unrecht, dass JIRA das neue Excel sei, also ein Tool mit dem Unternehmen versuchen, möglichst alles zu erschlagen.

Im Hinblick auf das Anforderungsmanagement und andere Aufgaben des Requirements Engineering stellt sich daher berechtigt die Frage, welchen Nutzen JIRA in diesem Umfeld liefern kann. Zweifelsfrei bietet JIRA grundlegende Features für das Anforderungsmanagement und kann somit in vielen Aspekten mit expliziten Anforderungsmanagement-Werkzeugen (RM Tools) mithalten. Dennoch stellen zunehmend immer mehr Unternehmen fest, dass sich durch die Nutzung von JIRA (oder ähnlicher Werkzeuge) nicht automatisch Projekterfolg einstellt oder die Kommunikation zwischen Fachbereich und IT nur ansatzweise verbessert werden kann. Sofern keine ausreichend methodische Basis bei den Projektbeteiligten vorliegt, greift auch in diesem Zusammenhang der alte Spruch „A fool with a tool is still a fool“ oder auch die noch drastischere Erkenntnis „Shit in, shit out“.

Zweifelsohne bietet JIRA exzellente Möglichkeiten für das Aufgabenmanagement und die zugehörige Statuskontrolle vor, während und nach der Entwicklung. Doch um überhaupt zu wissen, welche Aufgaben zu erledigen sind (sprich welche Anforderungen einer Umsetzung in einem gewissen Sprint oder Release bedürfen) braucht es mehr als das. Gutes Requirements Engineering umfasst noch immer zentrale Kernfragen wie beispielsweise

  • Wer sind meine Stakeholder?
  • Was sind Ihre Bedürfnisse?
  • Welche Systemeigenschaften und -fähigkeiten (Anforderungen) resultieren daraus?
  • Wie wichtig sind diese Anforderungen jeweils?
  • Wie stehen die Anforderungen miteinander in Beziehung und welche Verfeinerung gibt es zwischen ihnen?
  • Haben wir wichtige Anforderungen vergessen oder unzureichend spezifiziert?
  • etc.

Bekannte Werkzeuge am Markt können dies natürlich kaum bis gar nicht beantworten. Der Nutzen von JIRA, aber genauso anderer altbekannter RM Tools im Hinblick auf die Qualität der Anforderungen hängt daher nachwievor einzig und allein von der individuellen Expertise einzelner Projektbeteiligten ab.

Die Anforderungsmanagement-Software ReqSuite®

Mit OSSENO’s ReqSuite® (siehe Abb. 1) wurde in den vergangenen Jahren jedoch ein Werkzeug für das Anforderungsmanagement präsentiert, das auch inhaltliche und methodische Fragestellungen unterstützt und durch intelligente Assistenzfunktionen die Qualität und Vollständigkeit von Anforderungen von Beginn an sicherstellen kann. Analog zu einem Programm für die Erstellung von Einkommenssteuererklärungen, das auch unerfahrene Personen bei der korrekten und vollständigen Erstellung standardisierter Steuererklärungen unterstützt, bietet ReqSuite® Konzepte um (ausreichend) gute Anforderungsdokumente in standardisierter Weise ungeachtet persönlicher Expertise im Bereich „Requirements Engineering“ zu entwickeln. Somit bietet die Assistenz von ReqSuite® auch bei der Beantwortung oben genannter Kernfragen Hilfestellungen und weist daneben auf Unvollständigkeiten oder Inkonsistenzen direkt während der Anforderungsdokumentation hin. Der Spruch „A fool with a tool is still a fool“ greift daher in diesem Kontext nur noch begrenzt.

Abb. 1: Beispielhafte Maske von ReqSuite®

Die Vorteile liegen auf der Hand und wurden bereits bei einer Vielzahl von Kunden bestätigt: Unklarheiten und Unvollständigkeiten, die zu kostspieligen Nacharbeiten vor, während oder gar nach der Entwicklung führen, werden proaktiv reduziert. Zugleich besteht stets eine Übersicht über noch unzureichend geklärte Aspekte, was (sofern man nicht wasserfallartig entwickelt) insbesondere bei der Festlegung parallel zur Analyse laufender Sprints erfolgsentscheidend ist. Schließlich automatisiert ReqSuite® auch Formulierungen und Formatierungen, so dass sich Anwender ganz auf die Inhalte von Anforderungen und weniger deren Syntax fokussieren können. Das schafft schließlich nicht nur mehr Freiraum für inhaltliche Arbeit, sondern erhöht auch die Akzeptanz von dem bisweilen häufig als schwergewichtig und antiquiert wahrgenommenen Requirements Engineering im Ganzen.

Doch sollte man jetzt sein etabliertes JIRA abschalten und nur noch mit ReqSuite® arbeiten? Ganz klar nein! Auch wenn die korrekte Antwort stets im individuellen Einzelfall beantwortet werden muss, so lässt sich grundsätzlich sagen, dass JIRA für viele Arbeitsschritte in der Softwareentwicklung eine Vielzahl wertvoller Features anbietet, die von ReqSuite® bis dato nicht angemessen substituiert werden möchten. Gleichwohl bietet ReqSuite® enorme Mehrwerte für das Requirements Engineering und ähnlich geartete Disziplinen, die von JIRA und seinen Erweiterungen und begleitenden Tools wie z.B. Confluence nur unzureichend erreicht werden können.

Entsprechend ist es vielversprechend, die gemeinsame und integrierte Nutzung von JIRA und ReqSuite® nachfolgend zu beleuchten.

Methodische Integration

Die methodische Integration von JIRA mit ReqSuite® ist stark davon abhängig, in welchem Unternehmens- und Entwicklungskontext man sich befindet. Dies betrifft einerseits den Entwicklungsgegenstand (z.B. die Weiterentwicklung eines Bestandssystems in einer Versicherung vs. die Entwicklung eines Steuermoduls im Maschinenbau), andererseits aber auch den Umfang der Entwicklungsaktivitäten (z.B. Projekt vs. Portfolio).

Dennoch lässt sich kontextübegreifend für eine Integration folgende Best Practice postulieren:

„ReqSuite® verwaltet die Inhalte (wozu auch Anforderungen gehören) und JIRA die Aufgaben innerhalb eines Portfolios oder Projekts.“

Gemäß dieser Best Practice macht es bei der Integration von JIRA und ReqSuite® wenig Sinn die Inhalte von ReqSuite® eins zu eins nach JIRA zu kopieren und quasi eine Redundanz in beiden Werkzeugen herzustellen. Vielmehr sollte eine inhaltliche Abstraktionsebene festgelegt werden, die als geeignete Ausgangsbasis zur Synchronisation eingesetzt werden kann.

Die wesentliche Herausforderung bei der methodischen Integration (aber auch generell bei der Definition eines sauberen methodischen Vorgehens) besteht folglich darin, die inhaltliche Verfeinerungsstruktur von Anforderungen bis hin auf die Ebene von Entwicklungsaktivitäten zu definieren. Hierfür gibt es in der Regel kein pauschales Modell, da diese Struktur maßgeblich vom Entwicklungsgegenstand abhängig ist.  Im Umfeld eines betrieblichen Informationssystemen könnte diese Struktur beispielsweise Anforderungen hinsichtlich der Geschäftsprozesse, Organisationseinheiten, Use Cases, Systemfunktionen, Geschäftsdaten und Schnittstellen beinhalten, die angemessen auf entsprechende Entwicklungsaktivitäten abgebildet werden müssten (lesen Sie hierzu auch unser WhitePaper zur Definition maßgeschneiderter Anforderungsprozesse).

Deshalb kann für den Zweck dieses Beitrags auch nur eine abstrakte Verfeinerungsstruktur aufgezeigt werden, die eine mögliche Aufteilung zwischen ReqSuite® und JIRA darstellt (siehe Abb. 2).

Abb. 2: Konzeptioneller Zusammenhang von Elementen in ReqSuite® und JIRA

Gemäß dieses Modells umfasst ReqSuite® Informationen über Stakeholder, ihren Kontext, ihren Bedarf sowie die daraus resultierenden Themen, Projekte und Anforderungen. In JIRA werden ergänzend die aus den Anforderungen resultierenden Entwicklungsaktivitäten gepflegt. Projekte und Projektbeteiligte werden ggf. redundant in beiden Tools gepflegt.

Melden nun Stakeholder Bedarfe, so werden diese in Form von Themenbeschreibungen innerhalb eines zugehörigen Portfolios in ReqSuite® spezifiziert. Portfolio- oder Programmmanager können dann nach entsprechender Prüfung und Priorisierung der Themen diese auf konkrete Projekte abbilden. Innerhalb von Projekten bietet ReqSuite® dann die oben erwähnte Assistenzfunktionen an, um die Projektbeteiligten bei einer sukzessiven und qualitätsgesicherten Herausarbeitung der Projektanforderungen unter Berücksichtigung des Kontextes angemessen zu unterstützen.

Zu beliebigen, aber auch fest definierbaren Zeitpunkten lassen sich dann automatisiert Entwicklungsaktivitäten (Tickets) auf Basis der Anforderungen ableiten und in das zugehörige JIRA-Projekt exportieren. Dabei kann, sofern konfiguriert, auch eine automatische Zuweisung auf die für die Umsetzung zuständigen Projektbeteiligten erfolgen. Nach entsprechender Erledigung ihrer Aufgaben können Sie dann den Status ihrer Aktivitäten aktualisieren, der dann bei der nächsten Synchronisation automatisch nach ReqSuite zurückgespiegelt wird und somit den Erfüllungsstatus der Anforderungen dokumentiert.

Eine wichtige Frage an dieser Stelle bleibt jedoch, wie schließlich einzelne (System-)Anforderungen auf Entwicklungsanforderungen für jeweilige Entwicklungsaktivitäten abgebildet werden können. Auch dies hängt maßgeblich vom Entwicklungskontext ab. So wäre es im obigen Beispiel denkbar, geschäftliche Anforderungen über verschiedene Abstraktionsebenen wie Geschäftsprozesse und Use Cases schrittweise bis auf die Ebene feingranularer Systemfunktionen herunterzubrechen, die zugleich den Inhalt einzelner Entwicklungsanforderungen darstellen. So würde beispielsweise die Anforderung „Als Sachbearbeiter Lebensversicherung möchte ich den Rückkaufwert eines Vertrages auf der Vertragsübersicht sehen, damit ich den Kunden schneller beauskunften kann.“ aus ReqSuite® wortgleich als Entwicklungsanforderung (Ticket) in JIRA übernommen und die resultierenden Entwicklungsaktivitäten für die Entwickler implizit sichtbar. Alternativ denkbare wäre jedoch auch eine weitere Verfeinerung der Anforderung in tatsächliche Aktivitätsbeschreibungen wie „Erweiterung der Maske LV-Ü1 um ein ReadOnly-Feld Rückkaufwert“. Letztere hätten den Nachteil erhöhter Spezifikationsaufwände, jedoch den Vorteil einer präziseren Aufgabenbeschreibung und eines feingranulareren Trackings.

Technische Integration

Ein Hauptargument, das zuweilen gegen die Verwendung mehrerer Werkzeuge angeführt wird, sind Integrations- und Konsistenzprobleme. Können Daten nur manuell oder ausschließlich teilautomatisiert zwischen verschiedenen Werkzeugen ausgetauscht werden, stellt dies nicht nur ein Effizienzhindernis, sondern auch eine enorme Fehlerquelle dar. Neben methodischen Integrationsaspekten spielt daher auch die technische Integrationsfähigkeit eine entscheidende Rolle. Die technische Integration von JIRA und ReqSuite® wurde daher mehrstufig, dynamisch und bidirektional ausgelegt.

Mehrstufige Integration

Auf der obersten Ebene der Integration steht die Verknüpfung von Projekten in ReqSuite® mit entsprechenden Projekten in JIRA in Form von einer 0..* – 0..1-Beziehung. Zu jedem Projekt in ReqSuite® kann max. ein Projekt in JIRA hinterlegt werden. Anders herum können aber mehrere ReqSuite®-Projekte Inhalte mit einem JIRA-Projekt synchronisieren. Der Grund für diese unsymetrische Beziehung ist, dass aus Sicht von ReqSuite® jeweils ein klarer „Abnehmer“ für die Anforderungen definiert sein soll. Anders herum kann jedoch ein JIRA-Projekte Inhalte aus verschiedenen ReqSuite®-Projekten konsolidieren, da ggf. der Zuschnitt innerhalb der Entwicklung anders organisiert wird wie auf Ebene der fachlichen Projekte innerhalb des Themenportfolios. In Abb. 3 ist beispielsweise zu sehen, dass das Projekt „IT-Anforderungen“ aus ReqSuite® mit dem Projekt „ReConf2017“ synchronisiert werden soll.

Abb. 3: Mapping von Projekten mit Auswahl der zu synchronisierenden Anforderungstypen

Auf der zweiten Ebene der Integration steht dann die Verknüpfung der Anforderungstypen aus ReqSuite® mit Issue Types in JIRA ebenfalls in Form einer 0..* – 0..1-Beziehung. In jedem Projekt lässt sich somit definieren, ob die Anforderungen eines gewissen Typs aus ReqSuite® überhaupt nach JIRA exportiert werden sollen, und, wenn ja, in Form welches Issue Types. Im oben genannten Beispiel könnte man somit einstellen, dass nur Anforderungen des Typs „Funktion“ mit JIRA synchronisiert werden sollen (siehe Abb. 3) und zwar in Form des Issue Types „Task“ (siehe Abb. 4).

Auf der dritten Ebene der Integration lässt sich schließlich ein feingranulares Attributmapping zwischen ReqSuite® und JIRA definieren. Neben einem Standardmapping (Name -> Summary und Beschreibung –> Description), lässt sich sehr individuell einstellen, wie einzelne Felder aus ReqSuite® mit JIRA-Feldern zusammenhängen. Dabei lassen sich auch die Projektbeteiligten automatisch mappen, so dass bereits in ReqSuite® die zur Umsetzung verantwortlichen Assignees in JIRA definiert werden können.

Abb. 4: Mapping von Anforderungstypen auf Issue Types sowie der zugehörigen Attribute

Dynamische Integration

Bei der Integration von ReqSuite® mit JIRA wurde großen Wert auf Flexibilität und Konfigurierbarkeit gelegt. Folglich wurde die Schnittstelle so entwickelt, dass kaum statische Mappings vordefiniert wurden, sondern vollständig zur Laufzeit ausgewählt werden können. Die integrierbaren Projekte, Anforderungstypen, Issue Types und Attribute sowohl in ReqSuite® als auch in JIRA werden dynamisch zur Laufzeit ermittelt und können dann entsprechend miteinander in Beziehung gesetzt werden. Somit ist es auch möglich, sogenannte Custom Types und Custom Attributes, also selbst definierte Typen und Felder, bei der Abbildung zu berücksichtigen.

Bidirektionale Integration

Unter bidirektionaler Integration versteht sich die Möglichkeit, nicht nur Inhalte von ReqSuite® nach JIRA zu übertragen, sondern auch bedarfsweise zurückzuspiegeln. Bei der Konfiguration der Schnittstelle lässt sich daher definieren, ob eine (bidirektionale) Synchronisation oder nur ein (unidirektionaler) Export von ReqSuite® nach JIRA gewünscht ist. Im Falle einer echten Synchronisation ist die Schnittstelle in der Lage, Änderungen auf beiden Seiten zusammenzuführen bzw. im Falle eines Konfliktes automatisch auf Basis hinterlegter Regeln aufzulösen. Dadurch können Reibungsverluste durch Inkonsistenzen nahezu ausgeschlossen werden.

Wann macht eine Integration Sinn?

Eine Integration von JIRA und ReqSuite® kann viele Vorteile für das Requirements Engineering und Management mit sich bringen. Konkret macht eine Nutzung von ReqSuite® zusätzlich zu JIRA insbesondere im Falle folgender Gegebenheiten Sinn.

Wenn Qualität oder Vollständigkeit der Anforderungen unzureichend sind

Wenn die Qualität, Vollständigkeit oder auch Standardisierung von Anforderungen nicht zufriedenstellend ist, bietet ReqSuite® exzellente Möglichkeiten um hierfür Abhilft zu schaffen. Dies ist häufig (aber nicht nur) dann der Fall, wenn technisch weniger versierte Kollegen und Kolleginnen aus Fachbereichen involviert werden sollen, die kaum Erfahrung mit dem Schreiben guter Anforderungen besitzen. Diese ohne Assistenz direkt in JIRA oder vorgelagerte Werkzeuge wie Confluence ihre Wünsche und Anforderungen schreiben zu lassen, bringt i.d.R. unvermeidbar nachträgliche und ggf. kostspielige Klärungen und Anpassungen mit sich.

Wenn neben „Tickets“ auch noch Dokumente benötigt werden

In vielen Organisationen werden im Rahmen der Projektarbeit diverse Dokumente benötigt, selbst wenn letztendlich agil entwickelt werden soll. Durch eine sauberere Trennung von Inhalt und Repräsentation in ReqSuite® kann zu diesem Zweck ReqSuite® automatisch alle benötigten Dokumente und Reports wie Projektanträge, Fachkonzepte, IT-Konzepte, Abnahmekonzepte, Angebote, etc. im gewünschten Corporate Design auf Knopfdruck generieren. JIRA ist hinsichtlich der Generierung solcher Dokumente stark limitiert.

Wenn eine gute Zusammenarbeit zwischen Fachbereich und IT gewünscht ist

Wenn eine gute Zusammenarbeit zwischen Fachbereich und IT gewünscht ist, macht auch eine klare Trennung von inhaltlichen Beschreibungen und entwicklungsrelevanten Aufgaben Sinn. Insbesondere ist es hierbei notwendig, die Sprache der Fachbereiche angemessen zu adressieren (die beispielsweise in Abläufen, Aufgaben und Dokumenten denken) und von technische Details oder Konzepten zu abstrahieren. Ein weiterer Vorteil der Trennung von Inhalt und Entwicklungsaufgabe ist, dass konkrete Entwicklungsaufgaben, die i.d.R. nur einmal im Rahmen eines konkreten Projektes vorgenommen werden müssen, klar von den darin umgesetzten Inhalten getrennt werden können, die sich ggf. projektübergreifend wiederholen (z.B. Datenglossare).

Wenn Projektbeteiligte nicht mit JIRA arbeiten können oder wollen

Auch wenn JIRA recht einfach zu bedienen ist, ist es nach wie vor ein Werkzeug von Entwicklern für Entwickler und keins in dem sich Fachbereichsmitarbeiter zu Hause fühlen. Insbesondere dann, wenn unklar ist, was eigentlich die Anforderungen sind und wie sie systematisch hergeleitet werden können, reicht die Vorgabe einfacher Schablonen für beispielsweise Epics und User Stories nicht aus, um die Bedarfe der Fachbereiche angemessen zu ermitteln. Hier macht es Sinn durch zielgruppenspezifischere Erfassungsmasken und Assistenzfunktionen die entsprechende Arbeit zu unterstützen. Während dies in JIRA nur aufwändig implementiert werden muss, bringt ReqSuite® einfache, aber mächtige Features von Haus aus mit.

Fazit

Der Erfolg und Nutzen von JIRA ist unbestritten und soll in diesem Artikel in keinster Weise geschmälert werden. Dennoch ist insbesondere bei einer bereichsübergreifenden Zusammenarbeit die Nutzung zusätzlicher Werkzeuge insbesondere auf Seiten der Fachbereiche wünschenswert. Vielumworbene Produkte, die gerne im Bundle mit JIRA beworben werden, bieten jedoch keine wirkliche Arbeitsassistenz für Projektbeteiligte und stellen oft nicht mehr als eine webbasierte Word-Alternative dar; mit allen Vor- und Nachteilen wie man sie aus der Arbeit mit Office-Produkten bis dato kannte. Sofern oben genannte Aspekte gegeben sind, sollte daher über die ergänzende Nutzung von ReqSuite® als übergreifendes und vor allem inhaltsfokussiertes Portfolio- und Anforderungswerkzeug nachgedacht werden.

„Arbeitskultur“ – Ein wichtiger Baustein im Requirements Engineering

Requirements Engineering (RE) gewinnt immer mehr Beachtung in unterschiedlichsten Branchen. Doch bei der Einführung und langfristigen Etablierung eines RE-Prozesses besteht immer wieder die Frage, was „richtig“ oder zumindest „gut genug“ im eigenen Unternehmenskontext ist. Glaubt man Schulungsanbietern und Beratern, so ist gutes RE primär eine Frage der Methode und individueller Skills [1][2]. Glaubt man Toolherstellern, so ist gutes RE maßgeblich von der verwendeten Werkzeugunterstützung abhängig. Doch was davon ist richtig? Und steht dies im Widerspruch oder sind es nur verschiedene Facetten, die allesamt für das Gelingen eines erfolgreichen RE notwendig sind? Dieser Artikel versucht anhand aktueller Herausforderungen im Requirements Engineering eine Antwort hierauf zu finden und zeigt anhand der Analogie zu einer Reise auf, dass vielmehr dem Aspekt „Arbeitskultur“ Beachtung geschenkt werden sollte.

Betrachten man die Auswertung der Umfrage „RE Kompass 2014/2015“ [3] so findet man eine Vielzahl von Herausforderungen mit denen sich Praktiker im RE derzeit konfrontiert sehen, u.a.

  • Finden des richtigen Detailgrads (69%)
  • Anforderungserhebung generell (37%)
  • Anforderungsdokumentation generell (35%)
  • Wiederverwendung und Standardisierung von Anforderungen (33%)
  • Handhabung von Änderungen (29%)
  • Festlegung von Anforderungen (28%)
  • Feststellen der Vollständigkeit (24%)
  • Modellierung von Anforderungen (23%)
  • Sicherstellung der Nachverfolgbarkeit (22%)

Analysiert man diese Herausforderungen etwas genauer, stellt man fest, dass sich diese im Wesentlichen in die Bereiche „Methodische Unklarheit“, „(Zwischen)menschliche Aspekte“ und „Skalierungsherausforderungen“ unterteilen lassen. So ist beispielsweise das Finden des richtigen Detailgrads oftmals eine methodische Unklarheit, während Probleme bei der Festlegung von Anforderungen zumeist auf menschliche Aspekte wie begrenzte Entscheidungsfreudigkeit oder Kommunikationsfähigkeit zurückzuführen sind. Sicherstellung von Nachverfolgbarkeit oder Handhabung von Änderungen sind hingegen Beispiele für Skalierungsherausforderungen, da sie erst mit einer gewissen Anzahl von Anforderungen zum Problem werden.

Aufgrund dieser drei wesentlichen Gruppen von Herausforderungen, die sich übrigens in jedem Projekt wiederfinden, sind wir der Auffassung, dass sich diese weder mit Methoden noch mit Werkzeugen allein bewerkstelligen lassen. Vielmehr benötigt man gleichermaßen adäquate Methoden (adressiert „methodische Unklarheit“, also wie man etwas tun kann), Werkzeuge (adressiert „Skalierungsproblem“, also, dass man etwas auch im großen Umfang noch tun kann), Kommunikations- und Arbeitskultur (adressiert „(Zwischen)menschliche Aspekte“, also, ob man überhaupt etwas tun kann) um RE erfolgreich durchzuführen.

Verglichen mit einer Reise weisen Methoden also den Weg zum Ziel, während Werkzeuge das Fortbewegungsmittel darstellen und die Kultur den Untergrund repräsentiert, auf dem man sich bewegt. Aus dieser Analogie ist offensichtlich, dass man in der Regel alles davon braucht: Ohne einen klaren Weg (Methode) wird man entweder gar nicht bzw. nur zufällig oder mit Umwegen sein Ziel erreichen. Ohne ein Fortbewegungsmittel (Werkzeug) wird es ggf. lange dauern bis man sein Ziel erreicht, sofern man nicht schon vorher an Erschöpfung aufgibt. Und schließlich hängt es maßgeblich vom Untergrund (Kultur) ab, ob man auf gewissen Wegen überhaupt wie geplant vorwärtskommt.

In unserer langjährigen Beratungspraxis haben wir jedoch immer wieder erlebt, dass insbesondere bei der „Kommunikations- und Arbeitskultur“ noch erheblicher Nachholbedarf besteht. Dies betrifft insbesondere die Zusammenarbeit in der Anforderungsermittlung wie sie meist in Besprechungen und Workshops stattfindet. Dabei können bereits einige einfache Maßnahmen hierbei deutliche Verbesserungen ermöglichen.

Im Folgenden stellen wir einige Maßnahmen vor, mit denen die Arbeitskultur bei der Anforderungsermittlung dahingehend gesteigert werden kann, dass eine solide Grundlage für RE geschaffen ist. Auch wenn diese Maßnahmen auf den ersten Blick „trivial“ erscheinen, so zeigt die industrielle Praxis hier immer wieder erhebliche Defizite auf, weshalb uns eine explizite Motivation an dieser Stelle gerechtfertigt erscheint.

Vorbereitet sein: Gute Vorbereitung ist essentiell für jede einzelne Besprechung in der Anforderungsermittlung. Dazu gehört eine klare Zielsetzung, Stakeholderidentifikation und Moderatorensuche, aber auch die eigentliche Vorbereitung des Workshops hinsichtlich Agenda, Leitfragen, Techniken für die Beantwortung der Leitfragen (z.B. Kartenabfrage), Bereitstellung von Moderationsmaterial, Catering, Raumbuchung, etc. Tut man dies nicht verliert man unnötig Zeit und gar Motivation bei den Beteiligten während der Besprechung!

Einen klaren Fokus setzen: Besprechungen zur Anforderungserhebung sollten sich jeweils immer nur mit bestimmten Teilthemen eines Projekts auseinandersetzen [4], als in einem „generellen Anforderungsworkshop“ auszuarten. Dadurch können die richtigen Stakeholder viel einfacher hinzugezogen werden, bessere Diskussionen entfachen, zielgerichteter und konzentrierter arbeiten und letztendlich in kürzerer Zeit viel mehr rausholen. Die Erfahrung zeigt: Vier Workshops von jeweils zwei Stunden sind oft ergebnisreicher als ein einzelner Ganztagesworkshop.

(Nur) die richtigen Leute einladen: Stakeholder sind wichtig, aber nicht alle zu jeder Zeit. Wenn es zum Beispiel um technische Schnittstellen zu Drittsystemen gibt, braucht in der Regel niemand vom Fachbereich teilzunehmen. Für jeden Workshop sollten deshalb gesondert die Personen identifiziert werden, die sich bzgl. des jeweiligen Teilthemas auskennen und hier Probleme, Anforderungen oder gar Lösungsideen beitragen können. Ähnlich zum vorherigen Punkt kann in einer kleinen Gruppe viel effektiver gearbeitet werden („zu viele Köche… [2]“). Zudem wird die Terminfindung erheblich erleichtert.

Entscheidungsbefugnisse erteilen: Personen, die in Besprechungen teilnehmen, sollen Entscheidungen treffen wollen und dürfen. Repräsentanten einer Stakeholdergruppe (z.B. Abteilung) sollten von Vorgesetzten vorab entsprechende Entscheidungsbefugnis erhalten haben – alternativ sollte der Entscheider [2] selbst eingeladen werden, wenn er / sie seinen Angestellten entsprechende Befugnis nicht erteilen möchte. Ohne Entscheidungsbefugnisse verzögert sich der Anforderungsprozess signifikant, da häufig langwierige Abstimmungen nach dem Workshop stattfinden müssen oder gar getroffene Beschlüsse revidiert werden.

Einen unbefangene Moderator einsetzen: Moderation ist das A und O einer erfolgreichen Anforderungsermittlung. Ein fähiger (erfahrener) Moderator / eine fähige Moderatorin ist hierbei die Grundvoraussetzung. Es ist hierbei viel wichtiger, dass diese Person über Moderationsgeschick verfügt und auch Mut für „dumme“ Fragen hat, als dass sich diese Person in der Projektthematik auskennt. Folglich muss diese Rolle auch nicht aus dem Projektteam besetzt werden, sondern sollte sogar von einem/einer Kollegen/in aus einer anderen Abteilung oder gar einem Externen übernommen werden, der eine gewisse Distanz zum Projektinhalt hat und somit eine Verstrickung in länglichen Detaildiskussionen ohne Ergebnis im Hinblick auf das angestrebte Besprechungsziel vermeiden kann.

Entscheidungen treffen: Die Anforderungsermittlung ist kein Selbstzweck, sondern soll grundlegende Weichen für ein Projekt stellen. Daher sollte keine Besprechung ohne gefasste Beschlüsse beendet werden. Bewusst und möglichst gemeinschaftlich sollte entschieden werden, welche der Ideen und Vorschläge, die vorgebracht wurden, als „echte“ Anforderung aufgenommen werden sollen. Priorisierungs- und Verhandlungstechniken [1][2] sollten eingesetzt werden, wenn die Festlegung nicht so einfach durchzuführen ist.

Ergebnisse dokumentieren: Die Entscheidungen, die im Rahmen von Besprechungen getroffen wurden, sollten schnellstmöglich in Anforderungen überführt und angemessen dokumentiert werden. Klärungspunkte und sonstige Anmerkungen, zu denen noch keine Entscheidungen getroffen werden konnten, sollten in einem entsprechenden Protokoll dokumentiert und explizit zur Planung weiterer Schritte in der Anforderungsanalyse genutzt werden. Eine verzögerte Dokumentation führt häufig zu verzerrten oder gar falschen Anforderungen und erfordert unnötige Korrekturen.

Kultur, Methode und Werkzeug sind allesamt wichtig um RE erfolgreich betreiben zu können. In einschlägigen Schulungsangeboten und Lehrbüchern im Requirements Engineering wird jedoch fast ausschließlich die methodische Komponente beleuchtet, ohne ausreichend auf den Nutzen von Werkzeugen sowie die Notwendigkeit einer soliden Arbeitskultur ausreichend einzugehen.  Dabei zeigt sich jedoch in jüngerer Vergangenheit immer mehr, dass viele methodische Fragestellungen inzwischen zunehmend von „intelligenten“ Werkzeugen wie unserer ReqSuite® automatisiert werden können (hier ist die Analogie zu Assisted Driving passend), weshalb der Arbeitskultur in der RE-Ausbildung zukünftig eine viel größere Rolle eingeräumt werden sollte.

Quellen

  1. Pohl, K., Rupp, C.: Basiswissen Requirements Engineering, dpunkt (2011)
  2. Wiegers, K., Beatty, J.: Software Requirements, Third Edition, Microsoft Press (2013)
  3. Adam, S., Wünch, C., Seyff, N.: RE-Kompass 2014/2015 – Ergebnisbericht, http://www.re-kompass.de, (2014)
  4. Adam, S., Riegel, N., Doerr, J.: TORE – A Framework for Systematic Requirements Development in Information Systems, Requirements Engineering Magazine (4), IREB (2014)

Warum ein RE/RM-Werkzeug nicht der zweite Schritt sein sollte…

Das Thema Requirements Engineering und Management (RE/RM) erfreut sich in den letzten Jahren zunehmender Beachtung. Unternehmen unterschiedlichster Branche und Größe haben daher begonnen, ein professionelles RE in ihren Häusern zu implementieren und ihre Angestellten in den dazugehörigen Vorgehensweisen auszubilden. Doch die Einführung oder Verbesserung von RE-Prozessen in Unternehmen ist nicht einfach und stellt sogar die größte Herausforderung hinsichtlich RE überhaupt dar. Zu oft fällt es schwer, Kollegen von der Notwendigkeit eines systematischen Vorgehens zu überzeugen oder sie zu befähigen, zielführende, aber bis dato ungewohnte Methoden in ihrem Projektalltag einzusetzen.
In mehr als 10-jähriger Beratungspraxis in einer Vielzahl von Projekten zur Einführung oder Verbesserung von RE konnten wir immer wieder feststellen, dass der Nutzen von Schulungsmaßnahmen in diesem Kontext häufig überschätzt wird, zugleich aber kaum ein Mehrwert durch moderne RE/RM-Werkzeuge hierbei gesehen wird.
In unserem Artikel, den wir im Online Themenspecial Requirements Engineering des Objektspektrum veröffentlicht haben, möchten wir daher zunächst typische, diesem Sachverhalt zugrundeliegende Fehlannahmen benennen und aufzeigen, weshalb ein (gutes) Werkzeug bei der Einführung und Verbesserung von RE einen erheblichen Mehrwert liefern kann. Anschließend werden wir die dafür notwendigen Werkzeugeigenschaften am Beispieldes Werkzeugs ReqSuite®darstellen und erläutern, welche Potenziale sich dadurch für Unternehmen ergeben.

 

Zehn Tipps für eine bessere Anforderungsanalyse mittels Workshops

Auch wenn die Notwendigkeit expliziter Workshops zur Anforderungsermittlung im Rahmen eines professionellen Requirements Engineering zunehmend erkannt wird, tun sich nach wie vor viele Organisationen bei der effizienten Gestaltung solcher Workshops schwer. Was wir unabhängig der Branche in einer Vielzahl von Unternehmen immer wieder sehen, sind fünf gängige Fehler, die unnötige Ressourcen binden und für einen Mehrwertgewinn durch Requirements Engineering nicht unbedingt förderlich sind.

In diesem Artikel möchten wir diese Fehler und ihre problematischen Konsequenzen benennen und basierend hierauf Tipps für eine bessere Anforderungsanalyse mittels Workshops aufzeigen.

Fünf typische Fehler in Workshops zur Anforderungsermittlung

Im Folgenden finden sich fünf typische Fehler, die wir in zahlreichen Situationen in Anforderungsworkshops beobachten konnten.

Falsche oder zu viele Teilnehmer

Es ist unbestritten, dass jeder relevante Stakeholder in der Anforderungsanalyse einbezogen werden sollte, um zu verhindern, dass Anforderungen unvollständig, unnötig oder gar fehlerhaft sind oder die Akzeptanz bei den Betroffenen leidet. In der Praxis wird dieses Prinzip häufig jedoch misinterpretiert bzw. ins Extrem überführt. So werden häufig alle relevanten Stakeholder immer zu allen Anforderungsworkshops eingeladen, unabhängig davon, ob die einzelnen Personen in einem konkreten Workshop etwas (Sinnvolles) beitragen können oder nicht.

Die problematisch Konsequenz hiervon ist, dass die Workshopgruppe einerseits zu groß wird, um zielführend und strukturiert Anforderungen erarbeiten zu können (die ideale Fokusgruppe hat rund 6 Personen), und zum anderen, dass durch das Missverhältnis von aktiv beitragenden Personen und „stillen Beisitzern“ keine offenen und hilfreichen Diskussionen möglich werden. Beides führt letztendlich dazu, dass Kosten und Nutzen solcher Veranstaltungen in keinem akzeptablen Verhältnis stehen oder die passiveren Teilnehmer den Sinn und Zweck von Workshops zur Anforderungsermittlung grundsätzlich in Frage stellen.

Für diesen Fehler, der übrigens gemäß RE-Kompass 2013 in mehr als der Hälfte aller Unternehmen vorhanden ist, haben wir in den vergangenen Jahren verschiedene Gründe kennengelernt. Zum einen besteht häufig die Befürchtung, dass sich jemand übergangen fühlen könnte, wenn er oder sie nicht zu einem Workshop eingeladen wird. Aus politischen Gründen wird dann einfach jeder eingeladen, der irgendwie mit dem Projekt zu tun hat. Zum anderen ist oftmals nicht klar, über was man in einem Workshop genau reden möchte (siehe auch den nächsten Fehler) und deshalb bleibt offen, wen man tatsächlich benötigt und wen nicht. Ein weiterer Grund ist schließlich, dass Workshops zur Anforderungsermittlung häufig mit „Informationsveranstaltungen“ über den Projektfortschritt vermischt werden und somit auch Personen rein interessehalber dabei sind.

Interessanterweise stellen wir aber zugleich immer wieder fest, dass häufig nicht eine echte Obermenge der tatsächlich benötigten Stakeholder in Anforderungworkshops partizipiert. Vielmehr fehlen trotz der Vielzahl eingeladener Personen immer noch wichtige Stakeholder, weil man diese entweder vergessen hat oder explizit nicht wollte, dass diese „mit ihren Wunschlisten kommen“. Welche Probleme hierdurch entstehen können, wurde im einleitenden Satz bereits erörtert.

Fehlende Fokussierung

Der vielleicht größte Fehler, der in Anforderungsworkshops begangen wird, ist die fehlende Fokussierung eines jeden einzelnen Workshops auf ein klar umrissenes Teilthema. Oft erleben wir, dass sich in einer großen Gruppe (siehe vorheriger Fehler) mehrere Stunden bis Tage zusammengesetzt wird, um (generell) über die Anforderungen an das Projekt oder System zu reden. Entsprechend wird über alles mehr oder weniger gesprochen, was die Beteiligten persönlich beschäftigt, gerade im Gespräch aufkommt oder sich noch auf einer „offenen Punkte“-Liste aus einem vorherigen Workshop befindet.

Diese fehlende Fokussierung führt häufig dazu, dass vom „Hundertsten ins Tausendste“ gegangen wird und man sich schnell in langatmigen Detaildiskussionen verstrickt, noch bevor man grundsätzlichere Aspekte geschärft und gemeinschaftlich abgestimmt hat. Dies führt in der Regel dazu, dass man am Ende des Workshops auseinander geht ohne ein einzelnes Unterthema in der notwendigen Detailtiefe und Vollständigkeit besprochen zu haben. Entsprechend ineffizient und ineffektiv ist die gesamte Anforderungsanalyse und gering die Qualität und Vollständigkeit der resultierenden Anforderungen.

Die Gründe für eine solch fehlende Fokussierung von Anforderungsworkshops sind vielseitig. Einerseits werden organisatorische Gründe angeführt, wie „die Leute sind extra für den Workshop gekommen, jetzt müssen wir auch über alles reden“ (was selbst aber oft aus dem vorherigen Fehler resultiert), anderseits ist den Organisatoren der Workshops oft nicht klar, welche Unterthemen im Rahmen des Projektes überhaupt zu klären sind und wann ein geeigneter Zeitpunkt für welches Thema ist. Dies wäre allerdings unbedingt notwendig, um erfolgreiche Workshops mit den richtigen Personen zu einzelnen Aspekten vorab planen und zielgerichtet durchführen zu können.

Stattdessen erleben wir häufig, dass die dafür notwendige Auftragsklärung zu Beginn eines Projektes nicht erfolgt und bereits in einem ersten Workshop über Details diskutiert wird, die bei einer sukzessiven Anforderungsanalyse erst zu einem späteren Zeitpunkt relevant wären. Dies liegt einerseits im Irrglauben begründet, dass alle Beteiligte wissen, um was es geht (und man ja „hierauf keine unnötige Zeit verschwenden braucht“) oder andererseits darin, dass nur die wenigsten Personen den Mut aufbringen, die naive Frage zu stellen, ob es hinsichtlich des Projektumfangs bereits ein gemeinsames und abschließendes Bild gibt. Dieses fehlende Explizitmachen und Hinterfragen von impliziten Annahmen setzt eine Anforderungsanalyse von Beginn an falsch auf und erlaubt kaum ein systematisches und diszipliniertes Vorgehen, so wie es ein professionelles Requirements Engineering eigentlich erfordert.

Keine oder unzureichende Moderation

Eng verwandt mit der fehlenden Fokussierung einzelner Anforderungsworkshops ist auch eine fehlende, stringente Moderation. Ohne klare Fokussierung eines Workshops ist es natürlich nicht möglich, im Workshop auf das angestrebte Ziel (d.h. die Klärung der Anforderungen an ein gewisses Teilthema) systematisch hinzuarbeiten. Aber selbst wenn Fokus und Ziel eines Workshops definiert sind, braucht es einer disziplinierten Moderation um dieses Ziel auch zu erreichen.

Aus unserer Erfahrung heraus ist fehlende oder unzureichende Moderation von Anforderungsworkshops derzeit eines der größten Probleme in der gesamten Requirements Engineering Praxis. Häufig erleben wir, dass der Organisator eines Anforderungsworkshops zu Beginn zwar eine kurze Einführung gibt, aber dann die Gesprächsentwicklung der Gruppe überlässt und erst zum Schluss die (wenigen) Erkenntnisse und (vielen) neuen Fragen zusammenfasst.

Eine unmoderierte Diskussion führt einerseits zwangsläufig in eine Detailverzettelung und andererseits häufig in Zwiegespräche zwischen einzelnen, dominanten Charakteren während andere Teilnehmer zunehmend in eine passivere Rolle verfallen. Auch erleben wir oft, dass einzelne Experten innerhalb der Gruppe von den übrigen Teilnehmern regelrecht interviewt werden, die gewisse Dinge „schon immer mal wissen wollten“, auch wenn sie nicht unbedingt zielführend für das Workshopthema sind. Durch all diese Konsequenzen ist es quasi unmöglich, im gegebenen Zeitrahmen die gesetzten Ziele des Workshops zu erreichen.

Doch selbst wenn eine Person explizit die Rolle eines Moderators übernimmt, so ist ein Workshop nicht automatisch von Erfolg gekrönt. Hat beispielsweise der Moderator zu viel Fachwissen oder gar noch einen andere Rolle im Projekt, so fällt es ihm / ihr in der Regel schwer, die richtigen Fragen unbefangen zu stellen, die vermeintlichen „eh klaren“ Aspekte zu hinterfragen und sich selbst nicht aktiv in die Diskussion einzubringen. Leider erleben wir jedoch oft, dass ein Fachexperte oder gar der Projektleiter selbst die Rolle des Moderators in einem Workshop übernimmt und keine hilfreiche Rollentrennung vorgenommen wird.

Es besteht jedoch aber auch bei angemessener Besetzung der Moderatorenrolle die Gefahr, dass Diskussionen ineffektiv und ineffizient verlaufen, da einzelne Beteiligte aneinander vorbeireden, sich nicht öffnen oder aktiv einbringen, etc. Als Grund hierfür erleben wir oft, dass Workshops mit Sitzungscharakter durchgeführt werden, sprich, die Beteiligten die ganze Zeit nur am Tisch sitzen und sich ausschließlich verbal austauschen, anstatt in lockerer Atmosphäre mit Flipcharts, Metaplan und ähnlichen Werkzeugen Inhalte zu erarbeiten und diskussionsfördernd zu visualisieren. Gründe hierfür sind sowohl mangelnde Erfahrung mit solchen Techniken, als auch (unberechtigte) Befürchtungen, dass solche ungewohnten Arbeitsweisen negativ bei Kollegen ankommen könnten.

Keine Entscheidungsfindung

Requirements Engineerng ist zweifelsohne ein kritischer Entscheidungsprozess innerhalb eines Projektes. Es muss entschieden werden, was ein System leisten soll, welche Funktionalitäten und Qualitäten dazu benötigt werden, wie es mit seiner Umwelt interagieren soll, wer es verwenden soll, etc. Entsprechend geht es in Anforderungsworkshops nicht darum, nur Ideen und Wünsche auszutauschen, sondern bewusst auch Entscheidungen zu treffen, die die Gestaltung und den Umfang eines Systems betreffen.

Was wir in unserer langjährigen Beratungspraxis aber häufig erlebt haben, ist, dass sowohl Workshopteilnehmern als auch deren Vorgesetzten sowie den Projektverantwortlichen zuweilen nicht bewusst ist, dass Anforderungsanalyse genau auch diese Entscheidungskomponente umfasst. Beteiligte in Workshops wollen oder dürfen oftmals keine Entscheidungen treffen, sondern sehen sich mehr als Geber von Optionen, die dann „jemand anderes im Nachgang entscheiden muss“.

Entsprechend ist es wenig verwunderlich, dass Anforderungsphasen oftmals lange dauern, unnötige Überarbeitungszyklen und ergebnislose Workshops beinhalten und immer wieder zu Unvollständigkeiten und Unklarheiten in den Anforderungen führen, die letztendlich in den klassischen „ja, so habe ich mir das aber nicht vorgestellt“ Erlebnissen münden.

Unzureichende Nachdokumentation

Ein Anforderungsworkshop dient in der Regel der Anforderungsermittlung. Neben Anforderungsermittlung sind aber auch die Anforderungsdokumentation, die Anforderungsprüfung und das Anforderungsmanagement gleichberechtigte Aktivitäten innerhalb des Requirements Engineering. Ziel eines Anforderungsworkshops ist somit Anforderungen herauszuarbeiten, die im Nachgang dokumentiert, validiert und verwaltet werden, um einen Fortschritt und Mehrwert im Projekt zu generieren.

Gut dokumentierte und abgestimmte Anforderungen bieten jedoch nicht nur die Basis für die eigentliche Systementwicklung, sondern auch für die weitere (sukzessive) Anforderungsanalyse. Dennoch erleben wir häufig, dass die Ergebnisse von Anforderungsworkshops nicht richtig nachdokumentiert und in die Anforderungsdokumente oder -datenbanken übernommen werden, sondern lange Zeit den unverbindlichen Status eines Workshopprotokolls nicht überschreiten. Die Gründe hierfür sind einerseits darin zu sehen, dass aus einzelnen Workshops häufig zu wenig herausgekommen ist (siehe die ersten drei Fehler) und letztendlich im Anschluss mehr Fragen als Antworten bestehen, zum anderen aber auch darin, dass keine Entscheidungen getroffen wurden (siehe vorherigen Fehler), die eine saubere Ableitung und Ausformulierung zugehöriger Anforderungen motivieren. Daneben finden sich aber auch organisatorische Gründe, wie unklare Verantwortlichkeiten, unsaubere oder unvollständige Mitschriften oder Unkenntnis über die angemessene Dokumentation von Anforderungen.

Die Probleme, die aus diesem Fehler entstehen, sind zum einen, dass trotz (guter) Anforderungsermittlung letztendlich die Anforderungsdokumente unvollständig und uneindeutig bleiben, und das Terminalziel des Requirements Engineering, sprich, die Entwicklung auf eine verlässlichere Grundlage zu stellen, nicht erreicht werden kann. Andererseits verhindert eine fehlende saubere Nachdokumentation aber auch kommende Anforderungsworkshops angemessen vorzubereiten und durchzuführen. Zu oft haben wir erlebt, dass man immer und immer wieder über die gleichen Aspekte diskutiert, da sich niemand mehr zuverlässig daran erinnern kann, was schon alles besprochen und ggf. beschlossen wurde. Auch durch diesen Fehler kann trotz guter Absichten vieles unnötig ineffektiv und ineffizient werden.

Zehn Tipps für eine erfolgreichere und effizientere Anforderungsanalyse

Basierend auf den fünf typischen Fehlern in Workshops zur Anforderungsermittlung, lassen sich folgende Tipps und Best Practices für eine effizientere und vor allem erfolgreichere Anforderungsanalyse mittels Workshops ableiten.

1) Einen klaren Fokus setzen

Zerlegen Sie Ihr Projekt in Teilthemen und beschäftigen Sie sich in einem Workshop immer nur mit einem solchen Teilthema. Sie können dadurch viel einfacher die richtigen Stakeholder hinzuziehen, bessere Diskussionen entfachen, zielgerichteter Vorgehen und letztendlich in kürzerer Zeit viel mehr rausholen. Vier Workshops von jeweils zwei Stunden sind häufig ergebnisreicher als ein Workshop von acht Stunden.

2) (Nur) die richtigen Leute einladen

Es müssen nicht immer alle mitreden! Wenn es zum Beispiel um technische Schnittstellen zu Drittsystemen gibt, braucht man in der Regel niemanden vom Fachbereich und wenn es um geänderte Geschäftsprozesse geht, vielleicht niemanden vom Helpdesk. Identifizieren und involvieren Sie für jeden Workshop gesondert die Personen, die sich bzgl. des Teilthemas auskennen und hier entweder Probleme, Anforderungen oder gar Lösungsideen beitragen können. Drei Workshops mit fünf Leuten sind zielführender als ein Workshop mit 15 Personen.

3) Entscheidungsbefugnisse erteilen

Die Personen, die in Ihren Anforderungsworkshops teilnehmen, sollen Entscheidungen treffen wollen und dürfen. Stellen Sie sicher, dass diese Personen offizielle Repräsentanten der Stakeholdergruppe (z.B. Abteilung) darstellen und von ihren Vorgesetzten entsprechende Entscheidungsbefugnis erhalten haben. Scheuen Sie sich nicht, einen Abteilungsleiter selbst zum Workshop zu bitten, wenn er / sie seinen Angestellten entsprechende Befugnis nicht erteilen möchte.

4) Einen fähigen und unbefangenen Moderator einsetzen

Moderation ist das A und O eines erfolgreichen Workshops. Stellen Sie unbedingt sicher, dass Sie einen wirklich fähigen (erfahrenen) und unbefangenen Moderator(in) für Ihren Workshop haben. Es ist wichtiger, dass diese Person über Moderationsgeschick verfügt und auch Mut für „dumme“ Fragen hat, als dass sich diese Person in der Projektthematik auskennt. Folglich muss diese Rolle auch nicht aus dem Projektteam besetzt werden, sondern kann von einem / einer Kollegen/ in aus einer anderen Abteilung oder gar einem externen Consultant übernommen werden.

5) Vorbereitung, Vorbereitung, Vorbereitung

Gute Vorbereitung ist essentiell für einen Workshop. Dazu gehören die zuvor genannten Punkte wie Zielsetzung, Stakeholderidentifikation und Moderatorensuche, aber auch die eigentliche Vorbereitung des Workshops hinsichtlich Agenda, Leitfragen, Techniken für die Beantwortung der Leitfragen (z.B. Kartenabfrage), Bereitstellung von Moderationsmaterial, Catering, Raumbuchung, etc. Je mehr Sie vorab geplant und geklärt haben, je mehr Zeit und Raum haben Sie für den eigentlichen Workshop!

6) Visuell und haptisch arbeiten

In Workshop steckt das Wort „Arbeit“ (engl. Work). Es geht also nicht nur darum, zusammenzusitzen und zu reden, sondern auch etwas zu erarbeiten. Lassen Sie die Teilnehmer daher anhand Ihrer Leitfragen aktiv Ergebnisse produzieren, beispielsweise Stärken und Schwächen gegenwärtiger Arbeitsabläufe auf Karten sammeln, Ablaufdiagramme und Bildschirmmasken-Entwürfe am Flipchart zeichnen, etc. Dadurch fördern Sie nicht nur die aktive Diskussion zwischen den Beteiligten, sondern veranschaulichen Aspekte, die man sich im gesprochenen Wort ggf. falsch oder gar nicht vorstellen kann.

7) Entscheidungen treffen

Beenden Sie keinen Workshop ohne nicht mit den Beteiligten Beschlüsse gefasst zu haben. Entscheiden Sie bewusst und möglichst gemeinschaftlich welche der Ideen und Vorschläge, die im Rahmen des Workshops vorgebracht wurden, als „echte“ Anforderung ins Anforderungsdokument aufgenommen werden sollen. Lassen Sie den Moderator Priorisierungs- und Verhandlungstechniken einsetzen, wenn die Festlegung nicht so einfach durchzuführen ist. Fordern Sie von allen Beteiligten den Mut zu Entscheidungen!

8) Ergebnisse dokumentieren

Die Entscheidungen, die im Rahmen des Workshops getroffen wurden, sollten in Anforderungen überführt und entsprechend im Anforderungsdokument oder der Anforderungsdatenbank angemessen dokumentiert werden. Klärungspunkte und sonstige Anmerkungen, zu denen noch keine Entscheidungen getroffen werden konnten, dokumentieren Sie in einem entsprechenden Protokoll und nutzen Sie dieses explizit zur Planung weiterer Schritte in der Anforderungsanalyse.

9) Freigabe einholen

Bevor Sie die Ergebnisse des Workshops an eine größere Gruppe kommunizieren, sollten Sie Ihre Nachdokumentation zunächst an die Workshopteilnehmer mit Bitte um Review und Freigabe senden. So stellen Sie sicher, dass nichts falsch weitergeben wurde und sich die Workshopbeteiligten auch entsprechend gewürdigt und geschätzt fühlen. Beides ist enorm hilfreich um die weitere Anforderungsanalyse auf ein stabiles Fundament zu stellen.

10) Schrittweise weiter gehen

Durch einen erfolgreichen Workshop ergeben sich stets neue Teilthemen, die einer erneuten Analyse bedürfen. Planen Sie daher die nächsten Workshops einerseits abhängig von den generellen Teilthemen Ihres Projektes, aber andererseits auch von den neuen Aspekten, die sich durch die Entscheidungsfindung im Rahmen der Workshops ergeben. Wenn Sie beispielsweise erst in einem recht späten Workshop feststellen, dass eine neue Schnittstelle benötigt wird, scheuen Sie sich nicht für diese Schnittstelle einen eigenen Workshop anzusetzen.

Fazit

In unserer langjährigen Praxis konnten wir typische Fehler identifizieren, die immer wieder bei der Durchführung von Anforderungsworkshops auftreten. Mittels einfacher Tipps können viele der daraus resultierenden Probleme effektiv umgangen werden. Wenn Sie diese Ratschläge für Ihren nächsten Anforderungsworkshop beachten und umsetzen, steht einer effektiven und effizienten Anforderungsermittlung nichts mehr im Wege!

Autoren

Dr. Sebastian Adam ist Geschäftsführer der OSSENO Software GmbH und verantwortet hier die Bereiche Produktinnovation sowie Marketing und Vertrieb. Er ist IREB-zertifizierter Requirements Engineer und agiert selbst als Trainer für CPRE. Nach seinem Studium der Angewandten Informatik arbeitete er zehn Jahre als Berater, Wissenschaftler und Teamleiter für Requirements Engineering am Fraunhofer IESE und promovierte parallel dazu an der TU Kaiserslautern zum Thema „Wieder-verwendungsorientierte Anforderungserhebung“.
Dr. Norman Riegel ist Geschäftsführer der OSSENO Software GmbH und verantwortet primär die Bereiche Beratung, Qualitätssicherung und Administration. Er ist IREB-zertifizierter Requirements Engineer und agiert selbst als Trainer für CPRE. Vor der Gründung der OSSENO Software GmbH arbeitete er bereits als Berater, Trainer und Wissenschaftler für Requirements Engineering am Fraunhofer IESE. Parallel zu seiner Arbeit promovierte er an der TU Kaiserslautern zum Thema „Effi-ziente Anforderungserhebung auf Basis von Geschäftsprozessen“.

Komplexität im Requirements Engineering

Komplexität durch zweidimensionale Kompliziertheit

Komplexität durch zweidimensionale Kompliziertheit

Auf der REConf 2016 haben wir in unserem Vortrag die Frage beleuchtet, was es mit Komplexität im Requirements Engineering auf sich hat und wie man dieser begegnen kann.

Nach unserer Auffassung entsteht Komplexität im Requirements Engineering nicht allein durch die Menge der Anforderungen, die Kritikalität des Systems oder die Anzahl an Stakeholdern, sondern dadurch dass sowohl das zu entwickelnde System als auch die dazu verwendete (RE-)Methode von den Beteiligten als herausfordernd empfunden wird. Hat ein RE-Experte beispielsweise „nur“ mit einer großen Anzahl von Anforderungen zu tun, aber weiß, wie man diese systematisch erschließen kann, so ist für diese Person das Requirements Engineering zwar durchaus fordernd (insbesondere was die Verwaltung und Pflege der riesigen Anforderungsmenge betrifft), aber nicht unmittelbar komplex, da er / sie die notwendigen Methoden und Werkzeuge besitzt. Anders herum kann aber für weniger RE-versierte Personen bereits das Erheben und Dokumentieren von Anforderungen an ein recht überschaubares System als herausfordernd empfunden werden, wenn ihnen die dafür notwendigen Skills und Erfahrungen fehlen.

Die wirklich erfolgskritische Komplexität im Requirements Engineering entsteht erst dann, wenn beide Aspekte zusammenkommen: Nicht-Experten (und damit sind keine Laien oder Anfänger gemeint, sondern gemäß der Definition von Doug Norman Menschen, die nicht mindestens 5.000 Stunden praktische Erfahrung haben) sollen Requirements Engineering für große Systeme durchführen. Obwohl dies auf den ersten Blick grob fahrlässig und gar unrealistisch klingen mag, so belegen Studien wie zuletzt der RE Kompass 2014/2015, dass dies eher die Regel als die Ausnahme darstellt. Häufig führen Personen Requirements Engineering Aufgaben in Projekten durch, obwohl sie dies nie richtig gelernt haben, nur wenige Prozent ihrer Arbeitszeit darauf verwenden und auch von ihren Kollegen als  nur „mittelmäßig gut“ hierin eingeschätzt werden.

Typische Herausforderungen die einem Projektteam dadurch erwachsen gehen von einfachen Fragestellungen wie beispielsweise nach dem verständlichen und homogenen Dokumentieren über eine schrittweise Verfeinung und sinnvolle Strukturierung bis hin zu Wiederverwendung, Vollständigkeitsprüfung oder dem Finden der richtigen Detailebene. Vielbeworbene Zertifizierungslehrgänge liefern hierfür zwar erste Antworten, aber gute und vollständige Anforderungen lassen sich i.d.R. nur kontextspezifisch auf Basis von langjähriger Erfahrung verlässlich und effizient gewinnen. Der Spruch „A Fool with a Tool is still a Fool“ mag daher in diesem Zusammenhang zunächst passend erscheinen, berücksichtigt man die Möglichkeiten und Funktionalität etablierter Requirements Management Werkzeuge am Markt.

Allerdings zeigen Werkzeuge aus anderen Branchen und Anwendungsfeldern längst, dass der Spruch „A Fool with a Tool is still a Fool“ – der im Übrigen aus den frühen 1980er stammt, als erste PCs Einzug in Büros hielten – nur noch bedingt Gültigkeit besitzt. Gute Gegenbeispiele sind Programme für die Erstellung von Steuererklärungen oder Navigationssysteme im Auto. Solche Werkzeuge erlauben auch ohne Expertenwissen (z.B. zu Steuerrecht, ELSTER-Formularen, etc.) oder einer umfassenden Kenntnis über mögliche Wege, ein Ziel oder Ergebnis zumindest „gut genug“ zu erreichen. Insofern sehen wir einen Markt für neuartige und intelligente Werkzeuge auch im Requirements Engineering und Management, da der vereinfachte Ansatz „wir schulen erst mal unsere Mitarbeiter und schaffen dann ein RM Tool an“ viel zu kurz greift (denken Sie an die 5.000 Stunden Erfahrung), um komplexen Anforderungssituationen gemäß oben genannter Definition wirklich effizient zu begegnen.

Entsprechend hat uns gefreut, dass neben uns auch andere (kleinere) Hersteller von RE/RM-Werkzeugen die Notwendigkeit zunehmender Automatisierung und Assistenz erkannt haben. Während diese Anbieter jedoch oft isolierte Probleme wie die Transformation oder Qualitätssicherung von Anforderungen beleuchten, hilft unsere ReqSuite® den gesamten Prozess der systematischen Herausarbeitung von Anforderungen zu erleichtern. Hierfür konnten wir in unserem Vortrag anhand zahlreicher typischer Fragestellung überzeugende Beispiele liefern.

Der gesamte Vortrag findet sich hier.

Eine Methode für flexible, maßgeschneiderte Anforderungsprozesse

Abstract

Aktuelle Studien zeigen, dass sich viele Unternehmen nach wie vor mit der Durchführung effizienter und effektiver Aktivitäten im Bereich Requirements Engineering schwertun. Unternehmensspezifische, maßgeschneiderte Anforderungsprozesse haben ein großes Potential, dieser Herausforderung zu begegnen. Dieser Beitrag beschreibt einen neuartigen Ansatz, mit dessen Hilfe unternehmensspezifische Anforderungsprozesse semi-automatisch definiert und werkzeuggestützt durchgeführt werden können, um damit eine nachhaltigere und vor allem wertbringendere Durchführung dieser Disziplin zu erzielen.

Einleitung

Der RE Kompass 2014 / 2015 [1] hat aufgezeigt, dass sich eine Vielzahl von Unternehmen nach wie vor grundsätzlichen Fragestellungen im Bereich Requirements Engineering ausgesetzt sehen, wie z.B.:

  • Welcher Detailgrad von Anforderungen ist angemessen/notwendig? (69% der befragten Unternehmen)
  • Welche Anforderungstypen müssen erhoben werden? (37% der befragten Unternehmen)
  • Wie können die Anforderungen sinnvoll erhoben und dokumentiert werden? (35% der befragten Unternehmen)

Diese Unklarheiten führen in knapp der Hälfte der Unternehmen zu mehrdeutigen und unvollständigen Spezifikationen, mit entsprechend negativen Konsequenzen innerhalb der Projekte [1].

Obwohl existierende Literatur- und Schulungsangebote [2] [3] [4] mit guten Best Practices zur Erhebung und Dokumentation von Anforderungen aufwarten, lassen sich die oben genannten Fragestellungen oft nur kontext- bzw. unternehmensspezifisch beantworten. Es ergibt sich somit ein hohes Potential für maßgeschneiderte Anforderungsprozesse, um eine effektive und effiziente Arbeitsweise während der Anforderungserhebung und -dokumentation im jeweiligen Unternehmensumfeld zu gewährleisten.

Bei der Einführung und erfolgreichen Durchführung solch individueller Prozesse stoßen Unternehmen allerdings auf zahlreiche weitere Herausforderungen, wie etwa bei der

  • Festlegung einer sinnvollen Erhebungsreihenfolge für Anforderungen,
  • einfachen Durchführbarkeit der Erhebungs- und Dokumentationsaufgaben durch die Projektbeteiligten (insbesondere auch für Beteiligte ohne tiefgehende Expertise und Erfahrung im Requirements Engineering),
  • Entlastung von rein administrativen, nicht-wertbringenden Tätigkeiten des Requirements Engineerings, wie z.B. der Verknüpfung von Anforderungen,
  • Abbildung definierter Vorgehensweisen in Werkzeugen für das Requirements Engineering, ohne dabei Flexibilität einzubüßen.

Insbesondere beim letzten Punkt kommt hinzu, dass für die Anforderungsdokumentation in rund 80% aller Unternehmen (nach wie vor) Standardbüroanwendungen wie MS Office® eingesetzt werden [1]. Einerseits sind diese Produkte beliebt, da sie bekannt und weit verbreitet sind und eine einfache, gewohnte Verwendung bieten. Andererseits stößt man gerade durch die Nutzung solcher Standardsoftware oft an die Grenzen, wenn Arbeitsschritte während der Anforderungserhebung und -dokumentation effizienter gestaltet werden sollen. Sollen diese Produkte nicht gänzlich abgelöst werden, muss auch dies bei der Maßschneiderung von Anforderungsprozessen berücksichtigt werden.

In diesem Artikel wird ein werkzeuggestützter Ansatz vorgestellt, der die Einführung und Durchführung maßgeschneiderter Anforderungsprozesse in Unternehmen optimiert. Ziel dieses Ansatzes ist es, zum einen unternehmensspezifische Anforderungsprozesse effektiv und effizient durchführen zu können, aber auch die zuvor genannten, sich daraus ergebenden speziellen Herausforderungen während der Einführung gezielt zu adressieren. Dazu wird das innovative Werkzeug „ReqSuite®“ eingesetzt, mit Hilfe dessen individuelle Anforderungsprozesse konzeptionell abgebildet und mit Hilfe gängiger Office-Software bearbeitet werden können.

Eine werkzeuggestützte Methodik zur Einführung und Durchführung flexibler, maßgeschneiderter Anforderungsprozesse

Die Methode zur werkzeuggestützten Einführung maßgeschneiderter Anforderungsprozesse besteht aus insgesamt vier Schritten (siehe Abbildung 1), die im Folgenden detaillierter erläutert werden. Dabei gilt zu berücksichtigen, dass die ersten drei Schritte einmalige Schritte zum Aufsetzen eines Anforderungsprozesses darstellen und somit in der Regel nur einmal durchlaufen werden müssen. Schritt 4 wird hingegen mehrmals, d.h. einmal pro Projekt durchgeführt.

Abbildung 1. Schritte der Methode zur werkzeuggestützten Einführung maßgeschneiderter Anforderungsprozesse

Abbildung 1. Schritte der Methode zur werkzeuggestützten Einführung maßgeschneiderter Anforderungsprozesse

Schritt 1 – Informations- und Dokumentationsbedarf ermitteln: In einem Workshop werden zunächst mit den RE-Beteiligten des Unternehmens die individuellen Informationsbedarfe in typischen RE-Projekten ermittelt. Dies könnten beispielsweise bestimmte Anforderungstypen, domänenspezifische Anforderungsstrukturen sowie weitere Informationen sein, die in den Anforderungsdokumenten enthalten sein sollen. Dazu wird zunächst der aktuelle RE-Prozess analysiert. Dies kann im Workshop beispielsweise mittels Kartenabfrage realisiert werden, in dem alle Beteiligten ihre Aktivitäten sowie benötigte und gelieferte Informationen während der Erstellung der Anforderungsspezifikation darstellen. So können auch Schnittstellen zu nachgelagerten Prozessen, wie beispielsweise dem Änderungs- und Testmanagement, identifiziert und analysiert werden. Daneben werden bereits existierende Anforderungsdokumente betrachtet, um weitere Informationsbedarfe zu erkennen. Dabei werden neben Inhalten auch Beschreibungsvorlagen und Notationen betrachtet, die sich in der Unternehmenspraxis etabliert haben oder die sinnvollerweise im Unternehmen zukünftig genutzt werden könnten. Zur Optimierung des gesamten Anforderungsprozesses fließen neben etwaigen eigenen Verbesserungsvorschlägen der Unternehmensbeteiligten auch Expertenwissen sowie etablierte Best Practices aus der Literatur ein.

Schritt 2 – Anforderungsstruktur ableiten: Im nächsten Schritt werden die Analyseergebnisse mit Hilfe einer domänenspezifischen Sprache dokumentiert. Hierbei wird im ersten Schritt die Struktur der Anforderungstypen und begleitenden Informationen abgebildet. Beispielsweise kann hier definiert werden, dass Systemfunktionen immer in Anwendungsfällen Verwendung finden, welche wiederum Geschäftsprozessaktivitäten in Geschäftsprozessen unterstützen (siehe Abbildung 2).

Abbildung 2. Beispielhafte Abbildung einer einfachen Anforderungsstruktur

Abbildung 2. Beispielhafte Abbildung einer einfachen Anforderungsstruktur

Die Abbildung dieser Struktur ist nicht nur wichtig und sinnvoll, um die Verfolgbarkeit der Anforderungen zu gewährleisten, sondern ist auch maßgebliche Grundlage für die spätere Prozessunterstützung (siehe Schritt 4). Dieses Modell bildet somit das logische „Denkmodell“, das hinter dem Anforderungsprozess steht und das im Rahmen eines konkreten Projektes mit Inhalt zu befüllen ist.

Auf Basis der Ergebnisse aus Schritt 1 wird dann für jeden Anforderungstyp bzw. Informationsbaustein definiert, wie die Dokumentation der zugehörigen Anforderungen bzw. Informationen im Rahmen eines Projektes zu erfolgen hat. Dabei wird unter anderem festgelegt, ob die Beschreibung textuell (bspw. mittels bestimmter natürlichsprachiger Satzschablonen) oder grafisch (bspw. mittels UML- Modellen) erfolgen soll und welche Attribute (bspw. Priorität) für die verschiedenen Anforderungs- bzw. sonstigen Inhaltstypen zu pflegen sind. Im Beispiel aus Abbildung 2 könnte z. B. für den Anforderungstyp „Geschäftsprozess“ definiert werden, dass jeder in der Anforderungsspezfikation zu beschreibende Prozess mittels einer grafischen Prozessbeschreibung, wie bspw. BPMN, und zusätzlich mittels einer tabellarischer Kurzbeschreibung anhand diverser Attribute spezifiziert werden soll.

Die so formalisierte Beschreibung wird in das Werkzeug ReqSuite® importiert und dort automatisch in einen adaptiven Anforderungsworkflow transformiert. Daneben wird eine unternehmensspezifische Vorlage des Anforderungsdokumentes im Werkzeug hinterlegt, in das die eigentlichen Anforderungen und Inhalte später auf Knopfdruck exportiert werden können. Hierin kann der Nutzer beispielsweise festlegen, welche Inhalte aus der Datenbasis in welcher Form im Dokument erscheinen sollen. Aufgrund dieser strikten Trennung von Inhalt und Repräsentation können Anforderungen somit bedarfsweise anders erfasst und dokumentiert werden, als sie letztendlich im Anforderungsdokument repräsentiert werden sollen. Entsprechend können auch mehrere Vorlagen hinterlegt werden, wenn z.B. später aus den Daten unterschiedliche Dokumente erstellt werden sollen (z.B. ein Lastenheft und eine Testspezifikation).

Schritt 3 – Existierende Anforderungen importieren: In zahlreichen Unternehmen werden Systeme nicht von Grund auf neu entwickelt, sondern kontinuierlich ergänzt und um neue Funktionen erweitert. Dies schlägt sich auch auf den entsprechenden Anforderungsprozess wieder, da oft Anforderungen aus alten Projekten wiederverwendet werden können oder sogar müssen. Aus diesem Pool von bestehenden Anforderungen sollte zwecks Effizienzsteigerung in zukünftigen Projekten eine explizite Wiederverwendungsbasis aufgebaut werden, um die Risiken eines clone-&-own-Ansatzes zu vermeiden. Dazu werden relevante Anforderungen aus Altprojekten identifiziert, indem z. B. alte Anforderungsdokumente gesichtet werden. Hierbei sollten die Anforderungen auf Aktualität überprüft werden, um keine veralteten Anforderungen zu übernehmen. Da der Aufbau einer Wiederverwendungsbasis sehr aufwändig ist, kann ReqSuite® in diesem Schritt eingesetzt werden, um Anforderungen in geeigneter Form aus Word- oder Excel-Dokumenten automatisiert in eine zentrale Wiederverwendungsbibliothek zu importieren.

Schritt 4 – Requirements Engineering Prozess durchführen: Die eigentliche Durchführung des Anforderungsprozesses basiert auf dynamisch zur Laufzeit festgelegten Arbeitsschritten, die den Nutzern durch das Werkzeug ReqSuite® bereitgestellt werden. Im Gegensatz zu herkömmlichen Requirements Management Werkzeugen [5] unterstützt ReqSuite®, das sich clientseitig in Microsoft Office® Produkte integriert (siehe Abbildung 3), somit nicht nur die Spezifikation und Verwaltung von Anforderungen, sondern insbesondere auch den gesamten Prozess der inhaltlichen Herausarbeitung von Anforderungen.

Abbildung 3. ReqSuite® Client in Microsoft Word

Abbildung 3. ReqSuite® Client in Microsoft Word

Die auf Expertenwissen basierenden Algorithmen von ReqSuite® sind dabei in der Lage, eine sinnvolle Reihenfolge für die Herausarbeitung der relevanten Anforderungen vorzuschlagen. Dazu generiert das Werkzeug zur Laufzeit im sogenannte Process Guide (siehe unterer Teil in Abbildung 3) für jeden Prozessschritt einen Satz präziser Arbeitsanweisungen, um die Projektbeteiligten schrittweise durch die einzelnen Erhebungs- und Dokumentationsaufgaben zu führen. Vergleichbar mit Programmen zur Erstellung von Steuererklärungen stellt das Werkzeug dabei durch die kontinuierliche Abfrage und Qualitätsprüfung gewünschter Informationen sicher, dass die resultierenden Anforderungen in sich vollständige Inhalte in der gewünschten Form beinhalten.

Dabei ist der Prozess nicht statisch, sondern das Werkzeug agiert während der gesamten Anwendung stets adaptiv, was bedeutet, dass eine Reihenfolge von Arbeitsschritten weder vorab definiert noch genau befolgt werden muss. Stattdessen passen sich die Arbeitsschritte auf Basis der bereits erhobenen Anforderungen zur Laufzeit an. Dies trägt dem Sachverhalt Rechnung, dass sich aufgrund des schnelllebigen Charakters von Projekten Anforderungsprozesse einerseits ohnehin nicht in Form starrer Abläufe formalisieren lassen, andererseits selten dem gewünschten Vorgehen der Projektbeteiligten bei der Anforderungsanalyse entsprechen.

Die Bearbeiter können daher jederzeit die empfohlenen Schritte ignorieren und eigenständig andere Bearbeitungen durchführen. Dazu stellt ReqSuite® den sogenannten Content Manager (siehe rechter Teil in Abbildung 3) bereit, in dem die Anforderungen, sowie weitere Informationsinhalte und deren Beziehungen angelegt und gepflegt werden können. Das Werkzeug schlägt jedoch immer – anhand der bekannten Optionen zum weiteren Vorgehen und unter Berücksichtigung etwaiger Einschränkungen – den sinnvollsten nächsten Arbeitsschritt vor.

Diese Prozessunterstützung hilft insbesondere auch Projektbeteiligten ohne einschlägige Expertise im Requirements Engineering, an der Erstellung von Anforderungsdokumenten zielführend mitzuwirken. Eine Projektfortschrittsanzeige zeigt dabei stets den aktuellen Stand der Anforderungserhebung an.

Die Eingabe der Details für Anforderungen erfolgt direkt in Microsoft Office® bzw. über Popups, die von ReqSuite® bereitgestellt werden und die auf der zuvor hinterlegten Konfiguration für den jeweiligen Anforderungstyp basieren. In jedem Schritt lassen sich zudem die einzelnen Anforderungen sowie gesamte Anforderungsstrukturen aus anderen Projekten bzw. aus der Wiederverwendungsbasis importieren, um somit die Nutzung bereits existierender Dokumentation erheblich zu beschleunigen.

Erfahrungen aus der Praxis

Gerade für Unternehmen, die sich in ihrem Projektgeschäft oft in Spezialthemen oder abseits von RE-Standards bewegen, ist ein hohes Maß an Individualität in ihren Anforderungsprozessen erfolgsentscheidend, um sowohl Akzeptanz für Requirements Engineering bei den eigenen Mitarbeitern als auch beim Kunden zu erzielen.

So konnte durch die hohe Anpassbarkeit des hier beschriebenen Ansatzes gepaart mit seiner systematischen Anleitung bei Pilotkunden aus unterschiedlichen Branchen bereits eine effizientere Projektarbeit ermöglicht werden.

Dies war insbesondere dem Fakt geschuldet, dass mit Hilfe des individuell konfigurierten Werkzeugs Anforderungen vollständiger und konsistenter erhoben und dokumentiert werden konnten und somit weniger Rückfragen aufgrund unvollständiger oder unklarer Anforderungen notwendig waren. Insbesondere Mitarbeitern, die bis dato noch wenig praktische Erfahrung im Requirements Engineering hatten, konnte der Ansatz helfen, die eigenen Aufgaben durch eine Fokussierung auf wesentliche, inhaltliche Aspekte zu verbessern. Da bei der Erhebung und Dokumentation von Anforderungen oft sehr unterschiedliche Vorgehensweisen in der Praxis gewählt werden müssen – abhängig von den Rahmenbedingungen und je nach Verfügbarkeit der Stakeholder – stellt dies eine erhebliche Unterstützung für Unternehmen dar.

Bei der HK Business Solutions konnte beispielsweise gezeigt werden, dass durch die adaptive Prozessanleitung selbst unerfahrenere Mitarbeiter systematisch bei einer strukturierten Vorgehensweise mit Top-down-Ansatz unterstützt werden können. Dies beginnt bei Aktivitäten, die sehr früh im Entwicklungsprozess anzusiedeln sind, z. B. bei der Erstellung von Produktvisionen und dem Festlegen von Systemkontext und -umfang und endet schließlich bei der Konsistenz- und Vollständigkeitsprüfung sämtlicher erstellten Anforderungsartefakte. Viele Fehler, die typischerweise durch unvollständige, missverständliche oder fehlerhafte Anforderungen entstehen, können durch diese Unterstützung und durch die systematische Wiederverwendung bereits erfasster und qualitätsgesicherter Anforderungen vermieden werden.

Messbare Mehrwerte des Ansatzes sind somit eine höhere Vollständigkeit, Qualität und Einheitlichkeit von Anforderungsdokumenten und eine damit einhergehende Aufwandsersparnis im Gesamtprojekt bzw. bei den Wartungs- und Supportkosten. Dies ist insofern ein bedeutender Mehrwert, als dass laut RE-Kompass [1] Unvollständigkeit und uneinheitliche Detailtiefe von Anforderungen in 48% bzw. sogar 69% aller Unternehmen die größten Mängel von Anforderungsdokumenten gegenwärtig darstellen.

Auch wenn der Aufwand für den Anforderungsprozess selbst aufgrund der strukturierten Herangehensweise kaum verkürzt werden kann, bestätigen jedoch alle Anwender, dass ihre Aufgaben in der Anforderungsanalyse deutlich vereinfacht und beschleunigt werden konnten. Die Einführung des neuen RE-Ansatzes wird dadurch erleichtert, dass der Ansatz auf vertrauter Standardbürosoftware basiert; dies sorgte für einfaches Ausrollen und ermöglichte ein schnelles Zurechtfinden der Anwender. Auch hilft die sukzessive Führung durch verschiedene Schritte des Prozesses das unternehmensindividuelle Vorgehen im Requirements Engineering besser zu verinnerlichen.

Fazit

Maßgeschneiderte Anforderungsprozesse sind unabdingbar, um das Thema Requirements Engineering erfolgreich in Unternehmen zu verankern. Die Festlegung und Durchführung solcher Unternehmensprozesse stellt jedoch für viele Unternehmen eine zusätzliche Herausforderung dar. Dieser Artikel schlägt daher einen neuartigen, werkzeuggestützten Ansatz vor, um die Maßschneiderung und spätere Anwendung von individuellen Anforderungsprozessen bestmöglich zu unterstützen.

Literatur

  1. Adam, S., Wünch, C., Seyff, N.: RE-Kompass 2014/2015 – Ergebnisbericht, http://www.re-kompass.de
  2. Pohl, K., Rupp, C.: Basiswissen Requirements Engineering, dpunkt (2011)
  3. Rupp, C.: Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil, Carl Hanser (2014)
  4. Wiegers, K., Beatty, J.: Software Requirements, Pearson Education (2013)
  5. Birk, A., Heller, G.: List of Requirements Management Tools, http://makingofsoftware.com/ re-sources/list-of-rm-tools

Autoren

Dr. Norman Riegel ist Geschäftsführer der OSSENO Software GmbH und verantwortet primär die Bereiche Beratung, Qualitätssicherung und Administration. Er ist IREB-zertifizierter Requirements Engineer und agiert selbst als Trainer für CPRE. Vor der Gründung der OSSENO Software GmbH arbeitete er bereits als Berater, Trainer und Wissenschaftler für Requirements Engineering am Fraunhofer IESE. Parallel zu seiner Arbeit promovierte er an der TU Kaiserslautern zum Thema „Effiziente Anforderungserhebung auf Basis von Geschäftsprozessen“.

Dr. Sebastian Adam ist Geschäftsführer der OSSENO Software GmbH und verantwortet hier die Bereiche Produktinnovation sowie Marketing und Vertrieb. Er ist IREB-zertifizierter Requirements Engineer und agiert selbst als Trainer für CPRE. Nach seinem Studium der Angewandten Informatik arbeitete er zehn Jahre als Berater, Wissenschaftler und Teamleiter für Requirements Engineering am Fraunhofer IESE und promovierte parallel dazu an der TU Kaiserslautern zum Thema „Wiederverwendungsorientierte Anforderungserhebung“.

Hartmut Schmitt ist Koordinator Forschungsprojekte bei der HK Business Solutions GmbH. Er ist seit 2006 in Verbundvorhaben auf den Gebieten Mensch-Computer-Interaktion, Usability, User Experience und Requirements Engineering tätig.