Requirements Engineering in a nutshell

Wünsch Dir was

Stelle Dir vor Du findest im Urlaub eine Wunderlampe in einer geheimnisvollen Höhle. Du putzt sie daheim und plötzlich erscheint ein Geist, der sich als Genie vorstellt. Er sagt, dass er Dir drei Wünsche erfüllt.

Du überlegst nicht lange und wünscht Dir einen Diamantring, das schnellste Auto der Welt und eine Luxusvilla im Barockstil auf deinem Lieblingsberg in der Stadt.

„Simsalabim, die Wünsche seien Dir erfüllt“ sagt der Genie. Plötzlich stehst Du in einer Luxusvilla auf deinem Lieblingsberg, vor Dir liegt ein Diamantring und vor der Villa steht das schnellste Auto der Welt. Die Lampe und der Genie sind auf mysteriöse Weise verschwunden. Du bist überglücklich und begutachtest Deine neuen Habseligkeiten.

Als Du versucht den Ring anzuprobieren stellst Du zu deiner Verwunderung fest, dass er viel zu klein für Deinen Finger ist. Etwas enttäuscht wirfst Du einen Blick raus in den Hof zum schnellsten Auto der Welt. Dort stellst Du zum Entsetzen fest, dass das Auto in grellem Pink lackiert ist. Leider die Farbe, die Du am wenigsten magst. Beim Blick durch die Fenster nach draußen siehst Du, dass das Fenster der Barokvilla einfach verglast ist. Des Weiteren sind alle Wände nicht isoliert, es gibt keine Elektrik und Heizung, sondern nur Kamine in jedem Zimmer. Die ganze Villa ist im technischen Stand von Ende des 17. Jahrhunderts.

Dir wird jetzt klar, dass Du Deine Wünsche wohl etwas deutlicher hättest beschreiben müssen, um wirklich das zu bekommen, was Du Dir gewünscht hast.

Wenn Du den Inhalt des nachfolgenden Artikels schon gelesen hättest, wäre das Dir sicher nicht passiert. 😉

‍

Ziel des Artikels

‍

In diesem Artikel möchte ich Dir in wenigen Minuten vermitteln, was die Kernaufgaben eines Requirements Engineers sind und wie er mit seiner Arbeit dazu beiträgt das letzten Endes ein Produkt entsteht, das seinen Kunden großen Nutzen stiftet und sie begeistert.

‍

Kernaufgaben eines Requirements Engineers

‍

Beim Requirements Engineer dreht sich im Grunde alles um Anforderungen. Diese müssen von Stakeholdern erfasst, dokumentiert, abgestimmt und verwaltet werden. Anforderungen dienen als Input bzw. die Ausgangsbasis für die Entwicklung des Produktes oder der Dienstleistung. Zudem sind sie eine wichtige Grundlage für die Testing-Aktivitäten nach der Entwicklung.

Hinweis: Die Rolle des Requirements Engineers tritt in der Praxis selten in „Reinform“ auf. Wir Projektberater bei der @fellowork wenden das Wissen und die Methodik des Requirements Engineering tagtäglich in Rollen als Produkt Manager, Product-Owner oder Business Analysten an. Wenn Du selbst eine dieser Rollen innehast, könnte es sich für Dich lohnen weiterzulesen 😉

‍

Was ist eine Anforderung?

‍

Unter einer Anforderung verstehen wir eine vom zu entwickelnden Produkt zur Verfügung gestellte Eigenschaft oder Fähigkeit, die von Stakeholdern gewünscht/gefordert wird oder eines seiner Bedürfnisse befriedigt. Anforderungen können in die Kategorie fachlich und qualitativ (nicht-fachlich) unterschieden werden.

Fachliche Anforderungen beschreiben Funktionen und Eigenschaften des Produkts. In der Regel gibt es bei fachlichen Funktionen immer einen wahrnehmbaren Unterschied zwischen der Ausgangssituation vor der Funktion und die Endsituation nach deren Ausführung.

