Specs als ganz großes Kino

Wenn ich vergleiche, wie oft ich schon übermüdet ein eintöniges Science-Fiction-Buch nach wenigen Seiten weggelegt habe und wie oft ich beim Lesen von Softwarespezifikationen abschweife und mir lieber gedanklich mein Abendessen ausmale, dann ist das Rennen knapp und ich weiß nicht wer gewinnt!

Softwarespecs haben genauso wie SciFi oft einen immer wiederkehrenden Plot, der es schwer macht die wirklich interessanten und vielleicht ganz neuen Probleme zu erkennen und zu verstehen.

Das liegt meistens jedoch nicht am Leser, sondern am Autor. Manche denken vielleicht das Specs und insbesondere Architekturbeschreibungen so schwierig sind, dass wir nur mit Templates arbeiten können, z.B. dem arc24-Template.

Wozu das führt, sieht man hier mal an einem besonders grausamen Beispiel einer Spezifikation für ein Requirements Engineering Tool. Wer ein Tool zum Erstellen von Softwarespezifikationen programmiert, sollte eigentlich wissen wie man solche Dokumente saugut erstellt oder?

Ich bitte ausdrücklich diesem Link nicht zu folgen und sich das Dokument zu ersparen!

Hier ist das Inhaltsverzeichnis dieser Spec:

In diesem Dokument finden sich viel wichtige, gar essentielle Informationen für das System.

Aber wenn ich mir das Inhaltsverzeichnis anschaue, könnte dies auch genauso ein Dokument für eine Supermarkt-Kasse, ein Projektmanagement-Tool oder ein CRM-System sein.

Bevor ich darauf eingehe, was das Problem an solchen Dokumenten ist, möchte ich kurz einschieben, warum wir Spezifikationen schreiben. Dafür gibt es ja viele Gründe. Z.B. benötigen wir eine Vertragsgrundlage für die Entwicklung eines Systems und eine Grundlage für die Projektplanung. Entwickler leiten daraus ab, was Sie programmieren oder vorher designen müssen. Tester bzw. Testplaner leiten Testfälle daraus ab. Egal ob wir eine Spezifikation nun als Lastenheft, Pflichtenheft oder als internes Projektdokument nutzen, die primäre Funktion ist jedoch die Kommunikation zwischen Menschen. Selbst in einem kleinen Projekt dient es zur Selbst-Kommunikation.

Mir scheint das zwar trivial, aber ich wiederhole es noch einmal. Menschen lesen Spezifikationen, nicht Computer. Eine Spezifikation dient nicht zum Generieren von Programmcode und Testfällen, sie dient ausschließlich dazu gelesen und verstanden zu werden!

Wenn dies als Grundeinstellung verinnerlicht ist, sind die Probleme der oben gezeigten Spezifikation leicht erkennbar. Ein äußerst logischer Aufbau hilft nicht unbedingt in der Verständlichkeit. Dort werden Internal interface requirements, External interface requirements und Internal data requirements auf einer Hauptgliederungsebene unterschieden. Der Fakt, dass jeder Gliederungspunkt nur 1-2 Stichpunkte Content enthält, ist ein Indiz für die Sinnlosigkeit dieser Gliederung. Dahinter verstecken sich übrigens für den Programmierer recht triviale Entscheidungen wie JDBC als Datenbankzugriffstechnik zu verwenden.

Nun, einwas kann man dieser Spec abgewinnen. Sie wirkt recht vollständig, denkt an jedes Detail. Aber – auch dies ist nur ein Schein. Spezifikationen sind nie vollständig. Wären sie dies, wären sie quasi schon das System in einer “höheren” und abstrakten Sprache. Welcome to Fantasia Island. Komplexe und aus Templates aufgebaute Spezifikationen laufen aus meiner Sicht sogar viel eher Gefahr unvollständig zu sein, denn in kurzen Dokumenten fallen fehlende essentielle Inhalte viel schneller auf.

Was ist denn nun die Alternative zu einem so “krass” logisch gegliederten Spezifikationsdokument? Ich würde es analog zum Domain Driven Design (DDD) einfach Domain Driven nennen. Hier steht nicht die logische Gliederung, sondern ein strukturierter Aufbau im Mittelpunkt, der das spezifische Problem für Menschen optimiert aufbereitet und vielleicht sogar interessant zu lesen ist.

