Viele Bücher sind in den letzten 30 Jahren geschrieben worden zum Thema Requirements Engineering. Viele haben sich mit dem Thema beschäftigt. Die Methode wurde entworfen und verbessert. Der große Erfolg dieser Bemühungen liegt darin, dass das Bewusstsein für das Thema in einem breiten Fachpublikum bewusst gemacht wurde. Es gibt heute kaum noch jemanden der grundlegend bestreiten würde, dass Requirements Engineering für Software lastige Embedded Systeme und IT-Systeme sinnvoll ist. Andererseits kann auch festgestellt werden, dass die praktische Umsetzung von Requirements Engineering in den Projekten immer noch deutliche Mängel aufweist. An dieser Stelle setzt der nachfolgende Beitrag an. Anhand einiger ausgewählter Themen des Requirements Engineering zeige ich Differenzen auf, zwischen den Vorgaben in der Methodenbeschreibung, und dem Bedarf in der Praxis. Mögliche Lösungen werden angedeutet, sind aber nicht Bestandteil dieses Beitrags. Hier geht es zunächst einmal „nur“ um die Schärfung des Bewusstseins für die Problematik.

Theoretische Grundlagen auf die sich dieser Beitrag bezieht

Als wichtige Repräsentation der dokumentierten Requirement Engineering Theorie bilden folgende Bücher die Grundlage des vorliegenden Beitrags:

• Basiswissen Requirements Engineering von Klaus Pohl und Chris Rupp
• Systematisches Requirements Engineering von Christof Ebert
• Requirements Engineering und -Management von Chris Rupp

Was ist eine Anforderung?

Christof Ebert definiert eine Anforderung wie folgt:

Eine Anforderung beschreibt, was der Kunde oder Benutzer vom Produkt erwartet, also Bedingungen, Attribute, Ziele und vorallem Nutzen. Anforderungen sind definiert als:

• Eine Eigenschaft oder Bedingung, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
• Eine Eigenschaft oder Bedingung, die ein System oder eine Systemkomponente erfüllen muss, um einen Vertrag, eine Norm oder andere, formell vorgegebene Dokumente zu erfüllen
• Eine dokumentierte Repräsentation einer Eigenschaft oder Bedingung wie in den ersten beiden Punkten beschrieben

Was ist Requirements Engineering?

Klaus Pohl und Chris Rupp definieren Requirement Engineering wie folgt:

Das Requirement Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

• Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.
• Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren sowie die Anforderungen zu spezifiszieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.

Sie identifizieren vier Haupttätigkeiten, die damit einhergehen: Ermitteln, Dokumentieren, Prüfen und abstimmen, Verwalten. Nachfolgend zähle ich wichtige Punkte aus der Praxis auf, um welche die Requirement Engineering Methode ergänzt werden muss, um sie zielgerichteter einsetzen zu können.

Software Requirements Engineering

Beide dargestellten Definitionen legen den Schwerpunkt des Requirement Engineering auf die Erfassung der Anforderungen auf oberster Ebene von allen Stakeholdern.

Es wird nicht klar ob nicht auch Requirement Engineering auf Software- und Hardware Ebene durchgeführt werden sollte, oder ob es sich ausschließlich auf System Ebene beschränkt. Christof Ebert spricht in seiner Defintion davon, dass Anforderungen Eigenschaften sind welche von Systemkomponenten erfüllt werden können. Allerdings wird ist dies eingeschränkt auf Eigenschaften/Bedingungen die in einem Vertrag, einer Norm oder anderer, formell vorgegebener Dokumente enthalten sind.

Alle 3 Bücher behandeln sehr ausführlich die Themen Requirements Ermitteln, Dokumentieren, Prüfen und abstimmen, Verwalten. Auch RE-Werkzeuge werden besprochen, sowie das Themen Soft-Skills und agiles Requirements Engineering

