Ist RE tot?

Erstellt am 20 Oktober 2015
von Schreibe einen Kommentar

Kürzlich habe ich auf der Manage Agile 2015 in Berlin die Keynote eines namhaften Sprechers gehört, der neben einigen sehr sinnreichen Äußerungen auch die Behauptung aufgestellt hat: RE ist tot!

„Ich, RE, teile hiermit allen Interessierten mit, dass diese Nachricht über mein Ableben verfrüht ist und ich mich ausgezeichneter Gesundheit erfreue!“

Für Agilität doch noch nicht zu spät?

Erstellt am 25 August 2015
von Schreibe einen Kommentar

Stellen Sie sich vor, Sie arbeiten jahrelang als Systemanalyst im Automotivekontext. Die Methoden des klassischen Requirements Engineering sind Ihnen in Fleisch und Blut übergegangen, Sie kennen die Stärken und Schwächen. Nun werden Sie mit agilen Werten und Prinzipien konfrontiert. Wurde der Samen einmal gepflanzt, ist ein Umdenken nicht mehr aufzuhalten.

Die bewährten Praktiken des Requirements Engineering sind auch im agilen Umfeld wertvoll

Erstellt am 11 August 2015
von Schreibe einen Kommentar

In einer ersten Abstraktion sind die Hauptziele des Requirements Engineering das Verstehen, Vereinbaren und Sicherstellen von Anforderungen. Diese Ziele werden im traditionellen Requirements Engineering durch eine Vielzahl von Praktiken wirksam unterstützt wie z.B.

  • Abgrenzen von System und Systemkontext
  • Stakeholderanalyse
  • Ermittlungstechniken für Anforderungen
  • Klassifizierung von Anforderungen
  • Qualitätskriterien von Anforderungen

Der Einsatz dieser Praktiken trug wesentlich zum Erfolg des Requirements Engineerings bei. Jetzt gilt es, die wertvollen Erfahrungen auch im agilen Umfeld einzusetzen und so die Kommunikation im Team und zu den Stakeholdern wirksam zu unterstützen.
Weitere Informationen finden Sie unter folgendem Link:
http://www.hood-group.com/agile/training/certified-agile-requirements-specialist-cars/

Dokumentation von Anforderungen mit Code Based Modeling

Erstellt am 9 Juni 2015
von Schreibe einen Kommentar

Die Motivation
Kennen Sie die folgenden Situationen?

  • Wenn es auf ein Release zugeht, werden Good Practices wie das präzise Beschreiben der Anforderungen über Bord geworfen und alle Aufmerksamkeit auf das Fertigstellen der Software gelenkt.
  • Die Anforderungsdokumentation ist nach einiger Zeit nicht mehr auf dem aktuellen Stand, sie hinkt der Software hinterher.
  • Wenn die ursprünglichen Entwickler nicht mehr verfügbar sind oder viele Teams am selben Produkt arbeiten, wird es zusehends schwieriger herauszufinden, welche Teile der Software angepasst werden müssen um eine bestimmte Funktionalität zu ändern.

Diese Probleme resultieren häufig daraus, dass es kein einheitliches Konzept gibt, wie Anforderungen systematisch und möglichst direkt im Code abgebildet werden.

To finish or not to finish …

Erstellt am 21 Oktober 2014
von Schreibe einen Kommentar

Eine der stärksten mentalen Barrieren, die mir bei der Unterstützung von Software-Entwicklungsteams auf ihrem Weg in die agile Welt begegnen, ist das Bedürfnis, angefangene Arbeitsprodukte möglichst vollständig und in einem Zug fertigzustellen. Wir tendieren dazu, Arbeitsprodukte wie Spezifikationen, Design oder Architekturen möglichst perfekt fertigzustellen, bevor wir sie aus der Hand geben.

Agiles Requirements Engineering – Gibt es das überhaupt?

Erstellt am 17 Juni 2014
von Schreibe einen Kommentar

Requirements Engineering ist Requirements Engineering – Punkt.

Und Requirements Engineering ist auch nicht viel schwieriger als über Wasser zu wandeln – zumindest, wenn beides eingefroren ist. Während aber Wasser in manchen Regionen gelegentlich tatsächlich eingefroren ist, gilt das für Anforderungen – entgegen anders lautender Behauptungen – nicht. Und hier kommt die Agilität ins Spiel. Menschen mit agiler Geisteshaltung können mit nicht-eingefrorenen Anforderungen umgehen, sie schätzen Veränderungen und neue Herausforderungen.

Agilität beginnt im Kopf

Erstellt am 15 Mai 2012
von Schreibe einen Kommentar

In der Softwareentwicklung will heute praktisch jeder agil sein. Das klingt modern und dynamisch. Liest man die Werte, die hinter dieser Idee stecken (agiles Manifest), versteht man leicht, warum.

  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
  • Funktionierende Software ist wichtiger als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung
  • Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Es liegt aber im Wesen des Menschen, Ideen (auch gute) falsch zu verstehen – manchmal auch absichtlich, um eigene Interessen zu verfolgen.