• Systemischer Blick auf Requirements Engineering
• Requirements Engineering Methodik
• Fazit

Requirements Engineering spielt heutzutage immer wichtigere Rolle, ob es um Software oder Hardware Entwicklung, einfache oder sehr komplexe Produktentwicklungen geht. 

Durch die steigende Vernetzung und Komplexität der Produkte wachsen auch sowohl interne als auch externe Anforderungen.

Die Normen, Richtlinien und Prozesse national oder international steigen permanent und werden immer unübersichtlicher. 

Qualifizierte Ingenieure, die sich mit Requirements Engineering gut auskennen, werden immer gefragter.

Das VUCA Umfeld (Volatility, Uncertainty, Complexity, Ambiguity) macht uns immer mehr zu schaffen.

Durch die ständige Detaillierung, Vertiefung und Vernetzung hat man das Gefühl, den Wald vor lauter Bäumen nicht mehr sehen zu können.

Wie kann man sich heutzutage trotz Schwankungen im Marktumfeld, Unsicherheiten im Projektumfeld, der steigenden Komplexität der Produkte und sich daraus ergebenden Missverständnisse und Misskommunikation auf das Wesentliche im Requirements Engineering fokussieren und gefragte Produkte entwickeln?

Mit dieser Frage wollen wir uns in diesem Artikel beschäftigen.

Systemischer Blick auf Requirements Engineering

Auch wenn es nicht intuitiv erscheint, ist der erste Schritt nicht die Erhöhung der Komplexität, sondern eine drastische Vereinfachung notwendig.

Dies ist möglich, wenn als Erstes ein Blick auf das ganze System ermöglicht wird und daraus wirklich notwendige Schritte abgeleitet werden.

Der Kunde ist König

Obwohl dies immer wieder vergessen wird und der Fokus auf die detaillierten Anforderungen bei einer Produktentwicklung viel zu oft gerichtet wird, ist es gerade deswegen äußert wichtig nicht zu vergessen, für wen ein Produkt entwickelt wird.

Dabei geht es um zwei wichtige Bausteine:

1. Volle Fokussierung auf den Kunden und seine Bedürfnisse
2. Das Denken wie der Kunde

Der Lebenszyklus eines zufriedenen Kunden sieht wie folgt aus:

Der entscheidende Punkt bei der Ermittlung der Anforderungen für ein Produkt ist nicht, dass die Kunden einfach zufrieden sind.

Das Ziel ist, ein Produkt so gut wie möglich zu machen und die Erwartungen der Kunden zu übertreffen.

Dies wird dazu führen, dass die Kunden gerne ein Produkt weiterempfehlen und auch weitere Produkte kaufen.

Diese Vorgehensweise wird ein Unternehmen nicht nur profitabler machen, sondern auch dafür sorgen, dass es möglich sein wird, die Zeit und den Fokus auf die Erstellung richtiger Produkte zu richten und die Produkte besser zu machen.

Schnelles Feedback ist entscheidend

Ein weiterer Aspekt im Requirements Engineering ist der Fokus auf die schnellen Feedbacks der Kunden im Prozess der Produktentwicklung. Dies ist z.B. mit einem Minimum Viable Product (MVP) möglich. 

Wenn die Anforderungen ermittelt sind, ist es von großer Bedeutung ein minimal funktionsfähiges Produkt zu entwickeln, das den Kunden-, Markt- und den Funktionsbedarf abdeckt, um ein schnelles Feedback zu holen.

Dies wird helfen, die Verbesserungen so früh wie möglich einzusteuern und den unnötigen Entwicklungsaufwand so gering wie möglich zu halten.

Die Abbildung beschreibt einen vierstufigen Prozess.

Im Schritt 1 werden die Anforderungen nicht nur einmal besprochen, sondern in mehreren Frage und Antwort Sessions.

Im Schritt 2 wird darauf basierend ein Produktkonzept erarbeitet.

Im Schritt 3 wird das Konzept umgesetzt.

Im Schritt 4 wird das MVP (Minimum Viable Product) entwickelt und dem Kunden bzw. dem Markt zur Verfügung gestellt. Basierend auf dem Feedback der Kunden / vom Markt wird das Produkt weiterentwickelt.

Je kürzer dieser vierstufige Prozess desto schneller ist es möglich, ein Produkt zu entwickeln, das nicht nur die Bedürfnisse der Kunden und des Marktes erfüllt, sondern diese übertrifft. 

Simplicity – Priorisierung nach MoSCoW Prinzp

Was im Requirements Engineering auch sehr wichtig ist, die ermittelten Anforderungen so einfach und so klar wie möglich zu priorisieren.

Aus der Projektmanagement Praxis hat sich die Priorisierung nach MoSCoW-Prinzip vielfach bewährt

Am Beispiel eines klassischen Fahrrads wollen wir nun die Anforderungen nach MoSCoW-Prinzip  priorisieren:

• M steht für  Must (Muss-Anforderungen) – Dazu gehören Räder, ein Fahrradrahmen, ein Fahrradsitz, ein Lenkrad. Die Bremsen sind z.B. nicht unbedingt notwendig, da auch mit Füßen gebremst werden kann
• S steht für Should (Soll-Anforderungen) – Dazu gehören Fahrradpedale, Bremsen, Beleuchtung, eine Fahrradklingel, ein Fahrradhelm
• C steht für Could (Kann-Anforderungen) – Dazu gehören heutzutage ein Navigationssystem, eine Fahrradbrille
• W steht für Won’t have (überflüssige Anforderungen) – für Normalfahrer sind keine speziellen Fahrradklamotten notwendig und auch kein Flaschenhalter

Mit so einem einfachen Priorisierungssystem können beliebige Anforderungen schnell und unkompliziert priorisiert werden.

Requirements Engineering Methodik

Es gibt verschiedene Requirements Engineering Methoden, die sehr tief gehen, um die Wissenschaft von Requirements Management zu erklären.

Je nachdem, ob es um sicherheitsrelevante Produkte wie z.B. ein Zug, ein Flugzeug, kleine sicherheitsrelevante Produkte oder nicht sicherheitsrelevante Produkte geht, gibt es entsprechende gesetzliche Normen und Vorgaben, die im Falle eines sicherheitsrelevanten Produktes unbedingt zu erfüllen sind.

Nach IREB ( International Requirements Engineering Board) besteht ein solides Requirements Engineering aus den folgenden Schritten:

• Anforderungen ermitteln
• Anforderungen dokumentieren
• Anforderungen prüfen und abstimmen
• Anforderungen verwalten

Die oben genannten Schritte werden im Rahmen eines Projektes in verschiedenen Projektphasen und Prozessgruppen durchgeführt.

Anforderungen ermitteln

Sobald relevante Anforderungsquellen wie z.B. existierende Produkte oder Stakeholder identifiziert sind, geht es an die Arbeit, um die Anforderungen zu ermitteln.

Bei der Ermittlung von Anforderungen hat sich das Kano-Modell bewährt, das die Anforderungen nach folgenden Kategorien unterteilt:

• Basisfaktoren – Das sind selbstverständliche Faktoren, die bei Nichterfüllung zur Unzufriedenheit der Kunden führen können. Wenn z.B. ein Smartphone heutzutage ohne eine Kamera verkauft wird, wird so ein Smartphone kaum verkauft. Vor 10-15 Jahren wäre eine Kamera in einem Smartphone ein Leistungs- bzw. sogar ein Begeisterungsfaktor.
• Leistungsfaktoren – Das sind Faktoren, die je nach Grad der Erfüllung für die Zufriedenheit der Kunden sorgen. Bei einem Headset für jemanden, der mittel bis viel telefoniert, wäre das z.B. ein Headset, das gut Umgebungsgeräusche unterdrückt, ein gutes Mikrofon hat und auch nach langem Telefonieren keine Ohrenschmerzen verursacht.
• Begeisterungsfaktoren – Das sind Faktoren, mit denen der Kunde in der Regel nicht rechnet und welche für Begeisterung sorgen. Sogar eine kleine Leistungssteigerung eines Produktes von der Konkurrenz kann dafür sorgen, dass die Zufriedenheit der Stakeholder überproportional steigt. In den meisten Fällen handelt es sich um Produkte mit speziellen Extras wie z.B. ein Auto mit Sonderausstattung.

Wie oben bereits beschrieben, der Kunde ist König. Der Hauptfokus geht auf den Kunden und seine Bedürfnisse.

Darüber hinaus ist es sehr wichtig zu lernen, wie ein Kunde denkt und was für ihn wichtig ist.

Aus diesem Grund ist es entscheidend neben der Erfüllung der Basis- und Leistungsfaktoren die Begeisterungsfaktoren im Fokus zu behalten.

Anforderungen dokumentieren

Wenn die Anforderungen ermittelt sind, ist es wichtig, die Anforderungen professionell zu dokumentieren.

Es gibt unterschiedliche Formen, wie Anforderungen dokumentiert werden können. Einige Beispiele davon sind: 

• Anforderungen können als Diagramme abgebildet werden (z.B. als Ablaufdiagramm, Kontextdiagramm, Baumdiagramm, System-Diagramm, Zustandsdiagramm oder Sequenzdiagramm)
• Anforderungen können mit professionellen Tools modelliert werden, um komplexe Abhängigkeiten darzustellen 
• In der agilen Welt z.B. SCRUM werden Anforderungen in Form von so genannten Epics (für  Anforderungen auf hoher Ebene) und in Form von User Stories (für Detailbeschreibungen) dokumentiert. In der Regel benutzt man dafür spezielle Tools wie z.B. JIRA

Anforderungen prüfen und abstimmen

Wie oben unter “Schnelles Feedback ist entscheidend” beschrieben ist, ist es wichtig, die Anforderungen mit dem Kunden in mehreren Schleifen zu prüfen und abzustimmen.

In der Praxis haben sich verschiedene Formen der Prüfung und Abstimmung von Anforderungen bewährt. Neben der Prüfung und Abstimmung “auf Papier” werden abhängig von der Komplexität eines Produktes immer mehr zusätzliche tool-basierte Formen angewandt. Dazu gehören z.B.

• Modellierung der Anforderungen im frühen Projekt- und Produktstadium (z.B. als 3D), um komplexe Zusammenhänge abzubilden und Fehler so früh wie möglich auszuschließen 
• Nachbildung von physikalischen Produkten mit Hilfe von 3D-Druck in Originalgröße, um z.B. frühzeitig notwendige Änderungen am Design vorzunehmen
• Virtuelle Abbildung von benötigten Produkten und jeweiligen Funktionen, um rechtzeitig sowohl Designfehler als auch Funktionsfehler bzw. fehlende Funktionen oder auch Kollisionen (z.B. im Anlagenbau Kollision von Robotern mit Teilen einer Anlage)  zu identifizieren und entsprechende Maßnahmen noch im Frühstadium festzuhalten

Anforderungen verwalten

Zum professionellen Requirements Engineering gehört es natürlich dazu, dass die Anforderungen so transparent wie möglich verwaltet werden.

Dabei spielt eine durchdachte Gliederungsstruktur eine sehr wichtige Rolle. Darüber hinaus soll auch bedacht werden, wie Änderungen oder Hinzufügen/Entfernen der Anforderungen dokumentiert und genehmigt werden.

Je nach Komplexität eines Produktes kann es sehr viele Anforderungen geben. Da jede Anforderung eindeutig sein soll, ist es natürlich notwendig, dafür eindeutige Objekt-IDs zu vergeben.

Am besten eignet sich dafür ein professionelles Requirements Management Tool wie z.B. DOORS von IBM.

Mit DOORS habe ich mehrere Jahre sehr erfolgreich gearbeitet und Anforderungen verwaltet.

Bei der Verwaltung von Anforderungen ist die Transparenz sehr wichtig. Die Transparenz kann deutlich erhöht werden, wenn Anforderungen mit Hilfe einer Requirements Management Matrix verwaltet werden.

Eine Requirements Traceability Matrix stellt sicher, dass z.B. Business Anforderungen über funktionale Anforderungen, Use Cases und Test Cases miteinander verbunden und leicht zuzuordnen sind.

Wenn z.B. Tests durchgeführt und Fehlfunktionen festgestellt werden, kann die Kette bis nach ganz oben zu den Business Anforderungen leicht nachvollzogen werden, um notwendige Maßnahmen festzulegen.

Im Requirements Management Tool wie DOORS ist die Erstellung einer Requirements Traceability Matrix sehr gut möglich. Die Requirements Traceability Matrix kann im Prinzip auch in Excel erstellt werden.

Fazit

Professionelles Requirements Engineering spielt bei jeder Produktentwicklung eine wichtige Rolle. Professionell heißt allerdings nicht, dass es überladen ist. 

Praktisches Requirements Engineering nach Pareto Prinzip hat den Kunden maximal im Fokus, so dass der Kunde mit den Produkten möglichst hochzufrieden ist (Begeisterungsfaktor nach Kano-Modell).

Dabei ist es absolut notwendig, eine schnelle Feedbackschleife mit dem Kunden zu installieren, die es ermöglicht, sowohl Anforderungen möglichst schnell zu ermitteln als auch Produkte für die Verifikation seitens der Kunden und des Marktes schnell auf den Markt zu bringen.

Dabei sollte man sich auf langfristige Ziele und nicht kurzfristige Gewinne fokussieren und diese im Business Case berücksichtigen. Langfristiges Denken und der maximale Fokus auf die Kunden ist der Schlüssel zum Erfolg.

Und wenn dabei vereinfachte Methoden vom Requirements Engineering zum Einsatz kommen wie Priorisierung nach MoSCoW Prinzip und die Grundlagen der Requirements Engineering Methoden bestehend aus Anforderungen ermitteln, Anforderungen dokumentieren, Anforderungen prüfen und abstimmen und Anforderungen verwalten, steht einer erfolgreichen Produktentwicklung mit hoher Kundenzufriedenheit nichts mehr im Wege.