lohmeyer White Paper Use Cases UX+Prozessanalyse

Transkript

1 White Paper Use Cases Use Cases begegnen uns in fast allen IT-Projekten. Besonders größere Vorhaben kommen ohne sie nicht aus. Dieses White Paper beleuchtet einige Aspekte der Use Case-Modellierung für Fachanwendungen. 1 2 Die richtige Strukturierung der Use Cases ist entscheidend: Anleitungen zur richtigen Einordnung von Nutzerzielen und Unterfunktionen Use Cases zu schreiben erfordert einen besonderen Blick auf die Dinge - und Übung: 6 Tipps zur Formulierung von Use Cases

2 Nutzerziele und fliegende Fische Die Use Case-Analyse ist ein sehr mächtiges Werkzeug. Dabei ist die richtige Differenzierung zwischen Nutzerzielen und Unterfunktionen essentiell. Use Cases gehören zum Alltag der IT. Kein größeres Projekt kommt ohne sie aus. Die ganze Welt schreibt Use Cases. Wirklich? Dass ich diesen Artikel schreibe, mag erkennen lassen, dass ich da meine Zweifel habe. Meine These: Viele sogenannte Use Cases sind gar keine. Ich möchte im Folgenden darstellen, wie ich dazu komme. Da das Thema umfangreich ist, teile ich die Betrachtung in zwei Artikel auf: 1. Differenzierung zwischen Nutzerziel und Unterfunktion 2. Wie beschreibe ich ein Nutzerziel (Teil 2: Pure Fachlichkeit ist keine Lösung aber ein gutes Problem) Der Begriff Use Case lässt sich im Deutschen am besten mit Anwendungsfall übersetzen. Hier passt die wortgetreue Übersetzung sogar ganz gut. Ein Use Case beschreibt, wie ein Nutzer (Aktor) mit einem System in Interaktion tritt, um ein bestimmtes Ziel zu erreichen. Wenn ich hier vom Erreichen eines Ziels spreche, so steckt dahinter zweifelsohne eine Intention. Und die können nur Menschen bzw. Gruppen von Menschen haben. Genau genommen können Use Cases aber auch die Interaktion zwischen verschiedenen Systemen beschreiben. Diese spezielle Form von Use Cases möchte ich hier nicht diskutieren. Mir geht es an dieser Stelle ausschließlich um die Use Cases, die beschreiben, wie ein menschlicher User mit einem System interagiert, um ein fachliches Ziel zu erreichen. Warum ich das fachliche Ziel hervorhebe, lege ich später dar. Use Cases gemäß Alistair Cockburn Alistair Cockburn hat 2001 das Buch Writing Effective Use Cases herausgebracht. Es ist bemerkenswert, und ich kann es jedem interessierten Leser wärmstens empfehlen. Er stellt darin verschiedene Granularitäten von Bildquelle: foundation for information and research on marine mammals

