Modell einer Anforderung

Erstellt am 24 Juli 2018
von Schreibe einen Kommentar

Modell einer Anforderung

Ein Modell ist eine vereinfachte Abbildung der Wirklichkeit mit einem bestimmten Zweck. Das hier vorgestellte Modell hilft mir dabei, herauszufinden, ob eine Anforderung im Kontext einer Produktentwicklung verifizierbar ist. Zudem wird mir dadurch klar, welche der drei Aspekte Stakeholder, Aussage und Adressat einer Anforderung fehlen, unbekannt sind und ggf. ermittelt werden müssen. Die Anwendung dieses Modells hat mir im Übrigen gezeigt, dass auch User Stories und Use Cases Anforderungen sind.

FAKE NEWS – Erfolg mit User Stories und Akzeptanzkriterien

Erstellt am 6 März 2018
von Schreibe einen Kommentar

Peter Ranzinger, Geschäftsführer von Ranzinger Games

FAKE NEWS war die Neuveröffentlichung schlechthin in der Computerspiele-Saison 2017.
Ein absoluter Newcomer hat von heute auf morgen ein neues Genre geboren. „Social Reality“ sei die Zukunft im hart umkämpften Gaming Markt, behauptet zumindest die Fachpresse. Der Geschäftsführer der neuen Spieleschmiede Ranzinger Games aus Isny im Allgäu hat auf verschiedenen Konferenzen durchblicken lassen, dass diese Disruption nur möglich war, da die Entwicklungsmannschaft bei Ranzinger Games den Mut hatte, einen komplett neuen Weg mit User Stories und Akzeptanzkriterien zu gehen. 

Wir haben Peter Ranzinger getroffen und im Interview erfahren, was das Geheimnis seines Erfolges mit FAKE NEWS ist.

Anforderungen mit User Stories und Akzeptanzkriterien agil managen – nur wie?

Erstellt am 25 Januar 2018
von Schreibe einen Kommentar

Haben Sie sich auch schon mal gefragt, wie Sie Anforderungen in Ihrem Produktentwicklungskontext mit User Stories systematisch strukturieren sollten? Unter ständig einprasselnden Kundenäußerungen und neuen Erkenntnissen sollen alle Beteiligten wissen, was gefordert ist. Zudem soll genügend Information vorhanden sein, damit das Geforderte umgesetzt werden kann.
Die Grundlage für diese Fragestellungen bilden Anforderungen. Anforderungen stellen das Bindeglied zwischen Kundenwunsch und dem Produkt(inkrement) dar. In vielen Projekten wird die Frage nach einer Systematik zur Strukturierung von Anforderungen gestellt. An dieser Stelle will ich eine Vorgehensweise vorstellen, um mit Hilfe des sog. generischen Informationsmodells die erforderlichen Verantwortlichkeiten zu klären. Dabei kommen User Stories und Akzeptanzkriterien zum Einsatz.

Abbildung 1: Generisches Informationsmodell für Anforderungen (angelehnt an [2])

Cash, Stakeholder, Value – die drei Dimensionen des Business Values

Erstellt am 12 September 2017
von 1 Komment
Business Value hat 3 Dimentionen: Cash, Stakeholder und Value

Business Value – 3 Dimensionen

Zur Einschätzung des Business Values einzelner Produktfeatures oder User Stories hilft die Erkenntnis, dass Business Value immer durch Zusammenwirken der Dimensionen Cash, Stakeholder und Value entsteht.

Anforderungsdokumentation ist nicht generell sinnvoll!

Erstellt am 28 Februar 2017
von Schreibe einen Kommentar

Vor etwa zwei Jahren habe ich mit einem Kunden die Fragestellung erörtert, inwieweit sich User Stories in einer Entwicklung im regulierten Umfeld einsetzen lassen. Es herrschte die Meinung, User Stories seien gänzlich ungeeignet um im regulierten Umfeld eingesetzt zu werden, da sie nicht detailliert genug seien, um als geforderte Anforderungsdokumentation zu dienen.

Agile Softwareentwicklung benötigt mehr Werkzeuge

Erstellt am 23 August 2016
von Schreibe einen Kommentar

In den 90er Jahren und noch zu Beginn des Jahrtausends haben wir sogenannte CASE-Tools (Computer Aided Software Engineering) verwendet, um zuerst ein Design in Form eines großen, komplett durchdachten UML-Modells zu erstellen, bevor wir anfingen, die Details zu kodieren.

ISO26262 und Scrum – kein Widerspruch

Erstellt am 15 März 2016
von 1 Komment

Vorvergangene Woche habe ich mit meinem Kollegen Karsten Krennrich im Rahmen der REConf® 2016 einen Workshop mit Repräsentanten aus der Automobilentwicklung veranstaltet. Alle Anwesenden kamen zu der Überzeugung, dass sich die genannte Sicherheitsnorm grundsätzlich unter dem Einsatz des Scrum-Frameworks umsetzen lässt. Ich möchte im Folgenden skizzieren, wie es zu dieser Einschätzung kam.

Die geeignete Lösungsdichte – Welche Frage hätte ich dem Kunden stellen sollen?

Erstellt am 11 Juni 2013
von 1 Komment

Im klassischen Requirements Engineering werden Anforderungen auf verschiedenen Abstraktionsebenen definiert:Abstraktionsebenen

Über die Abstraktionsebenen hinweg sollten die Lösungsdetails idealerweise nach und nach zunehmen. In der Automobilindustrie entspricht die Beschreibung des Ziels dem Lastenheft des Kunden und die abstrakte Beschreibung der Lösung dem Pflichtenheft des Lieferanten.

Das nachfolgende Beispiel zeigt, dass es hilfreich sein kann, über das richtige Maß an Lösungsdichte von Zeit zu Zeit nachzudenken.

Kennen Sie den Unterschied zwischen “logisch” und “physisch”?

Erstellt am 4 Dezember 2012
von Schreibe einen Kommentar

Während eines Projektes im Umfeld der Systemanalyse eines eingebetteten Systems für die Automobilindustrie erlebte ich es als eine der Hauptherausforderungen, bei der Systemspezifikation die Problem-Ebene von der Lösungs-Ebene zu trennen.