Verstandene Anforderungen für jedermann!

Eine Preisfrage: User Story oder Use Case verwenden?

By am Apr 3, 2019 in Das kleinen Einmaleins der Anforderung, Glossar | 0 comments

Wann sollte man User Stories einsetzen und was ist der Unterschied zwischen beiden?

Vorweg:
Weder User Stories noch Use Cases sind Anforderungen. Vielmehr sind es Arbeitspakete, die beispielsweise in einem Sprint umgesetzt werden können. Aus Use Cases beziehungsweise User Stories können Anforderungen abgeleitet werden.


User Stories sind flexibel und flüchtig

Geeignet für (die Zeit der Innovation…):

  • Anforderungen an einen Prototypen dokumentieren
  • temporäre Dokumentation
  • ständige Änderung von funktionalen Anforderungen 

Nicht geeignet für:

  • Sobald es ein Release (fertige Version, die der Kunde bezahlt) gibt, sind User Stories bedingt geeignet, da keine Aktivitäten/Szenarien hinterlegt sind.

Problem: Falls nur User Stories eingesetzt werden, wird das System im Laufe der Zeit unverständlich und ist zu einem bestimmten Zeitpunkt – ohne Nachbereiten  – nicht mehr wartbar. 

  • Im Laufe der Zeit gibt es mehr und mehr Releases. Das System wird immer schwerer zu durchschauen, weil die Dokumentation fehlt, beziehungsweise die User Stories nicht aktuell sind. Die Wartung und neue Releases werden schwieriger, da das BigPicture 360° verloren geht.
  • Bei einer Systemablösung droht das Chaos – keiner weiß irgendwas und es muss Systemarchäologie betrieben werden.

CCC-Prinzip (Ron Jefferies, 2001)

Card:

  • Karte selbst zum Anfassen und Bewegen
  • Planungsartefakt

Conversation: 

  • Die Story soll den Dialog anstoßen (Team, Product Owner, Kunden, Tester, etc.

Confirmation: 

  • Akzeptanzkriterien zum Nachweis, dass die Ziele der Story erreicht wurden

Quelle


Use Cases sind genau und dauerhaft

Sie beinhalten Szenarien/Aktivitäten und steigern so das Verständnis des Systems.

Geeignet für (die Zeit der Konsolidierung…): 

  • Systemwartung
  • Anforderungen an ein Release dokumentieren
  • darstellen von Systemgrenzen
  • visualisieren von Anwendern 
  • dauerhafte Dokumentation

Damit ein System wartbar bleibt, sollten mindestens die Haupt-Use Cases eines Releases dokumentiert sein.

Nicht geeignet für: 

Verändern sich funktionale Anforderungen laufend, sind Use Cases ungeeignet, da die Aktivitäten/Szenarien angepasst werden müssen – das ist aufwendig und fehlerbehaftet. 

UC nach Kral.

Kommentar absenden

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.