3 Schematische Darstellung einer Use Case-Landschaft mit Beispiel-Use Cases in den verschiedenen Granularitäten. Grob Fein Use Cases dar. Da gibt es welche für sehr große Zusammenhänge und welche für die winzigen Details. Alistair Cockburn findet für die Kategorisierung das Bild eines vertikalen Querschnitts unser Erlebniswelt: Ganz oben die Wolken, darunter lassen Kinder Drachen am Himmel fliegen, dann kommt die Oberfläche eines netten Sees mit seinen kleinen Wellen, im See schwimmen Fische und am Seegrund leben Muscheln (siehe Abbildung). Globale Zusammenfassung (Wolke): Diese Use Cases beschreiben, wie Organisationen miteinander interagieren. Dabei werden die Organisationen lediglich von außen betrachtet. Zusammenfassung (Drachen): Mit diesen Use Cases werden Abläufe innerhalb einer Organisation beschrieben. Auf dieser Ebene wird auch beschrieben, wie Nutzerziel-Use Cases miteinander in Beziehung stehen. Eine solche Zusammenfassung verschafft einen guten Überblick über die Organisationsprozesse. Nutzerziel (Welle): Diese Use Cases beschreiben die Interaktion eines konkreten Nutzers mit dem System. Diese Ebene verdeutlicht, warum wir das System entwickeln, warum der Anwender das System braucht. Dabei wird das System als Blackbox von außen betrachtet. Technische Details des Systems sind irrelevant. Da hier die Musik spielt, werden unter Use Cases häufig diese Nutzerziele verstanden. Sie sind also DIE Use Cases. Unterfunktion (Fisch): Die Unterfunktionen beschreiben Funktionalitäten, die zur Erreichung der Nutzerziele erforderlich sind und von diesen benutzt werden. Der Nutzer würde diese Unterfunktionen aber nie ohne einen größeren Zusammenhang (Nutzerziel-Use Case) aufrufen oder aufrufen dürfen. Zu detailliert (Muschel): Viele Funktionalitäten sind derart kleinteilig, dass sie im Rahmen einer Use Case-Betrachtung vernachlässigt werden können. Wenn Sie während der Autofahrt den Gang wechseln, möchten Sie nicht wissen, wie Ritzel A in B greift. Der Use Case Kraftüber- tragung Ritzel A nach B veranlassen kann bei der Konzeption eines Fahrzeugs als Muschel vernachlässigt werden. Ich habe diesen kleinen Ausflug zu Alistair Cockburn gemacht, um ein besseres Verständnis der verschiedenen Use Case-

4 Granularitäten zu vermitteln. Wie ich schon eingangs erwähne, stoße ich bei der Beschreibung von Use Cases immer wieder auf zwei Schwierigkeiten: 1. Es wird nicht hin- reichend zwischen Nutzerziel und Unterfunktion differenziert. 2. Die Beschreibung der Nutzerziele beschränken sich nicht auf die Fachlichkeit sondern beinhalten schon eine vermeintliche Lösung. Dazu aber im Teil 2 Was ist ein Nutzerziel, was eine Unterfunktion? Ein Nutzerziel-Use Case beschreibt eine Funktion, deretwegen der Nutzer mit dem System arbeitet. Die erfolgreiche Erledigung eines Use Cases dieser Ebene bringt einen fachlichen Mehrwert. Stellen wir uns einen Sachbearbeiter in einer Versicherung vor, der für die Vertragsverwaltung zuständig ist. Er wird dafür bezahlt, Verträge aufzunehmen, aktuell zu halten und im Falle einer Vertragskündigung den entsprechenden Vertrag zu inaktivieren (Löschen wird vermutlich keine gute Lösung sein). Wir können hieraus drei wichtige Use Cases ableiten: Vertrag anlegen Vertrag bearbeiten Vertrag inaktivieren Diese drei Use Cases bringen zweifelsohne einen fachlichen Mehrwert im Sinne des Unternehmens und der Mitarbeiterverantwortlichkeit. Nun gibt es aber über diese drei Nutzerziele hinaus weitere Funktionen, die der Sachbearbeiter nutzt, um seine fachliche Arbeit bewerkstelligen zu können. Kommt ein neuer Vertrag auf den Tisch, wird der Sachbearbeiter bestimmt wissen wollen, ob der Kunde schon im System erfasst ist. Er wird also nach der Person suchen. Das ist in vielen Systemen eine sehr wichtige Funktion. Suche ist kein Nutzerziel, sondern in der Regel eine Unterfunktion. Wir haben also eine weitere Funktion: Person suchen Ist das aber ein Nutzerziel? Nein auf keinen Fall Der Sachbearbeiter wird ja nicht für das Suchen bezahlt. Die Suche bietet keinen fachlichen Mehrwert. Ja, es ist meistens sogar aus Datenschutzgründen verboten ohne größeren Kontext (Nutzerziel) im System zu suchen. Es gibt wenige Berufe, die das ermöglichen. Mir fallen da bestenfalls Geheimdienste und reine Recherche- unternehmen ein. In der Regel ist eine anlassunabhängige Suche untersagt. Und auch als privater Onlineshopper wollen wir nicht einfach suchen. Suchen ist nicht per se eine tolle Sache. Nein, wir möchten ein passendes Produkt bestellen und genau zu diesem Zweck (Nutzerziel Produkt bestellen) suchen wir. Jetzt wird vermutlich deutlich, dass es sich bei der Suche in den seltensten Fällen um ein Nutzerziel handelt. Was ist es dann? In fast allen Systemen ist die Suche eine Unterfunktion (Fisch), die in den Kontext übergeordneter Nutzerziele (Welle) eingebunden ist. Ein typisches Merkmal von Unterfunktionen ist auch, dass sie von mehreren Nutzerzielen verwendet / aufgerufen werden. In unserem Beispiel der Vertragsverwaltung wird der Sachbearbeiter die Unterfunktion Person suchen in allen drei Nutzerzielen verwenden. Tipps zur Unterscheidung Die klare Differenzierung zwischen Nutzerzielen und Unterfunktionen ist nicht

