Technology
18. März 2015

Mit Spec(k) fängt man Mäuse: Wie schreibt man eine Spezifikation?

Mit Speck fängt man Mäuse - KundenspezifikationWenn 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. Spezifikation für Kunden

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

annegret

Dr. Annegret Junker

Dr. Annegret Kampe arbeitete bis Ende Oktober 2017 als Enterprise Architect Cloud bei SupplyOn.

2 thoughts on “Mit Spec(k) fängt man Mäuse: Wie schreibt man eine Spezifikation?

  1. Prinzipiell finde ich das eine löbliche Frage:

    „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?“

    Ich finde die Antworten doch eher konservativ. Was ist denn eine Sprache, die Kunden verstehen? BPMN + UML + Prosa scheint mir nicht die Lingua Franca, mit der sich Nicht-Informatiker und Informatiker verständigen. Softwarefirmen müssen sich aus meiner Sicht viel mehr zur Sprache des Kunden entwickeln und die ist eher informell, denn formal. Insoweit stimme ich Ihnen bei der Nützlichkeit von Wireframes zu.

    Ich habe vor ein paar Jahren zu diesem Thema mal einen Artikel verfasst, der sich darum dreht, wie man Specs *interessant* hält, denn *nur* so füttert man den Kunden an, oder fängt Mäuse mit Speck, wie Sie das formuliert haben:
    http://kleffels-software-blog.de/?p=506

    Absolut zeitlos finde ich zu diesem Thema auch Joel Spolsky:
    http://www.joelonsoftware.com/articles/fog0000000036.html

    1. Annegret Kampe sagt:

      Hallo Herr Kleffel,
      vielen Dank für Ihren Kommentar. Die Antwort hat ein wenig länger gedauert – wegen der Osterfeiertage 🙂
      Ja der Ansatz ist wahrshceinlich eher konservativ. Wahrscheinlich weil natürlich eigentlich nur das Endstadium eines längeren Prozesses beschrieben ist. In einer interaktiven Diskussion sind BPMN und UML in der Regel zu abstrakt, um die Dinge wirklich kontrovers diskutieren zu können. Auf der anderen Seite brauchen wir aber bei der Überführung in die Software diesen abstrakteren Level. Da beißt sich für mich die Katze in den Schwanz.
      Mindmaps und andere vorgelagerten Strukturierungsansätze helfen hier ganz sicher. Wir haben aber auch schon UML mit Kunden diskutiert und zusammen erarbeitet. Auch das hat funktioniert.
      Will sagen – es widerspricht sich nicht. Man muss „nur“ das Tool wählen, das dem jeweiligen Erkenntniss-Stand und der jeweiligen Gruppe entspricht.
      Und das ist dann die Kunst … 🙂
      Gruß Annegret Kampe

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

12 + zwanzig =

Zum Seitenanfang