it-swarm.com.de

Was ist der Unterschied zwischen "Anwendungsfall", "User Story" und "Nutzungsszenario"?

Gibt es eine genaue, aber einfache und verständliche Definition der Unterscheidung zwischen "Anwendungsfall", "User Story" und "Nutzungsszenario"?

es gibt eine ganze Reihe von Erklärungen, aber im Moment sehe ich niemanden, der die Unterschiede in einem oder zwei Sätzen erklärt ...

(z. B. http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison sehr lang und schwer zu bekommen, voller Diskussionen)

44
Henning

A ser Story ist eine informellere, freundlichere und kleinere Version von se Case abzüglich des UML-Diagramms. Es wird normalerweise in iterativen Szenarien verwendet.

A Verwendungsszenario ist ein Anwendungsfall, der in einer schrittweisen Prozedur dargestellt wird, manchmal begleitet von einem Flussdiagramm.

21
Robert Harvey

Für mich sind die größten Unterschiede zwischen einer User Story und einem Anwendungsfall:

  • Eine User Story ist ein Lightweight Dokument, das auf eine Karte geschrieben werden kann (Um als wollen ). Eine User Story erfasst nicht alle Details, sondern ist eine informelle Unterstützung für die Diskussion.
  • Ein Anwendungsfall ist ein Schwergewicht Dokument, das ein Word-Dokument benötigt. Es beschreibt einen "normalen Ablauf" von Schritten und/oder Aktionen und "alternativen Ablaufabläufen", die detailliert beschrieben werden. Ein Anwendungsfall erfasst alle Details, es ist eine formale Spezifikation.

Laut Scott W. Ambler über Verwendungsszenarien sehen diese Artefakte wie der Ablauf eines Anwendungsfalls aus:

Ein Nutzungsszenario oder kurz Szenario beschreibt ein reales Beispiel dafür, wie eine oder mehrere Personen oder Organisationen mit einem System interagieren. Sie beschreiben die Schritte, Ereignisse und/oder Aktionen, die während der Interaktion auftreten. Verwendungsszenarien können sehr detailliert sein und genau angeben, wie jemand mit der Benutzeroberfläche arbeitet, oder auf einer relativ hohen Ebene die kritischen Geschäftsaktionen beschreiben, nicht jedoch, wie sie ausgeführt werden.

Ehrlich gesagt sind die Unterschiede zum Ablauf eines Anwendungsfalls selbst nach dem Lesen dieses Absatzes nicht ganz klar (der letzte Satz ist vielleicht der wichtigste):

Wie Sie sich vorstellen können, gibt es verschiedene Unterschiede zwischen Anwendungsfällen und Szenarien. Erstens bezieht sich ein Anwendungsfall normalerweise auf allgemeine Akteure wie den Kunden, während sich Szenarien typischerweise auf Beispiele der Akteure wie John Smith und Sally Jones beziehen. Nichts hindert Sie daran, ein allgemeines Szenario zu schreiben, aber es ist normalerweise besser, die Szenarien zu personalisieren, um ihre Verständlichkeit zu verbessern. Zweitens beschreiben Verwendungsszenarien einen einzelnen Pfad der Logik, während Anwendungsfälle normalerweise mehrere Pfade beschreiben (den Grundkurs plus alle geeigneten alternativen Pfade). Drittens werden in UP-basierten Prozessen Anwendungsfälle häufig als offizielle Dokumentation beibehalten, während Szenarien häufig verworfen werden, nachdem sie nicht mehr benötigt werden.

Ich kann mich irren, aber das Nutzungsszenario klingt wirklich wie ein Anwendungsfallfluss, wurde jedoch mit einem agilen Touch umbenannt.

20
Pascal Thivent

Eine User Story ist immer informell und beschreibt die Bedürfnisse eines Benutzers. Ein Anwendungsfall kann entweder formell oder informell sein und beschreibt das Systemverhalten.

Es ist möglich, "Tech" -Nutzergeschichten zu haben, dies gilt nicht für Anwendungsfälle.

Sobald dies erledigt ist, wird die User Story normalerweise verworfen. Anwendungsfälle können während des Produktlebenszyklus beibehalten werden.

Der Umfang ist auch anders. User Stories sind in der Regel kleiner und folglich umfasst ein Anwendungsfall mehrere User Stories. Eine geänderte Anforderung für ein vorhandenes System wird in einer neuen User Story oder einer aktualisierten Version des Anwendungsfalls beschrieben.