Zum Beispiel führt die Funktion „rühren“ einer Backmaschine dazu, dass die zu Beginn getrennten Zutaten zum fertigen Teig vermischt werden.

Qualitativen Anforderungen haben in der Regel keine unterschiedlichen Ausgangs- und Endsituationen und ändern sich auch nicht über die Zeit. Typische Qualitative Anforderungen sind Performance, Usability (Benutzerfreundlichkeit), Zuverlässigkeit, Sicherheit und Wartbarkeit.

Eine qualitative Performance-Anforderung für die Funktion „rühren“ der Backmaschine könnte lauten: „Der Rührprozess sollte (selbst bei maximaler Befüllung) innerhalb von einer Minute die Backzutaten homogen vermischen.“

‍

Warum ist die Arbeit des Requirements Engineer so wichtig?

Anhand der 10er-Regel der Fehlerkosten, die aus dem Qualitätsmanagement kommt, wird deutlich, warum es so wichtig ist, direkt von Anfang an großen Wert darauf zu legen Anforderungen korrekt zu erfassen, abzustimmen und zu validieren.

Die 10er Regel besagt, dass die Kosten für die Entdeckung und Beseitigung von Produktfehlern mit jeder Phase des Produktlebenszyklus um den Faktor 10 steigen. Einen Fehler in der Planungsphase zu entdecken und zu beheben kostet 1 Euro, wohingegen die Beseitigung des gleichen Fehlers nach der Auslieferung 100.000 Euro kosten kann.

Die Anforderungen der Stakeholder werden grundsätzlich im klassischen Vorgehen aber auch in der agilen Welt initial in der Planungs- und Konzeptionsphase erfasst. Sie stehen an erster Stelle im Prozess.

Werden nun wichtige Wünsche, Bedürfnisse und Anforderungen nicht erfasst oder relevante Stakeholder(gruppen) nicht befragt und mit einbezogen, kann das im schlimmsten Fall dazu führen, dass das entwickelte Produkt bzw. entwickelte Dienstleistung floppt oder die entstandenen Fehler beseitigt und sehr kostenintensiv nachgebessert werden müssen.

Nehmen wir an, dass bei der Anforderungsanalyse zur Backmaschine der wichtige Stakeholder „Endnutzer“ (Hausfrau/-mann) nicht ausreichend befragt und die oben erwähnte Qualitätsanforderung „Der Rührprozess sollte (selbst bei maximaler Befüllung) innerhalb von einer Minute die Backzutaten homogen vermischen.“ nicht erfasst wurde.

Dieses Fehlen der Anforderung führt dazu, dass in der Maschine schon im Prototyp ein zu schwacher Motor eingebaut wird. Ohne die qualitative Anforderung wird auch kein spezifischer Test entwickelt, der eine gute „Performance“ der Backmaschine sicherstellt. Der Fehler bleibt unentdeckt und die Backmaschine wird in großer Stückzahl hergestellt, beworben und im Handel verkauft. Kurze Zeit später gibt es erste Beschwerden von Kunden, die mit der Rührleistung der Maschine bei voller Beladung sehr unzufrieden sind. Hinzu kommt, dass eine unabhängige Testzeitschrift, die an sich gute Maschine, stark abwertet nur aufgrund dieses Mangels.

Die Firma „Gut-Back GmbH“ beschließt den Fehler zu beheben und bietet den unzufriedenen Kunden die Möglichkeit des kostenlosen Umtauschs. Neben den fehlenden Verkäufen durch den Imageschaden werden allein die Kosten für die Umtauschaktion und die Änderung der Konstruktionspläne sowie der Produktionsanlage auf 3 Millionen Euro geschätzt.

Letztendlich hätte der Schaden vermieden werden können, wenn man diese qualitative Anforderung initial erfasst hätte.

‍

Vom Systemkontext zur Anforderung

‍