Damit ich mich mit dem Wort gut blamiere, brauche ich natürlich erst einmal ein schönes Akronym:

  • Krass-logisch gegliedert: KlggSpecs
  • Domain Driven: DD-Specs

Aber nun genug der Techie-Wortklauberei. Machen wir uns mal ans Werk und zwar ganz genau ans Kino.

Nehmen wir mal an, das Kino Metropol will eine neue Software entwickeln lassen, z.B. um das Kinoprogramm einzutragen, auf der Homepage zu veröffentlichen, vielleicht die Ticketverkäufe abzuwickeln und ein paar Auswertungen anzusehen. Es geht hier um kein vollständiges Beispiel und vielleicht ist auch etwas nicht inhaltlich korrekt, sondern nur von mir ausgedacht.

Ich muss mich loben, dass ich auch in der Vergangenheit keine krass-logischen Exzessdokumente erstellt habe, aber basierend auf Best Practices vieler Projekte würde ich wohl eine Spezifikation erstellen, die ungefähr so aussieht:

Ich denke, dass dies für die Kommunikation schon sehr gut geeignet und sozusagen nur ein sanftmütiges krass-logisches Monster ist.

Es kommen zwar keine Techie-Schrottbezeichnungen wie Internal data requirements vor, aber dennoch dominiert hier die logische Gliederung.

Zunächst ist das Domain Scoping zu nennen. Darunter grenze ich ab, was zum System gehört und was nicht. Dies ist für die Kommunikation äußerst wichtig und muss jedem Projektbeteiligten (v.a. dem Auftraggeber) total klar sein, aber es hat keinen Bezug auf das Kinoproblem. Man erkennt es auch recht leicht daran, dass es ein englischer Fachbegriff ist.

Die Geschäftsprozesse sind für den Kinobetreiber recht gut gegliedert. Wahrscheinlich wird der Kinobetreiber dieses kleinen Kinos aber nicht von Geschäftsprozessen sprechen, wenn er sein Kinoprogramm plant.

An der Systemsicht habe ich nicht so viel auszusetzen, denn dies ist eher für den Implementierer gedacht, sodass eindeutige, aber komische Fachbegriffe wie Systemsicht hier völlig OK sind.

Da das System absolut User-zentriert entwickelt werden soll, werden Personas definiert. Der Inhalt ist äußerst wichtig, aber schon wieder so ein Fachbegriff den wir hier einführen.

Schauen wir uns nun an, wie wir diese Spec (mit dem gleichen Inhalt) Domain Driven trimmen können:

Wow, hier ist die Gliederung Programm und das erste Kapitel lädt sogar zum Lesen ein!

Zunächst fällt auf, dass einige Gliederungspunkte scheinbar verschwunden sind, z.B. Einleitung und Domain Scoping. Im Kapitel Gutes Kino braucht Organisation wird als Einleitung die Motivation für die Software erläutert,  darin enthalten ist auch das Domain Scoping. Die wichtige Information bleibt also erhalten, erhält nur keine separate Gliederungsnummer.

So funktioniert Kino enthält die Geschäftsprozesse, aber auch die Personas. Warum sollen wir dies für eine solche (eher einfache) Software trennen? Stellen wir doch Personas mit Ihren Charakteristiken direkt in Bezug zu den generalisierten Aktivitäten vor.

Auch in der Systemsicht wurden alle gesichtslosen Standardbegriffe durch Domänensprache ersetzt. Hier ist es übrigens besonders einfach, da wirklich nur die Überschrift umbenannt werden muss.

Zum Schluß fällt auf, dass das Kapitel Glossar fehlt. Es ist prinzipiell wichtig die Begriffe eindeutig zu halten. Wenn im ganzen Dokument über die Fachbegriffe klar benutzt wurden, dann ist das separate Glossar zumindest für eine kleine Software völlig überflüssiger Ballast.

Was ich jetzt natürlich nicht gezeigt habe, war ein vollständiger Inhalt einer Spezifikation. Aber für das Kinobeispiel kann sich dies hoffentlich jeder anhand der Gliederung vorstellen.

Jetzt vergleichen wir bitte noch einmal dieses Dokument mit dem des “Open Source Requirements Management System”. Manchmal haben wir leider nicht die Freiheit die Form der Spezifikation frei zu wählen, aber wenn wir dies können, gibt es nur eine gute Form und die ist Domain Driven!

Nachtrag: einige Ideen für ein Tool, was so etwas hoffentlich unterstützt.