Serie „Requirements Engineering für KMU“ – Teil 6 Requirements Engineering – Formulierung guter Requirements

Von Stefan Lange und Moises Lorenzo-Leon* 4 min Lesedauer

Anbieter zum Thema

Die korrekte, konsistente und vollständige Formulierung der Anforderungen ist für die Entwicklung des Endprodukts von entscheidender Bedeutung. Sie stellt sicher, dass alle Ziele, Anforderungen und Erwartungen der verschiedenen Interessengruppen präzise beschrieben, verständlich und eindeutig sind und nicht unterschiedlich interpretiert werden können. Zu diesem Zweck gibt es verschiedene Techniken, die helfen können, die Anforderungen korrekt zu formulieren.

Gegenüberstellende Übersicht über "gute" und "schlechte" Anforderungen im Requirements Engineering.(Bild:  Heitec)
Gegenüberstellende Übersicht über "gute" und "schlechte" Anforderungen im Requirements Engineering.
(Bild: Heitec)

Anforderungen in natürlicher Sprache

Anforderungen können in natürlicher Sprache geschrieben werden, was eine sehr flexible Formulierung von Anforderungen ermöglicht und für alle Arten von Anforderungen geeignet ist. Der Nachteil dabei ist, dass die natürliche Sprache oft mehrdeutig ist oder Auslassungen enthält, die in der Überprüfungsphase schwer zu identifizieren sind. Damit derart formulierte Anforderungen dennoch effektiv sind, müssen sie kurz, präzise, gut strukturiert und widerspruchsfrei sein sowie eine einheitliche Terminologie aufweisen. Unspezifische oder unvollständige Sätze sowie Universalquantoren wie“ alle, immer, keine, nie“ sind zu vermeiden. Weitere „DONTS“ sind weiter unten in diesem Artikel aufgeführt.

Anforderungsmuster / Vorlagen (Templates)

Eine bessere Möglichkeit, Anforderungen zu schreiben, ist die Verwendung von Mustern oder Vorlagen. Dabei handelt es sich um vordefinierte Sätze, die in ihrer Struktur die Formulierung qualitativ hochwertiger Anforderungen unterstützen. Die Vorteile hierbei liegen in der Reduktion von Spracheffekten, der syntaktischen Eindeutigkeit und der hohen, bewährten Qualität bei vergleichsweise geringem Aufwand.

Für das Schreiben einzelner Anforderungen wurden in der Literatur verschiedene Formulierungsvorlagen definiert. Eine hiervon ist folgende Vorlage für individuelle Anforderungen:

[<Bedingung>] <Gegenstand> <Aktion> <Objekte> [<Einschränkung>] Hier demonstriert am Beispiel eines Bankautomaten:

Wird eine gültige Karte erkannt, muss das System innerhalb von 200 ms die Meldung „Geben Sie Ihre PIN ein“ auf dem Dialogbildschirm anzeigen.

Definition einer Verbindlichkeit

Jede Anforderung muss ein Verb enthalten, das die Verbindlichkeit der Anforderung anzeigt. Diese Verben sind normiert und immer identisch zu verwenden:

  • „Muss“ (engl. „shall“): Bei diesen Anforderungen handelt es sich um zwingende, verbindliche Bestimmungen.
  • „Sollte“ (engl. „should“): Erwünschte, unverbindliche Bestimmungen wie Vorlieben oder Ziele werden im Konjunktiv mit „sollte“ formuliert.
  • „Kann“ (engl. „may“): Vorschläge oder Erlaubtes sind ebenfalls unverbindliche, nichtbindende Bestimmungen und verwenden das Verb „können“.

Ungünstige Praktiken bei der Anforderungsformulierung

Bei der Formulierung der Anforderungen gibt es ungünstige Praktiken, die vermieden werden sollten, um die positiven Effekte des Requirements-Engineerings zur vollständig zu nutzen. Einige der wichtigsten davon sind hier aufgeführt:

Inkonsistenzen zwischen Anforderungen

Bei der Formulierung der Anforderungen besteht die Möglichkeit, dass zwei Anforderungen nicht miteinander vereinbar sind, oder die natürlichsprachliche Formulierung nicht mit einer modellbasierten übereinstimmt. Daher müssen die Anforderungen analysiert und miteinander abgeglichen werden.

Anforderungen, die nicht zu realisieren sind