5 $ lohmeyer immer ganz leicht. Es gibt aber ein paar Anhaltspunkte, die dabei helfen: Nutzerziele Der Nutzer hat sich nach diesem Use Case eine Kaffeepause verdient. Der Nutzer wird dafür bezahlt, dass er diesen Use Case ausführt. Der Kunde bezahlt dafür, dass er diesen Use Case ausführen kann. Dieser Use Case bietet einen fachlichen Mehrwert. Der Use Case darf ohne übergeordneten Kontext ausgeführt werden. Es ist sinnvoll, diesen Use Case ohne übergeordneten Kontext auszuführen. Unterfunktionen Eine falsche Strukturierung der Use Cases kann das Projekt gefährden. die Use Cases als Übereinkunft zwischen den beteiligten Parteien dienen: Ja, das will ich gelöst haben. Ja, das können wir lösen. Um das zu gewährleisten, muss die Gesamtheit der Use Cases (alle Ebenen) klar gegliedert sein. Nur so entsteht eine verständliche Use Case-Landschaft, welche auch für das Projektmanagement wichtig ist. Häufig werden Unterfunktionen irrtümlicherweise als Nutzerziele definiert. Das geschieht oft aufgrund der Einschätzung, dass eine bestimmte Unterfunktion unverzichtbar und wichtig ist. Das ist aber ein Fehler: Niemand hat behauptet, Unterfunktionen seien unwichtig oder verzichtbar. Ganz im Gegenteil. Ohne manche Unterfunktionen wie beispielsweise die Suche lässt sich das System gar nicht vernünftig nutzen. Der Nutzer darf die Unterfunktion nur im Rahmen eines übergeordneten Nutzerziels ausführen. Die Unterfunktion ist zu kleinteilig, als dass das Management sich damit beschäftigen würde. Der Nutzer wird nicht dafür bezahlt, dass er die Unterfunktion ausführt. Die Unterfunktion bringt keinen Mehrwert, der in Rechnung gestellt werden kann. Die Unterfunktion wird von mehreren Nutzerzielen verwendet. Die Unterfunktion ist in wenigen Sekunden erledigt. Problem Fliegende Fische Use Cases haben das Ziel, ein System übersichtlich zu beschreiben. Sie dienen als Kommunikationsgrundlage zwischen Auftraggeber und Auftragnehmer, zwischen Fachabteilung und Entwicklung. Verschiedentlich wird auch beschrieben, dass Dieser Irrtum führt manchmal sogar dazu, dass Unterfunktionen nicht nur zu Nutzerzielen erhoben werden, sondern ihnen sogar noch eine eigenständige Zusammenfassungsebene (Drachen) eingeräumt wird. Beispiel für eine falsche Strukturierung: Zusammenfassung (Drachen): Suchen Nutzerziel (Welle): Person nach Name suchen Nutzerziel (Welle): Person nach Alter suchen etc.. Das Problem wird deutlich, wenn wir uns vergegenwärtigen, wie das Projektmanagement das Projekt in kleinere Entwicklungshäppchen aufteilt. Diese Aufteilung orientiert sich häufig an der Zusammenfassungsebene. Zuerst machen wir die Bestandsverwaltung, dann die Partnerverwaltung usw. Wenn nun die Suche ein Paket auf Drachen-Ebene einnimmt, kann es pas-

