In der Konzeption von großen Softwareprojekten erlebt man oft, dass Consultants sehr lange Dokumente schreiben, die vor allem aus Anwendungsfällen (Use Cases) bestehen. Wikipedia schreibt hierzu:

Ein Anwendungsfall beschreibt die Interaktionen zwischen Nutzer und System, die notwendig sind, um ein fachliches Ziel des Nutzers zu verwirklichen.

Das klingt ja schon mal ganz toll, aber was ist mit Aktionen die keinen Nutzereingriff erfordern. Wie werden diese beschrieben? Wo steht, was implizt ausgelöst wird? Die Theorie hat immer einen geeigneten Platz dafür. Die Realität sieht anders aus.

Wir stellen die Behauptung auf, dass Konzepte, die zum großen Teil aus Anwendungsfällen bestehen gerade einmal zu 50% bis 60% der Anwendung beschreiben. Dazu schreibt Wikipedia:

Die Granularität von Anwendungsfällen kann sich stark unterscheiden: Auf sehr hohem Niveau beschreibt ein Anwendungsfall lediglich sehr grob und abstrakt, was passiert.

Was fehlt? Grundsätzlich ist das abhängig von dem zu erstellenden Softwaresystem. Als Erstes sollte eine textuelle vollständige Beschreibung der Anwendung entstehen. Weiterhin empfehlen wir die Prozesse, die in der Applikation abgebildet werden gesondert zu beschreiben, sei es als Diagramm oder als Fließtext.

Aus den modernen Methoden der Softwareentwicklung (Agile Entwicklung) und des Projektmanagements (SCRUM) haben wir gelernt, dass es dem Kunden viel einfacher fällt eine User Story (kurze prägnante Anforderung die auf ein Karteikärtchen passt) zu verfassen als das System zu beschreiben. Diese User Stories sind Teil der Konzeption.

Als letztes gilt es, dass in Anwendungen mit Benutzerschnittstelle (und das sind fast alle) sogenannte Wireframes oder Mockups zu erstellen sind. Dabei handelt es sich um ein Bild der Anwendung wie sie der Benutzer sieht. Man erstellt diese Wireframes gemeinsam mit dem Kunden. Das hat mehrere Vorteile. Erstens ist der Kunde in der Lage sich die Anwendung tatsächlich vorzustellen und kann dann prüfen, ob seine User Story auch erfüllt ist. Zweitens erkennt man durch die gemeinsame Arbeit Anforderungen, die sonst im Verborgenen geblieben wären.

Ein gutes Konzept einer Software beinhaltet also wesentlich mehr als Anwendungsfälle.