Die Ähnlichkeit zwischen User Stories und Anwendungsfällen besteht darin, dass beide für die Planung und Terminierung verwendet werden.

3
user249665

Es gibt keine genaue Definition für irgendetwas davon. Es variiert alles ein wenig (oder sehr) von Unternehmen zu Unternehmen und von System zu System.

Am besten finden Sie ein Beispiel für Ihr aktuelles Projekt und folgen ihm.

Wenn Sie ein neues System erstellen, finden Sie Definitionen für verschiedene Arten von Anwendungsfällen für jedes System, das Sie bevorzugen. Wählen Sie einfach das Muster aus, das Ihre Absichten am besten zu kommunizieren scheint.

Lass dich nicht auf Namen ein.

3
Bill K

Eine User Story kann, wenn sie in Aufgaben zerlegt wird, die Entwicklern individuell zugewiesen werden können, detaillierter und nicht eingeschränkter sein als ein Anwendungsfallszenario. In einer User Story geht es um die Bedürfnisse des Benutzers - ein Ziel oder ein Ergebnis seiner Nutzung des Systems.

Beispiele für User Stories sind:

  1. Ich bin Kunde und möchte meinen Kontostand online bezahlen - eine ziemlich hochrangige Ansicht
  2. Ich bin Kunde und möchte das Ablaufjahr meiner gespeicherten Kreditinformationen aktualisieren - eine ziemlich detaillierte Ansicht.

Auf der höchsten Abstraktionsebene klingt ein Anwendungsfall sehr ähnlich - Ablaufdatum der Kundenaktualisierungskarte -, aber hier ist er eher eine Funktionserklärung als ein Ziel.

Wenn die Granularität der Anwendungsfallszenarien definiert wird, geht es mehr um Funktion und Vorgehensweise.

Die Nachbedingung eines Anwendungsfall-Hauptszenarios sollte das gleiche Ergebnis sein wie in der User Story angegeben - Das Ablaufjahr der Kreditkarte des Kunden wird aktualisiert.

Anwendungsfallszenarien beschreiben Schritt für Schritt entweder im Text oder im Prozessflussdiagramm (nicht unbedingt UML oder BPM - Ich verwende ein standardmäßiges funktionsübergreifendes Flussdiagramm, um ungeschulten Verbrauchern des Anwendungsfalls Klarheit und Benutzerfreundlichkeit zu bieten.

Unter dem Strich beschreiben User Stories Anforderungen und Ergebnisse (was das System liefern muss), während Use Cases Interaktionen zwischen Akteuren beschreiben, die zur Erreichung des Ziels erforderlich sind - UND was schief gehen kann (Erweiterungs-, Alternativ- oder Fehlerszenarien) (wie der Benutzer interagiert) das System erreicht dieses Ergebnis)

Für eine eingehende Diskussion zu diesem Thema empfehle ich, http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison auf der Website von Alistair Cockburn zu lesen. Da er das Agile Manifest unterzeichnet hat, der User Stories geprägt hat und in den letzten Jahrzehnten als Use-Case-Experte gilt, ist er meiner Meinung nach eine hervorragende Quelle für weitere Informationen.

1
jon karpoff

Kurzer vorübergehender Hinweis : Dieser Beitrag muss verbessert werden, um die Frage besser beantworten zu können, z. B. 1) zusätzliche Details sollten aus Referenzen 2) einige Zitate möglicherweise 3) allgemeine Korrektheit des Englischen 4) allgemeine Qualität der Erzählung 5) usw. Ich werde darauf zurückkommen. Fühlen Sie sich frei, es selbst zu verbessern.


Ein Blick auf ihre Vorlagen kann wertvolle Einblicke in die Unterschiede zwischen diesen Begriffen geben.

Anwendungsfall

Es gibt mehrere Vorlagen für Anwendungsfälle. Ich fand 3 nach einer schnellen Suche: 1 , 2 , . Einige Punkte, die sie (manchmal vage) gemeinsam haben, sind:

  1. Name des Anwendungsfalls/Titels
  2. Beschreibung - ein kurzer Text, der den Umfang beschreibt.
  3. Schauspieler/Hauptdarsteller - Person (en), die mit diesem speziellen Anwendungsfall interagieren.
  4. Voraussetzung - alles, was dieser Anwendungsfall vor Beginn seines Lebenszyklus als wahr annehmen kann.
  5. Erfolgsszenario - eine Schrittfolge, die den korrekten Ablauf der Ereignisse beschreibt.
  6. Erweiterungen - Anwendungsfluss, wenn er vom Ablauf des Erfolgsszenarios abweicht:

    1. Alternative Flüsse - andere Optionen für den richtigen Fluss
    2. Ausnahmeflüsse - Ereignisfluss, wenn etwas schief geht
  7. Erfolgsgarantie (aka. Post-Bedingung) - Anwendungsstatus, nachdem alles erledigt ist

