Glaubt man einer Studie der Standish Group aus dem Jahre 2002, könnte man dies glauben. Dieser Studie zufolge werden 45% aller Features eines Produkts nie benutzt. Führen Sie sich die Bedeutung des Wortes „nie“ nochmals vor Augen: diese Features werden nicht gelegentlich, oder selten, oder nur von speziellen, kleinen Zielgruppen genutzt, sondern überhaupt gar nicht! Wozu dann all der Aufwand, all die Zeit, all das Geld während der Entwicklung?
Agil und Traditionell sind keine Gegensätze
Das Cynefin-Modell von Dave Snowden zeigt sehr schön, dass es nicht ausreicht, als einziges Werkzeug einen Hammer zu haben und damit jedes Problem zu einem Nagel zu machen. Er nennt neben einfachen und komplizierten auch komplexe und chaotische Probleme. Und je nach Kontext brauchen wir unterschiedliche Methoden, Technologien und Praktiken, um ein Problem zu lösen.
Zeig doch mal die Metrik!
Kennen Sie auch folgendes Szenario: Sie sitzen in einem Projektmeeting und der erste Punkt der Agenda steht an: Die aktuellen Metriken. Noch bevor inhaltliche Themen der Entwicklung besprochen werden, wird der aktuelle Status der Metriken als wichtigstes Mittel zur Messung des Projektfortschrittes herangezogen.
Systems Engineering und Requirements Engineering – Gedanken aus dem Tag des Systems Engineering 2016
Auch dieses Jahr war ich auf dem Tag des Systems Engineering TdSE 2016. Diesmal in Herzogenaurach, 
wo es wieder viele spannende Themen gab [2]. Als Mitglied der Gesellschaft für Systems Engineering (GfSE) und als Experte für Requirements Engineering bei HOOD verfolge ich mit hohem Interesse die Entwicklung des Systems Engineering (SE) im Bezug zum Requirements Engineering (RE). Mich freut es, dass diese “zwei Gebiete” immer mehr zusammenwachsen und gemeinsam betrachtet werden.
Ziele und Nutzen des systematischen Umgangs mit Anforderungen
Kürzlich wurde ich wieder gefragt, wie sich der Aufwand von Requirements Engineering rechtfertigen lässt. Immer noch beobachte ich, dass die Tätigkeit des “systematischen Umgangs mit Anforderungen”, dies ist eine moderne Übersetzung des englischen Begriffs “Requirements Engineering and Management”, zu wenig Akzeptanz innerhalb der Unternehmen findet. Es werden verschiedenste Gegenargumente vorgetragen: Für das Projektmanagement ist es viel zu teuer, für die Entwickler und Fachabteilungen ist es “unmotivierter Mehraufwand” oder “Overhead für Dokumentation”, für manche agile Teams ist es “alter Hut” und für erfahrene, gewachsene Fachabteilungen ist es “nicht notwendig, das haben wir schon immer so, ohne Anforderungen, gemacht”.
Gewiss, der systematische Umgang mit Anforderungen kostet Zeit und Geld, und der Aufwand muss adäquat an die Struktur und die Gegebenheiten der Organisation, des zu entwickelnden Produktes oder Dienstleistung angepasst werden.
autoSWIFT: Was können wir zur Beschleunigung von Innovationen aus dem Agilen Manifest lernen?
Komplexe Fahrzeugfunktionen wie das autonome Fahren, Car2Car-Kommunikation und Fahrerassistenzfunktionen stellen die Automobilindustrie vor neue Herausforderungen.
REConf® 2016 – Rückblick
Die REConf®, die größte Konferenz zum Thema Requirements Engineering im deutschsprachigen Raum, fand zum 15. Mal statt. Das Thema der Konferenz war „Connecting People – Overcoming Barriers“.
Ein Requirement-Weihnachtslied
HOOD beteiligt sich am BMBF Forschungsvorhaben autoSWIFT
Schnellere Innovationszyklen für Elektroniksysteme entlang der Automobilwertschöpfungskette
Ist RE tot?
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!“