World Café Inspirationen – Lücken und Brücken im Requirements Engineering

“Wo sind die Lücken und Brücken im Requirements Engineering?”. Das war die Frage auf dem World Café der REConf® 2015 – mit inspirierenden Ergebnissen. Viele Themen dazu wurden von den Teilnehmern, über den Vormittag verteilt, an eine Pinnwand gehängt und am Abend auf dem World Café diskutiert. Hier eine Zusammenfassung der Ergebnisse:

In meinem letzten Blog hatte ich kurz berichtet, welche zentralen Vorteile Requirements Engineering (RE) bringen kann. Die REConf®– 2015 im März in München war voll von informativen Vorträgen über die “Lücken und Brücken” im RE. Auch die Teilnehmer selbst brachten viele Themen mit und diskutierten sie auch im World Café. Im World Café gab es lockere, moderierte Runden, die Probleme und Lösungen erörterten.
Lassen Sie mich eine kleine und spannende Zusammenfassung der Ergebnisse präsentieren, die die Teilnehmer erarbeitet haben:

Thema 1: Bridging the Gap between “System” and “Software”

Das Problem:
Wie unterscheidet man das System zur Software und anderen Bereichen? Die Systemgrenzen sind oft nicht komplett klar. Damit sind die Schnittstellen zwischen den Systemteilen unklar. Dadurch, dass jede Abteilung (für Software, Hardware, System, Komponenten usw.) das Problem nur aus ihrer Perspektive sieht, schränkt sie unbewusst den Lösungsraum des Gesamtsystems ein. Es wird unterschiedliches unbewusstes Wissen einbezogen, ohne dass allen klar ist, was damit wirklich genau gemeint ist.

Die Lösungsansätze:
Es bewährt sich hier eine Definition und Strukturierung des Gesamtsystems, die für alle, d.h. für den ganzen Unternehmensbereich bzw. das gesamte Produkt oder die Gesamtdienstleistung gültig ist. Wichtig ist die Abgrenzung: Was gehört dazu, was ist außerhalb des Systems. Dann leitet man aus dem “Gesamtsystem” die entsprechenden Subsysteme ab. Nehmen sie eine eindeutige Trennung und Definition der jeweiligen Bereiche vor: “System”, “Software”, etc. Hilfreich kann dabei eine “feature-basierte” Ansicht und Aufteilung des Gesamtsystems sein. Man definiert z.B. die “Software” als sogenanntes Architekturelement im Gesamtsystem. Ist die Architektur einmal bestimmt und festgelegt – klare Vereinbarungen über die Schnittstellen mit eingeschlossen – lassen sich die Anforderungen entsprechend zuordnen, aufteilen und detaillieren. Verschiedene Aufteilungen sind möglich, nach Variante, Projekt, etc. Wichtig ist, ein einheitliches und eindeutiges Verständnis des Gesamt-Systems, der jeweiligen Teil-Systeme und der zugehörigen Schnittstellen zwischen diesen Teil-Systemen.

Für die Softwareentwicklung ist ein bewährtes Vorgehen in ITIL (IT Infrastructure Library) ausführlich beschrieben. Gerade für IT-Service-Management ist dazu das ITIL sehr zu empfehlen. Es ist eine Sammlung von Best Practices zur Umsetzung und gilt inzwischen als internationaler De-facto-Standard im Bereich IT-Geschäftsprozesse.

Thema 2: Wie messe ich die Qualität der Anforderungen?

Das Problem:
Wie messe ich den Fortschritt der Requirements, die Qualität der Anforderungen und die Vollständigkeit der Anforderungen? Das führte uns auch zu den Fragen: “Wie kommuniziere ich den Mehrwert von RE zum Management?” und “Wie erzeuge ich eine allgemeine Motivation, die Methoden und Vorgehen des RE einzusetzen?”

Die Lösungsansätze:
Zuerst müssen dem Management die Vorteile von RE klar gemacht werden. Ohne “Management Commitment” geht es selten.
Die generellen Vorteile von Requirements Engineering habe ich kurz in meinem letzten Blog vorgestellt. Aussagekräftige Studien und Umfragen, um das Management für RE zu begeistern, bekommt man im RE Kompass, den die HOOD GmbH jährlich zusammen mit dem Fraunhofer Institut IESE und der Uni Zürich herausgibt. In der Umfrage des RE Kompasses 2013 zum Beispiel geben 96% der Unternehmen an, Verbesserungen durch RE erreicht zu haben. Über die Hälfte der Unternehmen nennen dabei jeweils die Verbesserung der Qualität ihrer Produkte, die verbesserte Kommunikation intern und extern zu den Stakeholdern, und verbesserte Tests. Ein Drittel der Unternehmen geben sogar an, eine klare Verbesserung der Kundenzufriedenheit erkennen zu können.

Der Fortschritt in der Entwicklung kann mit RE und einfachen Metriken sichtbar gemacht werden. Kommunizieren Sie zum Beispiel die absolute Anzahl der Anforderungen pro Bereich oder Abteilung, die geschrieben, bewertet, überprüft, getestet oder erfolgreich getestet sind. Aufgetragen über die Zeit lässt sich damit der Fortschritt im RE und in der Entwicklung hervorragend “nach oben” zum Management transparent machen. Halten sie sich dabei an einfache und wenige Metriken. “Bunt” und “viel” verwirrt dabei oft mehr als dass es hilft und kostet viel Vorbereitungszeit.

