Wenn wir heute ein Software-Entwicklungsprojekt starten, fangen wir an, eine Spezifikation zu schreiben – eine Spec. Die Spezifikation soll viele Anforderungen erfüllen und gleichzeitig verständlich für Entwickler, Tester und natürlich auch den Kunden sein. Sie sind unsere Mäuse, die wir mit unserer(unserem) Spec(k) fangen wollen.
Aber wie kann man für diese unterschiedlichen Lesergruppen komplexe technische aber auch geschäftliche Zusammenhänge so erläutern, dass am Ende eine Software entsteht, die die Erwartungen des Kunden hinsichtlich Funktionalität und Qualität erfüllt? In diesem Blog möchte ich erläutern mit welchen Modellen, Textbausteinen und Strukturierungen welche Lesergruppe am besten ansprechbar ist. Also welche Mäuse mit welchem Speck am besten gefangen werden können 🙂 .
Eine Spezifikation für einen Kunden
Was erwarte ich als Kunde von einer Software – sie soll einfach sein, intuitiv bedienbar und die Arbeit insgesamt vereinfachen – mit einem Speck, der mir nicht schmeckt, kann man mich auch nicht fangen. Und viel mehr: Einen Speck, den ich nicht kenne, werde ich nicht fressen. Das heißt, eine Spezifikation, die ein Kunde nicht versteht, wird von ihm höchstwahrscheinlich auch nicht in Auftrag gegeben.
Um die Arbeit für den Kunden zu vereinfachen, müssen wir die dahinter liegenden Business-Prozesse verstehen und sicher sein, dass wir eine gemeinsame Vorstellung von ihnen haben.
Um diese gemeinsame Vorstellung zu erreichen, greifen wir auf Business-Prozess-Modelle zurück, die wir mit UML oder auch BPMN darstellen. Beide bildlichen Darstellungsweisen ermöglichen es uns, eine gemeinsame Sprache zwischen Lieferanten und Auftraggeber zu finden. Allerdings reichen die bildlichen Darstellungen in einer Spezifikation allein nicht aus.
Um die Interpretierbarkeit der bildlichen Darstellung zu minimieren, beschreiben wir die Prozesse in einer natürlichen Sprache, die wir alle besser verstehen. In der Kombination von bildlicher Darstellung und natürlicher Sprache erreichen wir eine größtmögliche Übereinstimmung im Verständnis der Anforderungen – also in der Erwartungshaltung des Kunden und der geplanten Umsetzung. 
Diese abstrakte Darstellung erläutern die Business-Prozesse sehr gut. Allerdings sieht ein Sachbearbeiter – der letztlich die Software benutzen soll – in der Regel seinen Schreibtisch. Der dahinter liegende Business-Prozess muss ihn unterstützen, damit er schnell und problemlos seine Arbeit machen kann. Wenn er viele Briefe geschrieben hat, die dann aber nicht von einem Boten abgeholt werden um sie an die richtige Stelle weiterzugeben, so dass der Prozess nicht aufgehalten wird, haben wir im Design des Business-Prozesses etwas falsch gemacht.
Aber wir müssen den Sachbearbeiter unterstützen, diese vielen Briefe zu schreiben. Er will seine Arbeit erledigen und nicht warten, ob irgendeine Software endlich soweit ist, damit er seine Briefe schreiben kann.
Um ihn hier zu unterstützen, müssen wir die Benutzeroberfläche so gestalten, dass wir ihn in dieser speziellen Aufgabe unterstützen. Er muss die Dinge, die er braucht, dort finden wo er es gewohnt ist – z.B. das Briefpapier mit dem Firmenlogo auf der linken Seite und den Stempel auf der rechten.
Nun ist glücklicherweise nicht jeder Mensch gleich – und damit auch jeder Sachbearbeiter. Wir könnten nun dazu neigen, die Benutzeroberfläche so zu gestalten, dass jeder sie einrichten kann, wie er sie braucht. Am Anfang bieten wir einfach alles an, was geht (Briefpapier rechts, links, oben, unten, Stempel links und rechts, …). Das wirkt aber sehr verwirrend und es würden Tage vergehen, bis irgendjemand in der Lage sein wird, die Software zu benutzen.
Man könnte natürlich auch gar nichts anbieten und den Benutzer alles gewissermaßen aus der Schublade holen lasse und sich selbst seinen Schreibtisch einrichten zu lassen. Allerdings laufen wir hier Gefahr, dass wichtige Dinge nicht gefunden werden und wir den Benutzer frustrieren. Daher benutzen wir Mockups in unseren Spezifikationen. Mockups stellen in einer skizzenhaften Art die zukünftige Bedienoberfläche dar. Diese können wir mit dem Kunden diskutieren und so eine gute Balance zwischen den beiden Extremen erreichen.
Wir haben nun eine Spezifikation für den Kunden – aber was ist mit Entwicklern? Welche Informationen brauchen sie?
Lesen Sie außerdem:
Wie schreibt man eine Spezifikation für Entwickler und
Wie schreibt man eine Spezifikation für Tester