Aber wie kommt nun der Requirement-Engineer zu seinen für ihn und das Produkt/System so wichtigen Anforderungen.

Im Grund sind es im Kern fünf wesentliche Schritte zu den definierten Anforderungen:

1. Den Systemkontext analysieren
2. Klären von Zielen
3. Erheben von Wünschen, Bedürfnissen, Herausforderungen und Anforderungen
4. Use-Cases, Funktionen und Eigenschaften identifizieren
5. Systemanforderungen definieren und abstimmen

Hinweis: In der Praxis ist der Ablauf im Normalfall nicht so linear, wie hier im Artikel dargestellt. Die Übergänge der einzelnen Schritte sind meist auch nicht so scharf abgrenzbar. Vor allem im agilen Umfeld wiederholen sich die hier gezeigten 5 Schritte kontinuierlich mit unterschiedlichen Stakeholdern für jedes neue Komponenten oder Funktion eines Produktes (z.B. einer Software).

Die nachfolgende Grafik zeigt die Schritte grafisch aufbereitet in einer Übersicht. In den weiteren Abschnitten werden Dir die einzelnen Schritte sowie die Grafikelemente erläutert.

‍

Schritt 1: Den Systemkontext analysieren

‍

Alle Anforderungen, die an ein neu zu entwickelndes Produkt (System, Dienstleistung, Projektziel) gerichtet werden können, kommen aus seiner Umwelt bzw. dem Kontext, in dem sich das Produkt/System befindet.

Es ist nicht möglich die Funktion und den Sinn eines Produktes zu verstehen, ohne den Kontext zu kennen in dem es sich bewegt bzw. in dem es genutzt wird.

Im ersten Schritt geht es dem Requirements Engineer deshalb darum, die für die Produkt-/Systementwicklung relevanten Anforderungsquellen, wie Stakeholder, IT-Systeme (Software & Hardware), Schnittstellen, Geschäftsprozesse, Unternehmen, Lieferanten und Organisationen zu identifizieren. Im Kontext gibt es zudem noch einschränkende Randbedingungen, die z.B. durch gesetzliche Vorgaben, Normen oder das Unternehmensrichtlinien bedingt sind.

Im Backmaschinen-Beispiel identifiziert der Requirements Engineer als wichtige Anforderungsquellen im Kontext der zu entwickelnden Backmaschine, u.a.:

Stakeholder:

• Nutzer (Hausmann/-frau)
• Zulieferer
• Händler
• Verkäufer
• …

IT-Systeme:

• Lagermanagementsystem
• Bestell- und Abrechnungssystem
• Server mit Rezeptvorschlägen
• …

Prozesse:

• Produktion
• Marketing
• Vertrieb
• Entwicklung
• …

Randbedingungen

• Norm: EN 60335: Sicherheit von elektrischen Haushaltsgeräten und ähnlichen Elektrogeräten
• Norm: ISO 9001 - DIE Norm im Qualitätsmanagement
• Methodik: Scrum
• Richtlinie: Dokumentationsrichtlinie

In Zusammenarbeiten mit den relevanten Stakeholdern (z.B. zukünftige Nutzer, Kollegen, Vertreter der relevanten Fachbereiche, Geldgeber…) und unter Einbezug verfügbarer Dokumente, Richtlinien und Gesetze kann so eine Systemgrenze herausgearbeitet werden. Alles, was sich innerhalb der Systemgrenze befindet kann, bei der Produktentwicklung frei gestaltet werden. Eine Gestaltung sollte stets im Sinne der Wünsche und Bedürfnisse der Stakeholder erfolgen. Die Systemgrenze legt den Produkt- bzw. System-Scope fest. Dinge, die außerhalb der Systemgrenze liegen, sind nicht Bestandteil des Produktes. Sie können und sollen auch nicht beeinflusst werden.