Thema 3: Projektauftrag vs. goldene Wasserhähne

Das Problem:
Bei vielen Projekten wird entwickelt und entwickelt und entwickelt. Das Projekt wird immer länger und teurer. Der Projektauftrag ist nicht eindeutig klar. Oder aus den Start-Anforderungen werden im Laufe des Projekts unvorhergesehen sehr viele neue Anforderungen abgeleitet.

Die Lösungsansätze:
Schauen wir zuerst hinter die vordergründigen Probleme: Die eigentlichen Probleme beim Stellen von Anforderungen können verschiedenartig gelagert sein. Oft ist es der Fall, dass der Auftraggeber eigentlich gar nicht genau weiss, was er will. Oder er stellt gewisse Anforderung gar nicht ausdrücklich, sondern macht “selbstverständliche”, implizite Annahmen. In beiden Fällen hilft hier die aktive, direkte und regelmäßige Kommunikation und Abstimmung mit dem Kunden. Die RE Experten sollten so früh wie möglich eingebunden sein, und die Kundendomäne soll vom Auftragnehmer gut und vollständig verstanden sein. Ganz wichtig ist, sich kontinuierlich mit dem Kunden abzustimmen und laufend die Anforderungen zu überprüfen und zu priorisieren. So vermeidet man auch während der Entwicklung, dass überflüssige Anforderungen aus den ursprünglichen Kundenwünschen abgeleitet werden, und dass eben keine goldenen Wasserhähne, die keiner braucht, entwickelt werden.

Thema 4: Tools und deren Nutzbarkeit

Das Problem:
Tools und Werkzeuge könnten hilfreich für die Arbeit mit Anforderungen sein. Doch die Einarbeitung für ein Tool ist schnell langwierig und übermäßig kompliziert. Auch die laufende Arbeit am Tool ist mit vielen Haken und Ösen verbunden. Ein komplexes Tool überlagert den Benefit der RE Methoden, oder das Tool hat keine Akzeptanz im Unternehmen. Die Mitarbeiter sind “Tool-müde”.

Die Lösungsansätze:
Zu unseren Lösungsansätzen führte uns der Spruch:

“A Fool with a Tool is still a Fool”

:
Ein Tool oder Werkzeug kann und soll uns unterstützen und dabei unsere Arbeit einfacher machen. Es ist kein “IT-Selbstverwirklichungs-Projekt”. Es übernimmt auch nicht die Aufgabe einer Methode oder einer RE-Vorgehensweise. Ein Tool einzuführen bedeutet nicht, RE einzuführen! Die Methoden und Vorgehen des RE gestalten wir parallel zum Tool und müssen übergeordnet zum Tool entwickelt werden. Die Frage an uns selbst, die wir uns immer wieder stellen sollten: “wo kann mir das Tool helfen und wo würde es mich zu sehr behindern”. Diese Frage führt uns zu dem richtigen Einsatz des Werkzeugs. Und nur da, wo uns das Tool  wirklich hilft, werden wir es einsetzen. Das sollten wir hinterfragen, kontinuierlich. Dann können wir auch akzeptieren, dass es immer gewisse Einschränkungen gibt, wie das Tool zu nutzen ist. Machen sie unbedingt eine sinnvolle Tool-Evaluierung vor der Einführung. Erstellen sie dazu eine Checkliste, welche Eigenschaften ihnen wichtig sind (inklusive Performance & Load-Evaluierung) und vor allem, wobei ihnen das Tool wirklich helfen soll. Wenn sie mit gesundem Menschenverständnis an die Toolevaluierung gehen, wird ihnen diese auch nicht allzuviel Zeit und Geld kosten. Eine fundierte Tool-Einführung wird auch dafür sorgen, dass Ihre Anwender das Tool benutzen, ein nachhaltiges Tool-Wissen aufbauen und immer effektiver damit werden.

Es gab noch einige andere Themen der Teilnehmer. Leider reichte die Zeit nicht ganz aus, weitere Themen zu diskutieren. Hier gab es noch Fragen wie: “Brauchen wir Unterscheidung zwischen funktionalen und nicht-funktionalen Anforderungen?”, “Braucht agiles RE auch Features, Requirements, Specifications, etc. oder nur Teile davon?”. Haben auch Sie noch Fragen? Dann kommen Sie zum nächsten World Café, zur nächsten REConf®, zu anderen RE-Veranstaltungen oder sprechen sie uns einfach persönlich an. Sie sind herzlich eingeladen!

Dr. Thaddäus Dorsch

Kontaktieren Sie Dr. Thaddäus Dorsch

Dr. Thaddäus Dorsch ist als Trainer, Berater und Coaching im Bereich Requirements Engineering und agiler Systementwicklung bei der HOOD Group tätig. Seine Schwerpunkte sind modernes Systems Engineering und effizienter Umgang mit Anforderungen, Vorbereitet sein auf den digitalen Wandel, sowie neu Ansätze in der Systemtheorie und die Kombination von klassischen und agilen Denkweisen und Techniken. Thaddäus Dorsch schöpft aus seiner langjähriger Erfahrung in der Systementwicklung in den verschiedensten Branchen wie Telekommunikation und Biotech, Automotive, Mobilfunk, Luft- und Raumfahrt, Verteidigung, Print und Multimedia.