Beiträge

Use Cases Next Level: White Paper II zum Download

Dieses zweite White Paper beleuchtet weitere Aspekte der Use Cases: Bedingungen innerhalb von Use Case-Schritten und Ausnahmen vs. Alternativen.

Nachdem ich in einem ersten White Paper beschrieben habe, wie man Use Cases am besten strukturiert und formuliert, möchte ich nun darstellen, wie man mit komplexen Geschäftsregeln und Bedingungen umgeht. Und das führt uns dann direkt zu der Unterscheidung zwischen Ausnahmen und Alternativen. Diese Unterscheidung wird leider selten vorgenommen. Dabei ist sie recht einfach und hilft dem Leser ungemein.

Das White Paper beantwortet zwei Fragen:

  • Wie gehe ich mit Bedingungen in Use Cases um?
  • Wann beschreibe ich eine Ausnahme, und wann eine Alternative?

Weiterlesen

Teile diesen Beitrag:

Use Cases richtig schreiben: White Paper zum Download

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.

Use Cases richtig schreiben

Das Thema Use Cases begegnet uns in unseren Projekten immer wieder. Leider gibt es darum häufig viel Ärger und Missverständnisse: Die Menge der Use Cases ufert aus und wird unübersichtlich. Viele Use Cases sind unverständlich geschrieben und werden schlichtweg nicht gelesen.

Das muss nicht sein! Ich habe ein White Paper erstellt, indem ich Antworten gebe auf die folgenden Fragen: Weiterlesen

Teile diesen Beitrag:

Writing Use Cases: Avoid IF THEN in use case steps

Checking conditions within a use case step blows out the success scenario. The use case is hard to understand. Instead relocate conditions and their actions to exceptions or alternate flows.

When it comes to use cases I often read success scenarios describing lots of conditions.

The use case goes like this:

Teile diesen Beitrag:

Tool Set für Fachspezifikation: Alles von Anforderungen bis Aktivitäten

Eine Fachspezifikation beschreibt die fachlichen Anforderungen und Probleme, die es in einem Projekt zu lösen gilt. Es ist nicht notwendigerweise ein einziges großes Dokument. Ganz im Gegenteil: Es ist sehr viel sinnvoller, die verschiedenen Aspekte in unterschiedlichen Dokumenten und Modellen zu beschreiben.

Im Folgenden möchte ich eine Werkzeugpalette vorstellen, die meines Erachtens alle Mittel bereitstellt, um auch komplexe Zusammenhänge verständlich zu beschreiben. Es ist eine Kombination aus Textdokumenten, BPMN und UML. Wenn ich sage „verständlich beschreiben“, meine ich, dass die Dokumentation von den Projektbeteiligten verstanden werden muss. Das schließt die Auftraggeber und Fachabteilung gleichermaßen ein wie Designer und IT-Architekten. Denn nur, was verstanden wird, kann auch umgesetzt werden. Fehlt es an einer breiten Verständnisbasis, sind einerseits die Ziele unklar. Andererseits wäre es somit purer Zufall, wenn die Projektergebnisse (z.B. eine Software-Lösung) die ursprünglich erhobenen Anforderungen erfüllen.

Die folgenden Modelle und Dokumente müssen nicht in der hier vorgestellten Reihenfolge erstellt werden. Sie entstehen häufig parallel. Bei der Arbeit an einem Teil ergeben sich Aspekte, die Auswirkungen auf andere Modelle / Dokumente haben. Und nicht immer braucht man in jedem Projekt alle hier beschriebenen Artefakte. Man muss also immer wieder prüfen, was wirklich erforderlich ist. Es gilt: So wenig wie möglich, so viel wie nötig. Weiterlesen

Teile diesen Beitrag:

Use Cases Teil 1: Nutzerziele und fliegende Fische

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 (Use Cases 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. Weiterlesen

Teile diesen Beitrag:

Use Cases Teil 2: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem

Im ersten Teil über Use Cases habe ich dargestellt, dass die richtige Differenzierung zwischen Nutzerzielen und Unterfunktionen nicht ganz leicht aber überaus wichtig ist (Use Cases Teil 1: Nutzerziele und fliegende Fische). Erhebt man Unterfunktionen zu vermeintlichen Nutzerzielen, verlieren wir nicht nur den Überblick, das Projektmanagement kann sogar in große Schwierigkeiten geraten.

Da uns dies (hoffentlich) nicht mehr vorkommt, 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?

Weiterlesen

Teile diesen Beitrag:

Ohne UML in die Word-Falle

Über das Management in der UML-Falle habe ich bereits geschrieben. In dem Artikel habe ich darzustellen versucht, dass es eine große Gefahr birgt, wenn man sich in großen Projekten im Rahmen einer Spezifikation auf die Erstellung von UML-Diagrammen beschränkt und auf detaillierte textliche Erklärungen verzichtet. Man hat zwar schöne Fachklassen- und Use Case Diagramme, die gute Übersichten liefern. Die fachlichen Details – und die sind spätestens für die Entwickler unverzichtbar – gehen aber verloren.

Das andere Extrem

Doch es gibt auch das andere Extrem: den Versuch einer kompletten Fachspezifikationen in einem einzigen Dokument. Und das auch noch ohne grafische Übersichten.

Weiterlesen

Teile diesen Beitrag:

Management in der UML-Falle

Der Titel ist provokant. Das ist mir bewusst. Ich möchte zeigen, dass der unreflektierte Glaube in UML-Modelle zu einem echten Problem im Projekt führen kann. Und das droht besonders bei einem zeitlich engen Projektplan. Also genau dann, wenn man geneigt ist, es bei UML-Diagrammen zu belassen.

Der Werkzeugkasten UML

Die Unified Modelling Language –kurz UML- ist an sich gar nicht schlecht. Ganz im Gegenteil. Sie fasst verschiedene grafische Werkzeuge und Notationen für die Spezifikation von Software zusammen. Dazu gehören sehr unterschiedliche Diagrammtypen wie beispielsweise Aktivitäts- und Sequenzdiagramme zur grafischen Darstellung von Abläufen oder unterschiedliche Klassenmodelle zur Zerlegung der realen Welt in handhabbare Objekte. Und wie das bei Modellen eben so ist, haben sie Vor- und Nachteile. Einerseits machen sie die schier unvorstellbare Komplexität der echten Welt fassbar, andererseits laufen sie aber auch Gefahr, die Realität zu sehr zu vereinfachen oder zu oberflächlich zu betrachten. Wie hilfreich ein Modell wirklich ist, hängt letztlich von dem Modellierer ab – und der Fähigkeit des Empfängers, es richtig zu lesen und zu interpretieren.

Weiterlesen

Teile diesen Beitrag:

Storyboards: Eine Erfolgsgeschichte

Was sind Storyboards?

Storyboards sind Geschichtenbretter – jedenfalls wörtlich übersetzt. Ok, wir malen die nicht auf Holz. Storyboards beschreiben die Umsetzung eines fachlichen Anwendungsfalls in eine konkrete Software-Benutzeroberfläche. Beschreibt ein Anwendungsfall (Use Case) die rein fachlichen Abläufe (z.B. Anlegen eines Kontos), so beschreibt das entsprechende Storyboard, wie das in der Software-Oberfläche vor sich geht.

Herkunft

Storyboards verbindet man eher mit der Erstellung von Trickfilmen oder der Planung von Werbespots. Verschiedene Scribbles (flüchtige Skizzen) werden mit Pfeilen und Symbolen miteinander verbunden. Ziel ist es, eine Geschichte zu erzählen und den Ablauf der Geschichte zu verdeutlichen. Nun, da hat die gute alte IT-Welt mal von so neumodischem Kram wie Zeichentrick und Werbung gelernt. Wobei ich mir jetzt gar nicht so sicher bin, ob Storyboards nicht schon viel früher im Filmgeschäft eingesetzt wurden. Das Ziel sollte dasselbe gewesen sein: eine Geschichte erzählen. Wie dem auch sei, die Storyboards haben in die IT Einzug gehalten. Weiterlesen

Teile diesen Beitrag: