Category: Requirements Engineering Blog

Requirements Engineering Blog

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.

Requirements Engineering Blog

„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)
Requirements Engineering Blog

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.

 

Requirements Engineering Blog

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.

Hier weiterlesen…

 

Requirements Engineering Blog

Komplexität im Requirements Engineering

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.

Komplexität durch zweidimensionale KompliziertheitDie 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.

Requirements Engineering Blog

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.