Während der Formulierung der Anforderungen darf die Machbarkeit und die Möglichkeit der Umsetzung nicht aus den Augen verloren werden. In dieser Phase sollten die Stakeholder eine realistische Umsetzung ihres Produkts anstreben, wobei Konflikte als Folge unterschiedlicher Erwartungen entstehen können.

Anforderungen, gegen die nicht verifiziert werden kann

Artefakte, die während des Entwicklungsprozesses entstehen (Spezifikationen, Schaltpläne, Konstruktionszeichnungen), spätestens aber ein Muster des Produkts muss gegen die Anforderungen verifiziert werden, um sicherzustellen, dass die Anforderungen erfüllt sind. Dies kann durch Aktivitäten wie Review oder Tests erfolgen. Sind die Anforderungen fälschlicherweise so formuliert, dass gegen sie nicht z.B. durch einen Test verifiziert werden kann, kann dies zu Unstimmigkeiten zwischen den Projektparteien führen. Im schlimmsten Fall müssen Anforderungen neu formuliert und Teile der Entwicklung wiederholt werden. Das Thema Verifizierung wird dediziert noch einmal in einem späteren Artikel dieser Serie behandelt.

Nicht-Atomarität von Anforderungen

Eine leider immer noch stark verbreitete „Sünde“ ist es, mehrere Anforderungen in einem Anforderungs-Statement unterzubringen. Die Vorteile liegen zunächst auf der Hand: weniger Anforderungen, weniger Pflegeaufwand, schnelleres Vorankommen. Die Probleme dieser nicht-atomaren (nicht-eigenständigen) Anforderungen treten jedoch später im Entwicklungsprozess auf, wenn das Produkt gegen die Anforderungen verifiziert werden muss: Testfälle müssen erstellt werden. Wenn nun mehrere Anforderungen in einem Anforderungs-Statement enthalten sind, müssen mehrere Testfälle dieser Anforderung zugeordnet und deren Erfüllung geprüft werden. Mapping und Nachvollziehbarkeit sorgen für deutlichen Mehraufwand und erhöhte Komplexität.

Konzentration auf nur eine Formulierungsstrategie

Wird nur eine Formulierungsstrategie verwendet (z. B. nur natürliche Sprache), kann dies zu Unvollständigkeit oder Ungenauigkeit der Anforderungen führen, was später eine fehlerhafte Entwicklung des Produkts zur Folge hat. Idealerweise sollten alle verfügbaren Werkzeuge wie z. B. auch Modelle genutzt werden, um die Anforderungen so klar wie möglich zu formulieren. Diese werden im nächsten Teil der Serie behandelt.

Keine Nachvollziehbarkeit der Anforderungen

Um sicherzustellen, dass die Anforderungen einen Mehrwert bieten und auch um in regulierten Märkten konform zu normativen Vorgaben zu sein, müssen sie in allen Phasen der Entwicklung nachvollziehbar („traceable“) sein. Das bedeutet, für eine Entwicklung nach dem V-Modell müssen die Anforderungen durch den Entwurf, die Implementierung und die Verifikation verfolgt werden, um sicherzustellen, dass sie in allen relevanten Artefakten enthalten sind. Ein Werkzeug wie eine Requirements Traceability Matrix oder spezielle Software-Tools für das Requirements-Engineering müssen die Rückverfolgbarkeit der Anforderungen über den gesamten Lebenszyklus des Produkts hinweg ermöglichen.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Neben der Formulierung von Anforderungen in Sprache spielen aber auch modellbasierte Anforderungen eine immer stärkere Rolle. Diese werden im nächsten Teil der Serie betrachtet, seien Sie dabei!  (sg)

Literaturverweise

IREB (2022). Certified Professional for Requirements Engineering - Foundation Level - Handbuch (1.2.0). IREB e.V.

ISO/IEC/IEEE 29148:2018. Systems and software engineering - Life cycle processes - Requirements engineering

Alistair Mavin, Philip Wilkinson, Adrian Harwood, and Mark Novak (2009). Easy Approach to Requirements Syntax (EARS). 17th IEEE International Requirements Engineering Conference (RE'09). Atlanta, Georgia

C. Rupp (2021). Requirements Engineering und Management (7. Auflage). Hanser

* Stefan Lange ist Teamleiter Systems Engineering im HEITEC Geschäftsgebiet Elektronik und Dozent für Systems Engineering an der Hochschule Augsburg.

* Moises Lorenzo-Leon ist Systemingenieur im HEITEC Geschäftsgebiet Elektronik und Certified Professional für Requirements Engineering.

(ID:50643246)