Analyse & Design
Last updated
Last updated
Was versteht ihr unter Analyse & Design?
Wer hat schon an Kundensoftware gearbeitet?
Analyse: WAS muss das System können? Design: WIE soll das System gebaut werden?
Wie wir bereits gestern besprochen haben, ist eines der essentiellen Aufgaben, zu verstehen, was der Kunde oder die Kundin wirklich möchte.
In der Anforderungsanalyse findet aber bereits sehr viel Kommunikation statt. Es gibt Diskussionen, grobe Besprechungen in Workshops, Interviews oder sogar Beobachtung von Endbenutzern am Arbeitsplatz. Das alles muss auch dokumentiert sein.
Nun geht es darum, Anforderungen von Kunden zu analysieren und in Formen zu bringen bzw. so Abzubilden, wie sie uns für die Umsetzung möglichst nützlich sind. Dafür gibt es zahlreiche Tools und Methoden.
Eine Möglichkeit, um sehr schnell und abstrakt einen Überblick über die Anforderungen zu erhalten, ist das UML Use Case Diagramm.
Dieses Use Case Diagramm zeigt die Use Cases eines Online Shops, der zwei verschiedene Anwendertypen hat. Ein Verkäufer, der Artikel erfasst und Bestellungen verarbeitet und einen Kunden, welcher Artikel auswählt und bestellt.
Ein Use Case Diagramm stellt keine Logik dar, z.B. dass der Kunde zuerst Artikel auswählen muss, bevor er eine Bestellung abschicken kann. Darum geht es aber auch nicht im Use Case Diagramm. Es geht nur darum, schnell einen Überblick über die Funktionen einer Software zu erhalten.
"User Stories beschreiben die Anforderungen an ein Produkt oder Service aus Sicht des Nutzers. Als Format ist die User Story ein zentrales Werkzeug in der Zusammenarbeit agiler Teams. Ihr Einsatzgebiet reicht von der Validierung von Kundenbedürfnissen bis zur Anforderungsformulierung in Scrum Teams." - Andreas Diehl
User Stories sind einerseits dazu da, die Kundenbedürfnisse / Anforderungen abzubilden, dienen zugleich aber auch als Arbeitspakete für die Entwickler, und können durch Aufwandschätzung auch als Basis einer Offerte dienen. Das macht sie sehr wertvoll.
User Stories (dt. Nutzer- oder Anwendererzählung) haben ihren Ursprung in der agilen Softwareentwicklung. Im Gegensatz zu einer klassischen Spezifikation beschreibt die User Story ausschließlich die Erwartungen des Nutzers an die Funktionalität einer Software und nicht etwa WIE die Anforderung umzusetzen ist.
Heute sind User Stories auch über die Softwareentwicklung hinaus eines der zentralen Werkzeuge, um Anforderungen zu formulieren und zu diskutieren. Dabei bilden mehrere User Stories gemeinsam einen Use Case.
Der User Case ist wiederum, was wir im Use Case Diagramm modellierten.
Die Beschreibung einer User Story ist wie folgt aufgebaut:
Als <Nutzer> möchte ich <Funktion>, um <Wert>
Das heißt, eine User Story beantwortet die Fragen WER möchte WAS und WARUM. Lass uns auf die drei Bestandteile im Einzelnen schauen.
Wie detailliert Du den Platzhalter <Nutzer> füllst, ist von der User Story selbst, aber auch von der Reife deines Vorhabens abhängig. Für den passenden Detaillierungsgrad gibt es kein richtig oder falsch. Das Wichtigste ist, dass für Dich und dein Team mit dem gewählten <Nutzer> eine für Dich aussagekräftige User Story entsteht.
Den Platzhalter <Funktion> ersetzt Du mit der Erwartung, den Zielen und Wünschen des <Nutzers>. Damit beantwortest Du die Frage, WAS der Kunde braucht und erwartet. Wenn du bereits ein Produkt am Markt anbietest, erhältst Du sicher viele gewünschte Funktionen direkt vom Nutzer. In früheren Phasen deines Projektes kannst Du basierend auf deiner Erfahrung Annahmen formulieren, welche <Funktion> der <Nutzer> erwartet.
Der Platzhalter <Wert> beantwortet die Frage nach dem WARUM. Auch wenn der Satzbau dazu verleitet diesen Nebensatz weg zu lassen, ist eine User Story ohne diesen Zusatz nicht komplett.
Das heißt, erst mit dem <Wert> bringst Du zum Ausdruck, warum die Erreichung der <Funktion> für den <Nutzer> überhaupt wichtig ist und welchen Mehrwert die Erfüllung der User Story schafft. Spätestens an dieser Stelle bietet Dir die User Story eine ehrliche Reflektion, wie gut Du Dich bereits mit den Anforderungen deiner Kunden auseinander gesetzt hast. Anforderungen aufzunehmen ist einfach (z.B. weil der Kunde nach einer Funktion schreit). Zu verstehen warum es für ihn wichtig ist, gibt Dir und deinem Team aber erst den notwendigen Kontext.
In der Praxis trifft man meist auf User Stories, die nebst der Beschreibung nach dem obigen Schema auch Abnahmekriterien (auch Akzeptanzkriterien oder Acceptance Criteria genannt) definiert haben. Sie dienen dazu, während eines Sprints die Story als "Abgeschlossen" anzuschauen, nämlich dann, wenn die Punkte unter Abnahmekriterien alle zutreffen.
Beispiel:
Die Abnahmekriterien können teilweise etwas das "WIE" (Design) beschreiben, denn sie werden meist erst kurz vor der Umsetzung verfasst, wenn mehr technische Informationen vorhanden sind. Das ist der Moment, in dem die User Story auch als Arbeitspaket verwendet werden kann.
Wenn ein Entwickler eine Story für sich abgeschlossen hat, wird im Code Review meist auch auf die Abnahmekriterien eingegangen, um zu sehen, ob die Story auch wirklich abgeschlossen ist.
Es ist wichtig, Funktionalität in einer guten Granularität auf User Stories aufzuteilen. Eine User Story pro Funktionalität.
Ist Beispielsweise ein Login in einem System gewünscht, in welchem man auch gleich einen neuen Benutzer hinzufügen kann und das Passwort zurücksetzen kann, wenn man es vergessen hat, macht es keinen Sinn, das alles in eine User Story zu packen.
Hier könnte man Beispielsweise drei User Stories erstellen:
Story 1: Login Als registrierter Benutzer möchte ich mich im System einloggen können, damit ich das System mit meinen Berechtigungen verwenden kann.
Story 2: Passwort Vergessen Als registrierter Benutzer möchte ich mein Passwort zurücksetzen können, damit ich das System weiterhin verwenden kann, wenn ich das Passwort vergessen habe.
Story 3: Benutzer Erstellen Als nicht registrierter Benutzer möchte ich ein Benutzerkonto erstellen, damit ich mich im System einloggen kann.
Das macht auch später für die Umsetzung Sinn. Gibt es mehrere Entwickler im Team, könnten diese drei Stories parallel entwickelt werden.
Wie auch das Use Case Diagramm, ist das Aktivitätsdiagramm ein UML Diagramm.
Aktivitätsdiagramme sind eine Möglichkeit, um Programmabläufe zu dokumentieren. Diese Diagrammart wird nun kurz vorgestellt:
Die Ausführung einer Aktivität beginnt beim Startknoten und endet beim Endknoten (Eselsbrücke: wie eine Zielscheibe). Es sind auch mehrere Endknoten möglich.
Der wichtigste Baustein im Aktivitätsdiagramm ist die Aktion, als Rechteck mit abgerundeten Ecken dargestellt. Aktionen stellen die einzelnen Schritte dar, aus denen eine Aktivität besteht. Man könnte sagen, sie sind die kleinste, nicht mehr zerlegbare Einheit einer Aktivität.
Alle Aktionen zusammengenommen stellen einen schrittweisen Ablauf dar wie etwa den eines Use-Case oder einer Funktion (oder einer User Story). Im Rechteck mit den abgerundeten Ecken wird jeweils eine kurze Beschreibung der Aktion angegeben. Diese Beschreibung sollte wie bei Use-Cases kurz, knapp und präzise sein.
Verzweigungen ermöglichen es je nach Situation als nächsten Schritt verschiedene Aktionen auszuführen. Die Bedingung für die jeweilige Verzweigung kann direkt auf den entsprechenden Pfeil geschrieben werden (sh. Beispiel im nächsten Slide).
Eine Gabelung synchronisiert zwei oder mehrere separate Pfade (oder teilt sie).
Zu was für einem Use Case könnte dieses Aktivitätsdiagramm gehören?
Wie könnte eine User Story dazu und die dazugehörigen Abnahmekriterien aussehen?
Kommunikation ist alles! Wenn der Kunde von Anfang an miteinbezogen wird und durch eine auch in jedem Schritt beteiligt ist, sind Missverständnisse viel unwahrscheinlicher oder können schon sehr früh aus dem Weg geräumt werden.
Nachfolgende Texte sind (z.T, leicht angepasste) Ausschnitte aus dem Artikel:
Den Platzhalter <Nutzer> füllst Du mit Rollen bzw. deinen Personas. Eine . Die Rolle des Nutzers kann auch durch den jeweiligen Kontext definiert sein. So kann die gleiche Rolle z.B. für unterschiedliche Personas gelten und das Verhältnis zu deinem Produkt beschreiben.
Quelle:
