Die Entstehung von STABLE

Ich weiß nicht, ob Sie es schon wussten: Immer, wenn wir SOPHISTen gerade Zeit haben, sinnieren wir liebend gerne über Mögliches und Unmögliches, über Sinniges und Unsinniges und vor Allem über neue Möglichkeiten die RE-Welt zu verbessern. Oft kommt es vor, dass wir während solcher Fachsimpeleien – oder auch spontan abends bei einem Glas Rotwein – auf ein Thema stoßen, das wir für besonders interessant halten. Was wir dann machen? Ganz einfach, wir starten ein Innovations-Projekt (kurz Inno-Projekt) und jeder SOPHIST, der Interesse und/oder Erfahrung in dem Thema hat, kann sich beteiligen. Natürlich kommt es auch vor, dass eine anfangs brillante Idee auf den zweiten Blick nicht gar so brilliert und wir lassen das Projekt wieder fallen, doch aus vielen Ideen entstehen mit der Zeit wirklich gute, innovative und nützliche Ergebnisse.

Und genau solch ein Inno-Projekt – und speziell seine bisherigen Ergebnissen – möchten wir Ihnen im Rahmen einer kleinen Blog-Serie vorstellen…

Es begab sich also, dass wir SOPHISTen bei einem unserer regelmäßigen Erfahrungsaustausche auf ein Thema stießen, das jedem Anwesenden sofort ein wohlwissendes, leicht gequältes Lächeln auf das Gesicht zauberte: Das Problem schlecht strukturierter Anforderungen. Nach einer kurzen Diskussionsrunde und einigen lustigen Anekdoten später war Folgendes klar:

• Schlechte Strukturen für Anforderungen behindern immer wieder effizientes Arbeiten 
  Bei mehr als einem Autor entstehen endlose Diskussionen wo was beschrieben wird, Redundanzen weil zwei Personen das Gleiche an unterschiedlichen Stellen beschreiben, häufiges „Umsortieren“ von Inhalten mit Reibungsverlusten und, und, und…
• Schlechte Strukturen verursachen schlechte Lesbarkeit, Inkonsistenzen und sind Ursache für instabile Spezifikationen 
  „Geschwürbildung“ war hier eine der treffendsten Beschreibungen. Fremdkörper, d. h. nicht zum Thema passende Anforderungen nisten sich an einer Stelle ein, vermehren sich und zerstören die Struktur.
• Große Unterschiede zwischen einzelnen Spezifikationen innerhalb eines Unternehmens erschweren die Zusammenarbeit und Kommunikation über Projekt- bzw. Abteilungsgrenzen hinweg 
  Projektfremde Kollegen brauchen viel Zeit um sich in die Struktur einzuarbeiten und sich zurecht zu finden.
• Heterogene Spezifikationslandschaften verhindern die Wiederverwendung einzelner Anforderungskapitel und erschweren die Qualitätssicherung 
  Z. B. beschreibt jeder erneut die Anforderungen an eine Suchfunktion, oder an Reporting-Funktionen, die man oft auch einfach aus einem Nachbarprojekt übernehmen könnte.

Und voilà, ein neues Inno-Projekt war geboren! Schnell waren vier Interessierte gefunden, die sich des Themas annehmen wollten und schon ging es los.

Erster Diskussionspunkt: Wie sieht die perfekte Struktur für Anforderungen aus?

Unser Fazit: Die perfekte Struktur ist vor allem intuitiv nachvollziehbar, sie ist stabil für Erweiterungen und Änderungen, außerdem folgt sie einer festgelegten und über Projektgrenzen hinweg wiederholbaren Systematik. Letzteres war ein entscheidender Punkt, es muss eine feste Systematik dahinterstecken, ein regelgeleitetes Vorgehen und kein individueller, willkürlich kreativer Prozess.

Aber gibt es die nicht eigentlich schon? Diese Systematik? Jeder Trainer und Methoden-Coach bei uns kennt sie, wir alle haben sie schon unzählige Male in Projekten und Trainings an Flip-Charts und White-Boards gemalt und erläutert. Und unabhängig von Projekt, Fachgebiet und Detailtiefe ist der Kern immer der gleiche: Die Gliederung der Anforderungen anhand der Ergebnisse einer Use-Case-Analyse.

Das Bild, welches wir immer und immer wieder aufs Neue skizzieren, sieht ungefähr folgendermaßen aus – vielleicht kommt es ja dem ein oder anderen unter Ihnen bekannt vor :-)

Unsere nächste Frage lautete: Wie wollen wir die Systematik dokumentieren, wie soll unser Ergebnis aussehen?

Unser erster Ansatz war eine Schritt-für-Schritt Anleitung für die Überführung des gesamten Modells in die Struktur. Bald wurde uns klar, dass diese Methode für unsere Zwecke zu unflexibel ist. Wir mussten zu viele Bedingungen an das Modell stellen und zu viele Einschränkungen machen. Ein neuer Ansatz musste her, möglichst allgemeingültig und ohne Vorbedingungen. Dabei fiel unser Blick auf das Wörtchen „regelgeleitet“ in der Zielsetzung. Warum nicht einfach atomare, Regeln aufstellen? Für jedes Notationselement eine Regel und dazu ein Beispiel, wie die Anwendung der Regel aussieht. So wurde es dann auch gemacht.

Unsere dritte zu treffende Entscheidung war: Welche Diagramme wollen wir betrachten?

Diese Antwort war schnell gefunden. Für uns war klar, wir nehmen die in der Use-Case-Analyse am häufigsten verwendeten Diagramme: Das Use-Case-Diagramm, das Aktivitätsdiagramm und der Zustandsautomat. Diskussionen gab es lediglich im Hinblick auf das Klassendiagramm, welches in der Analyse gerne für die Erstellung eines Begriffsmodells verwendet wird. Da dieses aber als strukturelles Diagramm eine Sonderrolle einnimmt, haben wir seine Betrachtung auf einen späteren Zeitpunkt vertagt.

Nun wurde es schon konkreter: Welche Notationselemente innerhalb der Diagramme sollen wir betrachten?

Von unserem anfänglichen Ehrgeiz alle Elemente zu betrachten, kamen wir bald ab. Praxisorientierung und Einfachheit waren uns wichtiger als Vollständigkeit. Daher griffen wir uns die Notationselemente heraus, die einerseits in der Praxis häufig verwendet werden und die außerdem einen Einfluss auf die Struktur haben. So einfach dies klingt, diese Entscheidung hat so manche Stunde harter Diskussion gekostet. „Wer verwendet alles Schleifen in seinen Aktivitätsdiagrammen?“, „Was ist mit Unterbrechungsbereichen und Mengenverarbeitungsknoten?“, „Wer kennt überhaupt den Unterschied zwischen einer Kreuzung und einer Verzweigung bei Zustandsübergängen?“, „Ich würde gerne nochmal auf die Schleifen zurückkommen!“ … und, und, und. Kaum war eine Entscheidung getroffen, kam stets ein weiterer Kollege hinzu und hat alles kurzerhand wieder über den Haufen geworfen („Warum betrachtet ihr eigentlich keine Schleifen??“).

Aber wir haben auch diese Hürde gemeistert und für die von uns identifizierten Notationselemente Regeln formuliert, wie diese in eine hierarchische Struktur zu überführen sind.

Und nun, unzählige interessante, teils lustige, teils zähe aber immer aufschlussreiche Diskussionsrunden und Workshops später, ist es so weit. Wir sind um ein Regelwerk (oder besser gesagt drei Regelwerke – eines für jede Diagrammart) und viele wertvolle Erkenntnisse reicher. Unsere Ergebnisse haben wir sprechenderweise auf den Namen STABLE getauft. Getreu dem Motto: Mit STABLE STrukturieren Sie Ihre Anforderungen Besser, Lesbarer und Effizienter!“

Sind Sie neugierig geworden, wie STABLE aussieht? Hier ein kleiner Vorgeschmack.

Lust auf mehr? Dann schauen Sie doch einfach in der nächsten Zeit wieder einmal in unseren Blog, wir werden unsere Regelwerke hier vorstellen und würden uns über Interesse, Kommentare und weitere Ideen wie immer sehr freuen.

Zum Abschluss hier noch ein paar Highlights aus dem Fundus unserer wertvollen Erkenntnisse:

• „Methodische Abbildung und Integration von UML-Modellen in eine hierarchische Anforderungsstruktur“ ist ein zu langer Name für ein Projekt.
• Eigentlich funktioniert unsere Systematik auch wunderbar ohne Diagramme.
• Die Regeln könnte man problemlos in einen Generator stecken, der die Struktur automatisch generiert bei Änderungen aktualisiert.
• Spätestens ab der achten Gliederungsebene wird es mit dem Platz auf den Folien etwas eng.
• Man kann viele, viele Stunden über die richtige Reihenfolge für Use-Cases diskutieren, nur um dann festzustellen, dass sie eigentlich völlig egal ist.
• Ab drei beteiligten Beratern ist ein Terminvorlauf von 8 Wochen absolut normal.
• Regel, die niemand versteht ist eine schlechte Regel (und mag sie inhaltlich noch so korrekt sein)!