Blog

Unser Blog erscheint regelmäßig mit neuen Beiträgen aus den Themenbereichen der Anforderungsvermittlung und agilen Skalierung.

Notizbuch mit Anforderungsfabrik Logo Kugelschreiber daneben

Anforderungsvermittlung als Basis der Produktentwicklung

Für Entwicklungsvorhaben wird die gemeinsame Ausrichtung auf klare Ziele immer wichtiger. Entwicklungszyklen werden kürzer, der Grad der Selbstorganisation im Team steigt und unterschiedliche Fachbereiche arbeiten (und priorisieren) im direkten Austausch. Ohne einen klaren Rahmen, in dem sich alle Beteiligte frei bewegen können, kann das scheitern.

Auf Basis der gemeinsamen Ziele sind der Umgang mit Anforderungen und der daraus resultierenden Kommunikation die Faktoren, die den Erfolg von Entwicklungsvorhaben stark beeinflussen. Dabei geht es nicht primär um das Erstellen von Verträgen zwischen Auftraggeber und Auftragnehmer, sondern vielmehr um die Vermittlung von Bedarfen, Ideen und Anforderungen zwischen den verschiedenen Projektbeteiligten und Stakeholdern.

Die Definition von “vermitteln” nach dem Duden ist hier sehr passend:

  1. (zwischen Gegnern) eine Einigung erzielen, intervenieren, Zustande bringen, herbeiführenHandschlag verbindend Anforderungsfabrik

  2. dafür sorgen, dass jemand etwas, was er anstrebt, bekommt

  3. dafür sorgen, dass jemand, der eine Stelle o. Ä. sucht, mit jemandem in Verbindung gebracht wird, der eine solche zu vergeben hat

  4. jemandem verständlich machen, mitteilen, zeigen

[Duden]

In diesem Beitrag greifen wir unser Positionspapier zur Anforderungsvermittlung auf und beschreiben die notwendigen Aktivitäten für eine zielgerichtete und erfolgreiche Anforderungsvermittlung bei der Produktentwicklung.

Anforderungsvermittlung an der Schnittstelle zwischen Business und IT

Tabelle eines Projektalltags mit Zeichnungen diverser Transportmöglichkeiten

Insbesondere in planbasierten bzw. phasen-orientierten Vorgehen (z. B. Wasserfall) ist eine klassische Herausforderung die Kommunikation zwischen den verschiedenen Interessenvertretern, genannt Stakeholder. Stakeholder sind ein buntes Grüppchen: Ian Alexander hat das bekannte Zwiebelschalenmodell für Stakeholder beschrieben, worin u.a. die Nutzer der Software, die Entwicklung und die Sponsoren als Stakeholder beschrieben werden. Natürlich sind auch bei der agilen Produktentwicklung gleichermaßen Stakeholder beteiligt, nur in einer anderen Form der Zusammenarbeit. Für die Anforderungsvermittlung unterscheiden wir auf einer sehr groben Ebene zwischen zwei Seiten:

  • Die „Business“-Seite: Sie zeichnet sich dadurch aus, dass die meisten Personen einen fachlichen Fokus und (oftmals) einen betriebswirtschaftlichen Hintergrund haben (nach Scrum vertreten durch den Product Owner).

  • Die „IT“-Seite: Sie zeichnet sich dadurch aus, dass die meisten Personen einen informationstechnischen Hintergrund haben und daher eher auf Technologien schauen (nach Scrum das Development Team).

 

Die Kernprobleme

