Share ZU:
10 April 2012 @ Markus Eberhardt

Austausch von Anforderungen, aber richtig! – Teil 1

This entry is part 1 of 1 in the series Anforderungsaustausch
  • Austausch von Anforderungen, aber richtig! – Teil 1

In dieser zweiteiligen Blogreihe fassen wir unsere Erfahrungen mit dem Anforderungsaustausch an der Schnittstelle von OEM und Lieferanten zusammen. Im Vordergrund steht hier nicht die technischen Herausforderungen beim Datenaustausch sondern die flankierenden Maßnahmen, welche für einen erfolgreichen Datenaustausch essentiell sind. Hierunter fallen z.B. eine detaillierte Dokumentation der Ziele und Prozesse des Anforderungsaustausches.

Die ursprüngliche Initiative zum Anforderungsaustausch kommt von den Automobilhersteller- und ihren zahlreichen Lieferanten. Der konsequente Einsatz des Requirements Engineering hat hier einen hohen Stellwert, da ein Lastenheft zur Beschreibung eines Steuergeräts aus mehreren Containern und mehreren hundert oder tausend Anforderungen bestehen kann.

Abbildung 1 beschreibt Beziehungen, wie sie in der Automobilbranche häufig vorkommen. Dies lässt sich aber auch auf andere Branchen übertragen.

Abbildung 1 – Kunden – Lieferanten Beziehung

Im Jahre 2004 wurde von der HIS (Herstellerinitiative Software, ein gemeinsamer Zusammenschluss einiger OEMs) mit der Definition eines generischen, toolübergreifenden Formats zum Austausch von Anforderungen begonnen. ReqIf, das so entwickelte und abgestimmte auf XML basierende Format, wurde im April 2011 von der OMG als Standard anerkannt (http://www.omg.org/spec/ReqIF).

Aber die Verwendung von ReqIF allein ist noch kein Garant für einen erfolgreichen Anforderungsaustausch. Deshalb haben wir als Leitfaden die folgenden sieben Maßnahmen identifiziert, die z.T. iterativ durchgeführt werden können:

  1. Identifizieren Sie alle Stakeholder und definieren Sie Rollen
  2. Legen Sie Ziele des Datenaustauches fest
  3. Definieren Sie einen Datenaustausch Prozess
  4. Definieren Sie die logische Datenstruktur
  5. Bilden Sie die logische Datenstruktur im Tool ab
  6. Rollout Datenaustausch – Stellen Sie den definierten Datenaustausch im Tool bereit
  7. Erstellen Sie Dokumentationen
  8. Bereiten Sie Schulungen vor und führen Sie diese durch
  9. Leisten Sie Coaching

Im ersten Teil der Blogreihe gehen wir auf die ersten drei Punkte ein, die anderen Punkte werden im zweiten Teil der Blockreihe erläutert.

1     Identifizieren Sie alle Stakeholder und definieren Sie Rollen

Bevor Sie operativ in den Datenaustausch Prozess starten, machen Sie eine Stakeholder Analyse, d.h. analysieren Sie, wer ein Interesse an dem Datenaustausch hat. Ziehen Sie hierbei von Anfang an das Management und Projektleiter in den Prozess mit ein. Power User, die sich mit dem Anforderungsmanagement System exzellent auskennen, sind ebenfalls wichtige Stakeholder. Als wichtigste Stakeholder sind die Ansprechpartner bei Kunden bzw. Lieferanten zu nennen, die als wertvolle Informationsquelle in die Abstimmung einbezogen werden sollten. Die IT-Aministration und Anwender des Anforderungsmanagement Systems sollten zumindest von Anfang an über das Vorgehen und wichtige Meilensteine informiert werden.

Definieren und dokumentieren Sie Rollen für Verantwortlichkeiten in diesem Projekt sowohl auf Kundenseite, als auch auf Lieferantenseite. Hierbei sollten Sie jeweils Hauptansprechpartner für den Datenaustausch, Verantwortlichkeiten bezüglich des organisatorischen oder fachlichen Aspekts (nicht werkzeugtechnisch) und Ansprechpartner bei Problemen (Eskalation) definieren.

2     Legen Sie Ziele des Datenaustauches fest

In diesem Schritt müssen Kunden und Lieferanten Ziele und Zweck des Datenaustauchs erarbeiten und festlegen. Ziel dieses Schrittes ist es nicht, den Austauschmechanismus im Detail oder Datentypen der Daten zu definieren, sondern eine prinzipielle Analyse durchzuführen, um alle für den Datenaustausch relevante Faktoren zu identifzieren und zu dokumentieren. Dies kann z.B. in einem gemeinsamen Workshop geschehen. Am Ende sollten Sie mindestens die Infrastruktur, sowie Art und Inhalte der auszutauschenden Daten (d.h. welche Teile des definierten Informationsmodell für den Austausch relevant sind) auf beiden Seiten kennen und miteinander vereinbart haben. Zusätzlich sollten Sie Änderungsmechanismen und Versionskontrolle der Daten nicht vergessen.

Um Missverständnissen vorzubeugen, sollten Sie die Vereinbarungen schriftlich in einem Protokoll festhalten.

3     Definieren Sie einen Datenaustausch Prozess

Ein wohldefinierte Datenaustausch Prozess soll für einen reibungslosen Ablauf beim Austausch der Daten sorgen. Hierbei ist vor allem von Interesse,

  • Wie können die ausgetauschten Daten in die weitere Bearbeitung beim Lieferanten und Kunden integriert werden,
  • wie sind die Prozesse jeweils definiert,
  • müssen vor dem Austausch Maßnahmen durchgeführt werden (z.B. Reviews),
  • wie und wann werden Änderungen kommunizie
  • wie werden die Daten versioniert,
  • gibt es Änderungen der Daten auf beiden Seiten,
  • sind parallele Entwicklungen vorhanden,
  • werden Daten außerhalb des Anforderungsmangement Systems geliefert,
  • Gibt es Einschränkungen aufgrund der verwendeten Austauschdatenformate und Werkzeuge?
  • Etc.

Sie sehen also in diesem Schritt ist eine fachlich methodische Betrachtung notwendig und nicht nur die technische Verarbeitung. Auch in diesem Schritt sollten Sie gemeinsame Workshops durchführen, um Probleme und Lösungen gemeinsam zu erörtern.

Markus Eberhardt

Kontaktieren Sie Markus Eberhardt

Markus Eberhardt ist seit 2011 Senior Consultant bei der HOOD Group für Requirements Engineering und Management. Bei Agile-by-HOOD arbeitet er als Coach mit Leidenschaft und viel Herr Markus Eberhardt ist als Senior Consultant bei der HOOD GmbH sowohl im agilen Umfeld als auch im klassischen Requirements Engineering (RE) und Requirements Management tätig. Sein Spezialgebiet ist der wertorientierte Einsatz von bewährten Praktiken des Requirements Engineering im agilen Umfeld. Die Zertifizierungen des IREB, als Scrum Master, in SAFe und CARS bilden hierfür ein breites methodisches Fundament. Große Erfahrung besitzt er zum Beispiel mit IBM Rational DOORS zur Erfassung und Verwaltung von Anforderungen, sowohl aus Sicht des Anwenders als auch aus Sicht der Betriebsführung sowie mit dem äquivalenten Einsatz von TFS. Sein Wissen gibt Herr Eberhardt in Workshops, Trainings und durch Coaching in Projektteams weiter.