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.

Projekterfolg erleben

Erstellt am 15 November 2016
von Schreibe einen Kommentar

projekterfolg_erfahren

Es gibt nichts motivierenderes als den Erfolg eines Projektes selbst zu erleben. „Die Lorbeeren gemeinsam mit Kollegen zu ernten!“ Mein Kollege Marco Prillwitz und ich konnten dies in einem Kundenprojekt nun miterleben. Hier die Geschichte:

Ziele und Nutzen des systematischen Umgangs mit Anforderungen

Erstellt am 19 Juli 2016
von Schreibe einen Kommentar

Ziele von Anforderungen und Requirements EngineeringKü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.

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 Anforderung lebt!

Erstellt am 31 Juli 2015
von 1 Komment

Ist das Requirement Engineering tot?

desertDen Begriff „Requirements Engineering“ verbinden viele mit schwergewichtigen, dokumentenorientierten Vorgehensweisen, mit denen man Riesenprojekte besonders in der Luft- und Raumfahrt durchführt. Es beschreibt eine Herangehensweise aus den alten Zeiten der trägen „Wasserfall“-Projekte. Das Wort „Engineering“ klingt dabei wie ein komplexes Konstrukt, eine aufwändige Maschinerie für Anforderungen, ein starres Gebilde, das viel Ressourcen verschlingt und sich, wenn überhaupt, nur träge und langsam bewegt.

Zu viel ist zu viel!

Erstellt am 22 Juli 2014
von Schreibe einen Kommentar

Der Klassiker: ein Entwicklungsunternehmen hat von den Vorzügen des modernen Requirements Engineerings erfahren und möchte davon profitieren. Das Management ist vor allem von der verlockenden Aussicht, durch einen zukünftigen RE-Standard mittelfristig Kosten zu sparen, angetan. Zu diesem RE-Standard gehören ein definierter RE-Prozess, RE-Methoden und eine RE-Toolumgebung. Die Tool-Evaluierung ist ein zeitlich klar begrenzter Vorgang. Welche der bereits definierten Methoden zu verwenden sind, ergibt sich zum Teil im Projektalltag. Der RE-Prozess für ein konkretes Unternehmen muss jedoch erst entwickelt werden. Und hier liegt die Gefahr!

#2: Der „Bug“

Erstellt am 15 Juli 2014
von Schreibe einen Kommentar
This entry is part 2 of 3 in the series Änderungsmanagement im ALM

In den ALM Phasen gehen wir nun auf die Reise und werden Artefakte des Change Managements (ChM) unter die Lupe nehmen. Dabei steht diesem Teil der Blog Reihe vor allem die Phase “Develop” im Vordergrund. Eines der Artefakte des ChM der Bug, der eben nur in dieser Phase entsteht. Genauer gesagt,

Konsens oder Kompromiss? Eine Entscheidungshilfe

Erstellt am 11 Dezember 2013
von Schreibe einen Kommentar

Bei meiner Arbeit mit agilen Teams erlebe ich immer wieder heftige und langwierige Diskussionen, wenn eine gemeinsame Lösung gefunden werden soll bzw. eine Entscheidung getroffen werden muss. Das kann z.B. die Einigung über eine technische Umsetzung sein oder auch eine Übereinkunft über die Zusammenarbeit im Team. Um diese Diskussionen abzuschließen, kommt es häufig zu einer Abstimmung, wobei die Mehrheit dann „Recht“ hat. Dabei besteht die Gefahr, daß ein Teil des Teams offen oder versteckt in den Widerstand geht und die Entscheidung nicht mitträgt. Um das zu vermeiden, aber auch, um diesen Konflikten möglichst aus dem Weg zu gehen, wird versucht, es allen recht zu machen. Es wird ein Kompromiss gesucht.

Der Kundenflüsterer

Erstellt am 13 August 2013
von Schreibe einen Kommentar

Eine wichtige Aufgabe des Requirements Engineers ist die Erstellung und Pflege der Systemspezifikation. Er leitet dazu Kundenanforderungen ab, spezifiziert diese auf einem angemessenen Abstraktionsniveau und bietet dadurch eine solide Arbeitsgrundlage für nachfolgende Entwicklungsaktivitäten, z.B. die Softwareentwicklung. Doch woher weiß der Requirements Engineer eigentlich, was der Kunde wirklich will?

Austausch von Anforderungen aber richtig! – Teil 2

Erstellt am 4 September 2012
von Schreibe einen Kommentar

In dieser zweiteiligen Blogreihe beschreibe ich Ihnen, wie man Anforderungen innerhalb von Kunden – Lieferanten Beziehungen richtig austauscht. Im ersten Teil der Blogreihe wurden bereits folgende Punkte beschrieben:

  1. Identifizieren Sie alle Stakeholder und definieren Sie Rollen
  2. Legen Sie Ziele des Datenaustauches fest
  3. Definieren Sie einen Datenaustausch Prozess

Der zweite Teil der Blogreihe geht jetzt auf folgende Themen ein:

  1. Definieren Sie die logische Datenstruktur
  2. Bilden Sie die logische Datenstruktur im Tool ab
  3. Rollout Datenaustausch – Stellen Sie den definierten Datenaustausch im Tool bereit
  4. Erstellen Sie Dokumentationen
  5. Bereiten Sie Schulungen vor und führen Sie diese durch
  6. Leisten Sie Coaching