Das klassische Requirements Engineering hat Schwerpunkte in der Modellierung und der technischen Unterstützung von Anforderungsmanagement. Diese Schwerpunkte lehnen sich an Situationen in klassischen RE-lastigen, produktgetriebenen Branchen an, z.B. im Auto- oder Flugzeugbau. Dies sind nach unserer Erfahrung aber nicht die Kernprobleme in softwareintensiven Praxisprojekten. Diese sind u.a.:

  • Business und IT besitzen i.d.R. schon durch die typischen Ausbildungen sehr unterschiedliche Vorkenntnisse. Während das Business oftmals von kaufmännisch ausgebildeten Personen gestellt wird, arbeiten in der IT technisch ausgebildete Stakeholder (auch wenn sich die Lücke zwischen diesen Ausbildungen durch die agilen Ansätze immer weiter schließt).

  • Die beiden Seiten arbeiten typischerweise in getrennten Organisationseinheiten, woraus sich schon organisatorische Barrieren ergeben. Solche Barrieren können sowohl horizontal (unterschiedliche Abteilungen) wie auch vertikal (unterschiedliche Hierarchieebenen) sein.

  • Aus den beiden vorgenannten Punkten ergeben sich unterschiedliche Sprachen: die Sprache des Business und die Sprache der IT. Auch wenn der Wille da ist, fällt die Kommunikation in einer Fremdsprache immer schwer. Und oftmals ist den Beteiligten noch nicht einmal klar, dass es sich um zwei verschiedene Sprachen handelt!

  • Die Komplexität der Softwareentwicklungsprojekte nimmt immer noch stetig zu. Immer schnellere Reaktionen auf veränderte Anforderungen und neue Technologien werden erwartet, immer öfter müssen daher neue Kenntnisse erworben werden. Dies wirkt sich wiederum stark auf die verwendeten Sprachen aus.

  • Eine weitere organisatorische Schwachstelle liegt in der Nutzung von bestehenden Prozessen, in denen eine schwache Vermittlerrolle definiert ist. Oder es gibt bestehende Prozesse in Unternehmen, in denen zwar Vermittleraktivitäten eingebaut sind, diese jedoch nicht konsequent umgesetzt werden (können). Dazu kommt, dass derzeit die Prozesse durch den Einfluss von agilen Methoden sowieso im Umbruch sind.

Diese Faktoren treten in der Regel kombiniert und in verschiedenen Stärken auf. Für alle Faktoren wird jemand benötigt, der die Vermittlerrolle einnimmt, insbesondere zwischen Business und IT.

Wir benutzen den Begriff Anforderungsvermittlung als Synonym für alle Aktivitäten, die die Kommunikation zwischen Stakeholdern starten lässt oder diese unterstützt. Die Modellierung, die Sicherung der Verfolgbarkeit oder die Prozessunterstützung sind angrenzende Tätigkeiten, fallen aber nicht in den primären Fokus der Anforderungsvermittlung.

 

Das Rahmenwerk der Anforderungsvermittlung

Das Rahmenwerk ist eine Zusammenstellung von Erfolgsmethoden aus unserer Erfahrung bei der Produktentwicklung. In grober Anlehnung an die Aktivitäten des RE nach IREB haben wir die Anforderungsvermittlung in fünf Aktivitäten eingeteilt: Ausrichten, Einbinden, Ermitteln, Dokumentieren und Steuern.

Iteratives Modell der Anforderungsvermittlung

Ausrichten

werkzeugkoffer ausrichten Anforderungsfabrik

Der Projektscope oder die Produktvision wird i.d.R. auf einer Managementebene festgelegt. Im Projektmanagement ist hier der Projektleiter verantwortlich. Der Anforderungsvermittler muss hier mindestens klare Kenntnis erlangen, im besten Fall beratend mitgestalten. Wir unterscheiden drei Aktivitäten:

  • Der Anforderungsvermittler hilft den Bedarf des Auftraggebers oder Kunden zu formulieren und ihn den Stakeholdern zu beschreiben.

  • Auf Basis des Bedarfs wird der Umfang des Vorhabens definiert (Scope), d.h. die fachliche wie auch technische Ausrichtung des Projektes. Dazu gehört auch die Definition der Dinge, welche explizit nicht im Projekt berücksichtigt werden und „Out of Scope“ sein sollen.

  • Weitere Einflussfaktoren auf das Projekt, welche relevant für die Anforderungsvermittlung sind, müssen identifiziert und analysiert werden. Typische Faktoren sind bspw. die Vorgehensweise der Produktentwicklung (klassisch vs. agil), die lokale Verteilung der Stakeholder, der Zeitrahmen, das politische / kulturelle Umfeld sowie technologische Rahmenbedingungen.

Das so ausgerichtete Vorhaben ist nun startbereit. Bei allen wichtigeren Änderungen im Projektumfeld (Scope, Stakeholder, Rahmenbedingungen) ist die Ausrichtung zu prüfen und ggf. anzupassen.

Einbinden

werkzeugkoffer einbinden Anforderungsfabrik

Im ausgerichteten Vorhaben ist oft erst ein kleiner Teil der Stakeholder bekannt. In der Regel müssen diese noch ergänzt und/oder durch operativ agierende Personen ausgetauscht werden. Das aktive Einbeziehen aller Stakeholder sollte dabei Priorität haben.

Neben den einzubindenden Personen gibt es in der Regel weitere Anforderungsquellen wie Dokumente und bestehende IT Systeme, in denen wichtige Anforderungen in der nachfolgenden Phase ermittelt werden können. Diese müssen analog zu den Stakeholdern identifiziert werden.

Ermitteln

werkzeugkoffer ermitteln Anforderungsfabrik

Um Anforderungen an ein IT-System identifizieren zu können, müssen gezielt passende Ermittlungs- techniken festgelegt werden. Das geschieht auf Basis der zuvor definierten Projektausrichtung (Bedarf, Scope und Einflussfaktoren) und der eingebundenen Stakeholdern und weiteren Anforderungsquellen.

Es muss dann organisiert werden, wie Anforderungen zu ermitteln sind. Die Auswahl von geeigneten Ermittlungstechniken ist oftmals der entscheidende Faktor. Hier werden die Stakeholder verstärkt eingebunden, was allen Beteiligten bereits beim ‚Einbinden‘ kommuniziert werden sollte.

Dokumentieren

werkzeugkoffer dokumentieren Anforderungsfabrik

Die Ergebnisse des „Ermitteln“ der Anforderungen müssen geeignet und nachhaltig dokumentiert wer- den. Folgende Aktivitäten sind hierfür zu berücksichtigen.

  • Oft sind die Dokumentationsrichtlinien vom Auftraggeber vorgegeben. Sollte das nicht der Fall sein, sollten Dokumentationsrichtlinien festgelegt werden. Im agilen Kontext sprechen wir hier vom „Definition of Ready“ eines Backlog Items. D.h. es wird definiert, welche (äußere) Form das Dokument besitzen soll. Die Dokumentationsrichtlinien sollten in Abstimmung mit den Stakeholdern erstellt werden, die die Anforderungen zu einem späteren Zeitpunkt prüfen und abnehmen sollen (dazu gehört u.a. das Development Team nach Scrum).

  • Innerhalb eines Dokuments, oder Anforderungskatalogs in Form eines Product Backlogs, sollten dann Anforderungskategorien definiert werden, welche den Umgang mit den Anforderungen innerhalb der Dokumentation verbessern sollen. Die Kategorien können fachliche Prozesse, Interessensgruppen oder Subsysteme gruppieren, um ein Sichtenkonzept (z.B. über Filter im Product Backlog) zu ermöglichen.

  • Auch die Qualitätskriterien des Anforderungsdokuments und der einzelnen Anforderungen und Backlog Items muss (auf syntaktischer Ebene) festgelegt werden. Die Qualitätskriterien können sich in verschiedenen Abstraktionsebenen unterscheiden (beispielsweise an der Attributierung).

  • Anforderungen müssen dann natürlich sprachlich oder modellbasiert dokumentiert werden.

  • Die Dokumentation sollte von den Stakeholdern validiert werden. Eine Feedbackschleife mit der Anforderungsdokumentation als Basis hilft bereits in einer frühen Phase, Fehler zu finden und Fehlentwicklungen zu vermeiden.

Steuern

Kalender steuern Anforderungsfabrik

