Requirements Engineering

von | Mai 23, 2022

Requirements Engineering

– Wie sich schon aus dem Namen ableiten lässt, geht es beim Requirements Engineering um die Ermittlung von Anforderungen. Genauer gesagt: Anforderungen an Software, Systeme oder Produkte sollen spezifiziert und verwaltet werden.

Wie wichtig Requirements Engineering in der Entwicklung ist, wird bei der Betrachtung der Fehlerentstehungskurve im Produktlebenszyklus deutlich. Denn ca. 56% der Fehler entstehen bereits in der Spezifikationsphase. Welche Folgen dies haben kann, ist auf unserer Seite Qualitätssicherung detaillierter beschrieben.

Die Anforderungen, die an ein System oder Produkt gestellt werden, bilden die Basis für den Entwicklungsprozess. Herausfordernd bei der Spezifikationsentwicklung ist das Zusammenführen von Informationen aus einer Vielzahl verschiedener Bereiche. Die Berücksichtigung von Kundenbedürfnissen, Kosten, Qualität, Nachfrage, Serviceleistungen, rechtlicher Aspekte – nur um hier einige zu nennen – erhöhen die Komplexität bei der Anforderungsermittlung.

Aufgaben im Requirements Engineering

Nach dem International Requirements Engineering Board (IREB) werden die folgenden vier Aufgaben als Hauptaufgaben genannt:

    • Anforderungsermittlung
    • Anforderungsdokumentation
    • Anforderungsvalidierung
    • Anforderungsverwaltung

Methoden und Techniken zur Anforderungsermittlung

Zunächst müssen die Quellen zur Anforderungsermittlung identifiziert werden. Diese könnten u.a. Stakeholder, Dokumente oder Systeme sein. Gleichzeitig ist es wichtig bei allen beteiligten Personen ein gemeinsames Verständnis über das zu entwickelnde System zu schaffen. Begriffe, die das System definieren, müssen eindeutig sein und den Stakeholdern, Entwicklern und Requirements Engineers bekannt sein. Durch die Erstellung von z.B. Glossaren kann eine gemeinsame Wissensbasis geschaffen werden.

In der Phase der Anforderungserhebung kommen verschiedene Techniken und Methoden zum Einsatz. Ein geeignetes Modell, um zunächst die Relevanz einer Anforderung zu identifizieren, ist das KANO-Modell. Es stellt den Erfüllungsgrad von Anforderungen zur Kundenzufriedenheit in Relation. In diesem werden Systemmerkmale beschrieben, die beim Stakeholder Begeisterung auslösen oder nur als selbstverständlich betrachtet werden.

    • Basisfaktoren: Systemmerkmale, die vom Stakeholder vorausgesetzt werden.
    • Leistungsfaktoren: Systemmerkmale, die explizit vom Stakeholder gefordert werden.
    • Begeisterungsfaktoren: Systemmerkmale, die vom Stakeholder nicht erwartet wurden, aber zu Begeisterung führen.
Auf der x-Achse ist der Erfüllungsgrad und auf der y-Achse, die Kundenzufridenheit aufgetragen. Die Kurven und Geraden stellen die Begeisterungs-, Leistungs- und Basismerkmale dar.

Werden Basisfaktoren nur unzureichend erfüllt, führt dies zu einer sehr viel höheren Unzufriedenheit beim Stakeholder. Werden die Basisfaktoren hingegen sehr gut erfüllt, hat dies jedoch keinen großen Einfluss auf die Zufriedenheit des Stakeholders. Werden Begeisterungsfaktoren nicht ausreichend erfüllt, wird dies vom Stakeholder hingegen weniger abgestraft. Dafür führt die Erfüllung der Begeisterungsfaktoren zu einer überproportionalen Kundenzufriedenheit. Der Erfüllungsgrad der Leistungsmerkmale hingegen wirkt sich hingegen proportional auf die Kundenzufriedenheit aus.

Ermittlungstechniken werden allgemein in Erhebungstechniken und in Entwurfs- und Ideenfindungstechniken unterschieden.

Nach dem IREB kann zur Erhebung von Anforderungen u.a. auf Interviews, Fragebögen, Workshops, Feldbeobachtung, Feedbackanalyse und weiteren Techniken zurückgegriffen werden. Einige Methoden, die sich zum Entwurf und zur Ideenfindung sehr gut eignen sind Brainstorming, die Erstellung von Storyboards oder Prototypen und Design Thinking.

Es existieren jedoch noch viele weitere Methoden und Techniken, die je nach Anwendungsfall individuell zusammengestellt werden müssen.

Dokumentation der Anforderungen

Die Ergebnisse aus der Anforderungsermittlung werden in natürlicher Sprache, in Modellen oder als Mischform festgehalten. Für die verschiedenen Anforderungen, die in der Struktur-, Funktions- und Verhaltensperspektive betrachtet werden können, eignen sich verschiedene Modelle:

    • Strukturperspektive: Es werden Ein- und Ausgabedaten sowie Nutzungs- und Abhängigkeitsbeziehungen betrachtet. Geeignete Modelle sind hier UML-Aktivitätsdiagramme und ER-Diagramme.
    • Funktionsperspektive: Es wird erfasst, welche Informationen durch das System geändert werden. Zur Darstellung eignen sich UML-Aktivitätsdiagramme und Datenflussdiagramme.
    • Verhaltensperspektive: Es werden Zustandsänderungen und ihre Effekte dokumentiert. Diese lassen sich in UML-Zustandsdiagrammen und Statecharts modellieren.