6 sieren, dass die Suche erst später -oder gar nicht- entwickelt wird. Wir hätten dann möglicherweise unterhalb der Ebene Bestandsverwaltung (Drachen) ein Nutzerziel Vertrag bearbeiten (Welle), das es uns nicht ermöglicht nach einer Person zu suchen, da das Paket Suche (fälschlicherweise auch Drachen) erst für das nächste Release betrachtet wird. Versuchen Sie nun die Suche nachträglich in die Bestandsverwaltung hinzubringen Das wird teuer In diesem Fall spreche ich von Fliegenden Fischen. Die falsche Differenzierung zwischen Nutzerzielen und Unterfunktionen wird zu einem ernsthaften Managementproblem. Und letztendlich bleibt der Nutzer auf der Strecke. So, und nun Hand auf s Herz: Sind Ihre Nutzerziel-Use Cases wirklich immer Nutzerziele? Oder hat sich da auch schon mal eine Unterfunktion in den Vordergrund gedrängelt?

7 Pure Fachlichkeit ist keine Lösung aber ein gutes Problem Use Cases müssen das Problem rein fachlich beschreiben. Vermeintliche Lösungsansätze müssen dabei außen vor bleiben. Use Cases sind das Fundament für die weitere Entwicklung. Hier sind 6 Tipps, wie Sie gute Use Cases schreiben. Im ersten Teil über Use Cases habe ich dargestellt, dass die richtige Differenzierung zwischen Nutzerzielen und Unterfunktionen nicht ganz leicht aber überaus wichtig ist. Erhebt man Unterfunktionen zu vermeintlichen Nutzerzielen, verlieren wir nicht nur den Überblick, das Projektmanagement kann sogar in große Schwierigkeiten geraten. Stellt sich nun die Frage, wie man denn Nutzerziele am besten formuliert. Wie ich schon schrieb, werden da häufig Fehler gemacht. Im Folgenden möchte ich ein paar Tipps geben, wie man diese umgeht. Lösungs-fixiert? In Stellenausschreibungen finden wir immer wieder die Anforderung, der Mitarbeiter solle lösungsorientiert denken und arbeiten. Das klingt zuerst plausibel. Denn schließlich geht es letztendlich darum, ein Problem zu lösen. Bei all der Konzentration auf die Lösung wird aber oft das Problem aus dem Auge verloren. Gerade Techniker neigen dazu, wie aus der Hüfte geschossen eine Lösung zu präsentieren. Da werden schnell Details zu Server-Konfiguration und Kommunikationsprotokollen geliefert. Kunden und Auftraggeber sind oftmals geradezu begeistert, wie schnell das geht. Die vermeintliche Lösung hat schon x-mal funktioniert und so sollte es auch jetzt sein. Klappt schon Wirklich? Dieser Ansatz beeindruckt beizeiten, stellt aber eine sehr wacklige Basis für große Investitionsentscheidungen dar. Mir fehlt da etwas ganz entscheidendes: Das Problem Bevor man mit Lösungen durch die Lande zieht, muss das Problem beschrieben werden. Erst wenn das fachliche Problem allen Beteiligten bekannt ist, kann nach einer Lösung gesucht werden. Und die kann sich er- Bildquelle: Realgrund AG