Beispielsweise können die Funktionen der Backmaschine beliebig aussehen, der Steckdosenanschluss und die Betriebsspannung muss jedoch normgerecht erfolgen. Die Steckdose und die Netzspannung gehört zu Systemumwelt und können nicht beeinflusst werden. Gleich verhält es sich bei gesetzlichen Vorgaben. Sie gehören immer zur Systemumwelt, da sie nicht verändert werden können.

Der Systemkontext kann vom Requirements Engineer in einer Kontextmap übersichtlich inkl. vorhandener Abhängigkeiten dargestellt werden (siehe Schaubild).

Neben der Kontext-Map sollte auch eine Stakeholderliste angelegt werden, in der die wichtigsten Stakeholder-Daten für alle Beteiligten einsehbar hinterlegt sind.

‍

Schritt 2: Klären von Zielen

‍

Im weiteren Vorgehen empfiehlt es sich z.B. in einem ersten Workshop mit allen relevanten Stakeholdern die grundlegenden Ziele und dahinterstehende Interessen in Erfahrung zu bringen (Zielanalyse durchfrühen). Angestrebt wird es ein erstes grundlegendes gemeinsames Verständnis zum Vorhaben/Produkt zwischen den Stakeholdern herzustellen und schon direkt zu Beginn potenzielle Ziel- und Interessenkonflikte zu identifizieren.

Die definierten Ziele eignen sich als erste Basis zur Ableitung von Anforderungen und können im späteren Verlauf auch bei der Validierung herangezogen werden.

Identifizierte potenzielle Ziel- und Interessenkonflikte sollten im weiteren Verlauf ernst genommen werden und möglichst schon früh in Gesprächen mit den Konfliktparteien zur Zufriedenheit aller gelöst werden.

‍

Schritt 3: Erheben von Wünschen, Bedürfnissen, Herausforderungen und Anforderungen

‍

Um an die Bedürfnisse (B), Wünsche (W), Herausforderungen (H) und Anforderungen (A) zu gelangen, die Stakeholder, Organisationen, IT-Systeme, Prozesse und rechtliche Vorgaben an das zu entwickelnde Produkt/System stellen, bedient sich der Requirements Engineer verschiedener Ermittlungstechniken.

‍

Ermittlung von Anforderungen

Ein Teil der Ermittlungstechniken stellen Ergebungstechniken dar. Zu den Ergebungstechniken zählen u.a.:

• Befragungen (Interview, Fragebogen)
• Kollaborationen (Workshops, Crowed-basiertes RE)
• Beobachtungen (Feldbeobachtung, Apprenticing)
• Artefakten basiertes Vorgehen (Systemarchäologie, Wiederverwendung, Feedback-Analyse)

Der andere Bereich der Ermittlungstechniken sind die Entwurfs- und Ideenfindungstechniken. Sie eignen sich gut dazu, völlig neue und innovative Ideen und Anforderungen zu generieren, die den Nutzer begeistern. Man unterscheidet in:

• Kreativitätstechniken (Brainstorming, Analogie)
• Designtechniken (Design Thinking, Prototyping, Szenarios)

Der Requirements Engineer der Firma „Gut-Back GmbH“ nutzt verschiedene Techniken, um an die gewünschten Anforderungen zu gelangen.

Stakeholder:

Nutzer (Hausmann/-frau): Die eigentlichen Nutzer und Käufer der Backmaschine sind für den Produkterfolg besonders wichtig, weshalb der Requirements Engineer dieser Stakeholdergruppe extra viel Aufmerksamkeit widmet. Er führt mehrere Maßnahmen durch, um ein facettenreiches Anforderungsprofil zu erhalten. Ziel ist es als Ergebnis zum Ende dieses Prozesses eine Sammlung von Use-Cases (Anwendungsfällen) in den Händen zu halten. Ein Use-Case beschreibt, wie der Nutzer mit der Backmaschine interagiert und welche Funktionen / Eigenschaften letztendlich gewünscht sind.

