Anforderungsmanagement: So bekommen Sie Ihr Requirements Engineering (wieder) in den Griff!
Sie verlieren den Überblick über den Status Ihrer Anforderungen und kämpfen mit einem unstrukturierten Backlog? Ihre Projektbeteiligten versinken im Ticket-Chaos? Niemand fühlt sich verantwortlich? Im Ergebnis führt dies immer zu unnötigen Ausgaben und am Ende steht sowohl ein gescheitertes Projekt als auch ein unzufriedenes Projektteam. Das muss nicht sein! In diesem Blog-Beitrag zeigen wir Ihnen aus Sicht von UI-Konzeptionisten, wie Sie einen effizienten Produktentwicklungsprozess planen und aufsetzen. Dabei wird durch die frühzeitige, aktive Einbindung der Fachbereiche eine hohe Akzeptanz und eine starke Identifikation mit dem Produkt sichergestellt.
Was sind die größten Herausforderungen beim Anforderungsmanagement?
Vielleicht kennen Sie die folgenden Aussagen im Rahmen der Anforderungserhebung:
Diese Aussagen hören wir in unserer täglichen Arbeit leider sehr häufig. Sie sind typische Symptome dafür, dass es beim Kunden noch keinen etablierten Produktentwicklungsprozess gibt. Rollen und Verantwortlichkeiten sind oft gar nicht oder nicht eindeutig definiert. Auch das gemeinsame Verständnis darüber, in welcher Form und Granularität Anforderungen erhoben werden, ist bei vielen Kunden nicht vorhanden.
Fachbereiche möchten gerne so schnell wie möglich mit der Entwicklung starten. Entwickler hingegen wünschen sich vorab präzise formulierte Anforderungen in Form von User Stories. Daher ist es wichtig, gemeinsam zu Anfang eines Projektes, die Rolle und die Aufgaben des Anforderungsmanagers festzulegen sowie einen klaren und eindeutigen Produktentwicklungsprozess zu definieren.
Welche sind die Hauptaufgaben im Anforderungsmanagement?
Die Kunst im Anforderungsmanagement besteht darin, die Anforderungen sauber zu ermitteln, zu dokumentieren, zu validieren und den gesamten Prozess zu verwalten.
Ermittlung: Für die Ermittlung der Anforderungen haben sich für uns folgende Ermittlungstechniken in einer Vielzahl von Projekten besonders bewährt: Design Thinking, Interviews, Fragebögen, Workshops, (Feld-)Beobachtung, Apprenticing, Brainstorming, Storyboards und User Journeys.
Dokumentation: Die erhobenen Anforderungen dokumentieren wir gerne in Form von User Stories. Hierbei erhalten diese eine eindeutige ID zur Identifikation, einen Titel, eine kurze Beschreibung in Form einer Satzschablone, eine Priorität sowie Akzeptanzkriterien für die Abnahme der User Stories im späteren Test.
Bei der Erstellung von User Stories sollte auf die folgenden Dos und Don’ts geachtet werden:
Validierung: Während der Anforderungsaufnahme finden fortlaufend Validierungen mit dem Fachbereich und der Entwicklung statt. Hierbei werden die bestehenden Anforderungen erneut von allen Stakeholdern betrachtet und gemeinsam abgestimmt, bevor diese an die Entwicklung gegeben werden.
Backlog: Das Backlog enthält alle erfassten Anforderungen. Diese werden später im Rahmen von Sprint Plannings in entsprechende Sprint Backlogs überführt, priorisiert und nach einer Validierung in die Entwicklung gegeben. Zusätzlich leitet das Entwicklungsteam konkrete Tasks für sich ab.
Welche Rollen sind im Anforderungsmanagement beteiligt und wie spielen diese zusammen?
Während des Produktentwicklungsprozesses tragen verschiedene Rollen zu unterschiedlichen Zeitpunkten dazu bei, die Anforderungen an das Produkt möglichst vollumfänglich zu erfassen und zu validieren. Hierbei ist insbesondere die „Übersetzung“ der Anforderungen des Fachbereichs in eine für die Entwicklung eindeutige und verständliche „Sprache“ hervorzuheben.
Im Rollenmodell sind grundsätzlich folgende Positionen zu besetzen: Anforderungsmanager (Requirements Engineer), Entwicklung und Fachbereich. Diese müssen in jedem Projekt als Minimalbesetzung vorhanden sein. Je nach Komplexität des Projektes sind gegebenenfalls weitere Rollen erforderlich. Da der Fokus dieses Blog-Beitrags auf dem Anforderungsmanagement liegt, werden die für die agile Entwicklung spezifischen Scrum-Rollen wie Scrum Master und Product Owner oder allgemeine Rollen wie Projektleiter und Tester nicht näher beschrieben. Für einen reibungslosen Prozessablauf sind diese Rollen jedoch unverzichtbar. Nur wenn jeder Projektbeteiligte die für seine Rolle spezifischen Aufgaben komplett erfüllt, kann der nachfolgend beschriebene Prozess erfolgreich umgesetzt werden.
Vorstellung eines effizienten Anforderungsmanagementprozesses
Auf der Grundlage einer Vielzahl von durchgeführten Projekten hat sich folgender Prozess für unser Anforderungsmanagement bewährt:
Ausgangspunkt des Prozesses bilden hierbei die seitens des Fachbereichs definierten Anforderungen (User Stories). Diese werden im nächsten Schritt in aussagekräftige Mockups überführt, welche iterativ mit dem Fachbereich bis zur höchstmöglichen Detailierung abgestimmt werden. Anschließend werden die Mockups zusammen mit den User Stories und einem Datenkatalog seitens der Entwicklung – aber ohne Fachbereich – auf ihre technische Machbarkeit validiert. Nach erfolgreicher Freigabe durch das Entwicklungsteam werden Mockups, Datenkatalog und Anforderungen (User Stories) in einem gemeinsamen Termin zwischen Anforderungsmanagement und Fachbereich validiert. Im Anschluss werden die User Stories angepasst, sofern dies erforderlich ist. Die validierten Anforderungen werden jetzt an das Entwicklungsteam übergeben, das daraus eigenständig spezifische Entwicklungsaufgaben (Tasks) ableitet. Zum Abschluss werden die umgesetzten Anforderungen anhand der Akzeptanzkriterien durch den Fachbereich getestet und abgenommen.
Der Umgang mit Fehlern (Bug Management) lässt sich in diesen Prozess ebenfalls optimal integrieren, wird im Rahmen dieses Blog-Beitrags jedoch nicht näher betrachtet.
Erstellung, Strukturierung und Verwaltung von Anforderungen
Der erste Schritt im Praxiseinsatz besteht darin, Epics, Features und User Stories in einem professionellen Werkzeug zum Anforderungsmanagement wie Microsoft Azure DevOps, GitLab oder Jira anzulegen.
Die höchste Hierarchiestufe aller möglichen Strukturelemente bildet das Epic. Dieses kann ein oder mehrere Features und/oder User Stories enthalten. Ein Feature stellt die zweithöchste Ebene dar und dient ebenfalls der Strukturierung von User Stories. Die eigentlichen Anforderungen werden in Form von User Stories erfasst. Hier werden die einzelnen Funktionen aus Sicht eines Benutzers detailliert beschrieben und zusätzlich mit „smarten“ Akzeptanzkriterien erweitert. Ziel dabei ist, dass die Anforderungen sich allen Beteiligten unmittelbar erschließen. Tasks sind konkrete Aufgaben, die eigenständig vom Entwicklungsteam definiert und bearbeitet werden.
Anschließend werden Mockups unter Anwendung eines für den Anwendungszweck geeigneten Mockup Tools und unter Berücksichtigung der relevanten Zielgruppe erstellt. Die bereits definierten User Stories werden im Nachgang mit den Mockups verknüpft. Informationen dazu, wie professionelle Mockups auf einfache Art und Weise erstellt werden können, liefert unser Blog-Beitrag „SAP Fiori: Erstellen Sie mit Figma High-Fidelity-Mockups im Handumdrehen“.
Im dritten Schritt wird ein Datenkatalog passend zu den Mockups erstellt. Der Datenkatalog enthält alle Informationen, die das Entwicklungsteam für die Umsetzung der geforderten Funktionalitäten benötigt.
Folgende Attribute werden dabei für jedes einzelne Oberflächenelement durch das Konzeptions- und Entwicklungsteam erfasst und abgestimmt:
| Attribut | To Do |
|---|---|
| ID | Anforderungsmanager |
| Bezeichnung | Anforderungsmanager |
| Pflichtfeld | Anforderungsmanager |
| Datenquelle | Modulberater |
| Datenformat | Modulberater |
| Validierung | Anforderungsmanager |
| Aktion | Anforderungsmanager |
| Kommentar | Alle |
| … | … |
Bitte beachten Sie, dass es sich hierbei lediglich um einen kleinen Auszug möglicher Attribute handelt, um Ihnen den grundsätzlichen Aufbau zu verdeutlichen. In einem realen Projekt wählen wir zu Beginn der Anforderungsanalyse gemeinsam mit Ihnen die für Ihren Anwendungszweck passenden Attribute aus unserem detaillierten Katalog aus.
Der Datenkatalog wird ebenfalls mit den bereits vorhandenen User Stories verknüpft, sodass diese, zusammen mit den Mockups und den zuvor im gesamten Projektteam gemeinsam definierten und abgestimmten Akzeptanzkriterien, den „single point of truth“ darstellen.
Fazit
Ein gutes Anforderungsmanagement stellt sicher, dass am Ende ein Produkt entwickelt wurde, das eine hohe User Experience und Usability für den Endanwender bietet – so wird die klassische „Entwicklung im Elfenbeinturm“ vermieden. Zudem unterstützt die Philosophie des „Fail early, fail often!“ die Erkennung von Fehlern in einem sehr frühen Projektstadium, wo diese noch mit geringem monetären Aufwand zu beheben sind. Wie im Beitrag verdeutlich wurde, reicht der alleinige Einsatz eines Werkzeuges nicht aus, um mögliche Probleme im Zusammenhang mit dem Anforderungsmanagement anzugehen. Vielmehr ist ein übergreifender, funktionierender und praxistauglicher Prozess erforderlich.
Um das beschriebene Vorgehen zu erreichen, haben wir im Rahmen intensiver Analysen und Workshops und in enger Zusammenarbeit mit Entwicklungs- und Fachbereichen eine Methode entwickelt, um alle aus UI-Konzeptionssicht benötigten Informationen zusammenzustellen und in die durch die verschiedenen Anforderungs-Tools zur Verfügung gestellten Strukturelemente einzubetten. Die Rolle des Requirements Engineer wird bei uns durch speziell dazu befähigte UI Consultants wahrgenommen, die stets die nutzerzentrierte Sichtweise berücksichtigen. Gerne demonstrieren wir Ihnen das Vorgehen dazu in einem persönlichen Gespräch oder in Form eines Workshops.
War dieser Artikel hilfreich für Sie? Oder haben Sie weiterführende Fragen zu SAP HCM? Schreiben Sie uns einen Kommentar oder rufen Sie uns gerne an.
Über den Autor
Thomas Bauer berät als Senior UX Consultant bei der CONET Business Consultants GmbH im Bereich DXM (Digital Experience Management) Kunden in allen Fragen rund um die Themen Usability, User Experience und aktuelle SAP-Frontend-Technologien. Er ist SAP Certified Associate Design Thinking sowie UXQB Certified Professional for Usability and User Experience Foundation Level (CPUX-F).
Jan Winsche berät als Senior UX Consultant bei der CONET Business Consultants GmbH im Bereich DXM (Digital Experience Management) Kunden in allen Fragen rund um das Thema User Experience, sowohl bei SAP als auch Non-SAP-Lösungen. Er ist SAP Certified Associate Design Thinking sowie UXQB Certified Professional for Usability and User Experience Foundation Level (CPUX-F).
Jan Stendenbach berät als Senior Consultant bei der CONET Business Consultants GmbH im Bereich DXM (Digital Experience Management) Kunden in allen Fragen rund um die Themen Usability & User Experience. Außerdem ist er als Requirements Engineer und Changemanager aktiv. Er ist als “SAP Certified Associate Design Thinking” sowie “Certified Professional for Requirements Engineering” zertifiziert.