Einige zusätzliche Punkte, die aufgenommen werden können, sind Level , Minimale Garantien , Trigger usw.

Oben ist der sogenannte vollständig gekleidete Anwendungsfall . Sie können die Erstellung von Anwendungsfällen vereinfachen, indem Sie einen gelegentlichen Anwendungsfall verwenden, indem Sie nur die wichtigsten Punkte verwenden, zum Beispiel:

  1. Titel
  2. Schauspieler
  3. Reihenfolge der Ereignisse

Anwendungsfälle wurden von Ivar Jacobson Ende der 80er und Anfang der 90er Jahre erstellt und populär gemacht. Später haben auch andere Leute zu seiner Arbeit beigetragen (einer dieser Leute ist Alistair Cockburn, der Autor von Writing Effective Use Cases ). To mschreibt Martin Fowler Anwendungsfälle können Text und UML-Diagramme verwenden, aber ihr größter Wert liegt im Text davon. Sie sind am besten, wenn sie nicht groß und leicht zu lesen sind.

ser Story (aka. Feature)

User Story - eine kleine Story, die eine bestimmte Funktion beschreibt. Es gibt ein allgemeines Muster für das Schreiben einer User Story:

Als bestimmter Typ eines Benutzers
Ich möchte etwas tun
so dass ein Grund.

Darüber hinaus kann User Story Akzeptanzkriterien haben.

Wie Sie sehen können, ist diese Vorlage viel kleiner als die des Anwendungsfalls. User Stories werden häufig mit der Scrum/Agile/XP-Region der Softwareentwicklung in Verbindung gebracht. Sie sollen auf kleinen Oberflächenbereichen wie Haftnotizen und/oder auf Scrum-Boards geschrieben werden. Dort erhalten sie (normalerweise) Punktwerte, die ungefähr angeben, wie viel Aufwand in diese User Story investiert werden muss ref.

Bill Wake entwickelte INVEST mnemonic , um zu beschreiben, welche Eigenschaften eine gute User Story haben sollte, und ich werde sie ausleihen Martin Fowlers kurze Zusammenfassung davon von seiner Website :

Unabhängig : Die Geschichten können in beliebiger Reihenfolge geliefert werden
Verhandelbar : Die Details der Geschichte werden von den Programmierern und dem Kunden während der Entwicklung gemeinsam erstellt.
Wertvoll : Die Funktionalität wird von den Kunden oder Benutzern der Software als wertvoll angesehen.
Schätzbar : Die Programmierer können eine vernünftige Schätzung für die Erstellung der Geschichte erstellen
Klein : Geschichten sollten in kurzer Zeit erstellt werden, normalerweise eine Frage von Personentagen. Natürlich sollten Sie in der Lage sein, mehrere Storys in einer Iteration zu erstellen.
Testbar : Sie sollten in der Lage sein, Tests zu schreiben, um zu überprüfen, ob die Software für diese Geschichte ordnungsgemäß funktioniert.

Nutzungsszenario

Das Verwendungsszenario folgt dem GWT-Muster, das für Given-When-Then steht, wie folgt:

Szenario : Titel
Gegeben : eine bestimmte Tatsache
Und : eine weitere besondere Tatsache (kann optional sein)
Wenn : ein Ereignis passiert
Dann : ein anderes Ereignis passiert

Nutzungsszenarien sind mit verhaltensgesteuerter Entwicklung verbunden. Es klingt einem Test sehr ähnlich. Martin Fowler in seinem Blog-Beitrag gibt einen Überblick über die Geschichte und die Gründe für Nutzungsszenarien. Hier ist der wichtige Teil:

Der angegebene Teil beschreibt den Zustand der Welt, bevor Sie mit dem in diesem Szenario angegebenen Verhalten beginnen. Sie können sich das als Voraussetzung für den Test vorstellen.
Der Abschnitt when ist das Verhalten, das Sie angeben.
Schließlich beschreibt der Abschnitt then die Änderungen, die Sie aufgrund des angegebenen Verhaltens erwarten.