8 $ lohmeyer heblich von der ersten Schnellschuss-Lösung unterscheiden. Use Cases sind Problem-orientiert Analytiker sollten also vielmehr Problem-orientiert denken und weniger in Lösungen. Ein Problem ist nichts negatives. Analytiker müssen das WAS (Problem) beschreiben und nicht das WIE (Lösung). Und genau an diesem Punkt kommen Use Cases zum Zuge. Sie stellen eine sehr gute Möglichkeit dar, die fachliche Problemlage detailliert festzuhalten. Um das besser zu verstehen, führen wir uns vor Augen, wozu Use Cases da sind. Use Cases beschreiben fachliche Abläufe. Use Cases sind sozusagen die Vertragsgrundlage zwischen Auftraggeber, Fachabteilung und Design / Entwicklung. Use Cases sind das Maß, an dem sich das entwickelte Produkt letztendlich messen lassen muss. Use Cases dienen als Grundlage für einen Test Cases. Use Cases ermöglichen viele Lösungen. 6 Tipps zur Formulierung Im Internet gibt es sehr viele Anleitungen, wie man textliche Use Cases aufbaut. Auch finden sich dort sehr viele Vorlagen. Da es aber nicht nur um die Form sondern vielmehr um den Inhalt geht, vermisse ich konkrete Tipps, wie man das am besten schreibt. Sehen Sie hier wie Sie häufige Fehler vermeiden. 1 Fachlichkeit pur: Denken Sie lösungsunabhängig Das ist auch schon der schwierigste Punkt. Es ist nicht leicht, sich von bekannten Lösungen zu entfernen und die dahinter stehende Fachlichkeit zu beschreiben. Ich erlebe es immer wieder, dass Fachexperten bei der Erstellung von Use Cases die Handhabung der aktuell eingesetzten Software minutiös darlegen. So erfährt man zwar, wie die Bedienung der aktuellen Software Schritt für Schritt erfolgt. Wir lernen aber nicht, was da fachlich abläuft. Lassen Sie mich das an einem Beispiel folgenden Hauptablaufs darstellen: Falsch Lösungsabhängig: 1. Der Aktor klickt links in der Navigation auf Vertrag anlegen. 2. Das System zeigt die Erfassungsmaske Neuen Vertrag anlegen. 3. Der Aktor gibt die Daten ein und klickt auf OK. 4. Das System speichert die Daten. 5. Das System zeigt die Vertragsübersicht an. 6. usw. Wir haben nun eine Schwierigkeit. Dieser Ablauf beschreibt eine konkrete Lösung in einem konkreten User Interface. Es handelt sich dabei mehr um ein Storyboard als einen Use Case. Stellen Sie sich aber vor, die Designer planen als Lösung ein sprachgesteuertes System. Dieser Use Case wäre dann hinfällig, da man in einem sprachgesteuerten System nicht klicken kann. Es gibt auch links keine Navigation, genauso wenig einen Button namens OK. Man könnte diese Ablaufbeschreibung nicht als Basis für einen Test Case verwenden und das sprachgesteuerte System ließe sich nicht an diesem Use Case messen. Die ganze Arbeit wäre für die Katz. Und in Summe wird das richtig teuer. Das kann man aber umgehen. Denken Sie abstrakt. Lösen Sie sich von der Oberfläche. Was liegt hinter dem Ablauf? Oder stellen Sie sich vor, es gäbe noch keine Computer. Wie sieht der Ablauf dann aus?

9 $ lohmeyer Besser Lösungsunabhängig: 1. Der Aktor ruft die Funktion zur Anlage eines Vertrags auf. 2. Das System bietet die Möglichkeit, Vertragsdaten einzugeben. 3. Der Aktor gibt die Vertragsdaten ein und bestätigt die Eingabe. 4. Das System legt den Vertrag mit den angegebenen Daten an. 5. Das System bietet eine Zusammenfassung der erfassten Daten. 6. usw. Sie sehen, wir haben durch eine etwas andere Formulierung den Use Case von jeglichen Oberflächenlösungen befreit. Einen solchen Use Case können Sie auch als Grundlage für ein sprachgesteuertes System verwenden. Sie können aber auch eine Browser-Oberfläche gestalten, oder eine HOST-Anwendung oder, oder, oder Der Use Case bleibt gültig. Auf diese Weise kann sich der Analytiker / Fachexperte auf die Fachlichkeit konzentrieren und die nachfolgenden Designer und Architekten haben alle Freiheiten, eine passende Lösung zu gestalten. Und egal, welche Lösung gewählt wird, das System lässt sich an diesem Use Case messen. Dieser Punkt ist von zentraler Bedeutung und der Grund, warum ich vielen vermeintlichen Use Cases abspreche ein Use Case zu sein. Wenn wir Oberflächenbeschreibungen in einen Use Case reinbringen, handelt es sich um die Beschreibung einer Lösung. Wir können also dann eher von einem Storyboard sprechen. An Storyboards ist nichts auszusetzen. Ich setze sie selbst sehr oft ein. Wir dürfen aber nicht vergessen: Storyboards sind ein Designwerkzeug, kein Analyseinstrument. Beschreiben Sie Basisfunktionen außerhalb Es gibt in jedem System verschiedene Basisfunktionen, die beinahe jeden Use Case betreffen. Das sind beispielsweise: Zugangskontrolle Logging aller Zugriffe und Datenänderungen Fehlerhandhabung 2 Datenvalidierung und Plausibilisierung Systemverhalten bei Abbrechen einer Operation durch den Aktor Diese Basisfunktionen sollten Sie an zentraler Stelle einmal beschreiben. Das kann natürlich auch gerne in Form eines Use Cases geschehen, muss es aber nicht. Das hat den Vorteil, dass man nicht in jedem Use Case auf diese Basisfunktionen eingehen muss. Das erleichtert die Lesbarkeit ungemein. In vielen Systemen muss der Aktor angemeldet sein, um überhaupt arbeiten zu können. Wenn dem so ist, können Sie die Vorbedingung Der Aktor ist am System angemeldet. sparen. Aber: Wenn man in dem zu beschreibenden System viele Dinge auch ohne vorherige Anmeldung machen kann, dürfen Sie auf die Vorbedingung in Use Cases, die eine Anmeldung erfordern, nicht verzichten. Wenn das Logging an zentraler Stelle beschrieben ist, können Sie sich die Nachbedingung Das System hat alle Datenzugriffe und -veränderungen geloggt. sparen. Fehlerhandhabung, Datenvalidierung und das Verhalten beim Abbrechen der Operation blähen die Ablaufbeschreibung und die Ausnahmen häufig sehr stark auf. Wenn Sie das entsprechende Systemverhalten zentral definieren, entlasten Sie die Use Cases und steigern deren Lesbarkeit.

10 $ lohmeyer Vergessen Sie nicht das System im Hauptablauf Häufig lese ich Use Cases, die im Hauptablauf und den Ausnahmen ausschließlich die Schritte des Aktors benennen. Wäre ich gehässig, könnte ich sagen: Prima, wir sind fertig. Das System muss ja nichts machen, da der Aktor alles erledigt. Das ist natürlich nicht der Fall. Bei Use Cases geht es um die Interaktion zwischen dem Nutzer und dem System. Und das, was das System machen muss, ist genau das spannende. Denken Sie an die Benachrichtigung anderer Systeme, Berechnung von Folgeschritten und derartige Operationen, die dem Nutzer verborgen im Hintergrund ablaufen. Wenn diese Schritte nicht im Use Case erwähnt werden, werden sie nicht entwickelt und das System ist somit unbrauchbar. Beschränken Sie den Hauptablauf auf maximal zehn Schritte Die Verständlichkeit von Use Cases hängt in großem Maße davon ab, wie sie in der Gesamtheit strukturiert sind. Auf das Thema Nutzerziel vs. Unterfunktion bin ich schon eingegangen. Losgelöst von dieser Differenzierung gibt es eine Goldene Regel: Ein Use Case mit mehr als zehn Schritten im Hauptablauf ist falsch Das klingt radikal, ist aber eine gute Richtlinie. Sollte der Use Case mehr Schritte umfassen, überprüfen Sie die Granularität. Kann es sein, dass Sie zwei Use Cases in einem beschreiben? Hat sich da eine Unterfunktion eingeschlichen? Trennen Sie den Use Case auf. Das erleichtert es dem Leser sehr. Denn was nicht verstanden wird, wird nicht entwickelt. Validieren statt prüfen, ob Häufig muss das System die Benutzereingaben über die normale Validierung hinaus prüfen und in Abhängigkeit davon spezielle Schritte einschlagen. Man könnte das so schreiben: Hauptablauf: 1. Der Nutzer gibt die Daten ein. 2. Das System prüft, ob die Daten gültig sind: a) Die Daten sind gültig: Das System macht b) Die Daten sind ungültig: Das System macht So entstehen im Hauptablauf Unterabläufe, die schnell verwirren. Überlegen Sie stattdessen, welches der häufigste Fall ist. Nehmen Sie diesen in den Hauptablauf und die nicht so häufigen Fälle in die Rubrik Alternativer Ablauf auf. In dem konkreten Beispiel handelt es sich aber sogar um eine Ausnahme. Besser modelliert man das so: Hauptablauf: 1. Der Nutzer gibt die Daten ein. 2. Das System stellt sicher (validiert), dass die Daten gültig sind. Das System macht das Ausnahmen: zu 2.a) Die Daten sind ungültig: Das System macht jenes $

11 $ $ $ # lohmeyer 6 Vermeiden Sie Datenattribute und zu viele Details Manche Use Case-Autoren meinen es besonders gut und nehmen viele Details in den Use Case auf. Doch das ist kontraproduktiv. Zu detailliert: 1. Der Aktor gibt den Namen ein. 2. Der Aktor gibt den Nachnamen ein. 3. Der Aktor gibt das Geburtsdatum ein. 4. Das ist extrem kleinteilig. Ein Use Case sollte nicht in diese Detailtiefe gehen. Auch eine direkte Auflistung von Fachattributen im Use Case ist nicht sinnvoll. Auch zu detailliert: 1. Der Aktor gibt die Personendaten ein. Dazu gehören: Name, Nachname, Geburtsdatum, Geschlecht Besser: 1. Der Aktor gibt die Kunden- und Vertragsdaten ein. Einerseits reduzieren zu viele Details die Lesbarkeit. Auf der anderen Seite ändern sich Fachattribute auch gerne mal. Sie müssten bei allen auch noch so kleinen Änderungen alle Use Cases durchgehen und die Attribute anpassen. Das ist eine müßige Tätigkeit. Beschreiben Sie die Attribute besser in einem Fachklassenmodell (UML). Das ist aufgrund der grafischen Darstellung übersichtlicher und lässt sich an einer Stelle zentral pflegen. Die folgende Abbildung zeigt ein solches Fachklassenmodell in vereinfachter Form. Versuchen Sie aber mal die darin enthaltenen Informationen textlich im Use Case zu beschreiben. Sie werden sofort sehen, wie viel Text da zusammenkommt. Das wird unverständlich. Beispielhaftes Fachklassenmodell (UML) einer Vertragsverwaltung Fazit Use Cases sind nicht dadurch Use Cases, dass sie einer bestimmten Form folgen. Um ihrem Ziel zu dienen, müssen sie die Fachlichkeit lösungsunabhängig ohne Oberflächenmerkmale beschreiben. Andernfalls verlieren sie spätestens in der Designphase ihre Relevanz und können für spätere Qualitätssicherungsmaßnahmen nicht verwendet werden. Schlimmstenfalls könnte der Auftraggeber sogar die Abnahme des fertigen Produkts verweigern, da es mit größter Wahrscheinlichkeit mit den ursprünglichen (oberflächen-lastigen) Use Cases nicht mehr in Deckung zu bringen ist. Jetzt sollte klar geworden sein, warum ein Use Cases keine Lösung ist. Stattdessen liefert er ein gut beschriebenes Problem. Es gibt noch viele Dinge bei der Use Case- Beschreibung zu bedenken. Auch wenn das Schema denkbar einfach ist, bedarf es einiger Übung, Use Cases zielführend zu entwickeln. Welche Tipps haben Sie zu Use Cases? Lassen Sie uns Ihre Ideen diskutieren.

12 Bernd Lohmeyer Gerhart-Hauptmann-Str Wedel tel mail web Wir können uns auf das Fachliche konzentrieren, und die IT versteht besser, was wir brauchen. Hans Günther Mattern, Referatsleiter für Ausländerrecht, Auswärtiges Amt Impressum Angaben gemäß 5 TMG: Bernd Lohmeyer Gerhart-Hauptmann-Str Wedel