Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Im Rahmen der userzentrierten Entwicklung konzentriert man sich auf die Situation des Anwenders; schliesslich soll die neue Anwendung den Bedürfnissen dieses Anwenders dienen.
Da ja nicht jedes Teammitglied mit den Anwendern jedes Detail mündlich klären kann, ist es notwendig, die Situation des Nutzers nachvollziehbar zu dokumentieren. Heute haben wir einige Zeit über die begriffliche Abgrenzung der beiden Themenkreise „Use Case“ und „User Story“ gesprochen. Beide Konzepte leisten wertvolle, jedoch unterschiedliche Dienste in der Softwareentwicklung.
Da die präzise Abgrenzung von Begriffen manchmal sehr wichtig ist, wie die kleine Diskussion gezeigt hat, will ich heute kurz auf die Unterschiede eingehen.
Unter User Stories versteht man Informationen, die den Nutzer im Rahmen seiner betrieblichen Aufgabenstellung beschreiben. Dabei streben User Stories an, möglichst kurz und knapp zu sein. Sie folgen der folgenden Syntax
In meiner Eigenschaft als <Rolle> will ich <folgendes Ziel erreichen>, um den <folgenden Gewinn daraus zu ziehen>
Einige typische User Stories für ein tragbares Musikabspielgerät wären:
Aus solchen User Stories kann man sich während der Entwicklungsphase ableiten, welche Features warum benötigt werden, und wie diese gestaltet werden sollten. Die User Stories werden auf der anderen Seite relativ feingrannular. Insofern fällt es gerade bei größeren Projekten schwer, den Überblick zu wahren.
Use Cases beschreiben was das Softwaresystem leisten soll, und wie die einzelnen Aktoren zusammenwirken, um die Anwendung zu realisieren.
Sie bewegen sich damit sowohl auf einem höheren Level, als auch beschreiben sie das System aus umfassender Sicht. Obwohl Use Cases in einer formalen Sprache geschrieben werden, enthalten Sie keine Sprachelemente, die sich aus der Implementation ergeben. Sie konzentrieren sich vielmehr auf die abstrakte Ebene.
Use Cases behandeln die funktionalen Aspekte der Anwendung, und beschreiben die Geschäftsvorfälle, die sie abdecken. Sie behandeln aber weder Informationen zum Aufbau des User Interfaces, noch sind sie zu speziell.
Normalerweise entwickelt man Use Cases im ersten Ansatz noch sehr grob, und verfeinert sie, je weiter man in seinem Entwicklungsprojekt voranschreitet. Diese Vorgehensweise wird über die formalisierte Sprache unterstützt, die man verwendet, um Use Cases zu erstellen (UML – Unified Modelling Language).
Sowohl Use Cases, als auch User Stories werden genutzt, um das System zu spezifizieren. Sie können aber auch weiterentwickelt werden, um im Rahmen der Qualitätssicherung damit zu prüfen, inwieweit die angestrebten Features entwickelt worden sind.
In der Wikipedia finden Sie zwei weiterführende Artikel, in denen Sie mehr Informationen über die beiden Konzepte (Use Case und User Story) finden
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