UML-Zustandsdiagramm

Im nachfolgenden Bild ist ein UML-Zustandsdiagramm an einem vereinfachten Beispiel der EC-Kartenzahlung dargestellt.
Das Diagramm besteht in diesem Beispiel aus Zuständen, Pseudozuständen (Start- und Endzustand, Entscheidungsknoten) und Transitionen.
Das Diagramm beginnt mit dem Startzustand (Punkt). Die Karte wird zunächst in das Kartenlesegerät eingesteckt. Dies stellt die erste Transition im Diagramm dar (Pfeil). Als Zustand (Rechteck mit abgerundeten Ecken) folgt, dass die Karte im Kartenlesegerät eingesteckt ist. Danach wird die PIN eingegeben und es folgt ein Entscheidungsknoten. Ist die PIN nicht korrekt so folgt der Zustand “PIN-Eingabe nicht erfolgreich”, bei korrekter PIN folgt der Zustand “PIN-Eingabe erfolgreich”. Nach der erfolgreichen PIN-Eingabe wird die Verbindung zum Server der entsprechenden Bank aufgebaut und der Kontostand mit dem Zahlungsbetrag abgeglichen. Ist das Konto ausreichend gedeckt, wird die Zahlung autorisiert und die Ware kann bezahlt werden. Das Diagramm ist mit dem Endzustand (umrandeter Punkt) abgeschlossen.

Qualitätskriterien für Anforderungen

Wie bereits deutlich geworden ist, sollten Anforderungen im Allgemeinen gut beschrieben sein und damit bestimmte Qualitätskriterien erfüllen. Das IREB führt die folgenden Qualitätskriterien für Einzelanforderungen auf:

    • Adäquat: Die Anforderung reflektiert Bedürfnisse der Stakeholder.
    • Notwendig: Die Anforderung trägt dazu bei, einen Bedarf der Stakeholder zu decken.
    • Eindeutig: Die Anforderung wird von allen Stakeholdern gleich interpretiert.
    • Vollständig: Die Anforderung beschreibt die Funktionalität lückenlos.
    • Verständlich: Die Anforderung ist so beschrieben, dass alle Stakeholder diese verstehen.
    • Überprüfbar: Die Erfüllung der Anforderung ist eindeutig überprüfbar.

Validierung der Anforderungen

Um sicherzustellen, dass die Anforderungen korrekt und von den Stakeholdern auch als notwendig angesehen werden, erfolgt die Validierung der ermittelten Anforderungen. Das IREB schlägt die folgenden vier Prinzipien zur Anforderungsprüfung vor:

    • Beteiligung der Stakeholder
    • Trennung von Fehlererkennung und Fehlerkorrektur
    • Validierung aus unterschiedlichen Sichten
    • Wiederholte Validierung

Techniken, die zur Validierung zum Einsatz kommen sind:

    • Review Techniken
    • Explorationstechniken
    • Probe-Entwicklung

Die Auswahl der Techniken ist abhängig vom Entwicklungsprozess, der Systemkomplexität, als auch vom Risikoniveau.

Verwaltung der Anforderungen

Das Verwalten der Anforderungen läuft parallel zur Anforderungsermittlung, -dokumentation und -validierung. Wesentliche Bestandteile sind die Änderungssteuerung, Versionskontrolle, Überwachung des Anforderungsstatus und die Anforderungsrückverfolgung.

    • Änderungssteuerung: Anforderungsdokumente und Pläne werden aktualisiert, Auswirkungen analysiert und Änderungen vorgeschlagen.
    • Versionskontrolle: Diese zeichnet sich durch die Identifikation von Versionsänderungen der Anforderungsdokumente aus. Es wird ein einheitliches Kennzeichnungsschema für die Änderungen festgelegt.
    • Überwachung des Anforderungsstatus: Es werden Berichte erstell und der Status der Anforderung erfasst.
    • Anforderungsrückverfolgung: Es werden Verknüpfungen zu anderen Systemelementen und Anforderungen definiert.

Wie schon erwähnt, entstehen die meisten Fehler in der Softwareentwicklung bereits in der Spezifikationsphase. Fehler, die schon früh in der Entwicklungsphase entstanden sind, verursachen erhebliche Kosten für die Fehlerbehebung. Darüber hinaus sinkt die Zufriedenheit der Stakeholder durch die entstandenen Fehler und die Nichterfüllung von Anforderungen. Durch Requirements Engineering ist es möglich, Fehler frühzeitig zu erkennen und alle Stakeholder in der Entwicklung einzubeziehen. Es bildet somit die Grundvoraussetzung für effiziente Softwareentwicklung.

Artikel, die Sie auch interessieren könnten:

Weitere Artikel finden Sie in unserem IT-Blog.