Um dem Nutzer Basis-Anforderungen zu entlocken, beobachtet er einige Nutzer bei der Verwendung von Backmaschinen. Basis-Anforderungen sind Anforderungen, die der Nutzer zwar unterbewusst fordert, die er aber – wenn er direkt befragt – wird i.d.R. nicht erwähnt.

Zudem führt er einen Brainstorming-Session mit einer Gruppe ausgewählter Nutzer durch, in der völlig neuen Ideen generiert werden sollen. Durch innovative Funktionen, die begeistern, sollen sich die neue Backmaschine sich von der Konkurrenz abheben. Mit dieser Kreativitätstechnik sollen bewusst Begeisterungs-Anforderungen gewonnen werden.

Ergänzend wird den „Gut-Back GmbH“ der Kunden, die sich für den Newsletter angemeldet haben, ein Online-Fragebogen zugesendet, in dem sie gefragt werden, welche Funktionen und Eigenschaften ihnen besonders wichtig sind bei einer Backmaschine. In der Befragung wurden primär Leistungs-Anforderungen ermittelt. Also Anforderungen, die sich Kunden bewusst wünschen und die für einen Produkt- und Verkaufserfolg wesentlich sind.

Zulieferer: Der Requirements Engineer entscheidet sich die Anforderungen des Zulieferers im direkten Gespräch in Form eines Interviews zu ermitteln.

Händler, Verkäufer & Marketing: Da Handel, Verkauf und Marketing eng verwoben sind entscheidet er sich für einen Workshop mit Repräsentanten der Fachbereiche.

IT-Systeme:

Lagermanagementsystem, Bestell- und Abrechnungssystem, Server mit Rezeptvorschlägen:

In einzelnen Gesprächen mit den IT-Systemverantworlichen klärt der Requirements Engineer, welche IT-Schnittstellen relevant sind und welche Anforderungen diese Schnittstellen an das zu entwickelnde Produkt haben.

Prozesse:

Entwicklung, Produktion, Marketing, Logistik, Vertrieb: In Gesprächen mit den Fachabteilungen bringt der Requirements Engineer in Erfahrung, welche Vorgehensweisen, Richtlinien, Normen und Standards zu beachten sind.

Randbedingungen

Normen & Gesetze: Der Requirements Engineer prüft welche Aspekte der identifizierten Normen und Gesetzte für die Entwicklung des Produktes relevant sind und leitet zu beachtende Randbedingungen ab.

Methoden & Richtlinien: Der Requirements Engineer hält sich an die unternehmensweit geltenden Dokumentations- und Arbeitsrichtlinien. Er nutzt zur Dokumentation von Anforderungen, Use-Cases zur Verfügung gestellte Satzschablonen und Dokumentenvorlagen.

‍

Dokumentation von Anforderungen

‍

Alle im Erhebungsprozess ermittelten Anforderungen werden systematisch und strukturiert zentral für alle einsehbar dokumentiert. Ebenso müssen die dokumentierten Anforderungen in regelmäßigen Abständen erneut betrachtet und durch die betroffenen Stakeholder validiert werden.

Anforderungen können auf verschiedene weißen dokumentiert werden. Zum einen natürlichsprachiger Form, also in Form eines Textes bzw. Satzes. Zum anderen in einer grafischen Modellform. Häufig zum Einsatz kommende Modell- bzw. Diagrammtypen zur Dokumentation von Anforderungen sind:

• Klassendiagramm (Bezug auf Datenstruktur)
• Aktivitätsdiagramm (Bezug auf Funktion und Ablauf/Prozesse)
• Anwendungsfalldiagramm (Bezug auf Userinteraktion und Funktion)
• Zustandsdiagramm (Bezug auf Ereignisse und Verhalten)

In den meisten Fällen bietet sich eine Kombination beider Dokumentationsarten an, indem Anforderungen in natürlichsprachiger Form durch passende Diagramme und Modell ergänzt werden und umgekehrt.

‍

Problemraum – Was ist das Problem? Was wird gewünscht?

‍

Die meisten in dieser Phase festgehaltenen Anforderungen werden von außen an das System / Produkt gerichtet. Es wurde herausgearbeitet „was“ das Problem ist und „was“ das neue Produkt können soll.

Man spricht in diesem Zusammenhang auch von Problemraum, da noch unklar ist, bzw. es nicht feststeht, wie die Wünsche und Probleme dann konkret vom System/Produkt gelöst werden sollen.

Wenn man alle Anforderungen aus dem Problemraum in einer Anforderungsspezifikation (umfangreiches Dokument mit allen zu erfüllenden Anforderungen) sammelt entsteht daraus ein Lastenheft.

Würde die „Gut-Back GmbH“ die Entwicklung des Backmaschine komplett Outsourcen, wäre das Lastenheft für den Zulieferer, der das Produkt entwickelt, die Ausgangsbasis, um konkrete Anforderungen an das eigentliche Produkt zu entwickeln. Der Zulieferer würde Anforderungen an das Produkt ableiten und dabei genau definieren, „wie“ er die Lösung für die geforderten Eigenschaften und Funktionen umsetzt. Alle Anforderungen des Lösungsraumes gebündelt in einem Dokument sind die Basis des Pflichtenheftes.

Das Pflichtenheft („wie“) des Auftragnehmers ist die Antwort bzw. das Gegenstück zum Lastenheft („was“) des Auftraggebers.

‍

Schritt 4: Use-Cases, Funktionen und Eigenschaften identifizieren

‍

In vierten Schritt wendet der Requirements Engineer den Fokus verstärkt vom Problemraum hin zum Lösungsraum. Das heißt er überführt die von den Stakeholdern gesammelten Wünschen, Herausforderungen, Bedürfnisse und Anforderungen schrittweise in Funktionen, Eigenschaften und konkrete System-Anforderungen, die mit klaren und messbaren Akzeptanzkriterien versehen sind.

Beispiel Stakeholder-Wunsch: „Kinder sollen sich an dem Gerät, die Hände nicht verbrennen können.“

Beispiel Lösung/Systemanforderung: „Die Backmaschine ist so aufgebaut, dass alle von außen zugänglichen Teile (Außenwände, Griffe etc.) nicht wärmer als 45° C werden, damit sich niemand die Hände verbrennen kann.

‍

‍

Konkrete Funktionen und Eigenschaften lassen sich initial mithilfe von Use-Case-Diagrammen in Zusammenarbeit mit den Stakeholdern identifizieren. Ausgehend von Use-Case-Diagramm können im Folgenden dann Detailbeschreibungen für die einzelner Use-Cases und deren Sonderkonstellationen (Szenarien) ausgearbeitet werden. Ziel ist es, dass möglichst viele Bedürfnisse und Wünsche relevanter Stakeholder durch Funktionen und Eigenschaften des Systems befriedigt werden.

‍

Schritt 5: Systemanforderungen definieren und abstimmen

‍

Im nächsten Schritt werden die identifizierten Funktionen und Eigenschaften durch fachliche und qualitative Anford Anforderungen (Systemanforderungen) zurückzuführen sein auf eine von außen an das System/Produkt gerichtete Anforderung, Wunsch oder Bedürfnis der Stakeholder.

In Summe bilden alle an das Produkt/System gerichteten fachlichen und qualitativen Anforderungen die Basis für das Pflichtenheft.

‍

Die erfassten fachlichen und qualitativen Anforderungen auf Systemebene, können in den weiteren Schritten noch verfeinert und weiter in Komponentenanforderungen heruntergebrochen werden. Der Detailgrad von Anforderungen sollte stets so hoch sein, dass diese als Input in nachfolgenden Prozessschritten (z.B. die Entwicklung oder das Testing) gut verwendet werden können.

Beispiel für Anforderung auf Systemebene:

„Der Rührprozess sollte (selbst bei maximaler Befüllung) innerhalb von einer Minute die Backzutaten homogen vermischen.“

Beispiel für Anforderung auf Komponentenebene:

„Unter voller Belastung sollte die Rührgeschwindigkeit nicht stärker als 10% zu dem für die Rührstufe definierten Standard abfallen“

„Der verbaute Motor hat eine Minderleistung von 1000 Watt“

„Das verbaute Motor hat ein Drehmoment von mindestens 50 Nm“

In allen Phasen der Anforderungserhebung ist ein Austausch mit den für die Anforderungen relevanten Stakeholdern sehr wichtig. Immer ist zu beachten, dass erst durch die finale Bewertung (Validierung) der Anforderungen durch die Stakeholder, eine Anforderung zur Anforderung wird.

‍

Validierung von Anforderungen

‍

Zur Validierung der Anforderungen gibt es verschiedenste Möglichkeiten. Zum einen gibt es Reviews (Überprüfungen) bei denen Stakeholder gezielt Feedback geben zu betrachteten Anforderungen. Es gibt verschiedenen Arten von Reviews. In der einfachsten Form als Stellungnahme einer Einzelperson, über einen Walkthrough (Meeting mit mehreren Experten) bis hin zur streng formalen Inspektion mit unabhängigen externen Prüfern.

Eine andere Möglichkeit der Validierung stellen explorative Vorgehensweisen dar, bei denen Tests an Prototypen bzw. schon implementieren Lösungen (A/B-Tests, Alpha- und Beta-Tests) durchgeführt werden und es den Nutzern ermöglicht wird schon im frühen Stadium Feedback zu geben.

Der Requirements Engineer der „Gut-Back GmbH“ entscheidet sich für Reviews als auch für explorative Vorgehensweisen.

Bei den Anforderungen, wo es ihm sinnvoll erscheint, holt er sich Stellungnahmen einzelner Experten ein. Er klärt z.B. die Anforderung zur Schnittstelle des Lagesystems in einem Meeting mit seinem primären Ansprechpartner.

In vielen Fällen macht es Sinn Anforderungen in einer Gruppe bestehend aus unterschiedlichen Stakeholdern zu validieren. Hierdurch werden Unterschiede im Verständnis, potenzielle Konflikte und Missverständnis wahrscheinlicher aufgedeckt. Die Gruppe ermöglicht es i.d.R. zudem direkt Lösungsansätze für Probleme und Konflikte zu finden. Beispielsweise organisiert der Requirements Engineer einen Walkthrough mit Vertretern von der Entwicklung, Produktion, des Marketings, Logistik und Vertrieb, um die Anforderungen möglichst von allen Seiten zu beleuchten.

Gesondert organsiert er ein Meeting in dem er einer ausgewählten End-Nutzergruppe mit Hausmännern und -frauen, den Entwurf des finalen Produktes zeigt und die damit zusammenhängenden Anforderungen durchspricht. Abhängig vom Feedback der Nutzergruppe muss der Entwurf dann nochmals überarbeitet und Anforderungen angepasst werden.

Basierend auf dem überarbeiteten Entwurf und den validierten System-Anforderungen wird ein erster Prototyp der Backmaschine entwickelt.

Nach dessen Fertigstellung wird die Nutzergruppe erneut eingeladen, um einen Praxistest am Prototyp durchzuführen. Abhängig vom Feedback muss dann der Prototyp und die damit verbundenen Anforderungen nochmals überarbeitet werden. Im Fall eines durchweg positiven Feedbacks, können die Anforderungen in die Entwicklung und Produktion übergeben werden, die dann das Produkt für den Massenmarkt tauglich entwickelt und produziert.

‍

Änderungsmanagement

‍

Ein weiteres wichtiges Thema ist der Umgang mit Änderungen. Es ist normal das sich Anforderungen ändern, weil Stakeholder durch neues Wissen oder besseres Verständnis zum System/Produkt ihre Meinung wechseln. Ebenfalls können Änderungen im Umfeld neue Gesetze, neue Produkte am Markt oder gesellschaftlicher Wandel dazu führen, dass Anforderungen überarbeitet werden müssen.

Bei der Backmaschine sind Änderungen, nachdem die Maschine auf den Markt gekommen ist kaum mehr möglich oder sehr kostenintensiv. Deshalb ist es wichtig vor dem Breiteneinsatz in der Entwurfs- und Konzeptionsphase möglichst alle Änderungswünsche zu berücksichtigen. Änderungswünsche von Kunden und Feedback kann zwar gesammelt und ausgewertet werden, aber erst zeitlich verzögert in einer neuen Produktserie bzw. dem Nachfolgeprodukt berücksichtigt werden.

Anders verhält es sich bei Software-Produkten, die in der Regel agil, also in kleinen Schritten (iterativ), entwickelt und umgesetzt werden. Hier können Änderungen von Stakeholdern einfacher berücksichtigt und oft auch zeitnah umgesetzt werden. Da Entwicklungszyklen in der Regel zwischen zwei und vier Wochen gehen, kann theoretisch mit jedem neuen Zyklusbeginn Änderungswünsche einpriorisiert werden.

Unabhängig vom der Arbeitsmethodik sollten alle gewünschten Änderungen an Anforderungen (Änderungsanträge) immer hinsichtlich ihrer Auswirkungen (Risiken, Kosten, Nutzen…) analysiert und bewertet werden, bevor es zur wirklichen Änderung in der Anforderungen kommt. Basierend auf der Bewertung erfolgt dann eine Einplanung und Priorisierung der Änderung oder eine Verwerfung dieser. In vielen Fällen übernimmt diese Funktion ein Änderungsgremium (Control Change Board).

‍

Konfliktlösung, Prozesse und Arbeitsstruktur und Werkzeugunterstützung

‍

Neben dem hier vorgestellten Grundvorgehen gibt es darüber hinaus weitere Themenfelder, auf die hier nicht mehr im Detail eingegangen werden kann. Der Requirements Engineer sollte grundsätzlich Konflikte frühzeitig erkennen und möglichst eine Lösung herbeiführen können. Des Weiteren ist es in seiner Verantwortung zu Beginn das zum Kontext passende Vorgehen (Prozess, Arbeitsergebnisse, Methodik…) zu wählen, dass es ihm erlaubt die Anforderungen in guter Qualität, aber zugleich mit wenig Aufwand strukturiert zu erheben. Im Idealfall schafft es der Requirements Engineer eine End-zu-End-Rückverfolgbarkeit (Traceability) herzustellen bei der jede Anforderung eines Stakeholders verfolgt werden kann bis zur entsprechenden Funktion im fertigen Produkt und umgekehrt. Zur Herstellung einer Traceability bedarf es vor allem komplexen Vorhaben mit vielen Anforderungen technische Unterstützung durch ein geeignetes Software-Tool.

‍

Abschließende Worte

‍

Ich hoffe der Artikel hat Dir gefallen und konnte Dir die Welt eines Requirements Engineers etwas näherbringen, obwohl er wegen seiner Länge wohl eher eine Coconutshell als eine normale Nutshell war.

Wenn Dich das Thema über den Artikel hinaus interessiert, empfehle ich Dir das Buch „Basiswissen – Requirements Engineering“ von Klaus Pohl und Chris Rupp. Dieses Buch eignet sich zudem super zur Vorbereitung auf die Zertifizierung „Certified Professional for Requirements Engineering – Foundation Level“ (CPRE) vom International Requirements Engineering Board (IREB).

Über Feedback oder weitere Anregungen in den Kommentaren würde ich mich natürlich freuen. Bei Fragen kannst Du mir diese auch gerne in die Kommentare schreiben, ich werde sie dann zeitnah beantworten. Falls Du jemanden kennst, der sich für das Thema interessiert, kannst Du den Artikel gerne teilen.

Besten Dank für Dein Interesse!

‍