Der Fokus dabei ganz stark auf der Systemebene. Keines der Bücher bespricht das Thema Software Requirements Engineering und wie dieses im Bezug zum System Requirements Engineering steht.

Hardware Requirements Engineering

Hardware Requirements Engineering spielt in der Theorie gar keine Rolle. Das Thema wird bisher so gut wie vollständig in der Methodenentwicklung ignoriert. Bei der Entwicklung von Embedded Systemen ist die Fragen nach einer Hardware Requirement Engineering Methode offensichtlich. Die Vernetzung von Embedded Systemen und IT-Systemen steigert insgesamt die Systemkomplexität. Daher muss man die Requirement Engineering Methode um das Hardware Requirement Engineering ergänzen. Praxisprojekte zeigen mehr als deutlich, dass das Hardware Requirement Engineering dabei keine Kopie des Software- und System Requirement Engineering darstellt. HEICON hat hier eine Vielzahl von Erfahrungen gesammelt in den letzten Jahren, welche in die Hardware Requirement Engineering Methodenbeschreibung einfließen sollen.

Klare methodische Abgrenzung von Requirement und Architektur

Wenn man als Requirement Engineering nicht nur die Beschreibung auf Systemebene definiert, sondern auch die Software- und Hardwareebene mit einbezogen wird, dann wird klar, dass man auch eine methodisch definierte Abgrenzung zwischen Architektur und Requirements benötigt. Viele Projekte in der Praxis die ich den letzten Jahren begleiten durfte, leiden darunter, dass es diese Abgrenzung nicht in ausreichendem Maße gibt. Die Bücher von Christof Ebert, Klaus Pohl und Chris Rupp, definieren richtigerweise die Architektur als die Umsetzung des „Wie“ eines Produktes. Da Requirements Engineering als die Beschreibung des „Was“ eines Produktes auf Systemebene gesehen werden, ist die Abgrenzung erstmal eindeutig.

Wenn man aber auch das Requirement Engineering auf Hardware- und Software Ebene ausdehnt, wird schnell deutlich, dass man eine saubere Abgrenzung benötigt. Aus meiner Erfahrung sollen Software- und Hardware Requirement das „Was“ eines Produktes für die zu beschreibende Komponente definieren. Wenn man hier weiter denkt kommt man auch zur Klärung der Frage, in welcher Form Requirement dokumentiert werden. Es entstehen klare und nachvollziehbare Regeln, was in Textform und was mit grafischen Mitteln dargestellt wird. Auch diese Praxiserfahrungen werden hier zu einer Präzisierung des Requirements Engineering beitragen.

Hardware/Software Schnittstellen Requirement

Schnittstellen werden in allen 3 genannten Büchern nur als die äußeren Schnittstellen eines Systems verstanden. Sie stellen die Systemgrenzen dar. Dies ist richtig. Schon auf dieser Ebene (Systemebene!) stellt sich aber in der Praxis die Frage, wie Schnittstellen Requirements zu behandeln sind. Wie formuliert man sie? Wo genau verläuft die Grenze zwischen der Funktionalität und der Schnittstelle im Requirement Engineering?

In der Praxis wird das Thema noch viel komplexer, wenn man vor der Aufgabe steht Hardware-/Software Schnittstellen zu dokumentieren. Zum einen gibt es in einem Embedded System sehr viele dieser Schnittstellen, zum anderen gibt es Datenblätter, welche diese Schnittstellen beschreiben. Reichen die Datenblätter aus oder muss das Requirement Engineering noch tätig werden? Wenn ja, was genau muss gemacht werden? Auch für dieses Thema ist es wichtig, dass man die Requirement Engineering Methode so ergänzt, dass die gemachten Praxiserfahrungen für einen breiten Anwenderkreis zur Verfügung gestellt werden können.

Use Cases als Hilfsmittel bei Requirements Ermittlung auf Systemebene

Die Bücher zum Requirements Engineering beschreiben das Ermitteln von Requirements sehr ausführlich. Die Autoren beleuchten viele Techniken, wie Interviews, 6-3-5 Methode, Use Cases und viele weitere. Meine Praxiserfahrung zeigt auch, dass jede Technik in einer jeweils passenden Situation Ihre Berechtigung hat.

Allerdings ergibt meine Praxiserfahrung auch, dass viele Anwender mit der Vielzahl der Techniken häufig überfordert sind. Es wird nicht klar, in welcher Reihenfolge die Techniken zum Einsatz kommen sollen und welche Technik wichtiger ist als andere.

Für die Mehrzahl der Projekte macht es z.B: Sinn zunächst recht allgemeine Use Cases zu erstellen, mit dem Ziel möglichst alle wichtigen Themen einer zu erstellenden Spezifikation zu erfassen. Eine grafische Darstellung der Use Cases eignet sich hier ausgezeichnet. Mit einer ersten Version dieser Use Cases können dann Interviews und Workshops mit allen Stakeholdern durchgeführt werden. Dabei erfasst man dann Details zu den Use Cases und vervollständigt die Use Cases. Mit diesen Informationen lassen sich dann erste Requirements formulieren. Die erstellten Requirements werden dann einem Review unterzogen. Nach dem Review sind dann meist schon verifizierbare Requirements vorhanden. Damit ist in vielen Projekten, auf sehr effektive Art und Weise eine Wichtige Aufgabe des Requirements Engineering erfüllt. HEICON wird dieses Basiskonzept auch weiter ausarbeiten, um zukünftig in der Praxis anwendbare Leitfäden zu erhalten.

Fazit

Im vorliegenden Artikel wurden folgende Lücken zwischen der dokumentierten Requirements Engineering Methode und den Anforderungen in der Praxis aufgezeigt:

• Etablierung des Software Requirement Engineering zusätzlich zum System Requirement Engineering
• Definition der Besonderheiten des Hardware Requirement Engineering
• Fehlende Leitlinien zu der klaren Abgrenzung zwischen Requirements und Architektur
• Fehlende Leitlinien zur Behandlung von Schnittstellen Requirements im Allgemeinen und Hardware-/Software Schnittstellen Requirements im Besonderen
• Praxisleitfaden zur Vorgehensweise bei der Ermittlung von Requirements

Die Punkte sind nicht vollständig. Das ganze Thema Traceability Strategie habe ich zum Beispiel ganz ausgeblendet. Der Beitrag zeigt auf, dass für die meisten angesprochenen Punkte Lösungen vorhanden sind. Was fehlt ist dieses Wissen in der Breite zur Verfügung zu stellen und damit das Requirements Engineering 2.0 zu verwirklichen. Die Megatrends unserer Zeit wie Industrie 4.0, Smart Home oder autonomes Fahren benötigten dringend ein effektives Requirement Engineering! Gleches gilt übrigens für die schnelle, nachhaltige und sichere Entwicklung von technischen Lösungen um Covid-19 mit der modernen Medizintechnik zu besiegen!

Weitere HEICON Blog Beiträge zum Thema

• Requirement Engineering – Aspekte die schon in der Theorie zu kurz kommen!
• Requirement Engineering für Embedded- und IT-Systeme – Es wird Zeit das sich die Embedded Community der Unterschiede bewusst wird!
• Requirement- und Test Traceability – Mit Köpfchen!
• User Stories – Die besseren Requirements?
• Requirement/Code Review – Das bessere TDD?
• Wieviel Requirement Ebenen braucht man in der FuSi
• Requirements Reviews aus wirtschaftlicher Sicht betrachtet!
• Dokumentieren Sie noch oder spezifizieren Sie schon?
• Die Herausforderung Nicht-Funktionale Requirements!
• Kategorien von Requirements – Warum sind sie sinnvoll?

Ihre individuellen Fragen zum Requirements Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).