Verwendungsszenarien können zum Schreiben von Tests für Ihre Anwendung verwendet werden. Um den letzten Absatz von Martins Beitrag zu zitieren:

Obwohl der Given-When-Then-Stil für BDD symptomatisch ist, ist die Grundidee ziemlich häufig, wenn Tests oder Spezifikationen anhand von Beispielen geschrieben werden. Meszaros beschreibt das Muster als Vierphasentest. Seine vier Phasen sind Setup (gegeben), Übung (wann), Verifizieren (dann) und Abreißen. Bill Wake kam mit der Formulierung als Arrange, Act, Assert.


Referenzen für weitere Studien:

Wikipedia-Seiten für Anwendungsfall , ser Story , Nutzungsszenario
Martin Fowlers Blogs über Anwendungsfall , ser Story , Anwendungsszenario

1
wha7ever

Der Zweck des Verwendungsszenarios besteht darin, die Essenz der Benutzerinteraktion mit Ihrem System zur Erreichung eines Ziels zu erfassen, ohne auf die Details der Systemaktionen oder das tatsächliche Design einzugehen. Der Fokus liegt auf dem Benutzer, nicht auf dem System.

... Der Anwendungsfall enthält auch Aussagen darüber, was das System tun wird, während das Verwendungsszenario diese Diskussion vermeidet.

Sie haben noch nicht festgelegt, wie Sie es implementieren möchten.

Von der Produktkunst Seite.

0
Daniel

"Anwendungsfall" und "User Story" sind in dem Sinne identisch, dass sie "Anforderungen" des Kunden darstellen.

Anwendungsfall ist die Art und Weise, wie das System jeweils verwendet wird, normalerweise dargestellt als Interaktion zwischen Akteur und System oder zwischen Systemen.

User Story ist der Ausgangspunkt auf dem Weg zur Erstellung eines computergestützten Tools, mit dem Endbenutzer etwas erledigen können. Normalerweise beginnt sie mit einem einfachen Satz, in dem verwendet wird, wer, was, warum ("Als Benutzer, der die Anwendung schließt, möchte ich aufgefordert werden, alles zu speichern, was sich seit dem letzten Speichern geändert hat, damit ich nützliche Arbeit bewahren und fehlerhafte Arbeit verwerfen kann. "). Diese User Story muss dann zu einem Anwendungsfall verarbeitet werden, den Entwickler zum Erstellen einer Anwendung und Tester zum Durchführen von Tests verwenden.

Aus der Sicht eines QS-Testers testen sie keine "User Stories", sondern "Use Cases", dh sie testen Softwarefunktionen.

0
Kate

Ich bin mit User Story nicht vertraut, aber als ich mich vor einigen Jahren damit befasste:

Ein Anwendungsfall ist eine wichtige Aufgabe.
Benutzerszenarien sind die verschiedenen Möglichkeiten, wie Aufgaben ausgeführt werden können. Jeder Anwendungsfall hat also ein oder mehrere Szenarien. Der Anwendungsfall ist die Zusammenfassung. Die Benutzerszenarien sind ein Katalog aller möglichen Instanzen dieser abstrakten Aufgabe.

Damit:
Anwendungsfall A: Benutzer authentifiziert sich mit ID und Passwort.

Szenarien:
1. ID wird erkannt, Passwort ist korrekt. (Szenario "sonniger Tag")
2. ID wird erkannt, Passwort ist falsch.
3. ID wird erkannt, Passwort ist zum dritten Mal falsch.
4. ID wird nicht erkannt.

Ich habe immer an Anwendungsfälle gedacht, um Anforderungen für den Kunden in ihren Begriffen narrativ zu definieren. Wenn der Client oben sagt: "Aber was ist, wenn er versucht, sich zwischen Mitternacht und einem bei Systemausfall anzumelden?", haben wir ein anderes Szenario für die Authentifizierungsaufgabe und einige zusätzliche Anforderungen entdeckt.

0
cvsdave

Eine User Story ist aus Kundensicht, manchmal falsch oder unvollständig. Möglicherweise wird die Leistung, die Fehlerbehandlung oder nichts im Backend berücksichtigt.

Ein Anwendungsfall ist aus der Sicht von dev. Es ist genau und vollständig. Es sollte alle Anforderungen der Kunden erfüllen.

0
Dan