Eine übergreifende und unterstützende Querschnittsaktivität ist notwendig, die parallel alle zuvor beschriebenen Aktivitäten begleitet.

  • Der Anforderungsvermittler steht in kontinuierlicher Kommunikation mit dem Projekt- / Produktteam, d.h. er ist der zentrale Ansprechpartner für Anforderungen (im Idealfall über alle Projektphasen bzw. Abstraktionsebenen hinweg)

  • Während des Vorhabens können sich Anforderungen, der Projekt Scope oder sogar der Bedarf ändern. Bei der agilen Produktentwicklung ist dies oft über einen Prozess abgebildet (z.B. Scrum). In planbasierten Projekten muss hierzu ein Änderungsmanagement etabliert werden.

  • Der Umgang mit Anforderungen im Unternehmen mit Fokus auf den oben beschrieben Aktivitäten sollte definiert und eingehalten werden. Der Anforderungsvermittler sollte das bei seinen Aktivitäten berücksichtigen und für die Produktentwicklung sicherstellen.

  • Nach jeder Aktivität muss geplant werden, welches die nächste ist oder was in der nächsten Iteration notwendig ist. Ziel sollte es sein, die Aufmerksamkeit der Aktivitäten bei der Anforderungsvermittlung auf das Notwendige zu richten und Verschwendung zu vermeiden.

  • Um eine effiziente Anforderungsvermittlung durchführen zu können, ist die konstruktive Mitarbeit der Stakeholder entscheidend. Die Aufgabe des Anforderungsvermittlers ist die Akzeptanz und Motivation bei allen Projektbeteiligten für die notwendigen Vermittlungstätigkeiten hoch zu halten.

Mit einer strukturierten Vorgehensweise und klar definierten Aktivitäten können die negativen Auswirkungen der vorgenannten Probleme stark reduziert werden.

Die Aktivitäten des Rahmenwerks werden iterativ-inkrementell durchlaufen.

Fazit

Um den Kernproblemen bei der komplexen Produktentwicklung entgegenzuwirken, ist eine Vermittlerrolle notwendig. Insbesondere an der Schnittstelle zwischen Business und IT gibt es konkrete Aktivitäten, die die Qualität der Anforderungsvermittlung erhöhen. Diese Aktivitäten haben wir in unserem Rahmenwerk zusammengefasst, welches als Handreiche für die tägliche Arbeit verwendet werden kann. Zielgruppen hiervon sind u.a. Requirements Engineer, Business Analyst, Projektmanager und Product Owner.

Wie wichtig die Integration der Anforderungsvermittlung auch in Scrum ist, haben wir im Requirements Engineering Magazin „Product Owner in Scum“ beschrieben.

Weitere Details finden Sie auch in unserem Werkzeugkoffer.

Geschäftsführer Jesko Schneider

Über den Autor

Jesko Schneider ist als Berater, Trainer und Coach in unterschiedlichen Branchen und Unternehmen rund um das Thema Requirements Engineering und der Umsetzung dieses bei der agilen Produktentwicklung tätig. 

Sein Einsatz in Kundenprojekten umfasst die Optimierung der Zusammenarbeit bei der komplexen Produktentwicklung im Rahmen von Digitalisierungsvorhaben (klassisch, agil oder hybrid).

Darüber hinaus ist er als Trainer und Coach bei der agilen Transformation von Unternehmen tätig, wobei sein Fokus auf der strukturierten und fokussierten Zusammenarbeit zwischen Business und IT liegt.

Gründer & Geschäftsführer

Jesko Schneider Anforderungsfabrik

Jesko Schneider ist als Berater, Trainer und Coach in unterschiedlichen Branchen und Unternehmen rund um das Thema Requirements Engineering und der Umsetzung dieses bei der agilen Produktentwicklung tätig. 

Sein Einsatz in Kundenprojekten umfasst die Optimierung der Zusammenarbeit bei der komplexen Produktentwicklung im Rahmen von Digitalisierungsvorhaben (klassisch, agil oder hybrid).

Darüber hinaus ist er als Trainer und Coach bei der agilen Transformation von Unternehmen tätig, wobei sein Fokus auf der strukturierten und fokussierten Zusammenarbeit zwischen Business und IT liegt.

Gründer & Geschäftsführer

24. – 25. April 2024
Garantietermin

Sie wollen nichts mehr verpassen?

WordPress Cookie-Hinweis von Real Cookie Banner